Cryptographic Protection is the requirement that specifies which types of cryptography protect Controlled Unclassified Information (CUI). It is part of the System and Communications Protection (03.13) family, and it works alongside Transmission and Storage Confidentiality (03.13.08) and Cryptographic Key Establishment and Management (03.13.10) by naming the cryptography those controls rely on. Cryptographic Protection (03.13.11) requires implementing defined types of cryptography to protect the confidentiality of CUI. Per the NIST discussion, cryptography is implemented in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, and guidelines, and Federal Information Processing Standards (FIPS) validated cryptography is recommended for the protection of CUI.
A common difficulty with this requirement is using encryption that is not FIPS validated, or never formally defining which types of cryptography are approved for protecting CUI. R3 turns the choice of cryptography into a defined parameter, and for Department of Defense (DoD) contractors that parameter is FIPS validated cryptography. Encryption that is enabled but not validated, or not documented as an approved type, leaves the requirement unmet.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.13.11 Cryptographic Protection. Only the formatting has been adjusted for readability. This is a single statement with no lettered parts:
The source control is SC-13 from NIST 800-53. The bracketed assignment is the Organization-Defined Parameter (ODP): the types of cryptography. Per the NIST discussion, FIPS validated cryptography is recommended for the protection of CUI. You can read the requirement directly at NIST 800-171 R3, 03.13.11 (p. 61).
One (1) value sits inside this requirement. Depending on your contract, your organization may be permitted to define it. Organizations in the DIB subject to CMMC are not, because the DoD has defined it as policy.
The value below comes from Attachment A of the DoD Chief Information Officer (CIO) memorandum dated 10 April 2025 (signed David W. McKeown). The memo identifies each parameter by requirement sub-part, while NIST 800-171A R3 identifies the same parameter by ODP number. Both identifiers appear below so you can match your System Security Plan (SSP) language to either document.
The memo states that its values "will be updated as necessary," so confirm against the current version before writing them into policy.
NIST 800-171A R3 breaks 03.13.11 into two (2) assessment objectives: one (1) Organization-Defined Parameter (ODP) and one (1) determination statement. These AOs are:
The determination statement is that the defined types of cryptography are implemented to protect CUI. If you are a DoD contractor, the ODP is specified. Per the DoD-specified ODP value in ComplianceForge's NIST 800-171 R3 Transition Guide, the types of cryptography (ODP[01]) are FIPS validated cryptography, drawn from the Cryptographic Module Validation Program list of validated modules. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.13.11 (p. 80).
Examine: system and communications protection policy and procedures; procedures for cryptographic protection; system design documentation; system configuration settings; cryptographic module validation certificates; list of FIPS- validated cryptographic modules; system audit records; system security plan.
Interview: personnel with responsibilities for cryptographic protection; personnel with information security responsibilities; system developers; system administrators.
Test: mechanisms for supporting or implementing cryptographic protection.
03.13.11 maps from NIST 800-171 R2 requirement 3.13.11 (employ FIPS-validated cryptography when used to protect the confidentiality of CUI):
Mapped against the two (2) AOs, one (1) is net new (significant effort) and one (1) is indirect (moderate effort), with none direct and none unmapped. The core expectation carries forward: use validated cryptography to protect CUI. What is new is that R3 requires you to define the approved types of cryptography as a parameter, and the implementation objective is phrased against that parameter rather than naming FIPS directly. For DoD work the parameter resolves to FIPS validated cryptography, so the practical bar is the same as R2 with an added documentation step.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.13.11 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The following are issues teams may encounter rather than certainties. They are about validation and documentation, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.13.11 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.13.11 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.13.11 recording the ODP values you adopted.
With one AO net new and one indirect, 03.13.11 is a moderate lift where the documentation step is often the gap. A realistic sequence:
What value does the DoD require for the organization-defined parameter in NIST 800-171 R3 03.13.11? R3 leaves the value to the organization. For the DIB, the DoD set it in the 10 April 2025 memorandum under ODP identifier 03.13.11: FIPS Validated Cryptography (https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Validated-Modules).
How many assessment objectives does NIST 800-171 R3 03.13.11 have? NIST 800-171A R3 breaks 03.13.11 into two (2) assessment objectives: one (1) Organization-Defined Parameters (ODPs) and one (1) determination statements. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.13.11 come from? SC-13.
Where does NIST 800-171 R3 03.13.11 sit in the NIST 800-171 R3 Kill Chain? Phase 19, Cryptographic Key Management. The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.13.11 Cryptographic Protection implements defined types of cryptography to protect the confidentiality of CUI. It maps from R2 3.13.11 with the implementation objective transitioning indirectly, while defining the approved types is net new. For DoD work the defined type is FIPS validated cryptography, so the practical bar matches R2 with an added documentation step. The recurring problem is using non-validated or undocumented cryptography. Define the approved types, use validated mechanisms, and apply them consistently across the cryptography-related controls.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3 and references the DoD ODP memorandum of 10 April 2025. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
