Cryptographic keys are high-value targets. SC.L2-3.13.10 requires that you manage keys securely throughout their lifecycle. Keys must be protected from unauthorized access and replaced periodically. This supports SC.L2-3.13.8 (encryption in transit) and SC.L2-3.13.11 (encryption at rest).
What the assessor is actually evaluating
The assessor will examine:
Key management policy: You should have a documented process for generating, storing, protecting, rotating, and retiring keys.
Key inventory: You should maintain a list of all cryptographic keys used for protecting CUI, including their purpose, storage location, and rotation date.
Key storage and access controls: Keys must be stored securely (e.g., in a hardware security module, key vault, or protected system). Access to keys must be restricted.
Key rotation: Keys should be replaced periodically (typically annually) or when an employee with key access leaves.
What a realistic SSP definition looks like
Policy: “The organization establishes and maintains a key management process. Keys are generated using cryptographically secure methods. Keys are stored in protected locations (hardware security modules or key vaults). Key access is restricted to authorized personnel only. Keys are rotated annually or when an employee with access leaves. Retired keys are securely destroyed.”
Supporting details:
- Key generation: Keys are generated on secure systems using approved algorithms (AES-256, RSA-2048, etc.).
- Key storage: Database encryption keys are stored in Azure Key Vault or similar HSM. TLS certificates and keys are stored on web servers with restricted file permissions.
- Key access: Only database administrators can access database keys. Only the web server process can access TLS keys. Access is logged.
- Key rotation: Database keys are rotated annually. TLS certificates are rotated before expiration. Records of rotation are maintained.
- Retirement: Old keys are retained for historical data decryption but are marked as retired and never used for encryption.
How to present your evidence
- Key management policy document: Describes the process for generating, storing, protecting, rotating, and retiring keys.
- Key inventory: A spreadsheet listing each cryptographic key, its purpose (encryption at rest, TLS, etc.), storage location, key size, rotation date, and owner.
- Key storage verification: Screenshots or documentation showing where keys are stored (Key Vault, HSM, protected directory) and access controls in place.
- Key rotation records: Documentation of key rotations from the past 1-2 years. Show the old key was retired and a new key was generated.
- Access logs: Logs showing who has accessed keys and when. Restrict access to authorized personnel only.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Assessor: “Describe your key management process. How do you protect cryptographic keys?”
You: “Keys are stored in Azure Key Vault or on systems with restricted permissions. We have a documented process for generating, rotating, and retiring keys.” [Pull up key management policy and key inventory spreadsheet]
Assessor: “Show me where your database encryption keys are stored.”
You: “In Azure Key Vault. Only the database team has access.” [Pull up Key Vault configuration or access logs showing restricted access]
Assessor: “When was the last key rotation?”
You: “Our database encryption key was rotated in January. Here is the rotation record showing the old key and the new key.” [Pull up rotation documentation]
Common failures
Keys stored insecurely: Keys are hardcoded in application code, stored in plaintext files, or left in shared folders.
No key inventory or management process: Keys exist, but there is no documentation of where they are, who can access them, or when they were created.
Keys are never rotated: A TLS certificate or encryption key is 5+ years old and has never been replaced.
Overly permissive key access: Multiple users or systems have access to sensitive keys.
Centralized key management: Keys are stored in a Key Vault, HSM, or similar protected system. Access is restricted and logged.
Regular key rotation: Keys are rotated annually or per policy. Rotation records are documented.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
If an MSP manages keys on your behalf, ensure the MSP maintains a key inventory and rotation schedule. Request evidence that keys are stored securely and accessed only by authorized personnel. Verify that the MSP’s key management aligns with your policy and CMMC requirements.
This guide is for reference only and does not replace official CMMC documentation or professional compliance advice.