Technology notes,
without exposing the internals.
This page explains the public integration model and the current platform boundaries. Protocol layouts, certificate structures, internal key derivation details and operational secrets are intentionally not published here.
1. What SupportSDK provides
SupportSDK is a managed hardware-backed security layer for software vendors. A local Windows service performs TPM-related work and exposes a small application-facing interface. The software product asks for a named, scoped capability instead of directly implementing TPM commands, hardware enrollment and lifecycle logic.
Hardware identity
An installation is enrolled against a real TPM 2.0 device and receives a unique technical identity.
Protected capability
The product receives only the derived local capability required for its selected operation.
Managed lifecycle
Enrollment, binding, renewal, revocation and audited re-enrollment are coordinated by the platform.
Local daily operation
After enrollment, normal protected operations do not require a permanent cloud connection.
2. High-level application flow
Enroll the installation
The local agent establishes a hardware-backed installation identity and proves possession of TPM-protected keys.
Bind the product
The installation is authorized for a product deployment and the applicable capability policy.
Request a capability
The software requests the specific protected context needed by a feature such as local database encryption, signing or device-bound internal state.
Use it inside a real workflow
The capability becomes part of the product's normal data path. This replaces a single Boolean decision with a dependency that must be understood and reconstructed across the application.
3. What the TPM does—and does not do
The TPM protects the root of the key hierarchy and allows hardware-bound operations. A derived application key may still exist temporarily in process memory when the application must perform software encryption. SupportSDK therefore does not claim that runtime secrets are impossible to inspect on a fully compromised machine.
The realistic protection goal is to prevent normal copying, simple hardware cloning and basic licence-flag patching, while increasing the cost of reverse engineering to a structural attack on the authorized process or integration.
4. Current SupportRMM reference implementation
SupportRMM uses a TPM-derived capability for AES-256-GCM protection of volatile monitoring data such as runtime snapshots, resource history, event information and other rebuildable telemetry.
- The data itself is not treated as irreplaceable durable content.
- If the hardware identity changes, encrypted volatile data can be reset and rebuilt.
- The protected flow makes application operation depend on the valid hardware-backed installation rather than only a licence Boolean.
- Normal operation remains local after enrollment.
5. Current public boundaries
The current platform does not yet offer public third-party onboarding, a neutral vendor SDK, self-service product registration or durable-data recovery. These components will be introduced only after the security model, authorization boundary and operational redundancy are consolidated.
SupportSDK does not currently promise migration of old TPM private keys or automatic recovery of durable encrypted content. Re-enrollment creates a new hardware identity.
6. Integration suitability
The current design is most suitable for Windows software that can make selected operations depend on a local hardware-backed capability. Examples include application state, licensing dependencies, local field encryption, signed internal actions or controlled device identity.
Any use case involving irreplaceable documents or long-term encrypted archives requires a separate recovery and redundancy design. It must not be treated as equivalent to the current volatile SupportRMM data model.