Keep the key in hardware
The service sends a signing or decryption operation through the provider path; the HSM retains the private key.
SERVICE IDENTITIES & HSM
The cryptographic request moves. The private key does not.
Not only users but also the services behind x.ID need protected keys. x.ID stores sensitive secrets encrypted in SQL Server or PostgreSQL. An HSM can protect the private key of the protection certificate and other service keys.
VALUE IN 30 SECONDS
Service identities deserve the same control as user identities.
Keep ownership visible
Each Management Key and PUK is individual. These secrets are not derived across users.
Keep providers replaceable
The architecture distinguishes Windows CNG, provider KSP and HSM-specific paths instead of hiding them behind an undefined “HSM” label.
WINDOWS APPLICATION TO HARDWARE
What happens between an mTLS application and the HSM?
The certificate can be visible to Windows while the private key remains non-exportable in hardware. Understanding the interfaces makes operation, troubleshooting and provider changes controllable.
-
01
The application starts an authenticated connection
A Windows service or .NET application requests TLS or mTLS with a selected certificate and identity context.
-
02
Schannel uses Windows CNG
The Windows security stack resolves the certificate and requests the required cryptographic operation through the configured key provider path.
-
03
NCrypt addresses the persisted key
Windows identifies the private-key object through its Key Storage Provider instead of reading an exportable key file.
-
04
The provider KSP sends the operation to the HSM
The appropriate Utimaco, Thales Luna, YubiHSM 2 or keyONE NetHSM provider path translates the Windows request for its hardware target.
-
05
The HSM performs the private-key operation
Signing or decryption happens inside the protected hardware boundary and only the result returns to the application path.
-
06
x.ID keeps lifecycle and identity context connected
The service, certificate, key location, provider and policy remain visible so renewal or migration does not become an undocumented manual handover.
THE ARCHITECTURE AT A GLANCE
Windows and the KSP carry the operation—the HSM protects the private key.
TECHNICAL DEPTH
The Windows interfaces have different jobs.
Using the precise terms prevents false assumptions during troubleshooting, migration and security review.
- Schannel
- Schannel is the Windows TLS security package used by many .NET and Windows HTTP workloads. It coordinates certificate-based TLS authentication and calls the required cryptographic interfaces.
- BCrypt
- BCrypt is the CNG primitive layer commonly used for algorithms, hashing, symmetric cryptography and low-level cryptographic operations. It is not the persisted private-key store.
- NCrypt
- NCrypt exposes persisted key operations and Key Storage Providers. The application or Schannel can address a key whose private material remains behind the configured KSP.
- KSP and HSM
- A Key Storage Provider connects the Windows key abstraction to the vendor or integration-specific HSM interface. The HSM then enforces hardware storage, authorization and non-exportability policy.
- Service identity
- The account or workload using the certificate remains an accountable lifecycle object. gMSA can manage a Windows service account; mTLS and HSM-backed keys protect the service-to-service trust path.
- Encrypted application secrets
- Management Keys, PUKs and other sensitive credentials are encrypted in the database. With an HSM, the authorized x.ID Core uses the private key protected there. Database access alone is insufficient to decrypt them. Core, operating-system and HSM permissions still require protection.
EVIDENCE & BOUNDARIES
Supported provider paths remain explicit.
Each HSM integration has its own provider, authentication and operating requirements. x.ID makes the shared lifecycle visible without pretending the providers are identical.
Utimaco HSM reference path
Windows CNG and the Utimaco KSP provide a concrete reference path from application request to hardware-protected private-key operation.
Thales Luna HSM
Thales Luna provider and partition concepts can participate in the same controlled certificate and service-identity lifecycle.
Yubico YubiHSM 2
YubiHSM 2 can protect service and infrastructure keys through its supported provider and integration path.
Nitrokey NetHSM native CNG path
Provided on request. Windows CNG → keyONE NetHSM CNG KSP → keyONE Agent → Nitrokey NetHSM.
RELATED PRODUCT
SYNRION x.ID
Manage YubiKeys, identities, PIV certificates and FIDO2 centrally in a browser. SYNRION x.ID combines native Entra integration with cloud, on-premises or hybrid deployment through Outpost connectors. The portal also supports mobile access; the feature overview states release status and requirements.
THE NEXT CONTROLLED STEP
Trace one real service certificate from application to HSM.
We will map the Windows stack, provider, HSM, CA, service account, lifecycle and recovery path so every responsibility is visible.