SC.L2-3.13.10Key Management
Establish and manage cryptographic keys for cryptography employed in organizational systems.
[a]
cryptographic keys are established whenever cryptography is employed; and[b]
cryptographic keys are managed whenever cryptography is employed.
Keys born in HSM-backed vaults; escrow, rotation, and revocation are all ticketed events
Implementation
AO coverage. Addresses both Key Management objectives: keys are established and keys are managed wherever cryptography is employed.
Key inventory. One register lists every key and certificate class in use: endpoint FDE volume keys and their recovery keys, storage encryption keys, TLS server certificates, the B2B mutual TLS client certificate, SFTP SSH key pairs, code and script signing certificates, the internal CA's own keys, and the backup encryption key. Each row carries owner, generation method, storage location, rotation period, and revocation procedure. A cryptographic use with no register row is treated as a finding.
Establishment [a]. Keys are generated inside the boundary that will protect them: HSM-backed vault keys are created non-exportable in the vault, FDE keys are generated on the endpoint's TPM, and SSH key pairs are generated on the host that will use them with the private half never leaving it. Nobody emails a private key or pastes one into a ticket. Certificates come from the internal CA using approved templates that fix key length, algorithm, and lifetime, so an operator cannot accidentally issue a weak certificate.
Storage and escrow [b]. Private keys live in the HSM-backed vault, on the TPM, or in the secrets manager — never in source control, never in a share, never in a wiki. BitLocker recovery keys escrow automatically to the directory and are readable only by the recovery role, with each read logged and reviewed. The internal CA's key is offline for the root with an online issuing tier, and the root's activation material is under dual custody.
Rotation and revocation [b]. Rotation periods are per class: TLS certificates on the shortest lifetime the platform supports with automated renewal, SFTP keys annually, storage keys annually or immediately on suspicion, signing certificates per their template. Revocation is a documented runbook with an owner: revoke, publish the CRL/OCSP update, reissue, confirm the dependent system reloaded. Offboarding a person or decommissioning a host triggers revocation of their keys the same day. Access to the vault's key-use permissions is separated from access to its administrative permissions, so no single role can both use and silently replace a key.
Maintenance. Weekly expiry report at 60, 30, and 7 days so a certificate outage never becomes the reason for a rushed insecure workaround. Quarterly reconciliation of the register against the vaults and the CA's issued-certificate list. Annual dry run of the revocation runbook on a non-production key.
Accepted gap. One legacy appliance stores its TLS private key locally and offers no HSM or vault integration. The key is generated on the appliance, its filesystem access is restricted, the appliance is management-VLAN only, and rotation is a manual quarterly checklist item until it is replaced.
What the evidence looks like
- Key and certificate register with owner, generation method, storage, and rotation period
- Vault configuration showing non-exportable HSM-backed keys and separated use/admin roles
- CA certificate templates fixing algorithm, key length, and lifetime
- Recovery key escrow configuration plus an audited recovery-key read
- Completed revocation runbook from a real offboarding or host decommission
Environment
Tools
Was this example useful?
Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.
Discussion(0)
No discussion on this example yet
Verdicts capture a conclusion. Use a thread when the interesting part is the argument.
Sign in to start a thread.