What the FIPS 140-2 sunset means for DoD contractors on Enterprise Linux

On September 21, 2026, NIST moves every FIPS 140-2 certificate to Historical status. The modules keep running, but NIST's CMVP (Cryptographic Module Validation Program) defines ‘Historical’ as modules that federal agencies "should not include" in new procurements. For DoD contractors operating under CMMC, DFARS, and related requirements, that language has direct audit consequences, and CMMC Level 2 enforcement follows seven weeks later on November 10.

Historical certificates weaken your FIPS evidence chain in an audit

The closure of FIPS 140-2 will not retroactively invalidate certificates issued before September 21. A system running FIPS 140-2 validated modules will continue to operate. The distinction is in how those certificates can be cited going forward.

After September 21, NIST's operative procurement language says federal agencies "should not include" Historical modules in new acquisitions. For DoD contractors, that language maps to the evidence tables contracting officers, C3PAOs, and auditors use to evaluate compliance. A Historical certificate invites questions. In a CMMC assessment, questions risk becoming findings.

NIST allows agencies to make a risk determination for existing deployments where migration isn't complete, but that path requires documented justification and doesn't resolve the gap.

The practical impact falls into two categories: new system builds that must document a FIPS compliance evidence chain, and existing deployments that come up for contract renewal or assessment after September 21. Both need active FIPS 140-3 certificates to close that chain.

One CMVP lookup tells you whether your systems are exposed

FIPS mode enabled does not mean FIPS validated. What matters is whether the cryptographic module running on your Linux systems has an active FIPS 140-3 certificate in NIST's CMVP database. A FIPS 140-2 certificate transitions to Historical in September.

The specific exposure depends on two factors: whether your modules have been re-certified under FIPS 140-3, and whether the version running on your systems matches the certified version exactly. The second factor matters as much as the first. CMVP certificates are tied to specific module versions. A distribution may hold a FIPS 140-3 certificate, but if routine updates have advanced the module past the certified version, the certificate doesn't cover the running system.

fips-mode-setup --check tells you whether FIPS mode is active; it does not tell you whether your modules have active CMVP certificates. Those are separate facts, and only the second one survives the September 21 threshold.

Your FIPS evidence chain starts with a CMVP lookup. Read the solution brief

Three verification steps before September 21

Start with your cryptographic module inventory: which modules are running, at which versions, on which systems. This information lives in the running OS, not in static configuration docs. What was accurate at deployment may not reflect what a package manager has updated since.

With module names and versions identified, look them up in NIST's CMVP database. An ‘Active’ FIPS 140-3 certificate covering your running module version means no action is required for this deadline. A FIPS 140-2 certificate, transitioning to Historical on September 21, means you have a confirmed gap and a deadline to close it.

The third check: does your Linux distribution vendor have active FIPS 140-3 certificates available today? Not a roadmap commitment. Not a Module in Process (MIP) queue entry. Active certificates, verifiable in the CMVP database now.

FIPS mode restricts which algorithms the OS will use; it does not change whether the modules implementing those algorithms carry a current CMVP certificate. A misconfigured evidence chain, where FIPS mode is active but the underlying modules lack current certificates, creates a larger audit problem than a documented gap.

The September deadline directly shapes your CMMC readiness

CMMC Level 2 enforcement begins on November 10, 2026, roughly seven weeks after the FIPS 140-2 sunset. Control 3.13.11 of NIST SP 800-171, the underlying cryptographic requirement, specifies "FIPS-validated cryptography when used to protect the confidentiality of CUI."

After September 21, a Historical certificate as the basis for 3.13.11 compliance carries the same question in a C3PAO assessment that it carries anywhere else: NIST no longer recommends this module for new procurement. Contractors who address the September deadline enter November with a defensible FIPS 140-3 baseline. Those who defer manage both gaps under the same assessment pressure.

Active FIPS 140-3 certificates close the gap

FIPS 140-3 validation is not a configuration change. It requires a Linux distribution whose cryptographic modules hold active CMVP certificates under FIPS 140-3, tied to the specific module versions running on production systems. The CMVP database lists all active certificates with module names, versions, and associated OS details. An OS vendor with active FIPS 140-3 certificates can provide the certificate numbers and the module versions they cover.

For organizations evaluating whether to migrate: the answer to "does your distribution have active FIPS 140-3 certificates" is verifiable today, before any vendor conversation. Look up the distribution name in NIST's CMVP database and check the certificate status column. Active means post-sunset compliance is achievable. A Historical certificate means September 21 creates a gap.

Organizations on Rocky Linux 8 or Rocky Linux 9 have active FIPS 140-3 certificate coverage through RLC Pro. Five active FIPS 140-3 CMVP certificates are tied to specific module versions and verifiable in the NIST CMVP database today: #5200 (OpenSSL, Rocky 8), #5117 (libgcrypt), #5116, #5113, and #5095 (kernel). RLC Pro also includes GnuTLS modules covered by CAVP algorithm certificates A6464 through A6487 across both major versions.

For organizations on EL8 platforms, RLC Pro on Rocky 8 holds active FIPS 140-3 certificate #5200 for OpenSSL - validated coverage that lets EL8 contractors close the OpenSSL gap without a simultaneous major-version upgrade.

A DoD contractor migrating to RLC Pro before September 21 arrives at the deadline with an active FIPS 140-3 baseline documented: certificate numbers, module versions, and the evidence chain an auditor will follow. LTS version pinning keeps those certificates valid across routine update cycles, so maintenance doesn't advance a module past the certified version and reopen the gap.

Start the verification workflow now. The migration, validation, and documentation work to close a FIPS 140-3 gap spans multiple quarters for organizations without an existing validated baseline. September 21 is the first deadline; November 10 is the second. Learn more.

Request a technical briefing