SC-12 Cryptographic Key Establishment and Management

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Low, Moderate, High	Organization	4 (1 in a baseline)

Related controls: AC-17, AU-9, AU-10, CM-3, IA-3, IA-7, IA-13, SA-4, SA-8, SA-9, SC-8, SC-11, SC-13, SC-17, SC-20, SC-37, SC-40, SI-3, SI-7

Control statement

Establish and manage cryptographic keys when cryptography is employed within the system in accordance with the following key management requirements: [Assignment: organization-defined requirements].

NIST discussion

Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Organizations define key management requirements in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and specify appropriate options, parameters, and levels. Organizations manage trust stores to ensure that only approved trust anchors are part of such trust stores. This includes certificates with visibility external to organizational systems and certificates related to the internal operations of systems. NIST CMVP and NIST CAVP provide additional information on validated cryptographic modules and algorithms that can be used in cryptographic key management and establishment.

Control enhancements

SC-12(1) Availability

Baselines: High

Maintain availability of information in the event of the loss of cryptographic keys by users.

Discussion and assessment objectives for SC-12(1)

Escrowing of encryption keys is a common practice for ensuring availability in the event of key loss. A forgotten passphrase is an example of losing a cryptographic key.

Determine if information availability is maintained in the event of the loss of cryptographic keys by users.

Examine: System and communications protection policy; procedures addressing cryptographic key establishment, management, and recovery; system design documentation; system configuration settings and associated documentation; system audit records; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities; organizational personnel with responsibilities for cryptographic key establishment or management.

Test: Mechanisms supporting and/or implementing cryptographic key establishment and management.

SC-12(2) Symmetric Keys

Baselines: Not in a baseline

Produce, control, and distribute symmetric cryptographic keys using [Selection: NIST FIPS-validated; NSA-approved] key management technology and processes.

Discussion and assessment objectives for SC-12(2)

SP 800-56A, SP 800-56B , and SP 800-56C provide guidance on cryptographic key establishment schemes and key derivation methods. SP 800-57-1, SP 800-57-2 , and SP 800-57-3 provide guidance on cryptographic key management.

Determine if:

• SC-12(02)[01] symmetric cryptographic keys are produced using [Selection: NIST FIPS-validated; NSA-approved] key management technology and processes;
• SC-12(02)[02] symmetric cryptographic keys are controlled using [Selection: NIST FIPS-validated; NSA-approved] key management technology and processes;
• SC-12(02)[03] symmetric cryptographic keys are distributed using [Selection: NIST FIPS-validated; NSA-approved] key management technology and processes.

Examine: System and communications protection policy; procedures addressing cryptographic key establishment and management; system design documentation; system configuration settings and associated documentation; system audit records; list of FIPS-validated cryptographic products; list of NSA-approved cryptographic products; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities; system developer; organizational personnel with responsibilities for cryptographic key establishment or management.

Test: Mechanisms supporting and/or implementing symmetric cryptographic key establishment and management.

SC-12(3) Asymmetric Keys

Baselines: Not in a baseline

Produce, control, and distribute asymmetric cryptographic keys using [Selection: NSA-approved key management technology and processes; prepositioned keying material; DoD-approved or DoD-issued Medium Assurance PKI certificates; DoD-approved or DoD-issued Medium Hardware Assurance PKI certificates and hardware security tokens that protect the user’s private key; certificates issued in accordance with organization-defined requirements].

Discussion and assessment objectives for SC-12(3)

SP 800-56A, SP 800-56B , and SP 800-56C provide guidance on cryptographic key establishment schemes and key derivation methods. SP 800-57-1, SP 800-57-2 , and SP 800-57-3 provide guidance on cryptographic key management.

Determine if:

• SC-12(03)[01] asymmetric cryptographic keys are produced using [Selection: NSA-approved key management technology and processes; prepositioned keying material; DoD-approved or DoD-issued Medium Assurance PKI certificates; DoD-approved or DoD-issued Medium Hardware Assurance PKI certificates and hardware security tokens that protect the user’s private key; certificates issued in accordance with organization-defined requirements];
• SC-12(03)[02] asymmetric cryptographic keys are controlled using [Selection: NSA-approved key management technology and processes; prepositioned keying material; DoD-approved or DoD-issued Medium Assurance PKI certificates; DoD-approved or DoD-issued Medium Hardware Assurance PKI certificates and hardware security tokens that protect the user’s private key; certificates issued in accordance with organization-defined requirements];
• SC-12(03)[03] asymmetric cryptographic keys are distributed using [Selection: NSA-approved key management technology and processes; prepositioned keying material; DoD-approved or DoD-issued Medium Assurance PKI certificates; DoD-approved or DoD-issued Medium Hardware Assurance PKI certificates and hardware security tokens that protect the user’s private key; certificates issued in accordance with organization-defined requirements].

Examine: System and communications protection policy; procedures addressing cryptographic key establishment and management; system design documentation; system configuration settings and associated documentation; system audit records; list of NSA-approved cryptographic products; list of approved PKI Class 3 and Class 4 certificates; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities; system developer; organizational personnel with responsibilities for cryptographic key establishment or management; organizational personnel with responsibilities for PKI certificates.

Test: Mechanisms supporting and/or implementing asymmetric cryptographic key establishment and management.

SC-12(6) Physical Control of Keys

Baselines: Not in a baseline

Maintain physical control of cryptographic keys when stored information is encrypted by external service providers.

Discussion and assessment objectives for SC-12(6)

For organizations that use external service providers (e.g., cloud service or data center providers), physical control of cryptographic keys provides additional assurance that information stored by such external providers is not subject to unauthorized disclosure or modification.

Determine if physical control of cryptographic keys is maintained when stored information is encrypted by external service providers.

Examine: System and communications protection policy; procedures addressing cryptographic key establishment, management, and recovery; system design documentation; system configuration settings and associated documentation; system audit records; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities; organizational personnel with responsibilities for cryptographic key establishment or management.

Test: Mechanisms supporting and/or implementing cryptographic key establishment and management.

Withdrawn enhancements: SC-12(4), SC-12(5).

Assessment objectives (SP 800-53A)

Objectives and methods for SC-12

Determine if:

• SC-12[01] cryptographic keys are established when cryptography is employed within the system in accordance with [Assignment: organization-defined requirements];
• SC-12[02] cryptographic keys are managed when cryptography is employed within the system in accordance with [Assignment: organization-defined requirements].

Examine: System and communications protection policy; procedures addressing cryptographic key establishment and management; system design documentation; cryptographic mechanisms; system configuration settings and associated documentation; system audit records; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities; organizational personnel with responsibilities for cryptographic key establishment and/or management.

Test: Mechanisms supporting and/or implementing cryptographic key establishment and management.

Policy statement

• The System owner shall establish and manage cryptographic keys, wherever the system employs cryptography, in accordance with Fill in: requirements for key generation, distribution, storage, access, and destruction Typical: the requirements for key generation, distribution, storage, access and destruction in the encryption and key management standard. (SC-12)

SC-12(1) Availability

• The System owner shall maintain the availability of information when users lose cryptographic keys. (SC-12(1))

From the System and Communications Protection Policy template (draft). Highlighted fields are values your organization sets.

How to apply it

SC-12 asks you to set key management requirements and follow them wherever the system uses cryptography: how keys are generated, distributed, stored, accessed, replaced and destroyed. It supports every control that uses cryptography, such as SC-8, SC-13, SC-17 and SC-28: encryption is only as strong as the protection of its keys. NIST’s discussion adds that organizations manage trust stores so that only approved trust anchors are in them, both for certificates seen outside the organization and for those used inside its systems. The encryption and key management standard covers trust stores in its certificates section, which also serves SC-17.

Common implementations. A cloud key management service or hardware security modules generate and hold the keys, inside validated cryptographic modules, and rotate them on a schedule. Applications get keys and secrets at run time from the key management service or a secrets manager, never from source code, configuration files or container images. Access policies separate the custodians who administer a key from the services that use it, and every use and administrative action is logged. The key management function keeps a key inventory and a compromise plan. The encryption and key management standard sets each of these as a requirement, with a table of maximum periods of use by key type.

NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1 – General (May 2020), is the current final revision and the usual reference for cryptoperiods and the key life cycle; the standard’s example periods follow its Table 1. A sixth revision was published as an initial public draft on December 5, 2025; its comment period closed on February 5, 2026, and no final had been published (as of September 2026). NIST’s SC-12 discussion points to the Cryptographic Module Validation Program and the Cryptographic Algorithm Validation Program for modules and algorithms that can be used in key management.

Organization-defined parameters. Typical value, from the System and Communications Protection policy, which your organization may set differently:

Parameter	Typical value
Key management requirements	The requirements for key generation, distribution, storage, access and destruction in the encryption and key management standard

The policy points to the standard rather than repeating it, so the standard’s key management section is what an assessor tests against. Keep the two in step.

Evidence assessors ask for.

• The encryption and key management standard, and any system-specific key management procedure
• The key inventory for the system: purpose, algorithm and length, location, owner, custodians, creation date and next replacement date
• Key management service or hardware security module configuration: key policies, rotation settings and who holds each permission
• Logs of key use and administrative actions, and evidence someone reviews them
• Evidence that keys are replaced on schedule, and a sample of destroyed keys with their destruction record
• The key compromise plan
• The approved trust anchors, and the trust stores the organization manages
• For High, the escrow or recovery arrangement for keys that protect stored information, and the record of a recovery test (SC-12(1))

Inheritance. The cloud provider’s key management service and hardware security modules, and the organization’s certificate authority, are usually common controls or inherited from the provider. The system owns its key inventory, the access policy on each of its keys and how its own code gets keys, so SC-12 is usually a hybrid control. Where keys are provider-managed by default, record whether the system uses provider-managed or customer-managed keys for each store in its system security plan.

Common findings.

• Keys, passwords or API secrets in source code, configuration files or container images.
• Keys stored alongside the information they protect, or usable by every administrator.
• No key inventory, so nobody can say which keys protect which information or when they were last replaced.
• Keys and secrets that have never been rotated, including after the people who knew them left.
• Backup encryption keys held only in the environment the backups are meant to restore, so a disaster takes both.

Enhancements in the Moderate baseline. SC-12 has no enhancements in the Moderate baseline. High adds SC-12(1) availability. SC-12(2) symmetric keys, SC-12(3) asymmetric keys and SC-12(6) physical control of keys are in no baseline. SC-12(4) and SC-12(5) are withdrawn.

• SC-12(1) requires that information stay available when users lose their keys. NIST’s discussion names key escrow as the common practice, and a forgotten passphrase as an example of a lost key. The policy’s clause has no parameters; the encryption and key management standard meets it by escrowing or backing up the keys that protect stored information, such as the recovery keys for full-disk encryption. Test recovery before it is needed.

Federal systems (as of September 2026). FIPS 140-3 (March 22, 2019) applies to federal agencies that use cryptography-based security systems to protect sensitive information, and modules validated by NIST’s Cryptographic Module Validation Program are considered to conform to it. The program’s FIPS 140-3 transition page sets September 22, 2026 as the date all FIPS 140-2 certificates are placed on the Historical List; see SC-13 for what that means for existing and new systems. The encryption and key management standard requires keys to be generated and stored in approved modules, and its federal block requires modules validated by the program for cryptography that protects sensitive information.

Artifacts

• Encryption and Key Management Standard
• System and Communications Protection Decision Worksheet
• System and Communications Protection Policy