CMMC Level 2 Practice 3.13.10: Establish and manage cryptographic keys for cryptography employed in organizational

To satisfy cmmc level 2 practice 3.13.10: establish and manage cryptographic keys for cryptography employed in organizational requirement, you must run a formal key management program for every place you use encryption: documented ownership, approved key generation, protected storage, controlled access, rotation, backup/escrow where needed, and secure destruction. Assessors will look for proof that keys are managed consistently across systems. ¹

Key takeaways:

• Inventory where cryptography is used, then map each use to a specific key type, owner, and lifecycle.
• Centralize control with a KMS/HSM or tightly controlled procedures, and restrict who can create, export, or rotate keys.
• Keep audit-ready evidence: configs, access logs, rotation records, and documented exceptions. ¹

CMMC Level 2 Practice 3.13.10 focuses on a narrow but high-impact operational reality: encryption only protects CUI if the underlying cryptographic keys are created, stored, used, rotated, and retired under control. The practice is mapped to NIST SP 800-171 Rev. 2 requirement 3.13.10, which means your implementation should be understandable to a CMMC assessor and traceable to how your environment actually encrypts data at rest, data in transit, backups, and secrets used by applications. ¹

For most organizations, the fastest path is to stop treating “encryption” as a checkbox and instead manage keys as privileged assets with defined ownership and lifecycle events. That includes decisions like where keys live (KMS/HSM vs. local keystore), who can export them, how rotations occur without outages, and how you prove all of that happened. This page gives requirement-level guidance you can execute quickly: scope it, design the control, implement it in common platforms, and build an evidence bundle that holds up during a CMMC Level 2 assessment under the CMMC Program. ^{2 3}

Regulatory text

Regulatory excerpt (mapped requirement): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.10 (Establish and manage cryptographic keys for cryptography employed in organizational).” ¹

Operator interpretation: You must define and run a repeatable process to manage cryptographic keys used by your organization’s encryption, from creation through destruction. That process must cover keys used to protect CUI and keys that protect systems processing CUI, and it must be demonstrable through documentation and objective evidence. ¹

Plain-English interpretation (what the requirement means)

You need to answer, consistently, for every encryption use case:

• What keys exist, where are they, and what do they protect?
• Who can create, read, rotate, disable, or delete them?
• How do you prevent key loss, key theft, and key misuse?
• How do you prove controls operated as designed? ¹

If your team cannot quickly explain where the keys for disk encryption, database encryption, TLS certificates, backup encryption, and application secrets live, you are not meeting the intent.

Who it applies to (entity and operational context)

Applies to organizations seeking CMMC Level 2 that handle CUI for the DoD, including prime contractors and subcontractors. ^{3 2}

Operationally, it applies anywhere you employ cryptography in the CUI environment, including:

• Endpoints and servers using full-disk encryption
• Databases and storage volumes encrypted at rest
• TLS for internal and external services
• VPN and remote access cryptography
• Backup encryption and archive encryption
• Application-level encryption and secrets (API keys, signing keys, token keys)
• Third-party managed services where encryption is “on” but keys may be provider-managed

What you actually need to do (step-by-step)

1) Build a cryptography and key inventory (scope the control)

Create a register that lists every cryptographic implementation relevant to CUI processing, storage, or transmission. For each entry, capture:

• System/service name and owner
• Data type protected (CUI, authentication material, logs)
• Crypto function (at rest, in transit, signing, key wrapping)
• Key type (symmetric, asymmetric, certificate, token-signing key)
• Key location (KMS/HSM, OS keystore, application vault, SaaS-managed)
• Administrative path (who administers it; break-glass path)
• Evidence pointer (config screenshot/export, platform report, ticket link)

This inventory becomes the backbone for assessment conversations. ¹

2) Define a key management standard (the “how we do keys here” document)

Write a short standard that your technical teams can follow and your assessor can verify. Include:

• Approved key management systems (for example: cloud KMS, on-prem HSM, approved secrets vault)
• Key generation requirements (where keys may be generated; prohibition on ad hoc local key creation for protected workflows)
• Storage requirements (keys stored in managed keystore/HSM; prohibit storing plaintext keys in code repos, tickets, or shared drives)
• Access control rules (role-based access; least privilege; separation of duties for key admins vs. app operators)
• Export controls (when key export is allowed; approvals; logging; compensating controls)
• Rotation triggers (scheduled rotation, personnel change, suspected compromise, vendor incident)
• Backup/escrow rules (what is backed up, who can restore, how restores are logged)
• Revocation/retirement and destruction procedures
• Exception process (risk acceptance, time bounds, compensating controls)

Keep it operational and testable. ¹

3) Implement technical controls in your key platforms

Minimum operational expectations that assessors commonly expect to see evidenced:

Centralized key control where feasible

• Prefer managed KMS/HSM or a controlled vault for keys used by multiple workloads.
• Limit the number of humans who can directly access key material.

Strong administrative controls

• Enforce MFA for key administrators.
• Use separate admin roles for: key creation, key rotation, key policy changes, and key deletion.
• Require change control for key policy changes.

Logging and monitoring

• Enable audit logs for key management actions (create, disable, schedule deletion, policy change, decrypt operations where supported).
• Route logs to your central logging/SIEM and retain them per your retention standard.

Rotation and lifecycle

• Implement rotation workflows that do not depend on one person’s memory (automation or scheduled change tickets).
• Make certificate management explicit: issuance, renewal, revocation, and private key protection.

This is where many teams fail: they “have encryption” but lack proof of key governance. ¹

4) Manage third-party encryption and “provider-managed keys”

If a third party hosts a system that stores/transmits CUI:

• Identify whether encryption keys are customer-managed, provider-managed, or bring-your-own-key.
• Document who has the ability to access/export/rotate keys.
• Obtain and retain contractual or attestation evidence describing the key management model.
• If provider-managed keys are used, document your risk decision and compensating controls (access monitoring, configuration baselines, incident response obligations).

Your assessor will still expect you to “establish and manage” keys as far as your responsibility extends. ¹

5) Operationalize: recurring checks and evidence capture

Set a recurring control operation that collects evidence without a scramble:

• Quarterly review of the key inventory against system inventory changes
• Review of key admin access list and recent key management events
• Rotation/renewal completion checks for expiring certificates and critical keys
• Exception review (open exceptions, expired exceptions, remediation status)

Daydream can help by mapping 3.13.10 to a documented control narrative and building a recurring evidence checklist so you collect the right artifacts continuously, not just before the assessment. ²

Required evidence and artifacts to retain

Keep evidence tied to specific systems and keys, not generic policy PDFs.

Governance

• Key management policy/standard and supporting procedures (approved by accountable owner)
• Key inventory / cryptography register with owners and lifecycle notes
• Roles and responsibilities (RACI) for key custodians, system owners, security

Technical configuration evidence

• KMS/HSM/vault configuration exports or screenshots showing:
  • Key policies and admin roles
  • Key rotation settings (where applicable)
  • Key deletion protection controls (where applicable)
• Certificate management system settings and issuance/renewal logs
• Samples of encrypted storage configurations tied to key IDs/ARNs/handles

Operational evidence

• Change tickets for key rotation and key policy changes
• Access reviews for key admin groups
• Audit logs for key lifecycle actions (create/disable/delete/policy changes)
• Incident records where keys were revoked/rotated due to suspected compromise
• Exception approvals with expiration and compensating controls

Common exam/audit questions and hangups

Expect an assessor to press on these points (prepare answers and artifacts):

• “Show me where keys are stored for system X and who can administer them.” ¹
• “How do you prevent developers from placing keys in source code or CI variables without controls?”
• “Prove key rotation happened for these workloads. Show tickets, logs, or platform rotation history.”
• “If this SaaS encrypts data, who controls the keys and what can you do if a key is compromised?”
• “How do you handle key recovery without creating a ‘shared secret’ problem?”

Hangups usually come from missing inventories, unclear ownership, and weak evidence of operational cadence.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails 3.13.10	Fix
Encryption enabled, but no key inventory	You cannot show keys are “established and managed”	Build and maintain a key/crypto register tied to systems 1
Keys stored in code repos, tickets, or shared drives	Key compromise becomes likely; weak governance	Enforce secret scanning, vault usage, and access controls
One shared “KMS admin” account	No accountability; hard to prove least privilege	Use named roles, MFA, separation of duties, and logging
Rotations are ad hoc	You cannot prove lifecycle management	Schedule rotations; tie to tickets and audit logs
SaaS/provider-managed keys undocumented	Responsibility boundaries unclear	Document the model and retain third-party attestations/contracts

Enforcement context and risk implications

CMMC is implemented through the DoD CMMC Program and the CMMC rule framework in 32 CFR Part 170. Your practical risk is assessment failure or conditional outcomes if you cannot produce objective evidence of key management across the CUI environment. ^{2 3}

Operational security risk is straightforward: stolen or mishandled keys can negate otherwise-strong encryption, expose CUI, and complicate incident response because you cannot rapidly revoke/rotate keys with confidence. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Assign an executive owner and an operational owner for key management.
• Produce a cryptography/key inventory draft for the CUI boundary first.
• Identify “red zones”: plaintext key storage, shared admin accounts, unknown certificate sources.
• Select the system of record for evidence (GRC tool or controlled repository) and start capturing artifacts.

Days 31–60 (standardize and implement)

• Publish the key management standard and exception workflow.
• Centralize keys into KMS/HSM/vault where feasible; lock down exports.
• Turn on audit logging for key management actions and route to central logs.
• Implement access reviews for key admin roles; remove stale access.

Days 61–90 (prove operation and get assessment-ready)

• Run a tabletop “key compromise” scenario: revoke/rotate a key, update dependent services, validate logs.
• Perform a control self-test: pick representative systems and assemble an evidence packet per system.
• Close or formally exception the remaining gaps with time-bounded remediation plans.
• In Daydream, map the final control narrative to 3.13.10 and schedule recurring evidence tasks aligned to your operating rhythm. ²

Frequently Asked Questions

Does 3.13.10 require an HSM or KMS?

The requirement is to establish and manage keys, not to buy a specific product. If you use an HSM/KMS, it often makes access control and audit evidence easier to demonstrate. ¹

Are TLS certificates in scope for “cryptographic keys”?

Yes in practice, because private keys and certificate lifecycle management are key management activities tied to cryptography used to protect data in transit. Document issuance, renewal, revocation, storage, and admin access. ¹

If a cloud provider “manages the keys,” am I compliant?

You still need to define and document the key management model, your responsibilities, and the evidence you retain (contracts, configurations, logs available to you). Assessors commonly ask who can access and rotate keys. ¹

What evidence is strongest for assessors?

System-specific artifacts: KMS key policies, admin role membership, audit logs for key changes, rotation records, and change tickets tied to specific keys and systems. Generic policies help, but they do not prove operation. ¹

How do I handle keys embedded in legacy applications?

Treat it as an exception with compensating controls: restrict access, segment the system, add monitoring, and put a migration plan on a defined timeline. Capture the risk acceptance and the remediation workstream as evidence. ¹

Do I need to rotate every key on a fixed schedule?

3.13.10 requires managed lifecycle, not a single mandated rotation interval. Define rotation triggers and demonstrate that rotations occur per policy or risk events, and that you can execute rotation without losing data or breaking services. ¹

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170