FIPS 140-2 Sunset: What Is Validated in Your CUI Boundary

Quick answer: on 22 September 2026 every FIPS 140-2 certificate moves to the CMVP Historical List. That date does not change what your Macs do. It changes what you can write about the Windows half of a mixed fleet, and it changes what a vendor can honestly tell you. This page states what is actually validated, by certificate number, checked against CMVP on 21 August 2026.

Why do vendors answer a FIPS question with the wrong certificate?

Almost every bad FIPS answer in a CUI boundary comes from collapsing two separate questions.

1. Is there a validated cryptographic module? That is a CMVP certificate with a number. It belongs to a specific module, version and operating environment.
2. Is the service authorized? That is FedRAMP, StateRAMP, SOC 2 or similar. It is an assessment of a service, not of a cryptographic module.

Neither answers the other. If you ask a vendor for a FIPS certificate number and receive a SOC 2 report, you have not been answered. If you ask about service authorization and are told the traffic is encrypted with TLS, you have not been answered either.

Microsoft states the structural reason for the gap itself: current CMVP implementation guidance precludes a FIPS 140-2 validation for a cloud service as such, and "FIPS 140 compliant" is an industry term for products that rely on FIPS 140 validated products. So do not write that a cloud service is FIPS validated in an SSP. Write which module it relies on, or write that you could not establish one.

What is actually FIPS validated on a Mac today?

Verified on CMVP, 21 August 2026. Apple holds 30 active FIPS 140-3 certificates across corecrypto module versions.

For macOS 15 Sequoia on Apple silicon, the set is now complete:

Certificate #5387 is recent and it closes a real gap. Until 9 July 2026 the Apple silicon kernel module for that release was not validated, which meant a contractor standardising on Sequoia could be asked a question they could not fully answer. That is no longer true. If your reference material still says the Sequoia Apple silicon kernel module is unvalidated, it is out of date, and ours was until we rechecked.

Two precision notes that a knowledgeable reader will test:

• CMVP names modules by corecrypto version, never by macOS marketing name. The mapping from module version 18.3 to "Sequoia" is Apple's assertion on its own certifications page, not NIST's. Cite the certificate number, then the version, then the OS name in that order.
• Do not assert that a specific macOS feature is or is not FIPS validated. Which subsystems depend on the kernel module versus the user module is not something the certificate pages resolve. The validated thing is the module.

What happens to Windows cryptography on 22 September 2026?

The Windows client cryptographic modules are FIPS 140-2, and 140-2 certificates move to the Historical List on 22 September 2026. Verified on their certificate pages:

Both are FIPS 140-2. #4825 is bcryptprimitives.dll and #4766 is cng.sys, which CMVP describes as providing cryptographic services to Windows kernel components. These are the modules the platform relies on.

Microsoft holds exactly two active FIPS 140-3 certificates: #5313 Microsoft SymCrypt Cryptographic Library, and #4880 Pluton Security Processor ROM, a sub-chip subsystem. Neither covers a Windows client. The SymCrypt security policy lists server and Linux tested environments, not Windows 11, and a module is validated only in the environments its security policy names.

Microsoft is working on it, and the stage it has reached is the part that matters. Checked 22 August 2026: both Windows client modules appear on the CMVP Implementation Under Test list, named for Windows 11 version 23H2 and Windows 11 version 24H2, alongside Boot Manager, Code Integrity, BitLocker Dump Filter and the Windows OS Loader. Neither appears on the Modules In Process list.

Implementation Under Test is the earliest stage and it is not a validation. It records that a vendor has engaged an accredited laboratory. It is not a submission to CMVP, it carries no certificate number, and it publishes no completion date. Modules In Process is the next stage after it, and a certificate is the stage after that.

So the accurate sentence for an SSP is this: Microsoft has Windows 11 client modules under test and holds no active FIPS 140-3 certificate covering a Windows client. Whether a certificate exists before or after 22 September is not knowable from the public lists, and anyone telling you they know the date is guessing.

The three tiers you must not conflate

When you write a vendor into an SSP, it sits in exactly one of these.

1. The product is the validated module. The certificate is in the vendor's own name and names the product. Write the certificate number.
2. The product incorporates a validated module. The vendor holds no certificate; it embeds someone else's. Write "incorporates FIPS 140-3 validated module #N", never "is FIPS validated". Capture the number, not the module name: two active certificates can share an identical module name string.
3. The product holds no certificate at all. Very common, frequently fine, and it must be written down as what it is.

Tier 3 is not a disqualification. Apple device management platforms sit there routinely, including Jamf and Mosyle, both of which return zero CMVP certificates. On a managed Mac the cryptography is Apple's corecrypto; the MDM is not the thing performing CUI cryptography. The error is not being in tier 3. The error is writing tier 3 as though it were tier 1.

The practical test: a vendor that cannot give you a certificate number does not have one. Marketing language about military-grade or validated encryption without a number is not evidence, and at least one storage vendor markets exactly that while holding zero certificates.

How do I check whether a vendor is FIPS validated?

The CMVP validated modules search is URL-queryable and server-rendered, so you can check a vendor directly rather than taking a claim on trust.

• Use advanced search mode, which includes Historical and Revoked results. A vendor search that returns nothing in advanced mode is a genuine negative, because the vendor filter is a case-insensitive substring match.
• Open the certificate page. Do not read the standard from a results row; rows have misreported 140-2 as 140-3.
• The module version and the tested platforms are only in the security policy PDF, not on the certificate page. A certificate can look like it covers your platform and not name it.
• The results table shows neither the sunset date nor the standard. Both matter and both require the certificate page.

Does this mean Windows is non-compliant after 22 September?

It does not mean Windows becomes non-compliant on 22 September. Moving to the Historical List is a change in the status of a certificate, not a finding against your environment, and CMMC Level 2 requirements come from NIST SP 800-171 Rev 2, which did not change.

It does mean the sentence in your SSP has to be accurate on the day an assessor reads it. If a control narrative rests on a specific certificate, that certificate's status is a fact with a date attached, and 22 September changes the date-stamped answer for a large number of Windows environments.

The honest summary of the asymmetry, as of today: macOS 15 Sequoia on Apple silicon holds a complete set of active FIPS 140-3 validated modules. The Windows client modules are 140-2 and move to the Historical List on 22 September 2026, and Microsoft's two active 140-3 certificates cover neither of them. Both halves of that sentence are checkable against certificate numbers, which is the only reason it is worth writing down.