By Scott Miller
Last Updated: July 17, 2026
Quick Answer
CMMC control SC.L2-3.13.11 requires FIPS-validated cryptography to protect the confidentiality of CUI, which means the cryptographic module performing the encryption must hold a current certificate from the NIST Cryptographic Module Validation Program (CMVP). On September 21, 2026, NIST moves every remaining FIPS 140-2 certificate to the Historical list. Historical modules may continue operating in existing systems, but they lose standing for new procurements, and CMMC Level 2 enforcement under Phase 2 begins seven weeks later on November 10, 2026. Contractors should inventory their cryptographic modules against the CMVP list now, document module status in the SSP, and understand the narrow POA&M exception in 32 CFR 170.21 before their assessment window opens.
Most CMMC preparation guides treat encryption as a checkbox. Enable TLS, turn on BitLocker, move on. Then the assessment arrives and the assessor asks a question that stops the room: which CMVP certificate covers the module that performed this encryption, and what is its status?
That question is about to get harder for nearly every defense contractor running Windows infrastructure, because two dates are converging in the fall of 2026. This article explains what SC.L2-3.13.11 actually requires, what changes on September 21, 2026, why the standard Windows evidence trail is affected, and the specific steps to take before an assessor asks that question about your environment.
What SC.L2-3.13.11 actually requires
The control text from NIST SP 800-171 is short: employ FIPS-validated cryptography when used to protect the confidentiality of CUI. The load-bearing word is validated. The CMMC Assessment Guide for Level 2 makes the distinction explicit: using a FIPS-approved algorithm is not sufficient on its own, because the module that implements the algorithm must be separately validated under FIPS 140.
In practice, that means the evidence for this control is a certificate number you can look up on the NIST CMVP validated modules list, tied to the specific software or hardware module performing the encryption in your environment, operated under the conditions listed in that certificate's security policy. During an assessment, the artifact that satisfies this control is the certificate number itself, checked against the CMVP list on the day of review. Configuration screenshots showing AES-256 and vendor datasheets claiming FIPS compliance carry no weight without it.
The control also carries unusual weight in DoD scoring. Under the CMMC Scoring Methodology in 32 CFR 170.24, SC.L2-3.13.11 is a 5-point requirement. If encryption is employed but is not FIPS-validated, 3 points are subtracted from the maximum score. If encryption is not employed at all, 5 points are subtracted. Very few individual controls can move a SPRS score that far on their own.
What happens on September 21, 2026
NIST's Cryptographic Module Validation Program maintains three lists for validated modules: Active, Historical, and Revoked. Active modules meet current requirements and can support new federal procurements. Revoked modules have a known security failure. Historical sits in between, and its meaning is precise: agencies may continue using Historical modules in existing systems, but should not include them in new procurements.
Per NIST's FIPS 140-3 transition plan, every FIPS 140-2 certificate that is still Active moves to the Historical list on September 21, 2026, regardless of when it was issued. The CMVP stopped accepting new FIPS 140-2 submissions in 2022, so there is no path to a fresh 140-2 certificate. From September 22, 2026 onward, the only Active certificates are FIPS 140-3 certificates.
Much of the coverage overstates what this transition means, so precision matters here. NIST states plainly that even on the Historical list, the CMVP supports the purchase and use of these modules for existing systems, and that agencies should continue using FIPS 140-2 modules until replacement FIPS 140-3 modules become available. The sunset is a procurement and validation-status event. Your encryption does not stop working on September 21, and an existing, documented deployment does not become instantly non-compliant.
What does change is the strength of your evidence. A certificate that read Active in your System Security Plan in August reads Historical in October. For any system deployed or materially changed after the sunset, citing a Historical certificate invites the question of why a module NIST no longer recommends for new acquisitions was selected.
Seven weeks later: CMMC Phase 2
If the sunset stood alone, contractors could absorb it gradually. CMMC Phase 2 begins on November 10, 2026, which allows the Department of Defense to require CMMC Level 2 certification assessments as a condition of contract award for applicable solicitations. Contractors handling CUI who have been planning around a self-assessment now face third-party assessment by a C3PAO, and the timeline between the FIPS 140-2 sunset and the start of Phase 2 is seven weeks.
A C3PAO assessor evaluating SC.L2-3.13.11 in late 2026 will check module certificates against the CMVP list as it stands on the day of the assessment. Assessors distinguish between an existing system with a documented Historical module and a new deployment that selected one. The contractors who will have a clean story in November are the ones who documented their module inventory, status, and rationale before September.
For a breakdown of the CMMC framework, levels, and implementation timeline, see our guide to CMMC 2.0 and its rollout. For what the assessment itself examines at the file access layer, see CMMC self-assessment vs. C3PAO audit.
The Windows evidence problem
For most of the defense industrial base, this is a Windows problem. Windows encrypts through a small set of OS-level cryptographic modules. TLS connections through Schannel, BitLocker volume encryption, and applications that call the Cryptography API: Next Generation all rely on the Windows Cryptographic Primitives Library in user mode and its kernel mode counterpart. Those modules carry the CMVP certificates that your SSP cites.
As of this writing, the validated modules for Windows Server 2022 and Windows 11 are FIPS 140-2 validations. The user mode Cryptographic Primitives Library holds CMVP certificate #4825 and the Kernel Mode Cryptographic Primitives Library holds certificate #4766. Both are currently listed as Active, and both carry a sunset date of September 21, 2026. Microsoft has FIPS 140-3 submissions moving through the CMVP pipeline, and the validation queue for 140-3 has been running well over a year per module, so contractors should verify current status on Microsoft's FIPS 140 validation documentation and the CMVP search page as part of assessment preparation.
The practical meaning: a contractor running current, patched Windows Server infrastructure is very likely relying on FIPS 140-2 certificates that move to Historical this September. NIST's guidance on existing systems means nothing breaks that day, but the burden shifts to you to write down your position before an assessor asks about it.
Is FIPS mode the same thing as FIPS validated?
No, and this distinction fails more assessments than any other encryption misunderstanding. Windows has a Group Policy setting commonly called FIPS mode. Enabling it restricts the Cryptographic Primitives Library to FIPS-approved algorithms. It is a configuration setting. A CMVP validation is a formal certificate issued after independent laboratory testing of a specific module version. Microsoft's own documentation notes that it validates the cryptographic modules used in Windows, and that whether a given application calls those validated modules in a compliant manner is a separate question for the application vendor.
An assessor can and will hold both requirements against you: the module must hold a current validation, and it must be operated according to the conditions in its security policy. Enabling the Group Policy setting without knowing your certificate numbers satisfies neither.
CAVP and CMVP: the difference assessors care about
NIST runs two related validation programs, and conflating them is one of the fastest ways to lose credibility in an assessment. The Cryptographic Algorithm Validation Program (CAVP) tests whether an implementation of an algorithm, such as AES or RSA, produces correct results. The Cryptographic Module Validation Program (CMVP) validates the entire module that contains those algorithms, including key management, self-tests, and operational security requirements. Every CMVP validation builds on CAVP algorithm certificates, but a CAVP certificate on its own is an algorithm validation, and SC.L2-3.13.11 evidence rests on the module validation.
We hold ourselves to that standard of precision. MyWorkDrive has been issued FIPS 186-4 RSA algorithm validation certificate #3018 from NIST. That is a CAVP algorithm validation, and we describe it as exactly that. In a self-hosted MyWorkDrive deployment, the encryption protecting CUI in transit is TLS terminated on your Windows Server, performed by the Windows Schannel security package calling the Windows cryptographic modules. The CMVP certificates your assessor will ask about are Microsoft's certificates for those OS modules, inherited by every application on the server that calls them correctly. Any vendor at the file access layer who tells you their product alone makes you FIPS compliant is describing the control incorrectly.
This is the same shared responsibility logic that runs through all of CMMC. No single product achieves the certification for you. The product's job is to keep CUI inside a boundary you control, use the platform's validated cryptography correctly, and generate the evidence an assessor needs. That is the design rationale behind a self-hosted file access layer for CMMC environments: the TLS stack, the storage, and the audit trail all live on Windows infrastructure inside your assessment boundary, so your 3.13.11 evidence is the OS module certificate plus your own configuration, with no third-party cloud handling CUI outside the boundary. If you are weighing that boundary decision more broadly, our analysis of whether CMMC requires GCC High covers it in depth.
The POA&M exception most contractors miss
CMMC's POA&M rules are strict. Under 32 CFR 170.21, a Conditional Level 2 status only permits POA&M entries for requirements worth 1 point, which normally excludes every 3-point and 5-point control. There is exactly one exception written into the rule, and it is this control: SC.L2-3.13.11 may be included on a POA&M if encryption is employed but is not FIPS-validated, in which case it scores as a 3-point deduction.
Read the conditions carefully. The exception applies when encryption exists and the validation is the gap. If no encryption protects the CUI at all, the control is a 5-point deduction and cannot be deferred. And a POA&M entry starts the 180-day closeout clock, so deferring the control means committing to a validated solution within six months of the assessment.
Separately, 32 CFR 170.4(b) defines a temporary deficiency, which can apply when a previously validated module loses its status, for example because a security patch moved the environment off the tested module version faster than the vendor's validation cycle could follow. Claiming it requires that the module appear on the CMVP Modules in Process or Implementation Under Test lists and that the gap be documented in your SSP and operational plan of action with a target resolution date. A control that was never implemented does not qualify as temporarily deficient.
| Your encryption posture at assessment | Scoring impact under 32 CFR 170.24 | POA&M eligible under 32 CFR 170.21 |
|---|---|---|
| Encryption performed by a module with a current CMVP validation, operated per its security policy, documented in the SSP | Requirement MET, no deduction | Not needed |
| Encryption employed, but the module lacks a current CMVP validation | 3-point deduction | Yes, under the specific SC.L2-3.13.11 exception, with a 180-day closeout window |
| No encryption protecting the confidentiality of CUI | 5-point deduction | No |
What to do before September 21
Build a cryptographic module inventory
For every system in your CMMC assessment scope that encrypts CUI, record the specific cryptographic module, its version, its CMVP certificate number, the certificate's standard (140-2 or 140-3), its status, and its sunset date. The CMVP search page gives you all of it. For Windows hosts, that means the OS build's Cryptographic Primitives Library certificates, and for network appliances it means the vendor's module certificates. Your FIPS posture can change with an OS update, so this inventory needs an owner and a review cadence.
Document your position on Historical modules in the SSP
If your Windows modules will read Historical at assessment time, write down the position now: the system predates the sunset, NIST supports continued use of Historical modules for existing systems, the vendor's 140-3 validation is in process, and your operational plan of action tracks the transition. An assessor who finds that paragraph in your SSP is looking at a managed control. An assessor who has to raise the issue is looking at a finding.
Verify how your applications call the modules
The OS certificate only covers applications that route their cryptography through the validated modules. For each application touching CUI, confirm with the vendor that it calls the platform's validated cryptographic modules and supports operation with Windows FIPS mode enabled. MyWorkDrive supports Windows FIPS mode and performs TLS through the Windows cryptographic stack, and we document that architecture so you can cite it directly in your SSP.
Check your other encryption touchpoints
SC.L2-3.13.11 reaches further than the file server. VPN concentrators, backup encryption, email gateways, and mobile device management all encrypt CUI in many environments, and each one carries its own module certificate with its own status. Reducing the number of encryption touchpoints reduces the size of this problem, which is one reason consolidating remote file access to a single TLS entry point on port 443 simplifies assessment evidence compared with layered VPN infrastructure.
Frequently asked questions
Does FIPS 140-2 still count for CMMC after September 2026?
In existing systems, yes, with documentation. NIST moves all FIPS 140-2 certificates to the Historical list on September 21, 2026, and states that Historical modules may continue to be used in existing systems while agencies transition to FIPS 140-3 modules as they become available. For new procurements and new deployments after that date, Historical certificates no longer carry standing, and contractors should select modules with Active FIPS 140-3 validations where they exist.
Is enabling Windows FIPS mode enough to satisfy SC.L2-3.13.11?
No. The Windows FIPS mode Group Policy setting restricts the OS cryptographic libraries to FIPS-approved algorithms, but it is a configuration setting. SC.L2-3.13.11 requires that the module performing the encryption hold a validation certificate from the NIST Cryptographic Module Validation Program and be operated per its security policy. Assessors check the certificate, its status, and the operating conditions, and the CMMC Assessment Guide states that an approved algorithm alone is not sufficient without a validated module.
Can SC.L2-3.13.11 go on a POA&M?
Only under one specific condition. 32 CFR 170.21 limits POA&M entries to 1-point requirements, with a single exception: SC.L2-3.13.11 may be placed on a POA&M if encryption is employed but is not FIPS-validated, scored as a 3-point deduction. If no encryption protects the CUI, the exception does not apply, the control scores a 5-point deduction, and it cannot be deferred. POA&M items must be closed out within 180 days.
What is the difference between a CAVP certificate and a CMVP certificate?
The Cryptographic Algorithm Validation Program (CAVP) certifies that an implementation of a specific algorithm, such as AES or RSA, produces correct results. The Cryptographic Module Validation Program (CMVP) validates the complete cryptographic module, including key management, self-tests, and operational requirements, and issues the FIPS 140 certificates that SC.L2-3.13.11 evidence relies on. A CAVP certificate supports a CMVP validation but does not substitute for one.
Does MyWorkDrive provide FIPS-validated encryption for CMMC?
MyWorkDrive holds NIST CAVP algorithm validation certificate #3018 for FIPS 186-4 RSA, and in a self-hosted deployment it performs TLS encryption through the Windows cryptographic modules on your own server, which carry Microsoft's CMVP certificates. The module validation an assessor cites for SC.L2-3.13.11 comes from those Windows OS certificates, used correctly by the application and documented in your SSP. No file access product satisfies the control by itself, and vendors who claim otherwise are describing the requirement incorrectly.
My servers run Windows Server 2022. Am I affected by the sunset?
Very likely yes, in the documentation sense. The validated cryptographic modules for Windows Server 2022, CMVP certificates #4825 and #4766, are FIPS 140-2 validations with a sunset date of September 21, 2026, after which they move to the Historical list. Existing systems may continue operating on them per NIST guidance, and Microsoft has FIPS 140-3 validations in process. Verify current certificate status on the CMVP search page, record it in your module inventory, and document your transition position in the SSP before your assessment.
Keep your 3.13.11 evidence inside your own boundary
MyWorkDrive gives DoD contractors VPN-free remote access to existing Windows file servers over TLS on port 443, with the encryption performed by your own server's validated Windows cryptographic stack and CUI kept inside your assessment boundary. See how it maps to the CMMC controls that matter at the file access layer.