When the Rules and Reality Don’t Quite Line Up
A few days ago, as I was preparing myself a nutritious midnight snack, a bowl of Cap’n Crunch cereal. Don’t shame me. It has some vitamins in it…. I think. Anyways… I focused with great precision on getting the right amount of that sugary goodness in the bowl, then, with a steady arm, I prepared to pour the milk. Like any sane person, though, I had to take a whiff before pouring. I’ve had too many bad experiences with milk in my troubled past not to do so. And I’m glad I did. One sniff and my face became malformed. SPOILED! I turned the jug over to find the expiration date, and lo and behold, it was indeed expired. It looked fine, it swished around in the jug fine, all was well, but, unfortunately, my midnight snack was really dry that night and I lived to tell the tale. Friends, I share this precarious tale, this equivalent of a Greek tragedy, not to give you the heebie-jeebies, but as an analogy.
You see, that’s essentially what happens to a lot of Defense Industrial Base (DIB) contractors when it comes to NIST SP 800-171’s requirement, 3.13.11, the one that mandates Federal Information Processing Standards (FIPS)-validated cryptography whenever encryption is used to protect the confidentiality of Controlled Unclassifed Information (CUI). You implemented it. You enabled the Windows FIPS compliance policy via Intune or GPO. You checked the box. You moved on. And somewhere between putting it in your proverbial refrigerator for safekeeping and taking it out again when you need it (e.g., when you’re prepping your evidence for submission to your CMMC assessment, you notice something quite concerning: the certification status of the cryptographic modules baked into your Windows 11 build quietly… expired. Or worse, it never applied to the specific build you’re running in the first place. Same Windows logo on the start menu. Same “FIPS mode enabled” in Group Policy. But no active Cryptographic Module Validation Program (CMVP) certificate to back it up. Everything seems fine, until it doesn’t.
This blog is going to walk through the full picture: what 3.13.11 actually requires, what related requirements are in play, why the current FIPS certification landscape around Windows 11 and other common system components creates a real dilemma, what the concept of a “temporary deficiency” means and how it might help, and, most importantly, what you should practically do about all of this whether you’re mid-implementation or already on the other side of your certification assessment. Shall we?
What 3.13.11 Actually Requires: Words Mean Something
Let’s start at the source. NIST SP 800-171 Rev. 2 requirement 3.13.11 states simply: “Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.”
These few words have caused more headaches in the DIB compliance space than maybe any other single sentence in 800-171. And the key to understanding the headache lies in two concepts that many people conflate or misunderstand: FIPS-validated cryptography versus FIPS-compliant or FIPS-approved cryptography.
Here’s the distinction that matters enormously: it is not sufficient to simply use a FIPS-approved algorithm like AES-256 or SHA-256. The cryptographic module, the actual software or hardware component that implements those algorithms, must have been independently tested and validated through the NIST CMVP and have an active certificate on the NIST CMVP website. That’s it. That’s the bar. And many products and operating systems that claim “FIPS compliance” or advertise “FIPS-approved algorithms” simply have not gone through that formal module validation process.
The CMMC Assessment Guide for Level 2 is unambiguous on this point: “Simply using an approved algorithm is not sufficient; the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140.” So, when you enable that FIPS compliance group policy in Windows and Windows starts restricting itself to FIPS-approved algorithms, that’s not the same thing as the underlying cryptographic modules having a current, active FIPS 140-3 validation certificate. One is a configuration setting. The other is a formal certification. They are not synonymous.
However, to be clear, the inverse is also important. A module may be FIPS-Validated and still not be operated in a compliant fashion. When you read the actual certificate from the NIST CMVP website for the validated module, there’s a section called “Caveats” where they articulate what other conditions need to be met (i.e., the caveats) for the validation to apply to the cryptographic functions. For example, one caveat might say something like “When operated in approved mode. When installed, initialized and configured as specified in Section Secure Operation in Section 11 of the Security Policy. The tamper evident seals installed as indicated in the Security Policy”. This means that, if these conditions are met, any cryptographic functions using this module are being executed in a way that can be considered “FIPS-Validated”.
Side note: You’ll see both FIPS 140-2 and FIPS 140-3 referenced when you’re digging through the NIST CMVP website, and it’s worth understanding the difference. FIPS 140-3 is the current standard, which replaced FIPS 140-2 in 2019 and introduced updated testing requirements aligned with ISO/IEC 19790. NIST stopped accepting new FIPS 140-2 submissions in September 2021, and as of September 2026, all remaining FIPS 140-2 certificates will be moved to historical status meaning they’ll no longer be considered active validations for compliance purposes. So, if you’re currently relying on a product whose only FIPS credential is a 140-2 certificate, you’re not just dealing with the patching-versus-certification gap problem, you’re also on a bit of a countdown. Any product in your environment with a 140-2-only certificate needs to be on your radar for vendor follow-up and that follow-up should see answers to the following questions: Has the vendor submitted for 140-3 validation? Is it in the queue? Do they even have a plan? These are questions worth asking now, not six months after the sunset date has passed and your assessor has been given a bunch of certificate URLs to the CMVP website just to find several of them with a historical status.
The Encryption Family: Related Requirements in the Same Isle
Before we dive into the Microsoft-shaped elephant in the room, let me take a moment to acknowledge that 3.13.11 doesn’t live alone. It’s part of a broader family of encryption-related requirements in 800-171, and they all feed into each other. If you’re trying to understand the scope of your FIPS obligations, you need to look at all of them together.
SC.L2-3.13.8 requires the use of cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission. Think encrypted email, SFTP, TLS-protected web traffic, VPN tunnels. All of it. And as the Assessment Guide notes, because cryptography here is being used to protect CUI confidentiality, “the cryptography used must meet the criteria specified in requirement SC.L2-3.13.11.” There’s your link. 3.13.8 imports the FIPS-validated requirement by reference.
SC.L2-3.13.16 requires organizations to protect the confidentiality of CUI at rest. This is your full disk encryption, your volume encryption on file servers, your encrypted USB drives. Same story: if you’re using encryption as the means of protecting CUI at rest, the cryptographic modules involved need to be FIPS-validated.
Side note: It’s worth mentioning here that 3.13.16 doesn’t exclusively require encryption. Physical security and access controls can also satisfy this requirement in the right circumstances. But that nuance deserves its own blog, and I’ve already written it! Check it out here: Confident Guardians: Protecting CUI at Rest Under NIST 800-171 – IntelliGRC
MP.L2-3.8.6 addresses portable storage and the requirement to control and protect media containing CUI. And once again, if cryptography is your chosen protection mechanism for that portable storage, 3.13.11 applies. Same for AC.L2-3.1.13 (remote access confidentiality) and AC.L2-3.1.19 (encrypting CUI on mobile devices).
And then there’s MP.L2-3.8.9, which requires organizations to protect backups containing CUI. Whether stored on local hard drives, offsite in a colocation data center, or via cloud storage (which has its own separate concerns), if cryptography is involved in the protection, it needs to be FIPS-validated.
The bottom line: 3.13.11 isn’t on its own, it’s the cryptographic standard-bearer for a whole cluster of other requirements. Getting it wrong doesn’t just result in a finding on 3.13.11; it can cascade into findings across multiple related requirements. And that, friends, is why it matters so much to get this right.
Enter Microsoft, “Windows” into the Problem
Okay. Now let’s talk about the thing that’s been quietly causing headaches for CMMC practitioners and organizations alike: Microsoft’s track record of taking their sweet time getting FIPS 140-3 certifications for the cryptographic modules in their latest Windows 11 builds.
Here’s the basic dynamic. NIST’s CMVP process is rigorous and time-consuming. Getting a cryptographic module validated can take a year or more from the time the vendor submits for testing. Microsoft has typically pursued FIPS validation for their Windows cryptographic modules (like Cryptographic Primitives Library, bcryptprimitives.dll, and others), but they’ve historically done so for specific build versions, and newer Windows 11 feature updates frequently outpace the certification cycle. This means that if you’re running a relatively recent Windows 11 release, especially one from the last year or two, there’s a real possibility that the specific build you’re running doesn’t have an active, current FIPS 140-3 validation certificate.
You can check this yourself right now. Head over to the NIST CMVP website and look up Microsoft’s validated modules. You’ll find certificates for specific Windows builds, often with notes about which exact versions of Windows they cover. The question is whether your current Windows 11 version aligns with an active certificate, not one that has been moved to historical status or one that just doesn’t exist at all.
A module on historical status means the validation is no longer active. It existed once. It passed once. But NIST’s current position is that historical modules should no longer be used for new implementations, and some assessors will take a very strict view that a historical-status certificate doesn’t satisfy 3.13.11’s requirement for FIPS-“validated” cryptography. That’s a reasonable and defensible interpretation, and if your assessor takes that view, you may have a problem.
Now, to be fair to Microsoft, they’ve generally kept up better than many vendors, and there are versions of Windows 11 and Windows Server that do have active certificates against the FIPS 140-x standard. The issue is the gap or the window of time between a new Windows 11 feature update releasing to general availability and that version receiving its FIPS validation. Organizations running current patch levels for legitimate security reasons (you should be patching, obviously) can find themselves in a position where their fully patched, fully updated Windows 11 devices are running a build that technically doesn’t have an active FIPS certificate. It’s a real dilemma, and it’s not one the DIB community has fully reckoned with yet.
To be clear, Microsoft isn’t alone. Microsoft is just the most visible vendor here because Windows is in almost every DIB environment on the planet, but they are far from the only vendor playing catch-up with FIPS certification cycles. Firewall and network security vendors are arguably in an even trickier spot. Palo Alto Networks, Fortinet, Cisco, and others ship firmware and software updates on aggressive cycles, often driven by critical vulnerability patches that you absolutely cannot afford to delay, and their cryptographic modules face the exact same certification lag problem. A Palo Alto Next-Generation Firewall (NGFW) running the latest PAN-OS release for security reasons may not have an active FIPS certificate for that specific firmware version. Same story with Fortinet’s FortiOS and Cisco’s Adaptive Security Appliance (ASA) and Firepower lines. Virtual Private Network (VPN) concentrators, encrypted backup appliances, and collaboration platforms, if they use cryptographic modules and those modules haven’t been through the CMVP gauntlet for the version you’re running, you’ve got the same problem if used for CUI. The FIPS validation gap isn’t just a Microsoft problem. It’s an industry-wide reality that we need a practical way to address, as CMMC Implementation and Assessments are underway!
The Stringency Problem: Choosing Your Interpretation
Here’s where organizations and, frankly, assessors, face a genuine choice about how strictly to interpret the requirement. And I have to be honest, there isn’t a universal consensus on this in the CMMC community.
The strict interpretation says: the requirement is clear. FIPS-validated cryptography means an active, current FIPS 140-2 or 140-3 validation certificate on the NIST CMVP website. If your Windows build doesn’t have one, you’re not compliant with 3.13.11, period. Some assessors will apply this lens rigorously and, honestly, there’s nothing wrong with that reading of the requirement. It’s what the words say.
A somewhat more pragmatic interpretation acknowledges the realities of the patching-versus-certification gap and looks at whether the organization has done everything within its reasonable power to maintain FIPS-validated cryptography, has documented the gap, has a plan to address it, and is not meaningfully increasing security risk by continuing to use cryptographic implementations that are functionally identical to their validated predecessors just running on a newer OS build. This is where the concept of a “temporary deficiency” becomes relevant (we’ll get there in a minute.)
What I’d caution against is the lazy middle ground: enabling the FIPS policy setting in Windows Group Policy, calling it done, and hoping no one looks too closely. That’s the approach that shouts apathy. The policy setting restricts Windows to FIPS-approved algorithms, but as we’ve already established, algorithm approval and module validation are two very different things. Relying on the policy setting alone without verifying the actual CMVP certificate status for your specific Windows build is not a defensible implementation in my book.
A Lifeline? Temporary Deficiencies Under 32 CFR Part 170
This is where the regulatory framework gives us a genuinely useful concept; a tad bit of grace, if you will. The 32 CFR Part 170 (the regulation that governs the CMMC program) defines a “temporary deficiency” in a way that’s directly relevant to the Windows FIPS situation.
Per the definition in 32 CFR § 170.4: “a condition where remediation of a discovered deficiency is feasible and a known fix is available or is in process. The deficiency must be documented in an operational plan of action. A temporary deficiency is not based on an ‘in progress’ initial implementation of a CMMC security requirement but arises after implementation.”
And critically, the CMMC Assessment Guide itself provides an example that maps almost perfectly to our Windows situation: “FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency.” That is, almost word-for-word, the Windows FIPS lag problem we’ve been describing. The scenario where you’ve patched your system for legitimate security reasons, and the patched version is running ahead of the FIPS certification cycle is precisely the kind of thing the temporary deficiency concept was designed to accommodate.
So, what does this mean practically? It means that if your Windows 11 devices are running a build that doesn’t yet have an active FIPS 140-3 validation certificate, but Microsoft has a validation in progress for that build (which you can verify through the CMVP modules in process list) or a certificate for a very close prior build is active, you have a reasonable basis to document this as a temporary deficiency in your Operational Plan of Action (OPA), with the details necessary to show how you’ll get this addressed. In reality, this is probably something you’ll need to document every so often with these types of situations.
A few important notes on this: First, a temporary deficiency is not a free pass to ignore the requirement indefinitely. The whole point is that there’s a known fix that is feasible or in progress. Second, this is different from a CMMC assessment-level POA&M. The operational plan of action under CA.L2-3.12.2 is an internal risk management document. It’s not the same as placing 3.13.11 on a formal assessment POA&M to obtain Conditional CMMC status. Third, and I cannot stress this enough: the temporary deficiency concept does not apply if this is something you’ve known all along. It’s intended for those things that arise after initial implementation or on a small subset of things during the initial implementation. Now, from what I’ve seen, it’s generally accepted that, as part of initial CMMC implementation, if you’ve got Windows devices and you’re keeping them up-to-date, rendering them technically not FIPS-validated, putting them on your list of OPAs will probably do ok for your assessment due to the pervasive use of Windows devices in the DIB. However, this is not in accordance with the clearest requirements and there is nothing in writing I’m aware of that would allow such an exception, so buyer beware! A more stringent assessor would have every right to be concerned.
What Should You Actually Do? Practical Steps
Alright, let’s land the plane. Whether you’re in the middle of implementing CMMC requirements or you’ve already been assessed and are maintaining your posture, here’s what I’d recommend for 3.13.11 and the Windows FIPS situation specifically.
First: Audit your actual FIPS certificate status, not just your policy settings.
Go to the NIST CMVP website and look up the active certificates for the specific Windows builds and other devices from other vendors running in your environment. Don’t just assume that because you’ve enabled FIPS mode in Group Policy, you’re covered. Know exactly which versions you’re running, and know whether those versions have active (not historical) FIPS certificates.
Second: Check the CMVP modules in the process list.
If your Windows version doesn’t have an active certificate but Microsoft has submitted the module for validation, and it’s currently in the testing queue, that’s meaningful. Document it. That’s your evidence that a known fix is in process, which is what makes a temporary deficiency defensible rather than risking a stringent point of view.
Third: Document everything in your Operational Plan of Action.
If there is a gap between your current Windows build and the available FIPS validation certificates, don’t leave it undocumented. Write it up in your OA/POA: what the deficiency is, what the known path to remediation is (Microsoft’s or other vendor’s pending certification), and what compensating controls you have in place in the meantime (implementation of other NIST SP 800-171 requirements, regular review of CMVP statuses) to reduce risk during the gap period.
Fourth: Consider your Windows update strategy in the context of FIPS validation timing.
This is a nuanced one. I’m not suggesting you delay security patches; you absolutely should be patching. But if you’re running a mix of Windows 11 builds, it may be worth staying on a specific, validated build where possible, and being thoughtful about your upgrade cadence in relation to FIPS certification timing. Enterprise organizations with Windows Server Update Services or similar patch management tools have more control over this. Use that control strategically where practical.
Fifth: Look beyond Windows for your FIPS gaps.
Windows is one of the most common culprits in this conversation because it’s so ubiquitous, but the same validation-gap problem can affect VPN clients, encryption utilities, collaboration tools, and other products that use cryptographic modules to protect CUI. Do a full audit of every product in your environment that touches CUI through cryptographic means and verify FIPS-validated certificate status for each one.
Sixth: If you’ve already been assessed, stay on top of this.
CMMC is not a once-and-done compliance event. Your FIPS status can change as you patch and update your environment, and new certification cycles affect the tools you rely on. Build a recurring check of CMVP certificate status into your continuous monitoring practices. Quarterly is probably sufficient for most organizations, annually at the absolute minimum.
A Word on Assessors and the Judgment Call
I want to acknowledge something directly: assessors vary in how they handle this. Some assessors will have a very hardline approach, for instance, if the module isn’t on the active CMVP list for your exact build, it’s a finding, they can’t see it any other way. Others will be more willing to engage with the temporary deficiency framework and give credit for well-documented gaps with credible remediation plans. That variance is real, and it’s not unique to this requirement.
What I’d tell organizations is this: don’t bank on getting a lenient assessor. Document your situation thoroughly as if you’re going to get the most rigorous assessor on the planet, because you might. The organizations that come out of assessments in the best shape are the ones that have documented their gaps honestly, can articulate why the gap exists, can demonstrate the compensating risk reduction measures they have in place, and can show a credible plan for closing it. That’s good compliance practice regardless of how any individual assessor approaches it. This is not to say that you’re guaranteed to have a favorable determination for the requirement if you just document it well. Sometimes, the requirements just aren’t met. Thankfully, per 32 CFR Part 170.21, 3.13.11 is a requirement that can be included in an Assessment POA&M and given 180 days to figure out and implement a solution to any problems discovered. There are other nuances and conditions that need to be met in that portion of the regulation, but hopefully that’s a bit of encouragement for one of the more daunting parts of CMMC / NIST 800-171 implementation!
Final Thoughts
The tension between maintaining current security patches and maintaining FIPS-validated cryptographic module certification is a legit difficulty. Microsoft’s cadence for FIPS certifications for newer Windows builds has created a genuine compliance dilemma for organizations doing their best to navigate CMMC obligations in good faith. In reality, the requirement for private organizations to implement FIPS-validated cryptographic modules is already incredibly cumbersome depending on the context. The good news is that the regulatory framework, particularly the temporary deficiency concept under 32 CFR Part 170, does provide a mechanism to address this in an honest and defensible way as long as you document it properly and have a real plan for remediation.
At the end of the day, the goal of 3.13.11 is simple: ensure that when cryptography is used to protect CUI, it’s cryptography that has been independently validated as meeting rigorous security standards. The spirit of that requirement doesn’t change just because there are frustrating circumstances involved in its implementation. Your job is to do what you can as well as possible, document where you can’t get all the way there and why, show the path forward, and keep the security posture as strong as you can in the meantime.
If you and your organization are working through the FIPS compliance puzzle, whether it’s 3.13.11, related requirements like 3.13.8 or 3.13.16, or just trying to make sense of a FIPS validation scenario in general, we at IntelliGRC are constantly working on exactly these questions with DIB contractors and their MSPs across a wide range of industries and technical environments. We’d love to help you figure out where you stand and what to do about it. Feel free to reach out through our contact form here or shoot an email to sales@intelligrc.com, and we’ll get you pointed in the right direction.
As always, happy implementing!
Steven Molter | IntelliGRC
Connect with me on LinkedIn
Key Takeaways
NIST SP 800-171 3.13.11 requires FIPS-validated cryptographic modules, not just FIPS-approved algorithms. Enabling Windows FIPS mode via Group Policy is not the same as having a current and active CMVP certificate.
Microsoft has historically lagged on FIPS 140 certification for newer Windows 11 builds, creating a real potential compliance gap for organizations running current patch levels.
The requirements 3.13.8, 3.13.16, 3.8.9, 3.8.6, and 3.1.13 all inherit the FIPS validation requirement from 3.13.11 when cryptography is used to protect CUI.
The temporary deficiency concept under 32 CFR Part 170 may apply when a FIPS gap exists due to patching requirements outpacing certification cycles, but it must be documented in an Operational Plan of Action.
Verify your FIPS certificate status for every device in your environment against the NIST CMVP active certificate list.
Build continuous monitoring of CMVP certificate status into your compliance maintenance program. Your FIPS posture can change with every OS update.