FIPS 140-2 Goes Historical. What It Means for Macs.

Quick answer: on September 22, 2026 every remaining FIPS 140-2 certificate moves to the Historical list. Existing systems can keep using those modules. What changes is what you can defend for new deployments, and macOS has a specific problem worth checking this week.

What actually happens on September 22?

The NIST Cryptographic Module Validation Program transition page sets the date plainly: all FIPS 140-2 certificates are placed on the Historical List on September 22, 2026.

Watch the date if you are quoting it. A good deal of secondary coverage says September 21. That is the last day of validity rather than the day the move happens, and getting it right is a cheap credibility signal.

This is the end of a long transition to FIPS 140-3, not a sudden policy change. It has been scheduled for years.

Does a Historical certificate stop being usable?

Not for what you already run. The CMVP page states that even on the historical list, the programme supports the purchase and use of these modules for existing systems.

What it does mean is that a Historical certificate is a weakening position over time. If you are selecting a platform now, choosing one whose validation is Historical rather than current is a decision you will be asked to justify, and the justification gets harder every year.

Nothing here changes the underlying requirement. SC.L2-3.13.11 still asks you to employ FIPS-validated cryptography to protect CUI, and enabling encryption is not the same as employing a validated module. We covered that distinction in FIPS-validated encryption for CUI.

Which macOS versions have validated crypto today?

Apple holds current FIPS 140-3 certificates for macOS 15 Sequoia, corecrypto module version 18.3, all active:

• Certificate 5184, Apple silicon, User, Software, Security Level 1, validated March 11, 2026.
• Certificates 5217 and 5218, Intel, User and Kernel, Software, Security Level 1, validated March 30, 2026.
• Certificate 5305, Apple silicon Secure Key Store, Hardware, validated June 3, 2026.
• Certificate 5387, Apple silicon, Kernel, Software, Security Level 1, validated July 9, 2026.

That set is complete, and it only became complete recently. Until July 9, 2026 the macOS 15 Apple silicon kernel module was not validated, and a contractor standardising on Sequoia could be asked a question they could not fully answer. Certificate 5387 closed that gap.

If you are reading a reference that still says the Sequoia Apple silicon kernel module is unvalidated or in Comment Resolution, it is out of date. Ours was, until we rechecked on August 22, 2026. Apple's own certifications page published on July 20, 2026 still described that status eleven days after the certificate issued, which is a reminder that vendor pages lag CMVP and the certificate is the authority.

Two caveats on how to read this. CMVP names modules by corecrypto version rather than by macOS marketing name, so the mapping from 18.3 to Sequoia comes from Apple rather than from NIST. And you should confirm which macOS subsystems depend on the kernel module versus the user module before drawing conclusions about any specific feature.

What if you are already on macOS 26?

Then you do not have validated cryptography on that operating system today.

Rechecked August 22, 2026: the CMVP Modules In Process list shows both macOS 26 Apple silicon corecrypto modules, user and kernel, at status Review, dated July 30 and July 31, 2026. That is a later stage than the Pending Review they sat at a month earlier. The Secure Key Store for that release is on the separate Implementation Under Test list. No certificate has been issued.

Read that as a moving target rather than a settled fact. Tahoe advanced one stage in under a month, and a certificate would retire this whole section. Check the Modules In Process list yourself before relying on it.

This is where the deadline in the previous article becomes concrete. Under 32 CFR 170.21 the encryption requirement is the single exception that may be placed on a POA&M, and only where encryption is employed but not FIPS-validated. But 170.21(b) requires closeout within 180 days of the Conditional CMMC Status Date.

You cannot close that POA&M by waiting on a validation queue. You close it by having a validated module or by moving to one. That is inference from combining two provisions rather than a statement in the rule, but the arithmetic is not complicated and it favours caution. Full detail in what you can put on a CMMC POA&M.

How should you document this?

Name the certificate, not the feature. Writing that FileVault is enabled says nothing an assessor can verify. Writing the module name, the certificate number, the validation date and the macOS version it maps to gives them something checkable.

Three habits worth adopting now:

• Record the certificate number and date in the SSP, not just the product name.
• State your OS version policy explicitly. If you defer major upgrades until validation lands, that is a defensible control decision, and it only helps you if it is written down.
• Re-check before each major release. Certificate status changes and your documentation does not update itself.

Verify certificate numbers against the CMVP database yourself before relying on any of them in an assessment. Status changes, and this article carries a date for a reason.

For the vendor and boundary side of the same date, which modules your other tools actually rely on and what the Windows half of a mixed fleet looks like, see what is validated in your CUI boundary.

Sources

• NIST CMVP FIPS 140-3 Transition Effort page
• NIST CMVP validated modules search, Apple, active certificates
• NIST CMVP Modules In Process list, updated July 24, 2026
• Apple, macOS security certifications, published July 20, 2026
• 32 CFR 170.21(a)(2)(ii) and (b)

Certificate status observed August 1, 2026. Confirm current status directly with CMVP before relying on it. This is not legal advice.