Requirement
NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - SC.L2-3.13.10 – Establish and manage cryptographic keys for cryptography employed in organizational systems.
Understanding the Requirement
This control requires organizations to create and operate a cryptographic key management program that covers the full lifecycle of keys: generation, distribution, storage, backup, archive, recovery, use, revocation, and destruction. The objective is twofold: ensure keys are created securely so they cannot be reproduced by an attacker, and ensure keys are managed and protected so they cannot be stolen or misused. Practically, that means treating keys (SSH keys, PGP keys, BitLocker recovery keys, TLS certificates, etc.) as high-value assets with policies, assigned responsibilities, and technical controls that limit exposure throughout their life.
Technical Implementation
- Inventory and classification: Create a centralized inventory of all cryptographic keys and certificates (SSH, TLS/PKI, BitLocker, PGP, API keys tied to crypto functions). Record owner, purpose, location, algorithm/type, creation date, expiration, and storage method. Keep the inventory access-limited to authorized administrators only.
- Formal lifecycle policy: Publish a short, practical key management policy that defines generation standards (approved algorithms and key lengths), rotation intervals, storage requirements (HSM/cloud KMS vs encrypted vaults), backup/archival procedures, revocation and destruction steps, and roles responsible for each stage. Make the policy prescriptive and simple for SMB teams to follow.
- Use managed key stores where possible: Deploy a Key Management Service (cloud KMS), Hardware Security Module (HSM), or an enterprise-grade secrets manager for private keys and certificates rather than leaving keys on individual hosts. For SMBs, cloud KMS or a managed secrets platform reduces operational risk and complexity.
- Access control and least privilege: Restrict who can create, export, and deploy keys. Use role-based access controls, multifactor authentication, and require approval for key issuance and export. For SSH keys, enforce jump hosts or centralized bastion with short-lived certificates where feasible.
- Rotation, revocation, and recovery: Implement automated rotation for short-lived credentials (TLS certs, short-lived SSH certs) and a documented manual rotation schedule for longer-lived keys. Maintain a tested revocation and recovery process (CRLs/OCSP for certificates, revocation checklist for SSH and disk-encryption keys) and ensure backups of recovery keys are stored securely, with escrow if required.
- Logging, monitoring, and periodic audit: Enable logging for key usage and administrative actions on key stores. Review logs for unusual access patterns and perform quarterly audits confirming inventory accuracy, that expired keys are removed, and that access permissions remain appropriate.
Example in a Small or Medium Business
AcmeTech is a 60-person SMB that runs customer-facing services and has internal Windows laptops encrypted with BitLocker. They start by building a spreadsheet inventory listing each server, device, and application that uses cryptography and noting the associated keys or certificates. The IT lead and a designated security owner agree to a short key management policy: RSA 3072 or ECDSA P-256 for new keys, SSH keys rotated every 90 days, and BitLocker recovery keys escrowed in a protected vault. They adopt their cloud provider's KMS for TLS and application keys, configure BitLocker recovery keys to be backed up to the company's encrypted vault, and retire the practice of emailing keys. For SSH access, they move from shared static keys to user-specific keys managed by a bastion host and restrict SSH key creation to the system admin role with MFA. They schedule quarterly reviews to verify keys in the inventory match deployed assets, run drills to revoke a compromised key, and document recovery steps. When an employee leaves, HR triggers immediate revocation and rotation where that user's keys had access. These steps reduce the chance of key theft and provide clear processes for recovery and audit.
Summary
Implementing SC.L2-3.13.10 for an SMB is a mix of simple policy and practical technical controls: maintain an accurate key inventory, assign owners, adopt a concise lifecycle policy, and use managed key stores or vaults where possible. Controlling access, enforcing rotation and revocation procedures, and auditing key usage close the loop so cryptographic keys remain secure from generation through destruction. Together these measures ensure keys cannot be trivially reproduced or stolen, meeting the control's intent while remaining achievable for small IT teams.