StealthTech
Ask most IT teams whether their encryption meets CMMC requirements and the answer comes back fast: yes, everything runs AES-256. That answer is almost always true and almost always insufficient. CMMC Level 2 doesn’t require an encryption algorithm. It requires a validated cryptographic module, and the gap between those two things is where SC.L2-3.13.11 quietly fails more assessments than its plain-language wording suggests it should.
This control deserves its own deep dive for the same reason multi-factor authentication does: it’s one of only two requirements in the entire CMMC Level 2 framework with variable, partial scoring built into the methodology, which signals how seriously the DoD treats a partial or misunderstood implementation. It also happens to sit under a hard deadline right now, with the validation standard most contractors currently rely on set to age out in a matter of weeks. This piece breaks down what “FIPS-validated” actually means, where the requirement genuinely applies, and where contractors most commonly get it wrong.
Industry data on CMMC readiness consistently flags encryption and key management as one of the areas where self-reported compliance diverges most sharply from what a third-party assessment actually finds. Organizations that believe they’ve satisfied this control because a product data sheet mentions AES-256 are, in a meaningful number of cases, about to discover that belief was never tested against the specific standard the control requires.
What SC.L2-3.13.11 Actually Requires
The control language is short: employ FIPS-validated cryptography when used to protect the confidentiality of CUI. The word doing all the work in that sentence is “validated,” and it means something specific and narrow. A cryptographic algorithm like AES-256 can be FIPS-approved, meaning NIST has blessed the algorithm itself as sound. That is a separate question from whether the specific software or hardware module implementing that algorithm has been independently tested and certified through NIST’s Cryptographic Module Validation Program. An organization can run AES-256 everywhere in its environment and still fail this control if the module doing the encrypting was never put through CMVP testing.
This distinction is the single most common failure point on this requirement. Vendors describe their products as “FIPS-compliant,” “FIPS-approved,” or built with “FIPS-ready” encryption, language that signals the product uses an approved algorithm but says nothing about whether the implementation itself has been validated. Those terms are not accepted as evidence during a CMMC assessment. What an assessor wants is a specific certificate number from NIST’s Cryptographic Module Validation Program, tied to the exact module and version running in your environment, not a marketing claim about the algorithm it uses.
Where This Control Applies — And Where It Doesn’t
A common and expensive misconception is that every device or connection anywhere near CUI needs FIPS-validated encryption. It doesn’t. The requirement is scoped specifically to CUI when it’s transmitted or stored outside the protected environment of the organization’s information system, which in practice covers VPN connections, wireless networks, remote access sessions, removable media used to transport CUI, and cloud storage or backup destinations.
Encryption used purely within the protected environment, on an internal network segment that never leaves organizational control, isn’t held to the same standard, though most CMMC-mature organizations apply FIPS-validated encryption consistently anyway rather than trying to draw and defend that boundary precisely. Companion controls extend this same standard to specific scenarios: remote access sessions, wireless access, mobile device encryption, and physical media transport all reference the same FIPS-validated standard established in SC.L2-3.13.11.
This is also where organizations sometimes over-scope in the other direction, assuming every switch, internal firewall, or routing device carrying CUI traffic on a controlled internal network needs its own FIPS certification. That’s generally not the case. The requirement follows the data leaving the organization’s protected boundary, not every piece of hardware that happens to touch a packet along the way. Getting this boundary right during your CMMC scoping exercise saves significant time and cost that would otherwise go toward validating infrastructure the control was never meant to cover.
Getting the boundary right also depends on having an accurate picture of where CUI actually lives and travels in the first place, which is a scoping exercise in its own right before it’s an encryption exercise. Our explanation of what CUI is and why it matters for compliance is a useful starting point for organizations still mapping that boundary, since a FIPS validation effort applied to the wrong scope, too broad or too narrow, wastes budget either way.
Why This Is One of Only Two Controls With Partial Scoring
Under the CMMC Scoring Methodology in 32 CFR 170.24, nearly all 110 security requirements score as a straightforward binary: met or not met. FIPS-validated encryption is one of only two requirements in the framework where the DoD built in a mechanism for partial credit, the other being multi-factor authentication. That detail is a signal, not a formality. It tells you the requirement’s designers anticipated that organizations would implement encryption inconsistently across their environment, some systems validated, others not, and wanted the scoring to reflect the difference between an organization with zero FIPS-validated encryption anywhere and one that’s implemented it broadly but missed a handful of systems.
As with multi-factor authentication, that partial credit is smaller comfort than it sounds. A gap in FIPS validation on even one system in scope, a backup destination, a VPN client, a mobile device encryption policy, still generates a documented finding an assessor will record and expect remediated. Partial scoring changes how many points a gap costs. It doesn’t turn a real gap into a passing grade.
The Configuration Trap: Installed Isn’t the Same as Enabled
Even organizations that have correctly licensed FIPS-validated software frequently fail this control for a different reason: the validated module is present but FIPS mode was never actually turned on. Windows environments are the clearest example. BitLocker can run on a Windows Cryptographic Primitives Library module that holds a valid CMVP certificate, and the encryption can still fail SC.L2-3.13.11 because FIPS mode, a specific Group Policy setting, was never enabled. The module being technically capable of FIPS-validated operation and the module actually operating in that mode are two different configuration states, and only one of them satisfies the control.
This gap is easy to create and easy to miss, because everything continues to work normally either way. Encryption happens, files stay protected from casual access, and nothing in daily operation signals that the specific validated configuration required by the control isn’t actually active. It typically surfaces only when an assessor asks for configuration evidence rather than taking a product name at face value.
The same pattern shows up with network appliances. A firewall or VPN concentrator can ship with a FIPS-validated cryptographic module baked into the firmware, sitting alongside a non-validated mode that the device defaults to out of the box because it’s marginally faster or simpler to configure. An administrator who never explicitly toggles the device into its validated operating mode has, functionally, deployed hardware capable of meeting the control without actually meeting it. Confirming FIPS mode is active, not just available, on every device in scope is exactly the kind of five-minute check that prevents a finding an assessor will specifically test for.
What Assessors Actually Ask to See
For every system, application, or tool that touches CUI outside the organization’s protected environment, an assessor expects to see the specific cryptographic mechanism in use, documented in the System Security Plan by name, along with its CMVP certificate number. A System Security Plan entry that says an organization “uses AES encryption” or “encrypts data in transit” without naming the module and certificate reads as incomplete, and assessors are trained to ask the follow-up question that exposes the gap: which module, which certificate, and is it currently active in this environment.
Beyond documentation, expect a request for configuration evidence proving the validated mode is actually enabled, not just installed, along with a technical walkthrough of how encryption is applied to remote access sessions, backup destinations, and any removable media used to move CUI. Organizations that treat this as a one-time procurement decision, buying software with a FIPS-validated module and assuming the box is checked, are the ones most likely to discover a configuration gap during the live technical review rather than before it.
The September 2026 Deadline Most Contractors Haven’t Accounted For
There’s a timing element to this control that makes it more urgent right now than a typical compliance requirement. NIST’s Cryptographic Module Validation Program stopped accepting new FIPS 140-2 validation submissions in 2022, and on September 21, 2026, every remaining active FIPS 140-2 certificate moves to the historical list. Existing systems relying on those certificates continue to function technically, but the certificates themselves no longer support new federal procurement or a fresh compliance argument going forward. For a defense contractor documenting SC.L2-3.13.11 compliance using a FIPS 140-2 certificate that’s about to go historical, that’s a gap that needs attention now rather than something to revisit at the next reassessment cycle.
The practical step is a straightforward inventory: identify every cryptographic module protecting CUI in transit or at rest, check its current validation status against the CMVP database, and confirm whether the specific version running in your environment, not just the product line generally, holds an active certificate. FIPS 140-3 validation timelines have stretched well past a year in many cases, which means contractors who haven’t started this inventory are working against a narrowing window rather than a distant deadline.
Building an Encryption Program That Survives an Assessment
Organizations that handle this control well treat it as a documented inventory problem, not a one-time purchasing decision. That starts with mapping every point where CUI leaves the organization’s protected environment, remote access, cloud storage and backup, wireless connections, removable media, and confirming each corresponding encryption mechanism by name, version, and certificate number.
For contractors running cloud infrastructure, a properly scoped cloud transformation brings this encryption standard into the architecture from the start rather than retrofitting it onto a legacy on-premises environment where FIPS mode was never a design consideration. The same discipline applies to voice communications: a cloud-based VoIP platform configured with validated encryption in transit keeps voice traffic containing sensitive discussion inside the same compliance boundary as everything else, rather than treating phone systems as an afterthought outside the CMMC environment.
Backup and disaster recovery infrastructure deserves particular attention here, since backup destinations are one of the most common places CUI leaves an organization’s protected environment without anyone treating it as a FIPS-validation checkpoint. A managed IT partner with direct CMMC experience builds and documents this inventory with the specific assessment objectives in mind, rather than assuming a vendor’s general security claims translate directly into CMMC evidence. A broader CMMC gap assessment should surface any FIPS validation gaps, including the September 2026 certificate transition, well before a formal C3PAO assessment puts them on the record.
Stealth Technology Group audits and documents FIPS-validated encryption across your CUI environment, including the September 2026 FIPS 140-2 transition. If you need to confirm your encryption posture will hold up under CMMC assessment, visit our compliance services page, or contact Stealth Technology Group today at (617) 903-5559 to talk with a specialist.
