What FIPS-Validated Encryption Does CMMC Require?

Encryption appears throughout CMMC Level 2: remote access, wireless, mobile devices, portable storage and backups, plus CUI in transit and at rest. SC.L2-3.13.11 (CUI Encryption) decides what kind of cryptography counts in each of those places. This page covers what the requirement asks for and how to check a module against NIST’s CMVP. It also explains how the requirement is scored and what the September 2026 move of FIPS 140-2 certificates to the Historical list means.

Adjacent topics have their own pages. Boundary design is in CUI enclave architecture. GCC High vs commercial Microsoft 365 covers the Microsoft 365 tenant decision. POA&M and re-evaluation mechanics are in re-evaluation and POA&M under CMMC.

As of September 2026, contracts may designate only CMMC Level 1 (Self) or Level 2 (Self) while the Department of War (DoW) reviews the program. The encryption requirement hasn’t changed. DFARS 252.204-7012 still applies, with NIST SP 800-171 Rev 2 as its baseline. A Level 2 self-assessment scores SC.L2-3.13.11 with the same method a C3PAO uses. For what to check in a solicitation, see what to check during the CMMC pause.

What Does SC.L2-3.13.11 Require, and When Does It Apply?

SC.L2-3.13.11 requires FIPS-validated cryptography whenever cryptography is used to protect the confidentiality of CUI. The CMMC Assessment Guide places that need where CUI is transmitted or stored outside the protected environment, including wireless and remote access.

NIST SP 800-171 Rev 2 gives the requirement text: “Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.” The CMMC Assessment Guide, Level 2 sets the scope:

“FIPS-validated cryptography is required to protect CUI when transmitted or stored outside the protected environment of the covered OSA information system (including wireless/remote access). Encryption used for other purposes, such as within applications or devices within the protected environment of the covered OSA information system, would not need to use FIPS-validated cryptography.”

DFARS 252.204-7012 makes the contractor’s system “subject to the security requirements in” NIST SP 800-171, and 3.13.11 is one of them. The clause text itself never mentions FIPS. DoD’s 2024 CMMC final rule says the program “does not alter any separately applicable requirements to protect FCI or CUI, including the requirement to use FIPS-validated cryptography which comes from NIST SP 800-171 as required by DFARS clause 252.204-7012.”

Requirements That Rely on SC.L2-3.13.11

Six Level 2 requirements hand their cryptography to 3.13.11. In the Assessment Guide, each one carries the same sentence: “Because the use of cryptography in this requirement is to protect the confidentiality of CUI, the cryptography used must meet the criteria specified in requirement SC.L2-3.13.11.” The backup requirement asks directly: “Are cryptographic mechanisms FIPS validated [a]?”

The POA&M column refers to the POA&M that supports a Conditional status under 32 CFR 170.21. 32 CFR 170.24 still requires a POA&M entry for every NOT MET requirement.

Where FIPS Validation Is Not Required

• Encryption used for other purposes inside the protected environment. The Assessment Guide and DoD’s DFARS FAQ both say it would not need validation.
• CUI protected by other means. SC.L2-3.13.8 calls for cryptography “unless otherwise protected by alternative physical safeguards.” For portable storage, the Assessment Guide says: “When encryption is not an option, apply alternative physical safeguards during transport.” NIST’s discussion of 3.13.16 also names file share scanning alongside cryptography. The FIPS test applies to the cryptography the contractor relies on to protect the CUI.
• Level 1. FAR 52.204-21, the basis for Level 1, contains no encryption requirement. New solicitations issued under the FAR overhaul may show the basic safeguarding clause as 52.240-93.

Multi-factor authentication and password storage don’t need FIPS validation either. The Assessment Guide mentions FIPS only in the encryption requirements in the table above and in the definition of a temporary deficiency. Its sections for multi-factor authentication (IA.L2-3.5.3) and password protection (IA.L2-3.5.10, “Store and transmit only cryptographically-protected passwords.”) carry no FIPS or 3.13.11 reference. If the same product also encrypts a remote access session, that encryption falls under AC.L2-3.1.13 and therefore 3.13.11.

What Counts as FIPS-Validated Cryptography?

FIPS-validated means an accredited laboratory tested the cryptographic module. NIST’s CMVP then verified that testing and issued a certificate number. The Assessment Guide is explicit: “Simply using an approved algorithm is not sufficient,” and the module “must be separately validated under FIPS 140.” A vendor’s claim of “FIPS-compliant” doesn’t meet that test.

NIST draws the line in its CMVP FAQ. A “compliant” product is one where “a vendor believes its product implementation meets the FIPS 140-3 requirements, but the product has not gone through the CMVP validation process.” NIST’s advice for any claim of “compliance, conformance or certification to the FIPS 140 standards” is to “request the associated validation certificate number.” Commenters asked DoD to accept FIPS-compliant encryption in the 2024 CMMC rule. DoD declined.

FIPS 140-3 superseded FIPS 140-2. It was approved on March 22, 2019 and became effective on September 22, 2019. NIST’s discussion of 3.13.11 also lists NSA-approved cryptography as a cryptographic standard.

How Do You Verify That a Cryptographic Module Is FIPS-Validated?

Get the module’s CMVP certificate number from the vendor and look it up on NIST’s Validated Modules search. Confirm that the standard, status, versions, operating environment and caveat match what you run. Then configure the approved mode that the module’s security policy describes. Record the result in the System Security Plan (SSP).

1. List every place cryptography protects CUI. Use the requirements table above as the checklist, and name the product that encrypts each flow.
2. Find the module inside each product. NIST issues certificates “for cryptographic modules,” and a module “may either be an embedded component of a product or application, or a complete product in and of itself.” For an embedded module, NIST says to ask the product vendor which validated module the product uses.
3. Get the certificate number in writing. NIST suggests a signed vendor letter stating that the product is or incorporates a validated module, that “the module provides all the cryptographic services in the solution,” and which certificate number applies.

Next, check the certificate itself.

4. Look up the certificate. On NIST’s CMVP Validated Modules search, check the standard (FIPS 140-2 or FIPS 140-3), the status (Active, Historical or Revoked) and the sunset date.
5. Match the version and operating environment. NIST: “Each entry will state what version/part number/release is validated, and the operational environment (if applicable) the module has been validated.” If the vendor’s information and the certificate don’t agree, NIST says “the vendor is not offering a validated solution.”
6. Read the caveat and the security policy. A caveat can make the validation conditional on approved mode: the module “must be in an approved mode of operation as specified in the module’s Security Policy.”

Finish with the system and the SSP.

7. Turn on the approved mode and confirm it. In the Assessment Guide’s own example, the administrator checks the CMVP website and then turns on the server’s “FIPS Compliance” setting “because that is what is required for this product.” For TLS, DoD’s DFARS FAQ adds: “All cryptographic algorithms that are included in the configured cipher suites must be within the scope of the validation, as well as the random number generator.”
8. Record the result. Enter each module and its certificate in the evidence record below.

Reading a CMVP Certificate

A CMVP certificate page shows the fields below. Field names follow NIST’s certificate pages, which list versions by type (software, firmware or hardware). The checks are Deep Fathom’s recommendations.

The Evidence Record

Deep Fathom recommends one table in the SSP evidence, with a row for each place cryptography protects CUI. DoD’s 2024 preamble says “C3PAOs will assess based on the stated implementations,” so the SSP needs to name the module behind each CUI flow. The assessment objects for 3.13.11 include “cryptographic module validation certificates” and a “list of FIPS-validated cryptographic modules.” This table holds both. It answers the 3.13.11 questions in one place and shows which rows change when a certificate changes status.

Keep the supporting evidence with the table. That means security policy excerpts that define the approved mode, and configuration exports or screenshots that show the approved or FIPS mode is on. Add the CRM for each cloud service in scope. Reference any operational plan of action, enduring exception or DoD CIO adjudication in the SSP. For where it fits in the SSP, see how to write a CMMC System Security Plan.

What Does the FIPS 140-2 Move to the Historical List Mean?

Since September 22, 2026, NIST’s CMVP lists only FIPS 140-3 validations as Active, and FIPS 140-2 certificates are Historical. NIST says Historical doesn’t mean revoked, and it “supports the purchase and use of these modules for existing systems.” As of September 2026, DoW has issued no guidance on how assessors treat Historical modules under SC.L2-3.13.11.

NIST’s own words, from its CMVP pages:

• The switch. “FIPS 140-2 validated modules will remain on the active list through September 21, 2026. On September 22, 2026, only FIPS 140-3 module validations will remain on the active list.” (CMVP FAQ)
• Existing systems. “Even on the historical list, CMVP supports the purchase and use of these modules for existing systems.” (FIPS 140-3 Transition Effort)
• Continued use. FIPS 140-2 modules “can continue to be accepted by the Federal agencies of both countries for the protection of controlled unclassified information (United States) or Designated Information (Canada) through September 21, 2026.” After that date, CMVP allows “agencies to continue using these modules for existing systems only,” and adds: “Agencies should continue to make use of FIPS 140-2 modules until replacement FIPS 140-3 modules become available.” (CMVP overview)

From the Validated Modules page:

• New systems. “If a validation certificate is marked as historical, Federal Agencies should not include these in new systems but can be procured for legacy systems. This does not mean that the overall FIPS-140 certificates for these modules have been revoked.”
• Risk decision. “Agencies may make a risk determination on whether to continue using the modules on the Historical list based on their own assessment of where and how the module is used.”

Two points qualify all of these NIST quotes. NIST writes them for federal agencies, and they do not state how a CMMC assessor will score a module. On the Validated Modules page, NIST also warns that Historical certificates “have not been updated to reflect latest guidance and/or transitions, and may not accurately reflect how the module can be used in FIPS mode.”

As of September 24, 2026, a CMVP search returned no Active FIPS 140-2 certificates, 711 Active FIPS 140-3 certificates and 4,418 Historical FIPS 140-2 certificates. Certificates also move to Historical for other reasons: a 5-year sunset date or the sunset of a module they are bound to. So does an interim validation whose follow-up submission did not arrive in time. The same search showed 82 Historical FIPS 140-3 certificates. NIST also reminds purchasers “that for several years there may be a limited selection of FIPS 140-3 modules from which to choose.” Its Modules In Process list, last updated September 23, 2026, showed 203 modules in process.

What CMMC Guidance Says So Far

The current Assessment Guide (Version 2.13, September 2024) defines the term against the older standard: “FIPS-validated cryptography means the cryptographic module has to have been tested and validated to meet FIPS 140-2 requirements.” Its portable storage section asks, “Do cryptographic mechanisms comply with FIPS 140-2 [a]?” The guide predates the September 2026 move. As of September 2026, the DoW CIO site still links Version 2.13. Neither the July 2026 DoW CIO CMMC FAQ nor the Cyber AB’s CMMC Assessment Process addresses Historical modules.

DoD’s 2024 rule left the question open as well. A commenter asked whether FIPS 140-3 was acceptable. In response, DoD pointed to the CMVP website’s list of approved solutions and their timelines.

One point is settled. Answer C-A12 of the DoW CIO CMMC FAQ lists “replacing an old Federal Information Processing Standards (FIPS) 140.2 firewall with a FIPS 140.3 firewall” as a routine change. That change is “not considered significant,” so the upgrade does not by itself require a reassessment. The FAQ adds that “the decision of whether a change is significant enough to require a reassessment is the responsibility of the Affirming Official.”

In Deep Fathom’s view, a clear record is the defensible position until DoW or the Cyber AB speaks. Show each Historical certificate, where the module runs, when the system went into service, and a dated path to a FIPS 140-3 module. The decision table below applies this to each situation.

How Is SC.L2-3.13.11 Scored, and When Can It Go on a POA&M?

Under 32 CFR 170.24, SC.L2-3.13.11 costs 5 points when encryption is not employed. It costs 3 points when encryption is employed but not FIPS-validated. That 3-point case is the only POA&M exception above 1 point in 32 CFR 170.21. A Level 2 (Self) assessment uses the same scoring. As of September 2026, it’s the only Level 2 designation contracts may use.

From 32 CFR Part 170, the rule text reads:

“FIPS-validated encryption (CMMC Level 2 security requirement SC.L2-3.13.11) is required to protect the confidentiality of CUI. If encryption is employed, but is not FIPS-validated, three (3) points are subtracted from the maximum score; if encryption is not employed; five (5) points are subtracted from the maximum score.”

Only two requirements can score as partially effective under the rule: IA.L2-3.5.3 and SC.L2-3.13.11. DoD’s 2024 preamble adds that “there is no consideration for multiple layers of encryption.”

For a Conditional status, the score must reach 0.8 of the maximum (88 points). 32 CFR 170.21 also bars any POA&M item worth more than 1 point, “except SC.L2-3.13.11 CUI Encryption may be included on a POA&M if encryption is employed but it is not FIPS-validated.” DoD’s preamble does the arithmetic: a Level 2 POA&M “can include up to 22 security requirements that have a value of 1 … or may include non-FIPS-validated encryption and up to 19 security requirements that have a value of 1.” A POA&M closeout assessment must confirm closure within 180 days of the Conditional CMMC Status Date. Otherwise the Conditional status expires. For the rest of the POA&M rules, see re-evaluation and POA&M under CMMC.

NIST’s CMVP pages say that for federal agencies, “non-validated cryptography is viewed as providing no protection to the information or data.” That’s NIST’s position for agencies. CMMC scoring comes from 32 CFR 170.24, which sets the 3-point value above.

Patches, Vendor Queues and Temporary Deficiencies

A validated module can stop matching its certificate. NIST’s guidance on updates, patches and CVEs says “the original version would maintain its validation but the new version that includes the patch/update would not be validated.” NIST still says it “strongly recommend[s] patching.”

The CMMC rule anticipates this case. Its definition of a temporary deficiency in 32 CFR 170.4 gives the example: “FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency.” Three rules follow from the rule text:

• Operational plan of action. A temporary deficiency must be documented in an operational plan of action. That plan “does not identify a timeline for remediation and is not the same as a POA&M.”
• Enduring exception. Where full compliance “is not feasible,” such as “systems required to replicate the configuration of ‘fielded’ systems, medical devices, test equipment, OT, and IoT,” the circumstance is documented in the SSP. See specialized asset categories for how those assets are scoped.
• Assessed as MET. Under 32 CFR 170.24(b)(1), enduring exceptions “described, along with any mitigations, in the system security plan” and temporary deficiencies “appropriately addressed in operational plans of action” “shall be assessed as MET.”

Vendor validation queues are harder. DoD’s 2024 preamble says the government “is aware that FIPS module validation can exceed the 180-day CMMC assessment POA&M threshold.” It adds: “Limitations of the FIPS-validated module process do not impact the implementation status of FIPS cryptography.” It continues: “Vendor limitations with respect to FIPS validation could be considered enduring exceptions or temporary deficiencies and should be addressed in an OSA’s operational plan of action.”

“Could be considered” is permissive. The assessor decides whether a vendor limitation qualifies, or the contractor does in a Level 2 (Self) assessment. The temporary-deficiency definition also says a temporary deficiency “is not based on an ‘in progress’ initial implementation” and “arises after implementation,” with one exception. It “may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed.”

A third route runs through the contract. Under DFARS 252.204-7012(b)(2)(ii)(B), a contractor can ask the Contracting Officer to vary from NIST SP 800-171, for consideration by the DoD CIO. A favorable DoD CIO adjudication “must be included in the system security plan to receive consideration during an assessment.”

How Does SC.L2-3.13.11 Apply to Cloud Services, Email and File Sharing?

Encrypting CUI doesn’t change where it may be stored. A cloud service provider that stores, processes or transmits CUI must meet security requirements equivalent to the FedRAMP Moderate baseline. That rule comes from DFARS 252.204-7012, and it holds even when the CUI is encrypted. When email or file transfer carries CUI outside the protected environment and encryption is the protection, that encryption must be FIPS-validated.

Cloud. The DoW CIO FAQ answers the encrypted-cloud question directly (E-Q2): “No. If a contractor intends to use an external Cloud Service Provider in the performance of a Department of War contract to store encrypted CUI data, the contractor shall require and ensure that the Cloud Service Provider meets security requirements equivalent to those established for the FedRAMP Moderate baseline.” The same FAQ says “encrypted CUI data retains the control designation given to the plain text counterpart.” Under 32 CFR 170.16 and 170.17, the requirements from the provider’s customer responsibility matrix (CRM) must be documented or referred to in the contractor’s SSP. Per the Cyber AB’s CMMC Assessment Process, a C3PAO assessment team checks the FedRAMP Marketplace. It accepts a Moderate (or higher) authorization.

DoD’s FedRAMP equivalency memo does not mention FIPS 140. In Deep Fathom’s view, the safer course is to read the provider’s CRM and its cryptographic module documentation for each service that touches CUI. Don’t assume every service runs a validated module. See what the customer responsibility matrix must cover.

Watch item: FedRAMP’s 2026 rules. FedRAMP’s Consolidated Rules for 2026 require providers to “document the cryptographic modules used in each service” where cryptographic services protect federal customer data. They say providers with Class C certifications “SHOULD use cryptographic modules or update streams of cryptographic modules with active validations,” and Class D providers MUST. FedRAMP says Class C “will include the current Moderate” baseline. But it also says classes are not “one-for-one replacements” for impact levels. Adoption is optional from July 4, 2026. On January 1, 2027, the Class C cryptographic module rules take effect for obtaining and maintaining a certification. As of September 2026, DoW has not said how the new classes map to the “FedRAMP Moderate baseline” in DFARS 7012.

Enclaves. Encryption does not create a boundary. The DoW CIO FAQ says encryption “does not, by itself, prevent data transfer or enforce the security boundary of a network.” It also says that when an enclave is otherwise logically separated, “the transmission of properly encrypted CUI data does not incur an extension of the CMMC Assessment Scope to include the enterprise networking components.” See CUI enclave architecture for boundary controls.

Email and file sharing. The Assessment Guide’s example policy for AC.L2-3.1.3 “instructs users to encrypt any CUI transmitted via email or to use a designated secure file sharing utility.” DoD’s DFARS FAQ adds that “information that is independently and appropriately encrypted (e.g., an e-mail encrypted with a PKI certificate) is self-protecting and need not be double-encrypted.” A file transfer server using TLS falls under the cipher suite and random number generator rule in step 7 above. For whether a Microsoft 365 tenant can hold CUI, see GCC High vs commercial Microsoft 365.

What Do Assessors Examine for SC.L2-3.13.11?

Assessors evaluate one objective: “[a] FIPS-validated cryptography is employed to protect the confidentiality of CUI.” They examine documents such as the SSP, configuration settings and module validation certificates. Interviews cover administrators and the staff responsible for cryptography. Testing covers the mechanisms that implement it. In a Level 2 (Self) assessment, the contractor applies the same objective and enters the result in SPRS.

Assessment methods and objects come from NIST SP 800-171A, as reproduced in the Assessment Guide:

The guide’s assessment consideration asks: “Is cryptography implemented to protect the confidentiality of CUI at rest and in transit, through the configuration of systems and applications or through the use of encryption tools [a]?” For the evidence to have ready, see The Evidence Record above.

Common Failure Modes

Certificates

1. Treating an algorithm as validation. Algorithm certificates or a “FIPS-compliant” label do not make a module validated. Ask for the CMVP certificate number.
2. Counting a module that is still in the queue. A listing on the IUT or MIP list shows testing or review. It is not a validation.
3. Misreading Historical. A Historical certificate is not revoked, and it is not Active. Record it as what it is and plan the replacement.

Configuration

4. Running outside approved mode. A validated product running in its non-FIPS mode can perform operations that “would not meet the FIPS requirements.”
5. Running a build that isn’t on the certificate. Certificates name validated versions and environments. A patched or newer build is not the validated one until it appears on a certificate.
6. Leaving TLS cipher suites outside the validation. Every algorithm in the configured cipher suites, and the random number generator, must be within the scope of the validation.

Cloud and boundaries

7. Putting encrypted CUI in any cloud. Encrypted CUI is still CUI, and its cloud provider still needs FedRAMP Moderate or the equivalent.
8. Using encryption as the enclave boundary. Encryption protects confidentiality. It does not, by itself, enforce a network boundary.

Scope and records

9. Over-scoping. Encryption used for other purposes inside the protected environment does not need validation. The Assessment Guide also does not route multi-factor authentication or password storage to 3.13.11.
10. Writing a temporary deficiency into the POA&M. 32 CFR 170.4 puts temporary deficiencies in an operational plan of action, which is a separate document from a POA&M.

Decision Table by Situation

Each row pairs what NIST says with what the CMMC rule does. Where no CMMC guidance exists, the row says so.

FIPS and CMMC Status as of September 2026

For what contracts can require during the suspension, see what to check during the CMMC pause.

Next Step

Each party has a defined role. NIST’s CMVP validates modules and sets their status. Vendors maintain their validations and publish the security policies. The contractor records the module behind each CUI flow in the SSP and scores 3.13.11 in its self-assessment. A C3PAO assesses it when one is engaged. The DoD CIO adjudicates variance requests. Deep Fathom organizes the requirement, the evidence record and the POA&M in one place. It doesn’t validate modules or make the compliance determination.

Send us the list of systems that store or transmit CUI, with the encryption product and version on each. Our team will review it and reply within one business day with what needs attention for SC.L2-3.13.11 before your next SPRS affirmation. Send the list to our team. To work in the platform yourself, create a free workspace.