- Define the acceptable cryptography types explicitly and record where the parameter came from — contract terms, agency direction, organizational policy.
- Where FIPS validation is the defined type, verify module validation status: 'uses AES' and 'uses a validated module operating in its approved mode' are different claims, and assessors know the difference.
- Inventory the places cryptography protects CUI and check each against the parameter; the gap is usually an appliance or SaaS edge nobody examined.
03.13.11OFFICIAL TITLEPENDING NIST SME REVIEW
03.13.11 — Cryptographic Protection
03.13 System and Communications Protection · NIST SP 800-171 Rev. 3
Independent summary of the official requirement
Requires implementing organization-defined types of cryptography when cryptography is used to protect the confidentiality of CUI.
Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.
NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗Independent interpretation
What this requirement is after
When cryptography is what stands between CUI and disclosure, it must be of a defined, defensible type — not whatever a product happened to ship with. The organization writes down which types count; for most defense contractors what gets written down is FIPS-validated modules, because that is what the assessing ecosystem expects to see.
Across revisions
Rev. 2 named FIPS-validated cryptography in the requirement statement; Rev. 3 moves the acceptable types into an organization-defined parameter. In federal use the parameter is commonly set to FIPS-validated cryptography, so treat the new flexibility as procedural rather than substantive.
Mapped practices
Brilliant at the Basics practices that support this requirement
No practice maps to this requirement — deliberately.
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Doing the work
Implementation considerations and evidence
- The defined cryptography-type parameter and its source
- Module validation evidence — certificate numbers and validated configurations — per protecting system
Artifacts
Templates and worksheets with a mapped relationship
No artifact in the library names this requirement yet. The library index groups everything by category and practice.
The other revision
Where this came from in Rev. 2
Provenance
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |