3.13.10 — Manage Your Keys

The One-Liner

Encryption without key management is like a lock where you’ve lost track of who has copies of the key.

What It Says

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

What It Actually Means

Every encryption deployment needs a key management process covering the full lifecycle:

1. Generation — keys created using approved methods (not manually typed, not derived from weak sources)
2. Distribution — keys delivered securely to where they’re needed (not emailed in plain text)
3. Storage — keys stored in a protected location (hardware security module, key vault, not a text file)
4. Rotation — keys replaced on a defined schedule (annually is common for most use cases)
5. Revocation — keys invalidated when compromised or no longer needed
6. Destruction — keys securely destroyed when retired

The assessor will walk through each encryption deployment and ask about key management. BitLocker recovery keys, TLS certificates, VPN pre-shared keys, database encryption keys, S/MIME certificates — each one has keys that need managing.

The most common failure: “Where are your BitLocker recovery keys?” “…somewhere in AD, I think.” You need to know exactly where every key is.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are cryptographic keys managed for all cryptographic deployments?	Each encryption use has documented key generation, storage, rotation, and destruction
2	Is a key management process established?	Written key management procedures covering the full lifecycle

---

What to Have Ready on Assessment Day

Documents they’ll review: System and communications protection policy; procedures addressing cryptographic key management; system security plan; system configuration settings; key management documentation; key inventory

People they’ll talk to: System or network administrators; personnel with information security responsibilities; personnel with responsibilities for cryptographic key management

Live demos they’ll ask for: Mechanisms supporting or implementing key management; key storage locations; key rotation evidence

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Where are your BitLocker recovery keys stored? Show me.”
• “What is your key rotation schedule for TLS certificates?”
• “How do you generate encryption keys — manually or via approved tools?”
• “Walk me through what happens when a key is compromised.”
• “Show me your key inventory — which keys exist and where are they stored?”
• “How do you destroy keys when they’re no longer needed?”

Real-World Example

A contractor maintains a key inventory spreadsheet listing: BitLocker recovery keys (stored in Entra ID — verified by pulling a recovery key for a sample device), TLS certificates (managed through Azure Key Vault with auto-rotation every 12 months), VPN certificates (issued by internal CA, 2-year lifetime, revocation via CRL), and database TDE keys (managed by Azure SQL, rotated annually). The assessor spot-checks: navigates to Entra ID → Devices → picks a device → shows the BitLocker recovery key is present. Checks Key Vault → shows TLS cert with next rotation date. The key management procedure document covers generation, storage, rotation, revocation, and destruction for each key type.

---

Where Companies Trip Up

No key inventory. You have encryption deployed but can’t list where all the keys are.

BitLocker keys not centrally stored. Recovery keys exist only on the individual machines. If the machine is lost, the key is lost too.

Certificates never rotated. TLS certificates manually managed and renewed only when they expire — not rotated proactively.

No revocation process. If a key is compromised, there’s no defined process to revoke and replace it.

Keys stored alongside data. Encryption key stored in the same database it encrypts. Separate key storage from data storage.

---

How to Talk About This

To a CEO or Board

Every encryption key in our environment is inventoried, stored securely, rotated on schedule, and managed through its full lifecycle.

To an Engineering Team

Key inventory maintained. BitLocker keys: Entra ID. TLS certs: Azure Key Vault with auto-rotation. VPN certs: internal CA with CRL. Database keys: managed by Azure SQL. Key management procedure covers generation, storage, rotation, revocation, destruction per key type.

---

Connected Requirements

Requirement	Why it matters here
3.13.11 — FIPS or It Doesn’t Count	Keys must be used with FIPS-validated modules
3.13.8 — Encrypt in Transit	TLS certificates managed under this key management process
3.13.16 — Encrypt CUI at Rest	BitLocker and database encryption keys managed here

---

Implementation (coming soon)

Step-by-step setup for Microsoft 365 / Entra ID, AWS, Azure, and GCP — console steps, CLI commands, and evidence screenshots.

---

CMMC Practice ID: SC.L2-3.13.10 | SPRS Weight: 1 point | POA&M Eligible: Yes