SC.L2-3.13.10 Key management: requirements and evidence

SC.L2-3.13.10 key management: what the requirement asks for

If you are the compliance lead or engineer who must prove that keys are handled properly, start with this: SC.L2-3.13.10 asks your organization to establish cryptographic keys whenever cryptography is employed and to manage them across their life cycle. The CMMC Level 2 version matches NIST SP 800-171 Rev. 2 requirement 3.13.10, a derived requirement in the System and Communications Protection family. NIST SP 800-171A splits it into two assessment objectives: one for establishing keys and one for managing them, each applied wherever cryptography is used. In the CMMC scoring methodology it is a 1-point requirement, so it carries little weight in your score but still has to be met.

The risk is simple. Encryption is only as strong as the keys behind it. A key that is exposed, shared between systems that should be separate, reused beyond its purpose, or never rotated can make ciphertext readable to anyone who obtains it. The practical difficulty is that keys rarely sit in one place. They end up in application configuration files, container images, CI/CD variables, service accounts, database connection settings, hardware or cloud key stores, and backups that were never considered when the encryption was switched on. An assessor will ask where every key lives, who can use it, and how it was created, which is why the inventory of keys is usually the first piece of work.

Before your assessment, confirm three things in your own environment. First, list every system that performs encryption, signing or certificate-based authentication, and record which keys it uses. Second, confirm that the key life cycle is documented, covering creation, distribution, active use, expiry and revocation, and that records of these steps exist. Third, decide whether a small number of keys can be handled through documented manual procedures or whether a key management system is needed to show secure creation and protection throughout that life cycle, as the CMMC Assessment Guide for Level 2 describes. Open-source options such as OpenBao's transit secrets engine can support key rotation and versioning, and FreeIPA includes a certificate authority, but confirm each product's fit with your environment before you rely on it.

Which keys, systems and teams fall under key management

SC.L2-3.13.10 applies wherever the organization uses cryptography to protect CUI, so the key inventory starts with the systems and services that encrypt that data, not with a single key vault. The cards below cover the key types, the teams and third parties that create or hold keys, and the scoping checks that decide how much work lands in the assessment. Confirm the current CMMC status and phase with the Department of War before budgeting, since Phase II was suspended on 13 July 2026.

TLS certificates and their private keys

Every TLS endpoint that carries CUI needs a certificate and a private key, and each one has an issuer, an expiry date and a renewal owner. Scope covers public web portals, internal service endpoints, load balancers and mail gateways. Check whether certificates are issued by an internal CA, a public CA or a hosting provider, and who can export private keys. Expired or orphaned certificates are a common finding because nobody owns their renewal.

Disk and database encryption keys

Full-disk, volume and database encryption each rely on keys that unlock stored CUI, so these keys sit squarely in scope for SC.L2-3.13.16 and SC.L2-3.13.10 together. Record where each key is held, whether it is wrapped by a master key, and how it is recovered after a hardware failure. Confirm that recovery copies are protected to the same standard as the working keys, and that decommissioned volumes have their keys destroyed.

Application encryption and secrets

Applications that encrypt fields, tokens or files on their own behalf create keys that often live in configuration files or environment variables. Inventory these keys by application and owner, and check whether they can be rotated without a code change. A secrets engine or key management service can centralize them, but the inventory must still show which applications depend on which key version.

Code signing and build pipeline keys

Keys that sign software packages, container images and firmware are high-value because a compromised signing key lets an attacker publish trusted code. Identify which build systems hold signing keys, whether signing happens on a dedicated host or inside a shared pipeline, and who approves a signing request. Secret scanning in CI/CD helps catch keys committed to source repositories, but it does not replace a controlled signing process.

SSH keys and service account credentials

Administrative SSH keys, deploy keys and service account credentials grant access to systems that handle CUI, and they tend to accumulate without expiry or ownership. List every authorized key on administrative hosts, tie each to a named person or service, and set a review cycle for removals. Departing staff and retired automation are the usual sources of stale keys, so the scope should include the offboarding checklist.

Backup and third-party held keys

Backup encryption keys, cloud key management services, managed service provider consoles and hosting partner tooling may create or hold keys that protect CUI outside the organization's own servers. Ask each provider where keys are generated, who can administer them, and how key material is exported or destroyed at contract end. Shared responsibility terms should state these answers in writing, because the organization remains accountable for the keys its providers hold on its behalf.

How an assessor tests key management for CMMC Level 2

This table compares the two assessment objectives for SC.L2-3.13.10 and shows what an assessor tests, requests and usually finds for each. Read it as a checklist of what must exist before the assessment, since a requirement is MET only when every applicable objective is satisfied with evidence in final form.

Element	Establishing cryptographic keys	Managing cryptographic keys
Assessment objective	Keys are established whenever cryptography is employed in the system	Keys are managed whenever cryptography is employed in the system
What the assessor tests	How keys are generated, the mechanisms that create them and whether creation is secure	How keys are stored, rotated, retired and revoked across their active, expired and revoked states
Test approach	Review key establishment procedures and walk through the mechanism that creates a sample key	Review management procedures, inspect key inventory and test lifecycle changes against the documented process
Evidence requested	Written key establishment procedure, key generation configuration, cryptographic mechanism records and audit records of key creation	Key management procedure, key inventory, rotation and revocation records, and audit records of key state changes
Small estate (illustrative)	Manual procedures may be accepted for a small number of keys if steps are documented and repeatable	Manual tracking sheet with dated rotation and revocation entries, kept current and in final form
Larger estate	A key management system showing keys are created securely	A key management system showing protection across active, expired and revoked states
Common findings	Keys generated ad hoc with no documented procedure or no record of who created them	Expired or revoked keys still in use, no inventory, or draft procedures presented as current practice

How to implement key management in sequence

This sequence takes an organization from an unknown set of cryptographic uses to a key management practice that can be tested and shown to an assessor. Each step produces a record that the next step depends on, so the evidence trail builds as the work progresses.

Inventory every cryptographic use and key
List every system, application, service, device and integration in the CUI environment that uses cryptography, including TLS endpoints, VPNs, database and disk encryption, code signing, backup encryption, API tokens and certificates. For each entry, record the algorithm and module, the key or certificate, where the key lives, who or what uses it and its expiration. The step is done when the inventory is reviewed against network diagrams and asset records and no cryptographic use is left unlisted. Mismatches between the inventory and what the system actually runs are the first findings an assessor will look for.
Define key ownership and roles
Assign a named owner for each key class and each key store, plus a custodian who performs generation, rotation and revocation and a separate approver for high-impact actions. Separate duties so that no single administrator can create, use and destroy a key without a second party. Write the assignments into the key policy and the system security plan so they match the organization's personnel and access records. The output is a signed key policy that states who may establish, manage, retire and destroy each key class.
Select how keys are generated and stored
Choose a storage approach for each key class based on how many keys exist. The CMMC Assessment Guide Level 2 indicates that a small number of keys can be handled with documented manual procedures, while a larger population usually needs a key management system that shows keys are created securely and protected through their active, expired and revoked states. Confirm with the platform vendor whether the chosen tool generates keys in a validated module and how it protects key material at rest. Open-source options such as OpenBao, which provides a transit secrets engine with versioned keys and rotation, or FreeIPA, which includes a Dogtag-based certificate authority, can cover parts of this need, but each must be checked against the organization's own requirements. The output is a documented storage decision per key class, with the reasons recorded.
Configure rotation and revocation rules
Set rules for how often each key class is rotated, what triggers an immediate rotation (suspected compromise, staff departure, a vendor incident) and how a key is revoked and removed from services that trust it. Configure the key store or certificate authority to enforce these rules where it supports them, and document a manual procedure where it does not. Confirm that rotation does not leave encrypted data unreadable, so older key versions remain available for decryption until the data is re-encrypted. The output is a rotation and revocation standard plus configuration exports that show the rules in force.
Document and test the procedures
Write runbooks for generating, distributing, rotating, revoking, backing up and destroying keys, and for recovering when a key store is lost. Test each runbook in a non-production environment and record the results, including the steps that failed and how they were corrected. Testing should cover at least one rotation and one revocation end to end, with checks that services continue to work after the change. Confirm that backups of key material are themselves protected, since the CMMC media protection requirements also apply to them. The output is a set of approved runbooks and dated test records.
Connect module choices to SC.L2-3.13.11
Review the cryptographic modules used for key generation and storage against the FIPS-validated cryptography expectations in SC.L2-3.13.11, which applies wherever cryptography protects CUI confidentiality. An approved algorithm alone does not satisfy that requirement, so record the validation certificate of each module in use and confirm it covers the module as configured. Note any module that cannot be validated and address it in the plan of action where the scoring rules allow. The output is a module register that links each key store to its validation status.
Collect recurring evidence in an evidence log
Establish a log that captures key generations, rotations, revocations, access approvals, failed operations and key store audit events, and retain it according to the organization's audit record policy. Schedule periodic reviews of the key inventory to catch keys that were added without being recorded. Store the evidence in final form, since assessors accept only completed records and not drafts. The output is a maintained evidence log and a review record for each period, which together show that key management operates continuously and not only at the time of an assessment.

Evidence that passes a key management review

An assessor testing SC.L2-3.13.10 checks two things: that keys are established whenever cryptography is used, and that they are managed across their life cycle. The six artifacts below show both, and each needs a named owner and a recurring review so the evidence is still accurate when the assessor arrives. Assessors accept only final-form evidence, so drafts of these documents will not count toward a MET finding.

Key inventory

A current register listing every cryptographic key or key pair in scope, with its purpose, the system or data it protects, the algorithm and key length, the storage location, the custodian, and its state (active, expired or revoked). Assessors use the inventory to choose keys to trace, so gaps here lead to deeper sampling. Include keys inside applications, databases, backup tools and certificate authorities, not only the ones your team manages directly. Review the inventory each quarter and after any new system enters the boundary. Name the security engineering lead as owner. Confirm with your assessor how they expect a small environment to document keys managed manually.

Key management policy and procedures

The written rules for how keys are generated, distributed, stored, rotated, revoked, backed up and destroyed, including which approved mechanisms apply and who may approve exceptions. Assessors compare what the procedures say with what the configuration and logs show, so each procedure should name a system or tool that actually performs the step. Note that a procedure for manual key handling is acceptable for a small number of keys, but it must still describe creation, storage and destruction. Review annually and after any change in platform. The compliance lead owns the document and the technical owner signs off on its accuracy.

System configuration for generation and storage

Screenshots, configuration exports and command output showing how keys are generated and where they are held. For a key management system, this means the engine's settings for key type, length, access policies and the seal or unseal method. For file encryption, it means the encryption module status and the location of the server-side keys. Assessors look for keys that are created securely and protected throughout their life cycle, not just stored in a file next to the data. Capture these exports after every platform upgrade and retain them with dates. The platform engineering team owns the export process.

Key rotation and revocation records

Tickets, change records or automated logs that show each rotation and each revocation, with the old key version, the new version, the date and the approver. Assessors look for evidence that rotation happens on the schedule the procedure sets and that revoked keys are no longer used for encryption. A versioned key engine keeps prior key versions, so confirm that revoked versions can decrypt only where policy allows. Review rotation records monthly against the inventory and reconcile any key that has passed its scheduled date. The operations lead owns this record set.

Audit logs of key use and changes

Logs that record each key creation, use, policy change, export attempt and deletion, with the identity that performed the action and a reliable timestamp. Assessors sample these logs to confirm that key use matches the approved purposes and that changes went through the documented process. Forward key-engine logs to the central log platform so they cannot be altered by the administrators they describe. Review a sample weekly and investigate any use outside an approved service identity. The security operations lead owns the review and records each review as evidence.

Access records for key custodians

Current lists of the people and service identities allowed to create, read, rotate or unseal keys, with the approval for each grant and the date of its last review. Assessors compare these lists with directory groups and the key engine's policies, looking for shared accounts, stale custodians and administrators who can both approve and use a key. Separate custodial duties where possible and require multifactor authentication for interactive custody actions. Recertify custodian access each quarter and remove access the day a person changes role or leaves. The identity administrator owns the list and the security manager approves each recertification.

What key management costs to meet

This table breaks down the cost components of meeting SC.L2-3.13.10 Key management, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No figures are stated because none are supplied for this requirement, so use the drivers and quote questions to compare proposals. The main takeaway is that open-source tooling mostly moves spend from licenses to engineering and operations effort.

Cost component	Who is paid	One-time or recurring	What drives it
Tooling or licenses	Software vendor or none if open source	Recurring if commercial, one-time setup otherwise	Number of keys and systems, support tier, whether a key management system is already licensed
Engineering time to inventory and configure	Internal staff or implementation partner	One-time	Count of cryptographic uses across systems, cloud or on-premises placement, existing tooling
Procedure writing	Internal compliance staff or consultant	One-time, then reviewed on a cycle	Number of key types, custodians, and whether manual procedures cover a small key set
Evidence upkeep	Internal staff	Recurring	Frequency of key rotation, revocation events, and log retention for key activity
External review or testing	Independent assessor or security testing firm	Recurring around assessments	Scope of the key management system, number of integrations, and depth of testing requested
Auditor sampling	Certified third-party assessor	Recurring per assessment	Number of keys and systems sampled, and how complete the key inventory and logs are
Open-source platform operations	Internal platform or operations team	Recurring	Hosting footprint, upgrade cadence, high availability design, and backup and recovery testing of key stores

How self-hosted open-source tools support key management evidence

Self-hosted open-source tools can produce useful evidence for SC.L2-3.13.10, but each one covers only part of the key life cycle, and none of them settles the FIPS question on its own. OpenBao, licensed under MPL-2.0, is the most direct fit for centrally managed keys. Its transit secrets engine lets applications send data for encryption and decryption without the service storing that data, and it keeps versioned encryption keys that can be rotated. An assessor will want to see who created each key, where it lives, how rotation is scheduled, and how retired versions are handled, so the audit log and policy configuration for the engine are the artifacts to preserve.

Nextcloud, licensed under AGPL-3.0-only, uses server-side encryption to protect file contents at rest on local and external storage, with the keys held on the server. That is a key management decision in its own right: the organization must decide whether server-held keys meet its risk position for CUI, and it must record that decision in the system security plan. Confirm the exact encryption and key recovery settings in the admin documentation for the version you deploy. Also note the limit: file names and folder structure are not encrypted, so any CUI that appears in names or paths needs a separate control.

FreeIPA, licensed under GPL-3.0-or-later, includes an integrated certificate authority based on Dogtag for issuing and managing certificates, which covers the certificate portion of key management for internal services. Evidence here includes the CA hierarchy, issuance and revocation records, and the roles allowed to approve requests. GitLab Community Edition, licensed under MIT, adds a different kind of evidence: pipeline secret detection scans committed and pushed files in a CI/CD job and writes findings to a gl-secret-detection-report.json artifact in every tier, which helps show that keys are not left in repositories. Retain those reports, and confirm which rules and scan coverage apply to your projects. Finally, the organization must confirm that the cryptographic modules in each product meet the FIPS validation requirements that apply to the rest of the system, because an approved algorithm alone does not satisfy SC.L2-3.13.11.

Who owns key management and what a partner can take on

Your organization owns SC.L2-3.13.10 from start to finish. The obligation to establish and manage cryptographic keys sits with the company that operates the system holding CUI, and no vendor or consultant can accept it on your behalf. Your team sets the key management policy, decides which cryptographic uses are in scope, and signs off on the evidence the assessment will rely on.

Policy and standards: Write a key management policy that defines who may create, rotate, revoke and destroy keys, and which algorithms and FIPS-validated modules are approved.
Key custodians: Name individuals accountable for high-value keys, and document separation between people who hold key material and people who administer the systems that use it.
Risk decisions: Decide how to handle any keys that a key management system cannot cover, such as a small number of keys managed manually, and record the rationale and compensating steps.
Final sign-off: Approve the system security plan language, the list of key-using components and the final evidence package before submission.

Before the assessment, confirm that someone inside the company can explain every key-using component and name the owner of each key without relying on the consultant.

Common gaps in key management and how to close them

Most key management failures in a CMMC assessment are not missing technology. They are keys nobody owns, secrets copied into places they should not be, and procedures that exist only on paper. The cards below name the gaps assessors most often find under SC.L2-3.13.10 and the closing action for each.

Keys with no named owner

A key that no person or team is accountable for cannot be rotated, revoked or justified when it is found. Assessors look for an inventory that lists each key, its purpose, the system it protects and the role responsible for its life cycle. Close it by assigning an owner to every key in the inventory, including keys held by vendors, and recording who approves creation and retirement. Check that the owner can actually state where the key is used.

Service account keys in scripts

Credentials and encryption keys embedded in scripts, configuration files or CI jobs are hard to find, hard to rotate and often shared across systems. Source control makes the problem worse because old commits keep the value. Close it by moving keys into a managed store and running secret detection on repositories. GitLab Community Edition pipeline secret detection writes findings to a gl-secret-detection-report.json artifact, which gives you a starting point for the search. Confirm that scanning covers history, not only new commits.

No rotation or revocation record

Assessors expect evidence that keys move through active, expired and revoked states, not just that keys exist. A key that was never rotated, or was replaced without a record, shows that the life cycle is not managed. Close it by setting a rotation schedule for each key class and logging every rotation and revocation with date, reason and approver. Keep the log in a form an assessor can sample. Where keys are versioned, confirm that old versions remain decryptable only for the period you need.

Backups holding unmanaged keys

Backup sets often contain key material, configuration exports or encrypted volumes whose keys are stored alongside them or are not in the key inventory at all. A restore then depends on a key nobody tracks. Close it by including key stores in the backup plan, encrypting key backups under a separately managed key, and testing a restore that requires the keys to be recovered from the backup. Record who can perform the recovery and under what approval.

Keys stored beside the data

When the encryption key sits on the same disk, in the same directory or in the same database row as the data it protects, encryption adds little protection against anyone who can read that storage. Close it by keeping keys in a separate key management system or hardware-backed store with its own access control and audit logging. For Nextcloud server-side encryption, note that keys are kept on the server, so confirm where that key material lives and who can reach it. Document the separation in the system security plan.

Policies no one runs

A key management policy that describes generation, rotation and destruction steps that staff do not follow will fail testing as soon as an assessor compares it with records. Close it by writing the procedure from what your team actually does, then running a sample walkthrough and keeping its output as evidence. Assessors also accept that a small number of keys may be managed manually, but the manual steps must still be written, repeatable and recorded. Review the procedure against real tickets or logs before scheduling the assessment.

Key management questions buyers ask before hiring help

How much effort does key management for CMMC SC.L2-3.13.10 take?

The effort depends mostly on how many systems use cryptography and how those keys are created, stored and rotated today. The assessment guide accepts manual procedures for a small number of keys, but once keys are spread across storage encryption, TLS certificates, backups and application secrets, the work shifts toward a documented key management system with clear life cycle states for active, expired and revoked keys. Ask any partner to inventory every cryptographic use in the boundary first, because that inventory sets the scope of the remaining work. Tools such as OpenBao's transit secrets engine can hold versioned keys and rotate them, and FreeIPA includes an integrated certificate authority based on Dogtag, but each platform still needs configuration, access rules and evidence collection.

Can a small team handle CMMC key management in-house?

A small team can often handle it in-house if the environment is small, the number of keys is limited and someone owns cryptography decisions end to end. The requirement asks for two things: keys are established whenever cryptography is used, and they are managed throughout their life. Manual procedures are acceptable for a small key set, provided the procedure is written, followed and leaves records. The harder parts for a small team are usually consistency across systems, documenting key custody, and proving that revoked or expired keys are no longer used. Before deciding, check whether your staff can produce the evidence described in the assessment objectives, not just run the systems.

How long does SC.L2-3.13.10 key management work take?

No duration is fixed for this requirement, so treat any date you are quoted as an estimate to test against your own environment. The main drivers are the number of cryptographic systems in the boundary, whether key management already exists or must be built, how many teams must agree on procedures, and how much history you need to show. Work that proves a process has operated over time generally takes longer than writing the procedure. Ask the partner to break the timeline into inventory, design, implementation, evidence collection and review, and to state which steps depend on your staff's availability. Confirm the schedule against the system security plan and any active assessment deadline.

What must our team provide before a partner starts key management work?

Your team must supply access to the systems that use cryptography, the current documentation of key handling, and named owners who can approve decisions. Typical inputs include an inventory of encrypted storage, TLS endpoints, backup encryption, signing keys and application secrets, plus the existing system security plan and any relevant policies. Your team should also provide change approval paths and a place to store evidence in final form, since only final evidence counts toward a MET result under the assessment rules. Confirm access accounts, change windows and who signs off on key rotation before work begins, so the partner is not waiting on approvals during implementation.

Can a consultant or implementation partner issue our CMMC assessment result?

No. A partner can prepare systems, procedures and evidence for SC.L2-3.13.10, but it cannot issue an assessment result, certificate or attestation. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, and your organization owns its controls and its own score submissions. Keep the roles separate in your contract: the partner delivers configured systems, documented procedures and an evidence package, and the independent assessor evaluates them. Also confirm that the partner will not assess its own work for the same assessment, since independence is part of the process.

Can SC.L2-3.13.10 go on a POA&M, and what are the deadlines?

Yes, under the stated rule, SC.L2-3.13.10 is a 1-point requirement that is not on the exclusion list, so it may be placed on a plan of action and milestones (POA&M) for Conditional Level 2 status if the total score is at least 88 of 110. The closeout for the POA&M item is due within 180 days. Treat this as a conditional option rather than a plan. Confirm with your contracting officer and assessor how the rule applies to your situation, and note that the Department of War suspended Phase II in July 2026 while a review is underway, so check the current rule text before relying on the POA&M path.

What should a written scope for key management include?

A written scope should name every system and cryptographic use covered, the keys and key types in each, and the life cycle states you expect to manage. It should list deliverables such as a key inventory, key management procedures, configured key systems, rotation and revocation records, and an evidence index mapped to the two assessment objectives for SC.L2-3.13.10. Ask for explicit exclusions, the owner of each step, acceptance criteria, change control, and the process for handling findings. Require a fixed or clearly bounded schedule and a statement of what happens if the environment changes during the work. Your quote should follow from that scope, so ask for a fee breakdown by deliverable rather than a single lump number.

How DeployOpen scopes and prepares key management evidence

DeployOpen works on SC.L2-3.13.10 key management inside the client's own infrastructure, starting from a written scope. We prepare the systems, key procedures and evidence that an assessor reviews, while the organization keeps ownership of its controls and independent assessors issue any findings.

How we scope

Inventory every system and workflow where cryptography is used, so key establishment and management are covered for each one
Agree in writing which key types, key stores and life cycle states (active, expired, revoked) fall inside the engagement
Confirm with the client which keys are managed manually and which move to a key management system, and why

How we build

Deploy self-hosted key management components, such as a transit secrets engine with versioned keys and rotation, in the client's environment
Configure key rotation, expiry and revocation procedures and test that they run as documented
Check that secrets are kept out of repositories and pipelines, using scanning tools where the client's workflow supports them

How we hand over

Deliver key management procedures, configuration records and test results in final form for the client's review
Document the key inventory, ownership and life cycle records that an assessor would ask to see
Walk the client's team through the evidence so they can show it and maintain it without us

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer after handover
Assessment decisions stay with the client's assessor, and DeployOpen does not issue reports or certifications