SC-12 key establishment and management: evidence

What SC-12 asks for and why key management fails audits

An assessor who asks how your keys are generated, stored, rotated and destroyed is testing SC-12, the base control in the System and Communications Protection family that requires you to establish and manage cryptographic keys whenever cryptography is used in the system, according to defined key management requirements. The control does not ask whether encryption is turned on. It asks whether you can show who controls each key, where it lives, how it is replaced and how it is retired. Encryption switched on is not the same as keys under control. A volume can be encrypted with a flawless algorithm and still fail the review if the key sits in a configuration file on the same host, if no one can say who holds administrative rights over the key store, or if rotation has never happened since deployment.

Keys are the weak point because they sit at the junction of every other control. The same key material touches access control, audit records, backups, certificates and service accounts, so a gap in one place breaks the chain of custody elsewhere. The work is hard for three practical reasons: keys are created by many tools (databases, object stores, application frameworks, certificate authorities), no single system shows the full inventory, and key lifecycle events such as rotation and destruction are rarely written down as procedures someone runs. Before any assessment, confirm with your system owner which cryptographic uses exist in the boundary, which key store is authoritative for each, and what the documented requirements for generation, rotation and destruction say. The assessment procedures in SP 800-53A examine the system design documentation and configuration settings, so gaps between documentation and actual settings are where findings usually start.

For systems at the high baseline, SC-12 selects enhancement (1), which concerns key availability, meaning the organization must be able to keep keys accessible and recoverable when needed, for example through escrow or backup of key material held under appropriate protection. Losing a key can be as damaging as exposing one, so recovery testing belongs in the plan. FedRAMP's Rev5 baselines also require SC-12 at Classes B, C and D, and add SC-12(1) at Class D. At this level of explanation, the practical point is that a Class D assessor will expect key availability to be designed and tested, not only documented. Confirm the current FedRAMP requirements with the FedRAMP documentation and your authorizing body before you scope the work, since these requirements change with FedRAMP's rule updates.

Which keys, systems and teams SC-12 reaches

SC-12 looks like one control, but the work depends on which keys exist, which systems and backups rely on them, and who generates or holds them. Each decision below changes the evidence an assessor will ask for, so settle them in writing before mapping procedures.

Data encryption and key encryption keys

Data encryption keys (DEKs) encrypt content, while key encryption keys (KEKs) wrap the DEKs. Decide which layer each platform uses, where the KEK lives and who can unwrap a DEK. For example, if a file server holds both DEKs and the KEK in the same host, a single compromise exposes stored data. Check whether rotating a KEK re-wraps DEKs or requires re-encrypting data, and record that answer in the key management requirements SC-12 expects.

TLS private keys and certificate authorities

TLS private keys, internal certificate authorities and their signing keys all fall under key establishment and management. Inventory each certificate's issuer, owner, validity period and storage location, including certificates on load balancers, reverse proxies and internal services. Confirm who can issue certificates and how revoked or expired keys are removed from service. Self-hosted certificate authorities such as FreeIPA's Dogtag-based CA need their own key protection and backup procedure.

Signing keys and code-signing material

Keys that sign software releases, container images, configuration files and audit exports are often managed outside the main key inventory. Identify which pipelines hold signing keys, whether signing happens on shared runners and who can trigger a signature. A signing key compromise affects every artifact it produced, so the scope should cover the signing hierarchy, the approval steps for use and the procedure for revoking trust in a compromised key.

API tokens and service secrets

Service accounts, API tokens and database credentials are secrets that automated jobs read at runtime. Some assessors treat them as key material, and automated secret handling is a theme in FedRAMP's 20x indicators that cite SC-12. Find where secrets are stored, including CI/CD variables, configuration files and developer repositories. Scan committed code for exposed secrets and confirm that rotation can happen without an outage.

Backups, replicas and the teams holding keys

Backups and replicas of encrypted data are only recoverable if their keys are also backed up, and those key copies extend the scope. List every backup target, the key material it needs and whether keys are escrowed offline. Then name the teams and third parties that generate, hold or can access keys, including platform operators, managed service providers and hardware security module vendors. Each party with access should appear in the access and responsibility records.

How an assessor tests SC-12 key management

This table walks through how an assessor applies the two SP 800-53A determination statements for SC-12 using the examine, interview and test methods. Read each row as the question the assessor asks, the evidence to prepare, and the gap that most often delays a finding.

Assessment element	What the assessor does	Evidence to prepare	Common finding
Determination statement 1: key management requirements	Examine the defined key management requirements and confirm the organization-defined parameter in SC-12 is filled in with specific, testable values	Approved key management policy or standard with the organization-defined parameter completed, plus the system security plan entry for SC-12	Parameter left as a placeholder or described only in general terms
Determination statement 2: keys established and managed to those requirements	Sample keys across their lifecycle and confirm each was generated, distributed, stored, accessed, rotated and destroyed as the requirements state	Key inventory, generation and rotation records, access logs and destruction records for sampled keys	Keys with no owner, no recorded rotation, or key material stored outside the defined mechanism
Examine: cryptographic mechanisms	Review the cryptographic mechanisms in use and confirm each one is covered by the key management requirements	Mechanism list (for example encryption at rest, transport and signing) mapped to key stores	Mechanisms added after the policy was written and never brought under it
Examine: system design documentation and configuration settings	Compare the design and configuration with the stated key management requirements, including key store location and access paths	Architecture diagrams, key store configuration exports and documented key hierarchy	Configuration that differs from the documented design or defaults left unchanged
Examine: audit records	Check that key creation, access, rotation and destruction events are logged and that the logs can be reviewed	Sample audit records for key events and the review record showing who reviewed them	Key events not logged or logs held where the system administrators can alter them
Interview: key custodians and system administrators	Ask who generates, stores, rotates and destroys keys and how they are trained and authorized	Named key custodians, role assignments and records of how responsibilities are handed over	Staff unsure of the procedure or relying on one person with no documented backup
Test: key generation, rotation and destruction	Observe or reproduce a rotation or revocation on a non-production key and check that the old key can no longer be used	Test records, screenshots or command output from the test, and results of the rotation check	Rotation documented in policy but never exercised, or old keys still decrypting data
Key availability enhancement (SC-12(1), high baseline and FedRAMP Class D)	Confirm that the organization can keep keys available for the period the requirements define, including recovery of keys after loss	Backup and recovery procedure for key material, restore test results and the defined availability requirement	Key backups stored with the data they protect, or restores never tested
FedRAMP annual assessment (Classes B, C and D)	Expect SC-12 to be tested in a FedRAMP independent assessment every year, so evidence must be repeatable	Evidence refreshed each cycle and a change log showing how key procedures changed between assessments	Evidence collected once for the initial authorization and not kept current

Implementing cryptographic key management step by step

This sequence turns SC-12 from a policy statement into a working key lifecycle that an assessor can trace from requirement to system configuration to audit record. Each step names the artifact that closes it, so the organization owns a body of evidence rather than a single document.

Define key management requirements and the parameter
The organization writes its key management requirements and sets the organization-defined parameter in SC-12, which names the standard or framework the keys must follow. Security governance owns this step, with architecture and compliance reviewing it. It is closed when a key management standard is approved, it names the cryptographic uses it covers (data in transit, data at rest, signing, certificates, and secrets), and the parameter value is recorded in the system security and privacy plan. Confirm the exact parameter wording and any applicable FedRAMP or agency requirements with your authorizing official before approval.
Inventory keys, certificates and owners
Engineering builds a register of every key, certificate and secret the system uses, including the cryptographic use, the system component that holds it, the named owner and the expiry or rotation date where one exists. Discovery usually depends on configuration scans, certificate discovery tools and reviews of application code and infrastructure definitions. The step is closed when the register is reconciled against the system inventory and each entry has an owner, because assessors test keys they can trace to a person and a purpose.
Select key stores and generation methods
Architects choose where keys are generated, stored and used, separating long-lived master keys from application keys and deciding which keys may leave a hardware or managed boundary. For self-hosted environments, open-source options such as OpenBao can hold encryption keys and perform cryptographic operations through its transit secrets engine without exposing key material to applications. Certificate issuance can run through FreeIPA, which includes an integrated certificate authority based on Dogtag. The step is closed by an architecture decision record listing each key store, its approved algorithms and the cryptographic modules in use. Confirm FIPS validation status of any module with the vendor before stating it in the plan.
Set rotation, retirement and destruction rules
The security team writes the rules that govern when each key class is rotated, how old key versions are retired, and how keys and copies are destroyed when they are no longer needed. Rules differ by key type, so a certificate authority signing key will not follow the same schedule as an application data key. OpenBao supports versioned encryption keys with key rotation, which lets older ciphertext remain readable while new data uses the current version. The step is closed when the rules are documented, configured in the key store and tied to change tickets, so an assessor can see the rule and the system behavior matching it.
Restrict access to keys and key operations
Administrators grant key access through named roles, separate key administration from key use, and limit who can export, delete or change key policy. Identity systems and the key store's own policy engine enforce these rules, and privileged sessions are logged. Secret scanning in the delivery pipeline helps catch keys committed to source control: GitLab Community Edition runs pipeline secret detection on committed and pushed files and writes findings to a gl-secret-detection-report.json artifact. The step is closed when access reviews produce a list of key principals and their rights, and the scan report shows no unmanaged secrets in the repositories in scope.
Test key recovery and availability
Operations teams test whether keys can be restored from backup, whether a failed key store can be replaced, and whether encrypted data remains readable after rotation and recovery. Recovery tests belong in the contingency plan, and results must be recorded with the system's recovery objectives. Confirm with your assessor which key availability enhancement applies to your impact level, because the high baseline and FedRAMP Class D select a stronger form of this requirement. The step is closed by a signed test record showing what was restored, how long the restore took against the stated objective, and any corrective actions opened.
Collect evidence and prepare for assessment
The compliance lead assembles the artifacts that show SC-12 operating: the approved key management standard, the key register, architecture decisions, rotation and destruction records, access review results, secret scan reports, audit log extracts for key operations and recovery test records. Each artifact is mapped to the SP 800-53A determination statements and examine objects for SC-12, so the assessor can follow the trail without reconstruction. Independent assessors, not the implementation partner, decide whether the evidence satisfies the control. The step is closed when the evidence index is complete, dated and stored under change control.

Evidence that passes an SC-12 assessment

An assessor testing SC-12 looks for proof that keys are managed under defined requirements and that the organization can show it. The cards below cover the artifacts that connect policy to what the key stores actually do, and they should be kept current between annual assessments rather than rebuilt for each one.

Key management standard or procedure

This is the written requirement the assessment measures against. It should define key types, approved algorithms and key lengths, who owns each key class, and the lifecycle stages from generation through destruction. Check that it names the systems in scope and that it is approved by a responsible owner with a review date. An assessor will compare configuration and logs against this document, so any gap between the written rule and the running system becomes a finding.

Cryptographic key inventory

An inventory lists every key, certificate and secret used by the system, with its purpose, location, owner, algorithm, creation date and next rotation date. Assessors use it to confirm that cryptography in use is the cryptography the organization meant to run. Build it from the key stores themselves, not from memory, and reconcile it against deployed services at each review so keys that were created for a test or a retired application do not stay active.

Key store configuration settings

Configuration exports from the systems that hold keys show how the standard is implemented, such as the secrets engine settings, key versions allowed, minimum key lengths and access policies. Collect these as dated exports or version-controlled files so the assessor sees the state at the time of the test. Check that the settings match the procedure and that any default that weakens the standard has been changed.

Key access and audit records

Audit records of key creation, use, export and administrative change show who touched key material and when. Assessors sample these records to test whether access follows the procedure and whether unexpected use is detected. Confirm that the logs are protected from modification, retained for the period the organization has defined, and reviewed by someone other than the key administrator.

Rotation and destruction records

Rotation and destruction records prove that keys are replaced and retired as the procedure requires. For each rotation, keep the old and new key version identifiers, the date, the approver and any re-encryption performed. For destruction, keep evidence that the key material was removed from every store and backup it reached. Gaps here are common, because rotation often happens automatically while destruction is handled manually.

Key recovery test results

Recovery test results show that encrypted data can still be read after a key store failure, restore or key loss, which is the reason the SC-12(1) availability enhancement exists at the high baseline and at FedRAMP Class D. Record the scenario tested, the steps taken, the time to restore and any defects found. Retest after significant changes to the key store, and treat a failed restore as an open item in the plan of action and milestones until it is fixed.

What meeting SC-12 costs in money and effort

This table breaks the cost of meeting SC-12 into components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No price or duration is given because none has been supplied, so use the table to structure a written quote and to see where open-source tooling removes license spend.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Key management tooling or licenses	Software vendor or open-source project maintainers (open-source components carry no license fee)	Recurring if commercial licenses or support contracts apply; open-source removes license spend but not support needs	Number of key stores, whether the product is commercial or self-hosted open source, and whether support is bought separately
Engineering time to design and migrate keys	Internal staff or implementation partner under a fixed-scope agreement	One-time	Number of systems using cryptography, age of existing key handling, and whether keys are hardcoded or scattered across configuration
Configuration of key generation, storage and access	Internal staff or implementation partner	One-time, with periodic changes	Required key types, access separation between key custodians and applications, and integration with identity and logging
Key rotation and destruction procedures	Internal operations staff, sometimes with partner help to script and test	One-time to build, recurring to run	Rotation frequency set by the organization's key management requirements and the number of keys in scope
Evidence upkeep	Internal compliance and engineering staff	Recurring	Frequency of audit record review, volume of key events logged, and how much evidence is generated automatically
Key availability enhancement (SC-12(1), high baseline and FedRAMP Class D)	Internal platform team, cloud or data center providers for redundancy	One-time design, recurring operation	Redundancy design, backup and recovery testing, and whether the organization runs its own infrastructure
External testing or review	Independent assessor or security testing firm	Recurring, often annual	Scope of key management tested, number of systems, and whether the assessor interviews staff and examines configurations
Auditor sampling and assessment	Independent assessor or certification body	Recurring with each assessment cycle	Number of key stores and key lifecycle events sampled, and the quality of records available on request

Open-source tools that produce SC-12 evidence

SC-12 is satisfied by documented, enforced key management, and the evidence an assessor reviews comes from the systems that hold, rotate and certify keys. The four tools below each cover one part of that lifecycle, and none of them makes an organization's key management policy compliant on its own.

Versioned keys and rotation in OpenBao

The OpenBao transit secrets engine encrypts and decrypts application data without storing the data itself, and it keeps versioned encryption keys with rotation support. For SC-12, this gives assessors a central place to show who holds key material, how keys are rotated and where cryptographic operations happen. Check whether your applications can call the engine for their encryption, confirm the rotation interval your policy requires, and confirm that your chosen configuration meets any FIPS-validated cryptography expectations set by your authorizing body.

Server-side encryption limits in Nextcloud

Nextcloud server-side encryption protects file contents at rest on local and external storage, with the keys kept on the server. It does not encrypt file names or folder structure, so those metadata remain visible to anyone with access to the storage. For SC-12, the evidence is the key configuration and the documented key lifecycle, and the metadata gap must be recorded as a known limit in your system security plan. Confirm which key mode you enable, who can recover keys and how key material is backed up.

Secret detection reports in GitLab

GitLab Community Edition pipeline secret detection scans files committed and pushed to the repository inside a CI/CD job. It writes detected secrets to a gl-secret-detection-report.json job artifact, which can be retained as evidence that hard-coded keys and credentials are being caught before release. This supports the SC-12 expectation that key material is not exposed in code. Confirm that the job runs on every branch that can reach production, decide who reviews the report, and confirm how findings are triaged and rotated.

Certificate issuance with FreeIPA and Dogtag

FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates. For SC-12, it provides the record of certificate issuance, renewal and revocation that supports the certificate portion of key management. Assessors will expect the certificate policy, the issuing authority hierarchy and the revocation process to be documented alongside the logs. Confirm that your certificate profiles match your policy, that the CA signing keys are protected and that the platform fits your existing trust store and PKI design.

Who owns SC-12 work: your team, a partner and the auditor

Your organization owns SC-12. Leadership must decide what cryptography the system uses, which key management requirements apply, and who is accountable for keys across their lifecycle. Those decisions belong to your security, platform and application owners, and no partner or auditor can make them on your behalf. Your team also operates the key store day to day and keeps the records that show it.

Requirements and ownership: Define the key management requirements the SC-12 text refers to, name an owner for each key class, and document who approves key creation, rotation and destruction.
Key store operation: Run the key management service, manage its administrators and monitor its access logs.
Rotation and recovery: Own scheduled rotation, emergency revocation and the recovery steps you test.
Evidence: Keep configuration exports, access reviews and key lifecycle records current so an assessor can examine them.
Decisions on FedRAMP Class D: If the system is at Class D, confirm internally how the SC-12(1) availability enhancement is met.

Ask whether every key class has a named owner and a documented lifecycle before any outside party is engaged.

SC-12 questions buyers ask before hiring help

How much effort does SC-12 take to meet?

The effort depends on how many systems use cryptography, how many key types exist and how much key management is already documented and automated. SC-12 applies whenever cryptography is used in the system, so the first job is an inventory of every place keys are created, stored, used and destroyed: TLS certificates, database and storage encryption keys, application signing keys, API secrets and backup keys. Costs have three parts: the organization's staff time to supply system knowledge and approve decisions, the implementation partner's fixed-scope work to build or configure key management, and the independent assessor's fee for testing. No researched figure for effort is available here, so ask any partner to break its quote into these parts and to state which systems and key types are in scope. Recurring effort includes key rotation reviews, access reviews and evidence collection for each annual assessment.

How long does SC-12 implementation take?

Timeline is set mainly by how many key stores and key lifecycles need to be brought under a defined policy, and by how much the organization already has in place. Work usually runs in order: define key management requirements, inventory keys, select or configure a key store, migrate or document existing keys, then produce evidence that the process runs. Approval cycles, change windows for production systems and availability of system owners often take longer than the technical work. No duration is supplied for this control, so ask a partner for a written schedule tied to the scope and confirm which milestones depend on your change board. Also confirm whether an assessment is already booked, because assessor scheduling affects when evidence must be ready.

What does SC-12 require from our own staff?

Your staff own the decisions. The organization must define its key management requirements, decide who may access which keys, approve rotation and destruction practices and accept residual risk. Your engineers must explain how each system uses cryptography, including where keys are generated and which applications read them. Security and compliance staff must review the policy, access lists and logs, and support the assessor during interviews. A partner can prepare configurations, runbooks and evidence, but it cannot make these decisions for you. Ask any partner to name the internal roles it needs, how many hours each role is expected to give, and who signs off the final documentation.

Can our own team implement SC-12 without outside help?

Yes, an internal team can implement SC-12 if it has people who understand cryptographic key lifecycles, operates the platforms that use keys and can produce evidence an assessor will accept. The main gaps organizations report are unclear ownership of keys across teams, keys stored in configuration files or repositories, and no logging of key access. Outside help is most useful when the scope is large, when several platforms have separate key stores, or when the team needs a fixed deliverable with a deadline. Whatever you choose, the independent assessor will test the outcome, so do an internal readiness check against the examine, interview and test methods in SP 800-53A before deciding.

How do key availability and FedRAMP Class D change SC-12 work?

At the high baseline, SP 800-53B adds enhancement SC-12(1), which concerns maintaining availability of keys so that encrypted data stays accessible. FedRAMP's Rev5 baselines also require SC-12(1) at Class D, on top of SC-12 at Classes B, C and D. In practice this means you need documented key backup and recovery, tested restoration of key material, and a plan for key loss or hardware failure. Testing recovery is a separate workload that recurs, and it should be planned with the contingency team. Before scoping, confirm your system's impact level or FedRAMP class with your authorizing official or FedRAMP documentation, because that choice determines the required enhancements.

What should a fixed-scope quote for SC-12 include?

A useful quote states the systems, key types and environments in scope, the controls and enhancements covered (SC-12, and SC-12(1) if your baseline selects it), and the deliverables by name. Ask for the key inventory, the key management policy and procedures, configured key stores, access and rotation runbooks, backup and recovery test records, and an evidence index mapped to the assessment objects. The quote should list what is excluded, such as application code changes, third-party key services or the independent assessment itself, and who performs each task. It should also state assumptions about access to systems and staff time, the acceptance criteria for each deliverable, and what recurring support is available after handover. DeployOpen plans and implements work under written scope, and quotes follow from that scope.

How DeployOpen prepares SC-12 key management evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, including the key stores and secrets tooling that SC-12 depends on. We prepare systems and evidence for an assessment, while the organization owns its key management decisions and an independent assessor tests them.

How we scope

Scope agreed in writing before work starts, listing which systems, key types and cryptographic uses SC-12 covers
Key management requirements documented by the organization, which we map to each platform component
Confirmation of whether the target baseline includes SC-12(1) for key availability, with written deliverables for that enhancement

How we build

Self-hosted key management and secret services configured in the client's cloud accounts, data centers or air-gapped networks
Key generation, storage, access, rotation and destruction procedures implemented as configuration and tested against the documented requirements
Audit logging of key use and administrative changes enabled so assessors can examine the records

How we hand over

Documentation of key lifecycle procedures, configuration settings and ownership, prepared for examination by the assessor
Test results for key rotation, recovery and access restriction, with any open gaps recorded in a plan of action and milestones
Handover sessions so the client's staff can operate, review and update the key management setup independently

How we support

Ongoing support, upgrades and continuous testing available as a retainer after handover
Periodic review of key inventories, rotation records and access lists as systems change
Confirmation with the client's assessor of which evidence they expect, so that preparation matches the assessment procedure

SC-12 Cryptographic key establishment and management