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.
SYNRION x.ID connects accountable service identities, certificate lifecycle and policy with hardware-protected key paths for Utimaco, Thales Luna, Yubico YubiHSM 2 and Nitrokey NetHSM.
VALUE IN 30 SECONDS
Service identities deserve the same control as user identities.
Keep ownership visible
Service, account, certificate, application, key provider and lifecycle state remain explicitly related.
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
The operation travels through Windows and the provider path to the HSM. The private key remains inside the hardware protection boundary.
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.
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
Windows CNG → keyONE NetHSM CNG KSP → keyONE Agent → Nitrokey NetHSM.
RELATED PRODUCT
SYNRION x.ID
SYNRION x.ID combines verified primary identities, authentic hardware and independent policy enforcement into one reliable trust decision.
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.