Cryptographic Key Establishment and Management

To meet the cryptographic key establishment and management requirement, you must define and follow documented rules for how cryptographic keys are generated, distributed, stored, accessed, rotated, and destroyed anywhere cryptography is used in your system. Auditors will expect evidence that key handling is consistent, restricted, and repeatable across platforms, teams, and third parties. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• Your biggest job is to turn “organization-defined requirements” into a concrete key management standard and prove teams follow it. (NIST Special Publication 800-53 Revision 5)
• Scope includes every place cryptography exists: TLS, disk/database encryption, secrets, signing keys, KMS/HSM keys, and customer-managed keys. (NIST Special Publication 800-53 Revision 5)
• Evidence matters: inventories, configs, access logs, key lifecycle records, and destruction/retirement proof. (NIST Special Publication 800-53 Revision 5)

SC-12 is simple to read and easy to fail in practice: it requires disciplined key lifecycle control everywhere you use cryptography, not just “we use a KMS.” The text is explicit that your organization must set requirements for key generation, distribution, storage, access, and destruction, then operate to those requirements. (NIST Special Publication 800-53 Revision 5)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to operationalize SC-12 as a short “Key Management Standard” backed by (1) an inventory of keys and key-owning systems, (2) enforced technical controls in your chosen key management services (cloud KMS, HSMs, vaults), and (3) audit-ready artifacts that show the lifecycle is controlled and repeatable. That includes how keys are created, who can use or administer them, how they’re protected at rest, how they’re shared (or not shared), and what happens when keys are rotated, compromised, or no longer needed. (NIST Special Publication 800-53 Revision 5)

This page gives requirement-level guidance you can implement quickly: who it applies to, step-by-step actions, evidence to retain, common audit hangups, and an execution plan that gets you from “policy intent” to “operational proof.”

Regulatory text

Requirement (SC-12): “Establish and manage cryptographic keys when cryptography is employed within the system in accordance with organization-defined requirements for key generation, distribution, storage, access, and destruction.” (NIST Special Publication 800-53 Revision 5)

Operator translation:
If your system uses cryptography anywhere, you must (1) define how keys are handled across their lifecycle and (2) implement and follow those rules consistently. Auditors will look for two things: written requirements that are specific enough to test, and operational evidence that your environment follows them (not just “engineering preference”). (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation (what SC-12 is really asking)

SC-12 expects you to treat keys as controlled security assets with a governed lifecycle. That lifecycle starts at key creation (generation), includes movement and sharing (distribution), protection (storage), privilege control (access), and ends with retirement and secure disposal (destruction). Your “organization-defined requirements” are the heart of the control: you choose the specifics, but you must choose them, document them, and enforce them. (NIST Special Publication 800-53 Revision 5)

Who it applies to (entity + operational context)

Applies to:

• Cloud Service Providers operating systems subject to FedRAMP Moderate expectations. (NIST Special Publication 800-53 Revision 5)
• Federal Agencies operating or authorizing systems where FedRAMP/NIST 800-53 controls apply. (NIST Special Publication 800-53 Revision 5)

Operational scope (what to include):

• Encryption keys for storage and databases (including managed database encryption).
• TLS/HTTPS certificates and private keys (service-to-service and external).
• Keys used for signing (artifacts, updates, tokens), API authentication keys, and service account keys.
• KMS/HSM-managed keys, “bring your own key” and “customer-managed key” models.
• Secrets that function like keys (for example, symmetric secrets used for encryption or signing). SC-12 speaks to “cryptographic keys” explicitly; exam teams often test adjacent handling because weak “secret” handling undermines key controls. (NIST Special Publication 800-53 Revision 5)

Third-party context:
If a third party hosts part of your system or manages cryptography (for example, a managed database, CDN termination, SaaS integration, or outsourced PKI), you still need requirements and evidence that key handling meets your standard. Contractual and technical controls both matter.

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

1) Write a Key Management Standard that is testable

Your standard should be short, specific, and mapped to the SC-12 lifecycle words:

• Key generation: approved services (for example, cloud KMS/HSM), approved algorithms/strengths as your organization defines, and who is authorized to create keys. (NIST Special Publication 800-53 Revision 5)
• Key distribution: how keys are provided to workloads (prefer “never export,” use envelope encryption, short-lived certs, automated issuance), and prohibited behaviors (emailing keys, storing in tickets). (NIST Special Publication 800-53 Revision 5)
• Key storage: where keys may live (KMS/HSM/vault), how they’re protected, and explicit bans (source code, CI variables without protections, local laptops). (NIST Special Publication 800-53 Revision 5)
• Key access: separation of duties between key administrators and key users, break-glass rules, MFA/conditional access requirements as your organization defines, and logging/monitoring expectations. (NIST Special Publication 800-53 Revision 5)
• Key destruction: defined triggers (decommission, compromise, tenancy end), required method (disable, schedule deletion, shred HSM objects), and required evidence. (NIST Special Publication 800-53 Revision 5)

Practical tip: include a one-page “allowed patterns” appendix: TLS cert issuance path, application encryption pattern, token signing pattern, and approved exceptions process.

2) Build (or fix) a system-wide key inventory

You need a living inventory that answers:

• What key/cert exists
• What it protects
• Where it lives (service/location)
• Who owns it (human team)
• Who administers it
• Rotation/expiration expectations (as your organization defines)
• Whether export is permitted
• Related applications and environments

This inventory becomes your audit index and the anchor for lifecycle proof. Without it, you can’t show completeness. (NIST Special Publication 800-53 Revision 5)

3) Centralize key control in managed services (and lock down exports)

Operationally, SC-12 is easier when keys are created and kept inside managed KMS/HSM services, with strict IAM and logging. Prioritize:

• Non-exportable keys by default.
• Separate keys per environment and per tenant where required by your model.
• Limit administrative actions (create/disable/delete/rotate) to a small role set.
• Enforce service-to-service access through identities, not shared secrets. (NIST Special Publication 800-53 Revision 5)

4) Implement access control and monitoring that auditors can test

Access management must be provable. Do the basics well:

• Named roles for key admins vs key users (apps).
• Change control or approvals for high-risk admin actions (your organization defines the workflow).
• Central logging for key lifecycle events (create, enable/disable, policy changes, deletion scheduling).
• Periodic access reviews for key admin roles and for workloads that can use keys. (NIST Special Publication 800-53 Revision 5)

5) Define and execute lifecycle operations: rotation, compromise, and decommission

SC-12 does not dictate rotation frequency, but it requires lifecycle governance. You must define your expectations and then execute them. (NIST Special Publication 800-53 Revision 5)

Minimum operational components:

• Rotation playbooks by key type (TLS certs, symmetric encryption keys, signing keys).
• Compromise response: revoke/disable, re-issue, re-encrypt or re-wrap as needed, document incident linkage.
• Decommission/destruction workflow tied to asset retirement, customer offboarding, and environment teardown.
• Exception handling: business justification, compensating controls, and time-bound review. (NIST Special Publication 800-53 Revision 5)

6) Extend requirements to third parties and SaaS integrations

Where a third party touches your cryptography:

• Document the key ownership model (provider-managed vs customer-managed).
• Require contract language or attestations that keys are generated, stored, accessed, and destroyed per defined requirements.
• Ensure you can produce evidence (config screenshots, logs, SOC reports where applicable, or provider documentation) that maps to your standard. (NIST Special Publication 800-53 Revision 5)

7) Make it audit-ready: map controls to systems and produce repeatable evidence

Auditors will test a sample of keys/certs and trace lifecycle evidence. Prepare a “key evidence pack” that can be regenerated. Daydream can help here by turning your SC-12 requirements into an evidence checklist, assigning owners, and tracking artifact freshness across systems so you do not rebuild the same proof every audit cycle. (NIST Special Publication 800-53 Revision 5)

Required evidence and artifacts to retain

Keep artifacts that show both requirements and execution:

Governance

• Key Management Standard (approved, versioned).
• Key exception register and approvals.
• Key ownership/RACI for key admin and key user roles. (NIST Special Publication 800-53 Revision 5)

Inventory and scope

• Key/certificate inventory export (KMS/HSM/vault + PKI inventory) with owners.
• Data flow or crypto architecture diagrams showing where cryptography is used. (NIST Special Publication 800-53 Revision 5)

Configuration and enforcement

• KMS/HSM policies, key policies, IAM role bindings.
• Screenshots/exports showing non-exportable settings and deletion protections.
• Certificate issuance configs (internal CA settings, ACME configs, or equivalent). (NIST Special Publication 800-53 Revision 5)

Operations

• Logs showing key creation, policy changes, rotation events, disablement, deletion scheduling, destruction confirmation.
• Access review records for privileged key roles.
• Incident tickets or postmortems tied to key compromise or emergency rotation.
• Decommission tickets demonstrating key retirement and destruction steps. (NIST Special Publication 800-53 Revision 5)

Common exam/audit questions and hangups

Expect these, and pre-answer them with artifacts:

• “Show me your organization-defined requirements.” Auditors will not accept scattered wiki pages and tribal knowledge. Provide one standard and a mapping to systems. (NIST Special Publication 800-53 Revision 5)
• “Which keys exist in scope?” If you can’t enumerate keys/certs, sampling becomes chaotic and gaps appear. Provide an inventory plus automated exports. (NIST Special Publication 800-53 Revision 5)
• “Can anyone export keys?” Export is a frequent red flag. If export is allowed, auditors will ask why, who approved it, and how you controlled it. (NIST Special Publication 800-53 Revision 5)
• “How do you destroy keys?” Deletion in a console is not always destruction. Show your defined method, triggers, and proof. (NIST Special Publication 800-53 Revision 5)
• “What happens during incident response?” They will test whether compromise drives key actions and documentation. (NIST Special Publication 800-53 Revision 5)

Frequent implementation mistakes (and how to avoid them)

• Mistake: treating SC-12 as “we have KMS.” Fix: document lifecycle requirements and show execution evidence for real keys, not just architecture slides. (NIST Special Publication 800-53 Revision 5)
• Mistake: no owner for certificates. Fix: assign ownership by service, not by individual, and track certificate issuance/renewal paths. (NIST Special Publication 800-53 Revision 5)
• Mistake: shared key admin roles across environments. Fix: separate duties and scope admin privileges; keep production key admin roles tight. (NIST Special Publication 800-53 Revision 5)
• Mistake: exceptions become permanent. Fix: require time-bounded exceptions with explicit compensating controls and re-approval triggers. (NIST Special Publication 800-53 Revision 5)
• Mistake: destruction is undocumented. Fix: treat key retirement as a change-controlled event with logs/screenshots and ticket linkage. (NIST Special Publication 800-53 Revision 5)

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the approved source catalog. Practically, SC-12 gaps increase breach impact and slow incident response because teams cannot confidently rotate, revoke, or retire keys, and auditors can’t confirm keys are controlled consistently. (NIST Special Publication 800-53 Revision 5)

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Publish a Key Management Standard covering generation, distribution, storage, access, and destruction. (NIST Special Publication 800-53 Revision 5)
• Identify all key stores and certificate systems; start a system-of-record inventory.
• Lock down obvious high-risk access (shared admin accounts, unmanaged key copies) and document any exceptions with approvals. (NIST Special Publication 800-53 Revision 5)

Next 60 days (enforce and evidence)

• Centralize keys into managed KMS/HSM/vault patterns where possible; set non-exportable defaults.
• Implement logging and alerts for key admin actions; confirm logs are retained and reviewable.
• Run the first access review for privileged key roles; capture evidence.
• Create rotation/compromise/decommission playbooks per key type and run at least one tabletop to validate the steps and evidence outputs. (NIST Special Publication 800-53 Revision 5)

By 90 days (operationalize and scale)

• Make the inventory “complete enough to sample”: keys/certs mapped to owners and systems, with lifecycle status.
• Standardize onboarding: new services must use approved key patterns and register keys/certs in inventory.
• Build an audit-ready evidence pack you can regenerate on demand (policy, inventory exports, configs, logs, tickets). Daydream can track these artifacts, prompt owners for updates, and keep SC-12 evidence current across teams. (NIST Special Publication 800-53 Revision 5)

Frequently Asked Questions

Do we need a formal key management policy if engineering already uses cloud KMS?

Yes. SC-12 requires “organization-defined requirements” and evidence of lifecycle control, not just a tool choice. Write a short standard and show that systems follow it. (NIST Special Publication 800-53 Revision 5)

What counts as a “cryptographic key” for SC-12 scope?

Include KMS/HSM keys, private keys for certificates, signing keys, and keys used by applications for encryption. If a secret performs a cryptographic function, treat it with the same lifecycle rigor. (NIST Special Publication 800-53 Revision 5)

Are customer-managed keys in scope?

Yes. If your system supports customer-managed keys, document the shared responsibility model and keep evidence for how keys are generated, stored, accessed, and destroyed in that model. (NIST Special Publication 800-53 Revision 5)

How do we prove key destruction to an auditor?

Retain the ticket/change record plus system evidence such as KMS deletion scheduling, key disablement, and destruction confirmation logs or screenshots. Your standard should define what “destruction” means for each key system. (NIST Special Publication 800-53 Revision 5)

What if a third party terminates TLS or manages encryption for a managed service?

Treat it as in-scope cryptography and document requirements and evidence. Keep configurations, provider documentation, and contractual assurances that map to your lifecycle requirements. (NIST Special Publication 800-53 Revision 5)

What’s the fastest way to get audit-ready for SC-12?

Create a key inventory, publish a lifecycle standard, and assemble a repeatable evidence pack (configs, logs, access reviews, and lifecycle tickets) for a representative set of key systems. Then expand coverage system by system. (NIST Special Publication 800-53 Revision 5)