Hello @Jack 5T
If the HSM entered an administrator/tamper lock state after detecting chassis intrusion, I wouldn't try to clear or bypass the lock through Windows, registry changes, or generic HSM commands.
The important distinction is that AD CS doesn't control the HSM's tamper state. The CA accesses its private key through the HSM's CSP/KSP interface, while the HSM itself is managed separately. Microsoft specifically recommends installing, configuring, backing up, and managing HSM-protected CA keys according to the HSM vendor's procedures.
Since the CA private key is required to sign a new CRL, losing access to that key would explain why CRL publication has stopped.
I would recommend:
- Keep the Root CA offline and don't initialize, reset, zeroize, or reconfigure the HSM.
- Review the HSM audit/security logs to determine exactly which tamper or chassis-intrusion condition triggered the lock.
- Follow the HSM manufacturer's documented tamper-recovery/admin-unlock procedure or open a case with the HSM vendor. Depending on the HSM, recovery may require security-officer credentials, quorum/key cards, backup restoration, or physical servicing.
- After the HSM is returned to an operational state, verify Windows can see the provider: certutil -csplist
certutil can enumerate the CSP/KSP providers available to Windows.
Then verify that the CA certificate still has access to its associated HSM-backed private key before starting normal CA operations.
I would strongly avoid deleting/reimporting the CA certificate or changing the CA's CSP/KSP configuration at this stage. If the HSM has genuinely entered a security/tamper state, those actions won't unlock the private key and could complicate recovery.
Microsoft also states that when an HSM protects the CA key, private-key backup and recovery procedures are HSM-vendor-specific.
Sharing these references with you:
Microsoft — PKI design considerations and HSMs
Microsoft — Migrate/backup a Certification Authority
If you can provide the HSM manufacturer/model and the exact lock/tamper message, we can determine the appropriate vendor-supported recovery path without risking the Root CA key.
Please "Accept the Answer" if this information helped you. This will help us and others in the community.