ASD ISM 1957 Hardware security module protection for Microsoft AD CS private keys
What it says
Private keys for Microsoft AD CS certification authority servers are protected by a hardware security module.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEvery Microsoft AD CS certification authority, root and subordinate alike, keeps its private key inside a hardware security module rather than on the Windows server itself.
Microsoft Active Directory Certificate Services (AD CS) is the certificate authority (CA) built into Windows Server. Each CA has a private key, and that key is what makes every certificate the CA issues trustworthy. Whoever holds that key can issue certificates that the whole domain trusts. This control requires that the private keys of your AD CS certification authority servers are protected by a hardware security module (HSM). An HSM is a tamper-resistant hardware device (a network appliance, PCIe card or cloud-hosted service) that holds cryptographic keys and performs signing operations internally, so the raw key material never has to leave the device. It applies to all AD CS certification authorities in scope, including offline root CAs and online issuing (subordinate) CAs, not just one of them. It matters because AD CS is tightly bound to identity. CA-issued certificates are used for smart-card and certificate-based logon, Kerberos PKINIT, LDAPS, VPN, Wi-Fi (802.1X) and code signing. A CA private key that lives in a software key store on a Windows server can be exported or copied by anyone who gains administrative access to that server. With an HSM, an attacker who fully compromises the CA server still cannot walk away with the key; at worst they can use it while they have access, which is far easier to detect, contain and recover from than a silently copied key.
Free. Save your status, tasks and notes.
Why it matters
If a CA private key is held in software on the Windows server, compromise of that server (or of a backup, snapshot or exported PFX) lets an attacker take a copy of the key and forge certificates at will. Forged certificates can be used for persistent domain-wide authentication as any user, including privileged accounts, and for intercepting or impersonating internal services. Because the key itself is copied rather than used in place, the attacker retains this capability even after the original intrusion is cleaned up, and the only remediation is to revoke and rebuild the affected CA hierarchy and reissue every certificate it ever signed, which is a costly and disruptive exercise for the whole organisation.
How to implement
Inventory owners: the PKI or platform team lists every AD CS certification authority in the environment (offline root CAs, policy CAs and online issuing CAs) and records for each which key storage provider currently holds its private key, so no CA is missed when moving to HSM protection.
HSM selection: the security architect chooses an HSM (network appliance, PCIe card or cloud HSM service) that ships a Cryptography Next Generation (CNG) key storage provider (KSP) supported on the Windows Server versions running AD CS, and verifies it against the vendor's AD CS integration guide before purchase.
New CA build: the PKI engineer installs the HSM client and KSP on the CA server, then in the AD CS role wizard (or with certutil/PowerShell) selects the HSM's KSP as the cryptographic provider so the CA key is generated inside the HSM from the start, and confirms with `certutil -store my` and `certutil -getreg ca\csp` that the key is HSM-backed.
Existing CA migration: for a CA whose key is already in software, the PKI engineer schedules a change window, imports the key into the HSM using the vendor's approved tooling (or, preferably, renews the CA with a new HSM-generated key), repoints the CA to the HSM KSP, restarts the CertSvc service and issues a test certificate and CRL to confirm signing works through the HSM.
Ongoing assurance: the PKI team adds an HSM health and connectivity check to CA monitoring, keeps HSM backups only in the vendor's protected backup format, and re-verifies after any HSM firmware update, CA renewal or CA server rebuild that the CA private key still resides in the HSM.
Keep it running
**Key placement.** The CA private key should sit in the HSM for the whole life of the CA. It is strongly recommended to generate the key inside the HSM at CA installation time rather than creating it in software first and importing it later, because a key that has ever existed in software may already have been copied. Where an existing CA key must be migrated into an HSM, treat the migration as a controlled change and consider whether the key's software history warrants a new key and CA renewal.
**Both root and subordinate CAs.** An offline root CA is often left in a software key store because "it is powered off most of the time". The control does not carve out that exception: root and issuing CA keys alike are in scope.
**HSM availability.** An online issuing CA cannot sign certificates or CRLs if it loses contact with a network HSM. Build in HSM redundancy, monitor connectivity, and know your CRL validity window so an HSM outage does not turn into an authentication outage.
**Key backup and recovery.** Keep backups of the HSM key material in the vendor's protected form (for example, wrapped backup tokens or a secured backup partition) and test restoration. Avoid creating plaintext or PFX copies of the CA key outside the HSM, as that would undo the protection the control provides.
**Separation of duties (recommended).** It is good practice for HSM administration to be held by different people, or protected by a quorum of smart cards or tokens, from those who administer the Windows CA. This is advisory rather than something the statement mandates, but it reduces the chance that a single compromised administrator account can both drive the CA and reconfigure the HSM.
**Change and life-cycle events.** CA key renewal, HSM firmware updates, HSM replacement and CA migrations to new hardware all touch the key. Plan these as controlled changes and confirm afterwards that the CA is still using the HSM-backed key.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the list of all Microsoft AD CS certification authorities in scope, including offline root CAs, and the key storage provider used by each.
Look at
Compare the inventory against Active Directory (for example the Enrollment Services and Certification Authorities containers, or `certutil -dump`) and any offline CA documentation to confirm no CA has been left out.
Good evidence
Every CA in the hierarchy, root and subordinate, appears in the inventory and each is recorded as using an HSM key storage provider.
- Check 2 of 5What an auditor asks for
Ask for
Ask an administrator to show the cryptographic provider configuration on each CA server.
Look at
Review the output of `certutil -getreg ca\csp` and `certutil -store my` on each CA, or the equivalent registry values, to see which provider holds the CA certificate's private key.
Good evidence
The provider is the HSM vendor's CNG key storage provider rather than the Microsoft Software Key Storage Provider, and the private key is reported as present through that provider.
- Check 3 of 5What an auditor asks for
Ask for
Ask for evidence from the HSM side that the CA key objects exist inside the HSM.
Look at
Inspect the HSM's management console or CLI listing of key objects for the partition assigned to AD CS, and match key labels or identifiers to the CA certificates.
Good evidence
Each CA's signing key is listed as a non-exportable key held within the HSM, with identifiers that correspond to the CA certificates in use.
- Check 4 of 5What an auditor asks for
Ask for
Ask how the CA keys were created and, for any migrated CA, how the key got into the HSM.
Look at
Review the CA build records or change tickets describing key generation or migration, and whether any software copies of the key were created along the way.
Good evidence
Keys were generated inside the HSM at build time, or, where migrated, the migration is documented and any remaining software or PFX copies have been accounted for. Note that HSM-only generation is a recommendation rather than a requirement of this control.
- Check 5 of 5What an auditor asks for
Ask for
Ask how HSM backups and HSM administration are handled for the CA keys.
Look at
Review the HSM backup procedure and who holds HSM administrative credentials or quorum tokens.
Good evidence
Backups are kept in the HSM vendor's protected format so the key is never exposed in plaintext. Separation between HSM administrators and Windows CA administrators is good practice and worth noting, but its absence does not by itself mean the control has failed.
Mappings
Closest match in ISO/IEC 27001: A.8.24, Effective use of cryptography and key management, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.24.
ISM-1957 requires Microsoft AD CS certification authority private keys to be protected by storing them in a hardware security module (HSM). This directly implements a strong form of cryptographic key protection and lifecycle control that Annex A 8.24 expects organisations to define and implement via cryptography and key management rules. Annex A 8.24 is broader and technology-agnostic (covering policies and management for all keys), while ISM-1957 is a specific technical requirement for a particular key type and platform.
ASD Essentials for enterprise IT: 1 mapping
- IT.PRO-13.2Store keys, secrets and tokens in approved, access-controlled repositories with MFAPartially overlaps
This control partially overlaps IT.PRO-13.2.
IT.PRO-13.2 requires authentication keys, secrets and tokens to be stored in approved secure repositories with access controls and MFA; ISM-1957 requires Microsoft AD CS certification authority private keys to be protected by a hardware security module, a narrower case for one key type.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.