Skip to content
ControlVerdict
Sign in
SC.L2-3.13.10CMMC Level 2Level 2

Key Management

Submit your own example

Practice statement

Establish and manage cryptographic keys for cryptography employed in organizational systems.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.13.10.Source

The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.

Assessment Objectives(2)

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

  1. [a]

    cryptographic keys are established whenever cryptography is employed; and

    1 example covers this

  2. [b]

    cryptographic keys are managed whenever cryptography is employed.

    1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

Implementation examples(1)

Submit your own example
  • addresses
    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

    ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
    Community is just starting — add yours. No verdicts yet.

    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

    ~200-staff OSC using full-disk encryption, TLS certificates, SFTP SSH keys, and an internal issuing CA. Cloud workloads split between Azure and AWS.

    Tools

Discussion(0)

No discussion on this control yet

Edge cases, scoping questions, and “would this pass?” scenarios belong here.

Sign in to start a thread.