How to Build a Key Management Policy That Passes a CMMC Assessment

With CMMC Phase 2, enforcement beginning on November 10, 2026, most defense contractors have their attention on the obvious controls: multi-factor authentication, endpoint detection, and incident response plans.

SC.L2-3.13.10 — the practice requiring that you establish and manage cryptographic keys for all cryptography in your systems — tends to get less attention. It shouldn't.

Encryption controls are consistently among the highest-failure control families in CMMC Level 2 assessments. And the most common failure mode isn't a missing tool or a configuration error. It's a policy and documentation gap that contractors walk into, assuming they've solved.

The gap is almost always the same: "Our cloud provider manages our encryption keys."

Deciphering the NIST 800-171 Key Management Lifecycle Requirements

The practice maps directly to NIST SP 800-171 Rev. 2 control 3.13.10, which requires that organizations "establish and manage cryptographic keys for cryptography employed in organizational systems."

NIST SP 800-57 — the key management guideline that assessors reference — breaks this into a lifecycle that spans eight distinct phases:

• Generation: Keys must be created using methods that prevent reproduction by an adversary
• Distribution: Secure transfer of keys to authorized parties
• Storage: Keys must be protected when not in use, including encryption at rest and logical separation from the data they protect
• Backup and archive: Recovery procedures for lost or corrupted keys
• Rotation: Defined crypto periods specifying how long a key remains active, with procedures for rotation at end-of-period or upon staff departure
• Revocation: Procedures for immediately revoking compromised keys
• Recovery: Tested procedures for restoring key material when needed
• Destruction: Secure deletion procedures that ensure key material cannot be recovered

A passing key management program addresses every one of these phases with documented procedures, designated custodians, and evidence that the procedures are followed. The assessor isn't looking for sophisticated tooling; they're looking for documentation that proves organizational control over every stage.

The Shared Responsibility Trap: Why Cloud-Native Encryption Fails CMMC L2

This is the most common assessor finding, and understanding exactly why it fails is important for building something that passes.

When your cloud provider holds your encryption keys — even in a configuration marketed as "customer-managed keys" — the provider retains technical access to key material stored in their infrastructure. Under the CLOUD Act, a US-based provider can be compelled to produce that key material in response to a government request. Under the shared responsibility model, the provider's encryption applies at the infrastructure level, not at the individual file level required for CMMC CUI protection.

The assessor's specific objection is this: SC.L2-3.13.10 requires that your organization "establish and manage" the keys. If a third party holds the keys, you do not have independent control. And if that third party is part of your key management chain, they become part of your CMMC assessment boundary — which means the cloud provider must also demonstrate CMMC Level 2 compliance for the relevant scoped environment.

Standard commercial cloud platforms — Microsoft SharePoint, standard AWS S3, standard Azure Blob Storage — do not meet CMMC Level 2 requirements. Their encryption protects the provider's infrastructure. It doesn't provide FIPS 140-3 validated encryption at the CUI file level, and the key custodianship is not with your organization.

This leads to a specific pattern of findings during assessments. The contractor demonstrates that their files are "encrypted in the cloud." The assessor asks: Who holds the encryption keys? The answer is the cloud provider. The assessor documents: no independent key control demonstrated. The practice fails.

The Anatomy of an Assessor-Ready Cryptographic Key Management Policy

A policy document alone is not sufficient — CMMC assessment requires documented procedures, evidence of implementation, and audit logs that demonstrate the policy is operational. But the policy is where you start, and it needs to address each phase of the key lifecycle explicitly.

Key Generation

The policy must specify who is authorized to generate keys, what tools and algorithms are permitted (FIPS 140-3 validated cryptographic modules, approved algorithms per NIST SP 800-57), and document the validation status of the modules used. Crucially, it must establish that key generation occurs in a controlled environment where the key material cannot be observed or recorded by unauthorized parties.

Custodian Designations

Named individuals — not just roles — must be designated as key custodians with explicit responsibility for the lifecycle phases they own. The assessor will want to see who is responsible for key rotation, who has access to key storage, and what happens when a custodian leaves the organization. If the answer to "what happens when a key custodian resigns?" is "we're not sure," the practice fails.

Key Rotation Requirements

Define the crypto period for each key type. NIST SP 800-57 provides guidance on appropriate crypto periods based on the sensitivity of the protected data and usage frequency. A practical approach is to define a maximum active period (commonly 12 months for most key types) and a specific trigger requiring immediate rotation: staff departure with key access, suspected compromise, or system architecture change that alters the key boundary.

Key Storage and Protection

The policy must specify where keys are stored, how they are protected at rest (the answer should include encryption of the key material itself, not just the data it protects), and the logical or physical separation between keys and the data they encrypt. Keys stored in the same system as the encrypted data provide significantly weaker protection — assessors understand this and will ask.

Revocation Procedures

Document the procedure for revoking a compromised key — including who can authorize revocation, how it is executed, and what the audit trail looks like. Revocation must be immediate and verifiable. If your revocation procedure is "contact the cloud provider's support team," the practice will struggle.

Destruction Documentation

Key destruction is frequently the most documentation-deficient phase. The policy must specify how key material is rendered unrecoverable, who performs the destruction, and how the event is recorded. Assessors look for audit evidence — a log entry with date, responsible party, and confirmation of destruction — not just a procedure that says destruction will occur.

The Documentation the Assessor Wants to See

Assessment evidence for SC.L2-3.13.10 typically includes:

• System Security Plan (SSP): The cryptographic key management section of your SSP should describe your key management architecture, reference your key management policy, and identify the FIPS 140-3 validated modules in use
• Key Management Policy and Procedures: The documented policy covering each lifecycle phase, with revision history
• Custodian Designations: Documented appointments of named key custodians with explicit responsibilities
• Key Inventory: A record of keys in active use, their purpose, the data they protect, their current rotation status, and their assigned custodian
• Key Rotation Records: Evidence that rotation occurred at the defined intervals, with dates and responsible parties
• Audit Logs: System-generated evidence of key management activities — access to key material, rotation events, revocation events
• Training Records: Confirmation that staff with CUI access have completed security awareness training that includes cryptographic key handling responsibilities

An assessment interview will typically ask the key custodian to walk through a recent rotation event, describe what happens when a staff member with key access departs, and explain where key backups are stored and how they are protected. Preparation for these interviews is as important as the documentation itself.

The Zero-Knowledge Advantage for Assessment Documentation

One of the practical challenges with key management documentation is the shared-responsibility complexity introduced by cloud infrastructure. Every cloud service in your environment potentially expands the number of systems and parties you need to account for in your key management architecture.

A zero-knowledge architecture — where Theodosian holds no ability to access or decrypt customer key material — simplifies this documentation challenge considerably. The key management boundary is clear: keys are generated, managed, and controlled entirely within the customer's authority. There is no third-party key custodian to account for. The SSP section on key management describes a single, auditable chain of control.

This matters specifically for the assessor interview question, "does any third party have access to your encryption keys?" The answer with zero-knowledge architecture is definitively a no, and that answer is verifiable from the system design documentation.

Theodosian's per-file FIPS 140-3 validated encryption means each document carries its own cryptographic key. Key management operates at the file level, not the storage-system level. This maps directly to the SC.L2-3.13.10 requirement for establishing and managing keys "for cryptography employed in organizational systems" — with the key material under organizational control at every lifecycle phase.

The Timeline Risk

As of April 2026, only 1% of the approximately 76,000 defense contractors requiring CMMC Level 2 certification have completed it — a figure documented by Cybersheath's State of the DIB Report 2025.

The assessment timeline is not short. From gap analysis initiation to completed assessment, the realistic path for most contractors is 12–18 months. That timeline includes gap remediation, documentation development, assessor selection, scheduling (current wait times for C3PAO scheduling run 3–6 months, likely extending further as November approaches), active assessment work, and findings remediation.

Organizations that haven't begun active remediation work by mid-2026 are unlikely to complete their assessment before Phase 2 enforcement affects their ability to bid on new contracts.

SC.L2-3.13.10 is not a quick fix. Building a key management policy, designating and training custodians, deploying FIPS 140-3 validated tooling, and generating the audit evidence that the assessor will review takes time. It's one of the practices that needs to be addressed early — not because it's technically complex but because organizational documentation and evidence generation take weeks, not days.

A Practical Starting Point

If you're in the early stages of CMMC Level 2 preparation and haven't addressed key management yet, this is a reasonable starting sequence:

1. Inventory your current cryptography: Identify every system handling CUI, every key in use, and where key material is currently stored. You cannot write a key management policy for systems you haven't mapped.
2. Determine who currently controls your keys: If the answer involves your cloud provider, document the specific gap and begin evaluating alternatives.
3. Draft a key management policy using NIST SP 800-57 Part 2 as the template: The standard's key management specification requirements map directly to what CMMC assessors expect to see.
4. Designate named custodians and document their responsibilities explicitly: Get sign-off. Create a succession plan for when custodians change.
5. Define your crypto periods and rotation schedule: Put the first scheduled rotation on the calendar before the policy document is finalized.
6. Start generating audit evidence now: Key management audit logs are some of the most time-consuming evidence to produce retroactively — the further out you are from your assessment, the more runway you have to build a credible evidence record.

FAQs: CMMC Key Management