DKDavid Koran& Associates
Home The CMMC Guide Part III · System and Communications Protection SC.L2-3.13.11
The CMMC Guide · System and Communications Protection Family

SC.L2-3.13.11  FIPS-Validated Cryptography

Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.

Family
System and Communications ProtectionSC, 16 requirements
Point Value
5Maximum deduction; a 3-point partial-credit case applies
POA&M Eligible
ConditionalDeferrable only in its 3-point partial state
Objectives
OnePer NIST SP 800-171A

1Overview

SC.L2-3.13.11 sets the standard the cryptography must meet: it must be FIPS-validated. It requires that FIPS-validated cryptography be employed when cryptography is used to protect the confidentiality of CUI. This control carries an unusual scoring and deferral profile. Its maximum value is five points, but it has a partial-credit case, and it is the single requirement worth more than one point that can, in one specific circumstance, be placed on a plan of action.

Encryption protects CUI only if the cryptography is sound, and the government's measure of sound cryptography is FIPS validation: the algorithm and its implementation have been tested and validated against Federal Information Processing Standards. This control requires that when cryptography is used to protect the confidentiality of CUI, it be FIPS-validated, not merely encryption of some kind. The scoring reflects a gradation the other controls do not have. If no encryption is employed at all, five points are subtracted. If encryption is employed but is not FIPS-validated, only three points are subtracted, and in that specific partial state, and only that state, this requirement may be placed on a plan of action. If no encryption is in place, the five-point gap cannot be deferred. Its single assessment objective is that FIPS-validated cryptography is employed to protect the confidentiality of CUI.

The requirement · NIST SP 800-171 Rev 2, 3.13.11

Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.

The requirement is specific about the kind of cryptography: FIPS-validated. Employing encryption that has not been through FIPS validation does not meet the requirement, even though it may provide real protection. The distinction matters because the scoring methodology treats the two cases differently. Fully met means FIPS-validated cryptography protects the confidentiality of CUI. Encryption present but not FIPS-validated is the partial state, scored as a three-point deduction and, uniquely, eligible for a plan of action. No encryption at all is the full five-point deduction and is not deferrable.

2The Assessment Objective

NIST SP 800-171A frames 3.13.11 as a single objective: employ FIPS-validated cryptography to protect the confidentiality of CUI.

FIPS-validated cryptography is employed to protect the confidentiality of CUI. The cryptography protecting CUI is FIPS-validated, not merely present.

MeetsFIPS-validated cryptography protects the confidentiality of CUI.
FailsNo encryption protects CUI (five-point deduction), or encryption is employed but is not FIPS-validated (three-point deduction, the partial state).

The single objective turns on validation, not merely on the presence of encryption. The partial state, encryption employed but not FIPS-validated, is the specific circumstance in which this higher-point requirement may be placed on a plan of action, at a three-point cost. The assessor looks for cryptography that is FIPS-validated, not just cryptography.

3Failure Patterns

The failures turn on the difference between encryption and validated encryption.

Encryption present but not FIPS-validated

Using cryptography that has not been FIPS-validated is the partial state: a three-point deduction, and the one circumstance where this requirement may sit on a plan of action. Moving to FIPS-validated cryptography fully meets it.

No encryption at all

Protecting CUI confidentiality without any encryption is the full five-point deduction, and this state is not deferrable. Encryption has to be in place, and validated, before assessment.

FIPS mode not enabled

Using a product capable of FIPS-validated cryptography without enabling its validated mode leaves the cryptography non-validated. The validated mode has to be actually in use.

The common root
This control fails on a distinction that is easy to overlook: encryption and FIPS-validated encryption are not the same. Many products encrypt, but only validated modules meet the requirement, and a product often has to be configured into its FIPS-validated mode to qualify. The unusual scoring, and the narrow deferral window in the partial state, make this one of the requirements where the details of implementation directly determine the score and the assessment path.

4Ownership

This is an IT and security-owned technical control.

RoleResponsibility for this control
IT and securityEmploys FIPS-validated cryptography and enables validated modes. Owns the validation evidence.
System architectsSelect products with FIPS-validated modules for CUI protection.
Security or compliance leadConfirms the cryptography protecting CUI is FIPS-validated, and understands the scoring and deferral implications of the partial state.
See also: This control governs the strength of the cryptography implemented for SC.L2-3.13.8 and rests on the key management of SC.L2-3.13.10.

5Tooling

The control is delivered by FIPS-validated cryptographic modules in validated modes.

ObjectiveToolingWhat it provides
validated modulesFIPS 140-validated cryptographic modulesCryptography that meets the validation requirement.
validated modeFIPS mode configurationThe validated mode actually in use for CUI.

The caveat is that the module must be FIPS-validated and its validated mode enabled. Encryption that is strong but not validated is the partial state, three points and deferrable; no encryption is the full five-point, non-deferrable gap. The assessor examines whether FIPS-validated cryptography is employed, so the validation, not merely the encryption, has to hold.

6Evidence

The satisfied version of 3.13.11 shows FIPS-validated cryptography in use.

EvidenceWhat it demonstrates
FIPS validation certificatesThe objective. The cryptographic modules are FIPS-validated.
FIPS mode configurationThe objective. The validated mode is in use for CUI.

The evidence should show FIPS-validated cryptographic modules, with their validated modes enabled, protecting the confidentiality of CUI. The validation certificates together with the FIPS mode configuration are the clearest demonstration. Because full compliance requires validation and not merely encryption, and because only the partial encryption-not-FIPS state is deferrable, the validated cryptography should be in place at the time of assessment.

Encryption and FIPS-validated encryption are not the same

Only validated cryptography meets this requirement, and its unusual scoring, five points for no encryption, three for encryption that is not FIPS-validated, makes the details decisive. Getting to FIPS-validated cryptography in the right modes, rather than relying on the narrow partial-state deferral, is central to the onsite readiness work this practice does.

Start CMMC Readiness or call 802-335-2662

7Sources

  1. NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.13.11. csrc.nist.gov
  2. NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objective 3.13.11. csrc.nist.gov
  3. 32 CFR 170.24, CMMC Scoring Methodology, which provides that SC.L2-3.13.11 is scored as a three-point deduction where encryption is employed but not FIPS-validated, and a five-point deduction where no encryption is employed. ecfr.gov
  4. 32 CFR 170.21, Plan of Action and Milestones Requirements, which permits SC.L2-3.13.11 on a POA&M in its three-point partial state as the sole exception above one point. ecfr.gov
← Previous in System and Communications Protection
SC.L2-3.13.10 · Manage Cryptographic Keys
Next in System and Communications Protection →
SC.L2-3.13.12 · Control Collaborative Computing Devices
About the Author
David W. Koran is a CyberAB Registered Practitioner Advanced and the author of The CMMC Decision, now in its second edition. He works onsite with defense contractors and their counsel, from the first leadership briefing through the pre-assessment review. Reach him at 802-335-2662 or dkoran@davidkoran.com.
Entry SC.L2-3.13.11 · Edition 2026.1 · Last reviewed July 12, 2026