03.13.10: Cryptographic Key Establishment and Management

To meet the 03.13.10: cryptographic key establishment and management requirement, you must define and run a controlled lifecycle for cryptographic keys used to protect CUI: how keys are generated or established, stored, distributed, rotated, revoked, backed up, and destroyed, with clear ownership and auditable evidence (NIST SP 800-171 Rev. 3). Implement this through a written key management standard, approved key handling procedures, and repeatable operational logs and reviews.

Key takeaways:

• Document a key lifecycle (create/establish → store → distribute → rotate → revoke → destroy) and assign accountable owners (NIST SP 800-171 Rev. 3).
• Centralize keys in approved KMS/HSM/secret management tooling, then prove operation with inventories, configs, and rotation/revocation records.
• Auditors will focus on evidence: key inventories, access controls, rotation settings, and exception handling tied to systems handling CUI.

03.13.10 sits in NIST SP 800-171 Rev. 3’s security requirements for protecting Controlled Unclassified Information (CUI) on nonfederal systems. Practically, it forces you to treat cryptographic keys as high-value assets with their own controls, not as a byproduct of “turning on encryption.” If keys are weak, shared, never rotated, or stored alongside encrypted data, encryption becomes a paper control and CUI exposure becomes a matter of time.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing 03.13.10 is to narrow scope to “keys that protect CUI” and then require three things: (1) a defined key lifecycle standard, (2) an inventory that maps keys to systems and owners, and (3) recurring evidence that the lifecycle is followed. That evidence is what makes the requirement assessable.

This page gives requirement-level implementation guidance you can hand to security engineering, cloud platform teams, and application owners. It also flags the exam and audit hangups that commonly derail otherwise solid encryption programs: unmanaged application secrets, unclear rotation ownership, and the absence of key material handling rules.

Regulatory text

Requirement excerpt: “NIST SP 800-171 Rev. 3 requirement 03.13.10 (Cryptographic Key Establishment and Management).” (NIST SP 800-171 Rev. 3)

What the operator must do: establish and manage cryptographic keys used to protect CUI through controlled processes and procedures that cover how keys are created/established, protected, accessed, changed, retired, and destroyed, with accountability and evidence (NIST SP 800-171 Rev. 3). In practice, assessors expect your program to prevent ad-hoc key creation, prevent uncontrolled sharing/export of keys, and prove that keys are rotated or replaced based on defined triggers.

Plain-English interpretation (what 03.13.10 is really asking)

03.13.10 requires you to run key management as a system of record. Encryption controls are only as strong as the keys and the processes around them. You need to show that:

• Keys are created/established in approved ways (not copied from a wiki or generated on a laptop).
• Keys are stored and accessed securely (least privilege, no broad admin access, controlled export).
• Keys are rotated/replaced and retired intentionally (not “whenever someone remembers”).
• Key loss, compromise, or staff departure triggers revocation and replacement.
• You can prove all of this with artifacts.

Who it applies to (entity and operational context)

Applies to organizations that handle CUI in nonfederal systems, including federal contractors and any nonfederal system handling CUI (NIST SP 800-171 Rev. 3). Operationally, the requirement lands on teams responsible for:

• Cloud services (KMS, HSMs, certificate services, secret managers)
• Endpoint and disk encryption (BitLocker/FileVault, mobile device encryption)
• Application and database encryption (TDE, field-level encryption, envelope encryption)
• TLS certificates and internal PKI
• Backup encryption and key escrow
• Third parties processing or storing CUI on your behalf (you still own the compliance outcome)

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

1) Define scope: which keys are “in scope for CUI”

Create a scoping rule: any key that encrypts, decrypts, signs, or establishes secure channels for systems that store/process/transmit CUI is in scope (NIST SP 800-171 Rev. 3).
Output: “CUI Key Scope Statement” plus a list of in-scope systems.

2) Establish a key management standard (the non-negotiables)

Write a standard that answers, at minimum:

• Approved cryptographic modules/services where keys may reside (for example, enterprise KMS/HSM/secret manager)
• Allowed key types and intended uses (encryption at rest, TLS, code signing, database TDE)
• Key generation/establishment requirements (who can create keys, how entropy is ensured, approval gates for production)
• Storage requirements (no plaintext keys in repos; prohibit emailing key material; rules for export)
• Access control (least privilege roles, break-glass, separation of duties)
• Rotation and rekey triggers (scheduled rotation, compromise suspicion, role changes, vendor compromise)
• Revocation/retirement/destruction rules
• Logging and monitoring expectations
  Tie the standard to your policy set so it is enforceable and reviewable (NIST SP 800-171 Rev. 3).

3) Build and maintain a key inventory (the control plane)

Auditors will ask, “Show me all keys used to protect CUI and who owns them.” Create an inventory with:

• Key identifier/alias (not the key material)
• System/application and environment (prod/non-prod)
• Data classification (CUI) and purpose
• Owner (a named role) and administrator group
• Storage location (KMS/HSM/service)
• Rotation configuration and last rotation event
• Whether export is enabled
  Tip: If your cloud KMS can tag keys, require CUI tags and use them to generate the inventory automatically.

4) Implement lifecycle controls in technology (make the standard real)

Map the standard to platform settings and guardrails:

• Centralize keys in managed services (KMS/HSM) and disable “bring your own random key file” patterns.
• Restrict key admin roles to a small group; separate “key admins” from “data users” where feasible.
• Turn on logging for key administration events and key usage events when the platform supports it.
• Enforce rotation settings for keys that support automatic rotation; for keys that cannot auto-rotate, define a manual runbook with tickets and approvals.
• Control secrets: many “key management” failures are really unmanaged application secrets (API keys, service account keys, private keys). Treat these as in-scope key material where they protect CUI access paths.

5) Operationalize with runbooks and change management

Create runbooks that an on-call engineer can follow under pressure:

• “Create a new CUI encryption key” (approval, naming, tagging, access grants)
• “Rotate or rekey a CUI system” (dependencies, downtime expectations, validation steps)
• “Revoke access for departing admins” (access review checklist)
• “Key compromise response” (containment, re-encrypt, cert revocation, comms path)
  Attach these to your change management process so changes leave an audit trail.

6) Review and prove operation on a recurring basis

Your program should generate evidence without heroics:

• Periodic access reviews for key admin roles
• Alerts for disabled logging, export enabled, or overly broad grants
• Exceptions tracked with expiration dates and compensating controls
  This is where tools like Daydream fit naturally: track the requirement-to-control mapping, assign owners, schedule evidence pulls (inventory exports, KMS policy snapshots, access review signoffs), and keep the audit packet organized for 03.13.10.

Required evidence and artifacts to retain

Maintain an “03.13.10 audit packet” with:

• Key Management Policy/Standard approved by the business (NIST SP 800-171 Rev. 3)
• Key inventory for CUI systems (export or system report)
• System architecture diagrams showing where encryption occurs and where keys live
• Configuration evidence: KMS/HSM policies, role assignments, rotation settings, export controls
• Logs or audit trails for key admin actions (creation, disablement, deletion)
• Rotation/rekey records (change tickets, runbook execution evidence, validation outputs)
• Access review records for key administrators and break-glass accounts
• Exception register for non-standard key handling (with approvals and end dates)
• Third-party evidence when a third party hosts keys or performs encryption on your behalf (contract clauses, shared responsibility notes, and their attestations if available)

Common exam/audit questions and hangups

Expect these questions and prepare screenshots/exports, not explanations:

1. “Where are the keys for this CUI application stored, and who can administer them?”
2. “Show rotation configuration and last rotation for the key that protects this database.”
3. “Can anyone export key material? Show the control that prevents it.”
4. “How do you handle key compromise or an admin leaving the company?”
5. “Do developers ever store private keys or API keys in source control? How do you detect and remediate?”
6. “How do you ensure consistency across cloud accounts, subscriptions, or environments?”

Frequent implementation mistakes (and how to avoid them)

• Mistake: treating certificates, API keys, and service account keys as “out of scope.” Fix: classify them as cryptographic key material when they protect access to CUI systems; manage them in a secret manager with rotation and logging.
• Mistake: no owner for a key. Fix: require an accountable application owner for every production key alias; “security” can be the platform owner, not the business owner.
• Mistake: rotation policy exists, rotation doesn’t. Fix: enforce rotation technically where possible; otherwise require change tickets with evidence and track completion in your GRC system.
• Mistake: keys created ad-hoc across teams. Fix: standard naming/tagging, guardrails, and a short intake process for new keys.
• Mistake: exporting keys for convenience. Fix: prohibit export except for a documented, approved exception; require compensating controls and expiry.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement. Your practical risk is still concrete: weak key management collapses encryption protections for CUI and creates audit failure modes that are easy for assessors to validate, such as missing inventories, overly broad KMS permissions, and absent rotation evidence (NIST SP 800-171 Rev. 3).

Practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Confirm which systems handle CUI and list encryption use cases per system (at rest, in transit, backups).
• Pick approved key stores (KMS/HSM/secret manager) and document “no other key storage locations.”
• Draft and approve a key management standard with ownership, access, rotation, logging, and exception rules (NIST SP 800-171 Rev. 3).
• Start a minimum viable key inventory for the highest-risk CUI systems.

Next 60 days (implement guardrails and evidence)

• Migrate or wrap ad-hoc keys into approved stores where feasible.
• Lock down admin roles; implement break-glass and reviewable access grants.
• Enable and route key management logs to your SIEM/log platform.
• Create runbooks for key creation, rotation, and compromise response.
• Stand up an evidence cadence in Daydream: inventory export, role membership export, rotation settings snapshots.

By 90 days (operate and validate)

• Run at least one end-to-end rotation/rekey exercise for a CUI system and retain the ticket and validation outputs.
• Complete an access review for key administrators and document remediation actions.
• Review exceptions, expire what you can, and add compensating controls for what remains.
• Do an internal “audit-style walkthrough” of one CUI system: trace data flow, show where encryption happens, show key custody and rotation evidence.

Frequently Asked Questions

Does 03.13.10 require an HSM?

NIST SP 800-171 Rev. 3 03.13.10 requires controlled key establishment and management, not a specific product (NIST SP 800-171 Rev. 3). If a managed KMS meets your security needs and you can evidence access controls, logging, and lifecycle operation, that can satisfy the requirement.

Are application secrets (API keys, OAuth client secrets) covered by this requirement?

If the secret functions as key material that protects access to CUI systems, treat it as in scope for 03.13.10 controls (NIST SP 800-171 Rev. 3). Store it in an approved secret manager, restrict access, and track rotation and revocation.

What evidence is strongest for auditors?

Auditors typically accept objective evidence: key inventory exports, KMS/HSM policy snapshots, role membership lists, and change tickets proving rotation/rekey actions (NIST SP 800-171 Rev. 3). A written policy without operational records rarely closes the loop.

How do we handle keys in third-party SaaS that processes CUI?

Document the shared responsibility model and confirm how keys are managed (customer-managed keys vs provider-managed) as part of third-party due diligence (NIST SP 800-171 Rev. 3). Keep contracts, security documentation, and your internal approval for the chosen model in the audit packet.

What if a system can’t rotate keys without downtime?

Treat it as an engineering constraint, not a compliance waiver. Document a rotation runbook with maintenance windows, define triggers for rekey, and track exceptions with expiration dates and compensating controls (NIST SP 800-171 Rev. 3).

How detailed does the key inventory need to be?

Detailed enough to answer “which key protects which CUI data path, where is it stored, and who controls it” without opening consoles during the audit (NIST SP 800-171 Rev. 3). Avoid storing key material; store identifiers, ownership, and configuration facts.