SC-12, Cryptographic Key Establishment and Management, asks the organization to establish and manage cryptographic keys, when cryptography is used in the system, according to key management requirements it defines. The requirements are yours to write.
800-53 binds US federal systems, and others through contract. For small and mid size companies it is a reference, and key handling is a favorite subject of security reviews because encryption is only as good as its keys.
What it means in practice
The guidance says key management can be manual, or automated with supporting manual procedures. You define the requirements in line with applicable laws and standards, choosing options, parameters and levels. It also asks you to manage trust stores so only approved trust anchors are in them. That covers certificates visible outside your systems and certificates used inside them.
For validated modules and algorithms, the record points to NIST CMVP and CAVP.
Key management is a life cycle: generation, distribution, storage, use, rotation, revocation and destruction. SC-12 is the control that asks whether you thought about each stage.
The enhancements are specific: SC-12.1 Availability, SC-12.2 Symmetric Keys, SC-12.3 Asymmetric Keys, SC-12.4 PKI Certificates, SC-12.5 PKI Certificates / Hardware Tokens and SC-12.6 Physical Control of Keys. SC-12.1 matters more than it looks, since losing a key can mean losing the data it protects.
Evidence to collect
- A key management standard with generation, storage, rotation, revocation and destruction rules.
- A key inventory: purpose, location, owner, algorithm, creation date, rotation date.
- Configuration from your key management service or hardware module showing access controls and rotation settings.
- Audit logs of key use and administrative actions.
- The trust store policy and a list of approved certificate authorities.
- A certificate inventory with expiry dates and renewal records.
- Backup and recovery tests for keys.
Common gaps
Keys in source code, environment files or chat. Scanning repositories for secrets is a quick way to find out.
No rotation. A key created at launch and still in use years later.
Everyone can use every key. Separate the right to use a key from the right to administer it.
Expired certificates that cause outages, which usually means there is no inventory.
An unmanaged trust store on servers and build machines, with extra certificate authorities added long ago.
Strong algorithm, weak handling. See SC-13 for the algorithm side.
How to implement it
- Write the requirements: key sizes, rotation periods, who may administer, how keys are backed up.
- Move keys into a managed key service or hardware module, and remove copies from code and files.
- Turn on automatic rotation where the service supports it.
- Restrict and log key access by role.
- Inventory certificates and automate renewal.
- Test recovery, since a backup that has never been restored is unproven.
- Review the trust store yearly and remove anything you cannot justify.
Quick check
What does the guidance say about trust stores?
Organizations manage them so that only approved trust anchors are included, covering both externally visible certificates and those for internal operations.
Can key management be manual?
Yes. The guidance allows manual procedures or automated mechanisms with supporting manual procedures.
