SC-12: Cryptographic Key Establishment and Management

To meet the sc-12: cryptographic key establishment and management requirement, you must run a formal key management program wherever your systems use cryptography, covering how keys are generated or established, stored, distributed, rotated, revoked, backed up, and destroyed, with clear ownership and evidence. Auditors will look for documented procedures plus system-level proof that keys are controlled throughout their lifecycle.

Key takeaways:

• Treat keys as controlled security assets with a defined lifecycle, not as an implementation detail inside applications.
• Standardize key generation/establishment, storage, rotation, revocation, and destruction across platforms (cloud, on-prem, SaaS).
• Evidence matters: you need policy/procedures and technical artifacts that prove keys are managed as designed.

SC-12 applies whenever you use cryptography in a system: TLS, database encryption, disk encryption, token signing, S/MIME, VPNs, SSH, code signing, secrets wrapping, or application-layer encryption. The control is simple to say and hard to operationalize because keys sprawl across environments and owners. Some keys live in managed KMS platforms, some sit in HSMs, and others hide inside application configs, CI/CD variables, third-party SaaS consoles, or legacy appliances.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate SC-12 into a small set of non-negotiables: a single key management standard, an inventory of keys and key stores, role-based access control for key operations, defined rotation and revocation triggers, and repeatable evidence. You are not trying to “do crypto.” You are making key custody auditable and resilient so confidentiality and integrity don’t hinge on tribal knowledge in a single engineering team.

This page gives requirement-level guidance you can hand to platform, security engineering, and app owners to implement quickly and defend in an assessment against NIST SP 800-53 Rev. 5. ¹

Regulatory text

Requirement (SC-12): “Establish and manage cryptographic keys when cryptography is employed within the system in accordance with the following key management requirements: {{ insert: param, sc-12_odp }}.” ²

Operator interpretation of the text:

• If your system uses cryptography, you must have defined, implemented key management requirements for that system. ¹
• “Establish” covers how keys are created or agreed (for example, key generation, key exchange, key derivation, enrollment, or issuance).
• “Manage” covers everything after creation: storage, access, use, rotation, backup/escrow (where appropriate), revocation, recovery, and destruction.
• The placeholder sc-12_odp indicates organization-defined parameters (ODPs). Practically, you must define your own standards (for example, rotation triggers, approved key stores, and separation of duties) and then follow them consistently.

Plain-English interpretation (what SC-12 means in practice)

You need a key management lifecycle that is (1) documented, (2) assigned to accountable owners, and (3) enforced through technical controls. If an engineer can generate a key, copy it to a laptop, and keep using it indefinitely without detection, you have not met the intent.

SC-12 typically fails in two ways:

1. Key sprawl without inventory (you cannot prove what keys exist, where they live, who can operate them, or what they protect).
2. Policy without proof (a key management policy exists, but rotation, access control, and revocation are not consistently implemented in the actual platforms).

Who it applies to

Entity scope:

• Federal information systems and contractor systems handling federal data that adopt NIST SP 800-53 Rev. 5 as the control baseline. ¹

Operational scope (where SC-12 shows up):

• Cloud KMS (AWS KMS, Azure Key Vault, Google Cloud KMS), HSMs, on-prem key managers.
• PKI environments (internal CAs, certificate issuance, mTLS).
• Application signing keys (JWT signing, SAML signing, OAuth client secrets where treated as keys).
• Storage encryption keys (database TDE, disk/volume encryption, backup encryption).
• Third-party SaaS encryption controls (customer-managed keys, bring-your-own-key features).
• DevOps and CI/CD secret stores when they hold crypto material (private keys, signing keys).

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

1) Define your “key management requirements” (your ODPs)

Create a short, enforceable Key Management Standard that answers:

• Approved key storage: KMS/HSM requirements; no local storage of private keys except documented exceptions.
• Approved algorithms and key sizes (reference your crypto standard; keep this as a pointer rather than rewriting crypto guidance).
• Key lifecycle states: requested → issued/generated → active → rotated → retired → revoked → destroyed.
• Rotation expectations: define triggers (time-based, personnel change, suspected compromise, system change, certificate expiry).
• Access control rules: who can create keys, rotate, disable, schedule deletion, and export (if export is allowed at all).
• Logging/monitoring requirements for key operations.

Output: Key Management Policy + Key Management Standard (system/applicable-scope language).

2) Assign ownership and separation of duties

For each key store and key type, document:

• Control owner: usually Security/Platform Security or IAM.
• Key custodians/operators: cloud platform team, PKI team, SRE.
• Approvers: change management or security for high-impact keys.
• Break-glass process: tightly controlled emergency access for key operations.

Practical rule: the team that writes application code should not be the only team able to export or delete production root keys.

3) Build a key inventory that an auditor can test

Create a Cryptographic Key Inventory (spreadsheet or CMDB-backed) with:

• Key identifier and platform (KMS key ID, HSM slot, Vault path, certificate serial).
• What it protects (service/database/bucket/API, data classification).
• Environment (prod/non-prod).
• Owner and operator group.
• Rotation mechanism (automatic/manual) and triggers.
• Exportability and backup/escrow position (allowed or prohibited).
• Links to evidence (logs, screenshots, config exports).

Scope note: You do not need to list ephemeral session keys, but you do need to capture long-lived keys, KEKs, CA keys, signing keys, and encryption-at-rest master keys.

4) Enforce secure key establishment

Decide how keys are created/established by category:

• KMS/HSM-generated keys: prefer keys generated inside managed services or HSMs.
• PKI private keys: define where keypairs are generated (central CA/HSM vs endpoint) and how CSRs are handled.
• Key exchange and derivation: specify approved libraries and configurations for TLS/mTLS; enforce via configuration management.

Evidence expectations: configurations that show keys are non-exportable where required, and that private keys are not stored in code repos or CI logs.

5) Control key access and key operations

Implement RBAC so that key operations are permissioned explicitly:

• Create/enable/disable keys
• Rotate keys and versions
• Schedule deletion / destruction
• Export (ideally disabled for most keys)
• Modify key policy / access policy
• Grant/revoke usage permissions to workloads

Also require strong authentication for administrators of key systems and restrict access paths (for example, admin access only via hardened admin workstations or controlled jump hosts).

6) Implement rotation, revocation, and destruction workflows

Operationalize three runbooks:

• Rotation runbook: how to rotate without downtime (dual-key or versioned-key approach), how to update dependent services, how to validate.
• Revocation/compromise runbook: triggers, who decides, how to disable key usage fast, how to re-issue certificates, how to re-encrypt if required.
• Destruction runbook: criteria to retire, how to prove deletion (KMS scheduled deletion evidence, HSM zeroization record, CA key retirement record).

7) Centralize logging and review for key events

Turn on and retain logs for key operations:

• KMS/HSM audit logs
• Vault audit logs (if applicable)
• CA issuance/revocation logs
• Administrative access logs for consoles where key policies can change

Then define what gets reviewed (for example, alerts on disable/delete, policy changes, export attempts, high-risk admin actions).

8) Make it assessable: map SC-12 to procedures and recurring evidence

For audit readiness, maintain a single SC-12 control sheet that points to:

• Owner
• Procedure references
• Systems in scope
• Evidence produced each cycle (log extracts, access reviews, config snapshots)

Daydream is helpful here because teams often lose time chasing “where is the evidence” across cloud accounts and third parties. A simple SC-12 evidence map with recurring collection tasks prevents scramble-mode audits.

Required evidence and artifacts to retain

Maintain artifacts that show both design and operation:

Design / governance

• Key Management Policy and Key Management Standard (approved and current)
• Key lifecycle procedure(s): creation, rotation, revocation, destruction
• Role definitions and access model for key operations
• Exception register for any non-standard key storage or exportable keys

Operational evidence

• Cryptographic Key Inventory (current, with owners)
• Configuration exports or screenshots showing:
  • key policies / access policies
  • non-exportable settings (where applicable)
  • rotation configuration (automatic or scheduled procedure)
• Audit logs for key events (samples that include rotate/disable/delete/policy change)
• Access reviews for key administrator roles and key usage permissions
• Tickets or change records for key rotations and certificate renewals
• Incident records for any key compromise events and remediation actions (if applicable)

Common exam/audit questions and hangups

Auditors and assessors commonly press on:

• “Show me your key inventory. How do you know you found all keys that matter?”
• “Who can disable, delete, or export production keys? Show the role assignments.”
• “What is your rotation standard, and where is evidence that it happens?”
• “How do you handle key compromise? Who approves emergency rotation?”
• “Do third parties hold keys for systems processing federal data? How do you govern that?”

Hangup to anticipate: teams confuse secrets management with cryptographic key management. Passwords and API tokens matter, but SC-12 is specifically about cryptographic keys used by cryptographic mechanisms.

Frequent implementation mistakes (and how to avoid them)

1. No owner for PKI and certificates. Fix: assign a PKI service owner and track CA keys and issuance workflows in the key inventory.
2. Exportable master keys by default. Fix: require non-exportable keys for encryption-at-rest and signing keys unless an approved exception exists.
3. Rotation policy without a dependency plan. Fix: document how apps handle key versioning; require staged rollouts and validation steps.
4. Key deletion without recovery plan. Fix: require a destruction approval step and document recovery/rollback for services that depend on the key.
5. Third-party encryption left out of scope. Fix: include SaaS platforms that encrypt customer data; record who controls the keys (provider-managed vs customer-managed) and what evidence you can obtain.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for SC-12. Practically, SC-12 failures tend to show up as:

• Data exposure when keys are copied, shared, or left in code repositories.
• Integrity failures when signing keys are mismanaged.
• Outages when rotations or revocations are performed without dependency mapping.

From a risk register perspective, treat weak key management as a direct contributor to confidentiality and integrity risk across multiple systems, plus a control effectiveness issue during assessments against NIST SP 800-53 Rev. 5. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Name an SC-12 control owner and publish a draft Key Management Standard.
• Identify all approved key stores (KMS/HSM/Vault/PKI) and ban new ad-hoc key storage paths.
• Start a key inventory with “most critical first”: production encryption-at-rest master keys, CA keys, and signing keys.
• Turn on centralized logging for key operations where it is currently off.

Days 31–60 (make it repeatable)

• Implement RBAC for key administration and remove broad admin rights.
• Write and test runbooks for rotation, revocation/compromise, and destruction.
• Establish a rotation calendar or automation approach per key type; document exceptions.
• Add SC-12 evidence collection to your GRC cadence (access reviews, log samples, rotation proof).

Days 61–90 (close gaps and prep for assessment)

• Expand inventory coverage across remaining systems, including third-party SaaS with encryption features.
• Validate that key operations are logged and alertable; tune alerts for high-risk events (policy change, disable, delete, export).
• Run an internal tabletop for key compromise and emergency rotation.
• Package assessor-ready evidence: inventory, policies, runbooks, access reviews, and sampled logs tied to specific systems.

Frequently Asked Questions

Does SC-12 require an HSM?

SC-12 requires managed keys with defined requirements; it does not inherently mandate an HSM. If your risk posture or system categorization demands stronger controls, HSM-backed keys can be the simplest way to enforce non-exportability and separation of duties.

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

Include keys used for encryption and signing that persist beyond a single session: KMS master keys, data encryption keys when stored, CA private keys, JWT/SAML signing keys, SSH private keys used for automation, and private keys tied to certificates.

How do we handle customer-managed keys in a third-party SaaS?

Record the SaaS system in your key inventory with the key custody model (provider-managed vs customer-managed). Retain evidence of configuration and administrative access controls, plus any logs or attestations the provider makes available.

Our apps generate keys dynamically; do we have to inventory every key?

Inventory the systems and mechanisms that create and control keys, plus any long-lived root, master, or signing keys. Ephemeral session keys generally do not belong in the inventory, but the establishment method (for example TLS configuration) still needs to follow your standard.

What evidence is strongest for rotation?

Prefer system-generated evidence: KMS rotation settings, key version history, certificate renewal logs, and change records that show dependent services were updated. A policy statement alone rarely satisfies an assessor.

How do we operationalize SC-12 across multiple cloud accounts and business units?

Standardize on a small number of approved key management platforms, publish a single Key Management Standard, and require each platform team to produce the same evidence set. Daydream can track ownership and recurring evidence so SC-12 stays audit-ready as environments change.

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON