03.13.10 Cryptographic key management: what it requires

03.13.10 cryptographic key establishment and management: what the requirement asks for

03.13.10 requires the organization to establish and manage cryptographic keys in the system in accordance with organization-defined key management requirements. Under Rev. 3, the organization writes those requirements itself, so the assessor will test two things: whether the rules exist, and whether the system actually follows them. Encryption is only as strong as the control over its keys. A CUI file encrypted with a strong algorithm offers little protection if the key sits in a shared configuration file, is readable by every administrator, or was never retired when a system was decommissioned. This is why key management is often the weakest point in an otherwise well-encrypted environment.

The source control for 03.13.10 is SC-12 from SP 800-53 Rev. 5, which covers cryptographic key establishment and management as a control family in its own right. The Rev. 3 discussion of 03.13.10 points to 03.13.11 for the types of cryptography to use, so the two requirements should be read together: 03.13.11 decides which algorithms and modules are acceptable, and 03.13.10 decides how keys for them are generated, distributed, stored, accessed and destroyed. Practitioners still working from Rev. 2 will find this as 3.13.10, with the CMMC practice SC.L2-3.13.10 worth 1 point in the scoring methodology under 32 CFR 170.24.

Most organizations struggle here for three predictable reasons. The organization-defined parameter for key management has not been written down, so there is no standard to test against. Keys are scattered across application configuration, cloud consoles, backup tools and developer repositories, with no inventory of who holds what. And destruction is rarely evidenced, so there are no records showing when a key was retired or whether copies were removed. Before any assessment, confirm with your assessor which key management requirements they expect to see documented, then build an inventory of every key that protects CUI and map each one to an owner, a storage location and a retirement procedure.

Which keys, systems and people fall under 03.13.10

Scoping decides how much work 03.13.10 creates. The organization must define key management requirements for every key that protects CUI, then show that those requirements are followed by the teams and third parties that touch keys. The cards below cover the scoping choices that most often change the effort.

Keys that protect CUI

Start with an inventory of every key that encrypts or decrypts CUI, both at rest and in transit. This includes disk and volume keys, database and object storage keys, TLS private keys on services that carry CUI, and keys used for backups and media. Each key family needs its own documented generation, storage, access and destruction rules under the organization-defined parameter. Ask for a list tying each key to the system and CUI flow it protects, because keys without an owner are the usual gap an assessor finds first.

Keys held in cloud or hardware modules

Keys held in a cloud key service or a hardware security module are often assumed to be out of scope because the provider runs them. They are still in scope for the organization's key management requirements. Document which service holds each key, who can administer it, how access is logged, and how the provider's controls are inherited or shared. Confirm with the provider which key lifecycle steps are configurable by the customer and which are fixed, because that decides what the organization must write down itself.

PKI and certificate authorities

Any internal certificate authority that issues keys for CUI systems falls under 03.13.10, including its signing keys, issuance policy and revocation process. Identify whether the organization runs its own authority, uses a managed service, or relies on a public authority for externally facing services. Internal authorities add the most effort because the organization must document root and intermediate key ceremonies, storage of the signing keys and how certificates are renewed and revoked. Open-source options such as FreeIPA include an integrated certificate authority based on Dogtag, which should be checked against the organization's own requirements.

Service and automation keys

API tokens, deployment credentials, signing keys for pipelines and keys used by automated jobs are easy to miss because no person uses them directly. Each one that can reach CUI needs a defined owner, rotation schedule and destruction step when the service is retired. Pipeline secret detection can help find committed secrets, but it does not replace a key register. Ask the team how many automated keys exist and whether any are shared between environments, since shared service keys complicate access review and key destruction.

People with key custodian roles

Identify who holds key custodian roles, who approves generation and destruction, and who can recover keys after an incident. Security, platform engineering and application owners usually share these duties, so the scope should name a person for each step rather than a team alone. Interviews are part of the assessment, so the named people must be able to explain their responsibilities. Confirm that custodian duties are separated from routine administration and that the organization keeps records of who held each role and when.

Third parties that handle keys

Managed service providers, hosting companies and software vendors that generate, store or rotate keys on the organization's behalf must have their key handling documented in the scope. Request each provider's key management description, the locations where keys are held, the access their staff have, and how keys are destroyed at contract end. Where the provider's documentation does not cover a requirement, the organization must still show how it manages that gap. Treat these provider records as evidence to collect early, since they often take longer to obtain than internal records.

Writing the key management rules that 03.13.10 depends on

Rev. 3 introduced organization-defined parameters, and 03.13.10 has exactly one: the key management requirements that the system must follow for key generation, distribution, storage, access and destruction. NIST does not assign values to that parameter. A federal agency that contracts with you may specify them. If it does not, the requirement is not complete until your organization assigns the values itself, and an assessor will look for those values written down before testing anything else. Treat the parameter as a document you must author, not a setting you can inherit.

A usable set of rules states, for each lifecycle stage, what is required, who decides, and what evidence proves it. For generation, name the approved generator and the strength of keys it must produce. For distribution, state how keys leave the system and whether they may travel in clear form at all. For storage, specify where keys live (a hardware module, a key management service or a vault) and forbid keys in source repositories, configuration files or tickets. For access, name the roles allowed to use or export keys and require that access be logged and reviewed. For destruction, define when keys retire, how old versions are kept to decrypt existing data, and how destruction is verified. Each rule should map to a configuration you can show an assessor, such as the rotation setting in OpenBao's transit secrets engine, which supports versioned keys and key rotation, or a secret detection job in GitLab that reports committed secrets in a gl-secret-detection-report.json artifact.

Before you finalize the values, confirm which set your contract applies. The FAR overhaul proposed rule published 23 June 2026 would require contractors handling CUI to use SP 800-171 Rev. 3 with ODP values published by the DoW CIO. That rule was not final as of October 2026, and a DoW class deviation currently has contracting officers name Rev. 2. Ask your contracting officer in writing which Rev. 3 values, if any, apply to your contract, and record the answer in your system security plan. If the agency supplies no values, document your own, have leadership approve them, and keep the approval as evidence. The NIST SP 800-171 Rev. 3 publication is the reference for the parameter wording.

How an assessor tests 03.13.10 and what they ask to see

This table breaks down how an assessor works through 03.13.10 under SP 800-171A Rev. 3, row by row, with the method, the objects they examine, the people they interview and the mechanisms they test. Read it as a list of what to have ready before the assessment starts, since gaps usually appear when the key lifecycle cannot be shown end to end.

Assessment element	What the assessor does	Evidence to have ready	Common findings
Determination statements	Confirms that cryptographic keys are established and managed in the system under the organization's defined key management requirements, and that the ODP values are defined	Written key management requirements that name generation, distribution, storage, access and destruction, with values filled in for each	ODP values left as placeholders or left to the federal agency that never specified them
Examine method	Reviews the system and communications protection policy and the procedures for key establishment and management	Approved policy and procedure documents, with owners and review dates	Procedures that describe a key process the system does not actually follow
Examine method (design and settings)	Reviews system design documentation and configuration settings that govern how keys are created, stored and rotated	Architecture diagrams showing key stores, key services and trust relationships, plus exported configuration for key services	Design documents that omit where keys live, such as backups, build pipelines or application config files
Interview method	Talks with personnel responsible for key establishment and management	Named key custodians, their responsibilities and records showing they performed key tasks	Responsibility held by one person with no documented backup or handover
Interview method (security)	Talks with personnel who hold information security responsibilities about how key management is monitored and reviewed	Review records, access review outputs and any exceptions raised for key handling	Security staff describe key handling differently from the written procedure
Test method	Examines the mechanisms that implement key establishment and management and checks they behave as the procedures state	Test results showing key generation, rotation, access restriction and destruction on the live or representative system	Keys stored in plain configuration files, shared credentials or keys that are never rotated or retired
Destruction and retirement	Checks how keys are retired and destroyed when they expire, are compromised or are no longer needed	Destruction logs, rotation history and retirement records tied to specific key identifiers	No record that old keys or backup copies of keys were removed
Access to key material	Checks who can read, use or export keys and whether that access is limited and reviewed	Access control lists for key stores, access review records and evidence of removed access after role changes	Administrators with broad key access that no review has covered

The sequence for implementing 03.13.10 in the order assessors expect

This sequence moves from knowing which keys protect CUI, to defining the rules and owners for those keys, to building and testing the key store, so that the assessment evidence for 03.13.10 exists before an assessor asks for it.

Inventory every key-bearing system and key type
Start by listing each system in the CUI boundary that generates, stores, uses or destroys cryptographic keys, including TLS certificates, file encryption keys, database keys, backup keys, signing keys and SSH or API credentials. For each entry, record the key type, the system that holds it, the data it protects and whether that data is CUI. The output is a key inventory that the system security plan can reference. The step is done when someone outside the project team can trace every CUI-protecting key to an owning system.
Write key management rules and assign ODP values
03.13.10 has one organization-defined parameter covering requirements for key generation, distribution, storage, access and destruction, and the organization must assign those values because the requirement cannot be completed without them. Write a rules document with one section per lifecycle stage, stating what each stage must do for each key type in the inventory. Have the security owner approve it and record the approval date. The output is a signed key management standard that names the ODP values in plain terms.
Assign key custodians and access roles
Name a custodian for each key class and define which roles may generate, read, rotate, export or destroy keys. Separate the people who administer the key store from the people who administer the systems that use the keys wherever the environment allows it. Record these assignments in a role matrix and tie each role to a named individual or group. The output is an approved access matrix that an interviewer can compare against the live access list. The step is done when every key class in the inventory has an accountable custodian.
Choose and configure the key store or key service
Select the mechanism that will hold and manage keys for each class, such as a secrets and transit encryption service, a certificate authority, or the key handling built into the platform. Confirm with the vendor or project which key generation, rotation and export controls the chosen product supports, and document any gap that needs a compensating procedure. Build a configuration baseline that sets access policy, audit logging and key lifecycle options to the values in the rules document. The output is a configuration baseline stored under change control.
Set up rotation, distribution and destruction procedures
Write the operating procedures that carry the rules into daily work: how keys are rotated and when, how new keys reach the systems that depend on them, and how retired or compromised keys are destroyed and confirmed as destroyed. Test one full rotation and one destruction in a non-production environment and keep the logs. Where the platform keeps old key versions for decryption, document how those versions are retired. The output is a set of approved procedures plus a dated test record for each procedure.
Collect evidence and records for each determination
Assemble an evidence folder organized by the assessment objects for 03.13.10: policy and procedures, the key management standard, system design documentation, configuration settings, access lists, audit logs of key events, and the rotation and destruction records. Map each item to the determination it supports so that an assessor can move from statement to proof without help. Confirm that interview answers from custodians match what the records show. The output is an indexed evidence package that is current on the assessment date.
Run an internal test before the assessment
Before an external assessment, have a person who did not build the controls walk through the requirement as an assessor would. They should examine the documents, interview each custodian, and test the live configuration by attempting actions the rules prohibit, such as exporting a key without approval. Record each gap, assign a fix and retest it. The output is an internal test report with closed findings, and the step is complete when the remaining gaps are documented in the plan of action and milestones. Note that an independent assessor, not DeployOpen, issues any assessment result.

Which self-hosted open-source tools support the key evidence

Nextcloud's server-side encryption is a useful source of evidence for how file contents are protected at rest. Keys are held on the server, so the key lifecycle is controlled by the platform operator rather than by individual users. The gap matters for 03.13.10: file names and folder structure are not encrypted, so the organization's key management requirements must address that metadata separately, either through access restrictions, storage design or a documented decision that the metadata is not CUI.

Evidence it can produce: Configuration showing whether server-side encryption is enabled and which encryption module is active, taken from the administrator's configuration files and the encryption settings in the admin manual.
Key location: Documentation of where the server-held keys are stored, who can reach them, and how the key directory is protected at the operating system level.
Recovery and master key handling: Records of how a recovery key is created, stored and used, if the deployment enables that option.
Metadata gap: A written statement of what is encrypted (file contents) and what is not (file names and folder structure), with the compensating controls.
Storage scope: Confirmation of which local and external storage mounts are covered, since encryption behavior can differ by storage backend.

What to check: confirm the encryption mode, key storage path and recovery settings on your own instance, then have the key rules name who may enable, disable or rotate these keys and how changes are logged.

Evidence that passes 03.13.10 and how to keep it current

An assessor testing 03.13.10 looks for a written key management rule set, proof that keys are handled under it, and records showing the rules still hold. The cards below cover the artifacts that connect those three things, with the owner and refresh expectation for each. Refresh intervals are set by your own key management rules and assessment cycle, so confirm them with your assessor before the assessment begins.

Signed key management rules with ODP values

This is the written requirement the whole control rests on. Because 03.13.10 has one organization-defined parameter covering key generation, distribution, storage, access and destruction, the document must state the actual values your organization chose for each of those areas. Check that every value is specific enough for an engineer to implement and that an accountable executive has signed it. Review it at least annually and after any change in key stores or cryptographic libraries. Owner: the CISO or security architecture lead.

Cryptographic key inventory

An inventory lists every key, certificate and key store in scope, with its purpose, algorithm, location, creation date, rotation date and the system that uses it. Assessors use it to select samples and to confirm that no key sits outside the documented rules. Build it from configuration exports rather than memory, and reconcile it against the system security plan when systems change. Refresh it on every key or system change and at least quarterly. Owner: the system owner with platform engineering support.

Key custodian and access role assignments

Assessors ask who can generate, export, read or destroy keys, and they expect a short list of named roles with the people in them. Record custodians, approvers and break-glass holders separately, and confirm that no single person can both create and use a key without oversight. Compare the list against directory group membership, since drift between the document and the directory is a common finding. Review access at least quarterly and on every personnel change. Owner: the identity team, approved by the system owner.

Configuration baselines for key stores

Key stores such as hardware security modules, secrets engines and certificate authorities need documented configuration baselines covering encryption settings, audit logging, authentication methods and network exposure. Export the live configuration and compare it with the baseline so the evidence reflects the running system, not the design intent. Where the platform supports it, store the exports under version control so changes have a history. Recheck after every upgrade and at least quarterly. Owner: platform engineering.

Rotation and destruction logs

Rotation and destruction records prove that keys are retired on the schedule your rules set and that destroyed keys cannot be recovered from backups or replicas. Logs should show the key identifier, the action, the time, the actor and the approval reference. The OpenBao transit secrets engine supports versioned keys and key rotation, which can produce some of this history, but you should confirm what its audit device records in your deployment. Export logs monthly and retain them for the period your audit schedule requires. Owner: the key custodian role.

Interview-ready responsibility descriptions

Assessors interview the people who run key management, so each custodian should be able to explain their duties, the procedure they follow and the evidence they produce, without reading from a script. Keep a one-page responsibility description per role, tied to the procedures for key establishment and management, and rehearse it with each person before the assessment. Mismatches between what people say and what documents state are among the most common reasons a test is marked as not met. Refresh on every role change and before each assessment. Owner: the security compliance lead.

Records of exceptions

Any key that does not follow the signed rules, such as a legacy key pending migration or an emergency manual recovery, needs a dated exception record with the reason, the compensating measures, the approver and an expiry date. Assessors look for exceptions that were approved in advance and closed on time, and they treat undocumented deviations as failures. Track exceptions in the same register as plan of action and milestones items where you use one. Review open exceptions monthly and at each assessment. Owner: the system owner, with the CISO approving.

What meeting 03.13.10 costs in money and effort

This table breaks down the cost components of meeting 03.13.10 by who is paid, whether each cost is one-time or recurring, and what pushes it up or down. No official cost figure is supplied for this requirement, so use the rows to structure a written quote rather than as a budget.

Cost component	One-time or recurring	What drives it up or down
Licenses or managed key services	Setup one-time, subscription or usage fees recurring	Number of key types and tenants, cloud versus on-premises placement, and whether an existing key service is already licensed
Self-hosted open-source key tooling	Setup one-time, operations recurring	Removes most license spend but shifts cost to engineering hours for installation, high availability, backups and upgrades
Engineering time to configure key stores and rotation	One-time, with periodic rework	Number of systems that use keys, how many key types exist today, and whether rotation can be automated
Writing and approving key management rules and ODP values	One-time, with annual review recurring	Number of key categories, approval chains, and whether the federal agency has already supplied values
Evidence upkeep	Recurring	Frequency of key rotation and destruction events, log retention settings, and how often key inventories change
External testing or review of key handling	Periodic, scope-dependent	Scope of cryptographic testing, number of systems in the assessment boundary, and whether testing is folded into wider security testing
Assessor sampling of key records	Per assessment cycle	Number of key stores, rotation records and access reviews the assessor samples, and how well evidence is organized in advance
Third-party key custody or hosting	Recurring	Number of third parties that hold or process keys, and contract terms covering their key handling

Who owns 03.13.10, what a partner prepares and what the auditor tests

Your organization owns 03.13.10. The requirement asks that cryptographic keys be established and managed under key management requirements that the organization defines, so those requirements are yours to write, approve and enforce. Your security leadership is accountable for the rules, and the people who hold keys day to day carry the operational duties. Because the requirement has an organization-defined parameter, the decisions on what the key management requirements must say also sit with you, and a federal agency that does not specify values leaves that choice to you.

Ownership of the rules: Approve the key management requirements covering generation, distribution, storage, access and destruction, and keep them under document control.
Custodians: Name the people or service owners who hold key custodian duties, and record who may generate, rotate and retire each key class.
ODP decisions: Decide and record the values for the organization-defined parameter, with a rationale that an assessor can trace back to your CUI risk assessment.
Exceptions and review: Approve any deviation from the rules and review them on a schedule you set.
Staff and training: Ensure personnel with key management responsibilities understand their duties, since the assessor will interview them.

Before engaging any partner, confirm internally who signs the key management requirements and who is the accountable executive for the outcome.

Common questions about 03.13.10 cost, effort and outsourcing

How long does 03.13.10 key management work take?

The timeline depends on your environment, so ask for a schedule built from the written scope rather than a standard duration. The main drivers are how many systems hold or use CUI, how many key types exist, and whether keys are already managed centrally. A single application with a documented key hierarchy moves quickly. A mixed estate, where keys sit in configuration files, scripts and vendor consoles, takes longer because each location needs to be found, documented and brought under the same procedures. Work also waits on decisions the organization has not yet made, such as key lifetimes, who approves destruction and how key access is granted. The procedures and configuration settings an assessor examines cannot be finalized until those decisions are recorded, so each open decision extends the schedule. Ask the partner to list the systems in scope, the decisions it needs from you and the dates it depends on your team's responses.

Can our own team implement 03.13.10 without an outside partner?

Yes, if your team has the skills and capacity, because the organization defines and owns its own key management requirements. The work breaks into four parts: setting the key management requirements, configuring the systems that generate, store and use keys, producing the evidence and testing the mechanisms. Internal teams usually own the policy decisions and the approvals, while outside help is often used for configuration, hardening and evidence packs. Your team needs people who understand cryptographic key lifecycles, public key infrastructure and system configuration, plus a reviewer who did not build the solution. An assessor will check whether the people who run key management can explain the process consistently, so documentation that only the builders understand will not hold up. Outsourcing the build does not transfer accountability for the control, which stays with the organization.

What does the 03.13.10 work need from our staff?

Plan for named owners, access to records and time for reviews and interviews. The assessment method for 03.13.10 examines documents, interviews personnel and tests mechanisms, so your staff are part of the evidence. Expect to provide:

Named owners for key generation, distribution, storage, access and destruction, with backups for each role.
Access to system design documentation, configuration settings, change records and existing key procedures.
Time for interviews with personnel who run key establishment and management and with staff who hold information security responsibilities.
Approval of the organization-defined key management requirements, which the organization must set and record.
Participation in tests of the key mechanisms and sign-off on the results.

After go-live, the same people carry recurring duties such as reviewing key access, approving rotation and confirming that destruction happens as documented. Agree those duties before the work starts so the evidence stays current.

How do we set ODP values when the contract is silent?

The nonfederal organization sets them. NIST does not assign organization-defined parameter values, and if a federal agency does not specify them, the organization must assign them to complete the requirement. For 03.13.10, the parameter covers the key management requirements for generation, distribution, storage, access and destruction. Set those values in a key management standard approved by the accountable owner, and map each element to the systems where it applies. Record the rationale, because the assessment procedure checks that the parameter is defined. Ask the contracting officer in writing whether the agency specifies any values. A proposed FAR rule published on 23 June 2026 would require contractors handling CUI to use ODP values published by the DoW CIO, but it was not final as of October 2026, so confirm its current status. For DoD contracts, the DoW class deviation names SP 800-171 Revision 2, so confirm which revision your contract requires before you finalize values.

Can an implementation partner issue the 03.13.10 assessment result?

No. Only an independent auditor, assessor or certification body issues reports or certificates. An implementation partner prepares the systems, controls and evidence, and the organization remains responsible for its controls and for any score it submits. DeployOpen plans, implements and documents key management inside the client's own infrastructure and prepares evidence for an assessment, but it does not issue audit reports, attestations or certifications. Where a government assessment or a self-assessment applies, the organization submits the result and is responsible for its accuracy. Ask any partner to state in writing which tasks it performs and which the assessing party performs. Also arrange for someone independent of the implementation to review the evidence, since a team should not be the only check on its own work.

What should a quote for 03.13.10 include?

A quote should follow from a written scope that names the systems, key types and responsibilities involved. DeployOpen does not publish a price list, and a quote follows from the written scope, so use the scope as your checklist. Ask that it cover:

The systems and key types in scope, with each environment named.
The key management design for generation, distribution, storage, access and destruction, tied to the parameter values you set.
The implementation tasks, who performs each one and what the organization must provide.
The evidence to be produced, mapped to the examine, interview and test objects in the assessment procedure.
Testing and review steps, with clear acceptance criteria.
Dependencies on your team, including decisions and dates.
One-time work separated from recurring items such as key rotation support or a retainer.
Exclusions and the process for handling scope changes.

Compare quotes on these items rather than on total figures alone.

Which open-source tools can support 03.13.10 key management?

Several self-hosted tools cover parts of the key lifecycle, but none satisfies the requirement alone, so confirm each tool against your own parameter values. OpenBao's transit secrets engine encrypts and decrypts application data without storing it, signs and verifies data, and supports versioned encryption keys with rotation, which helps with generation, rotation and access control. FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates, which covers much of the certificate lifecycle. Nextcloud's server-side encryption keeps keys on the server, but it does not encrypt file names or folder structure, so document that limit. GitLab Community Edition's pipeline secret detection scans committed files and writes findings to a report artifact, which helps find keys stored in code but does not manage them. Confirm cryptographic module validation and the operational steps for each tool before you rely on it in the assessment.

How DeployOpen prepares 03.13.10 systems and evidence

We start by agreeing the scope in writing. For 03.13.10 that means identifying every system that generates, stores, distributes, uses or destroys cryptographic keys for CUI, including the key stores, certificate authorities, application encryption paths and backup or archive locations that hold key material. We map each one to the key-management requirements your organization has defined, because the requirement is satisfied only by the parameter values you assign, not by the software alone. Your team owns those values and approves them. Our part is to prepare the systems, configuration and documentation so the decisions are visible and testable.

On your infrastructure, in your cloud accounts, data center or air-gapped network, we prepare the key stores and rotation configuration. Examples of what this can involve include a transit encryption engine such as OpenBao, with versioned keys and a rotation schedule set in configuration, and a certificate authority such as the Dogtag component in FreeIPA, with issuance and revocation controls. We also draft the key generation, distribution, storage, access and destruction rules as a document for your security owner to review, amend and approve before anything is treated as in force. Where a choice depends on your own risk decisions or on cryptographic validation requirements, we record it as an open item for you to confirm rather than deciding it for you.

Evidence is assembled from the running configuration, approved procedures, access records and destruction logs, mapped to the examine, interview and test objects in the assessment procedure for 03.13.10. The assessor reviews this evidence independently. DeployOpen does not issue audit reports, attestations or certifications; only an independent auditor, assessor or certification body can do that. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins. Ongoing support, rotation reviews and periodic evidence refresh are available as a retainer, which suits organizations whose key lifecycle changes after the initial work.

03.13.10 Cryptographic key establishment and management