Two dates define the sunset. FIPS 140-2 certificates remain usable for new systems only through September 21, 2026. On September 22, 2026, every remaining 140-2 certificate moves to the CMVP Historical List. If a 140-2 module sits anywhere in your stack — or your product — you have a deadline, whether or not anyone has told you yet.
The final day a FIPS 140-2 certificate can be used to satisfy the validated-module requirement for a new system. Through this date, 140-2 remains a legitimate answer for new deployments.
All remaining FIPS 140-2 certificates move to the CMVP Historical List — every one of them, in a single sweep. From this date, a new federal system needs a FIPS 140-3 validated module.
The Historical List is precise about scope. Modules on it should not be included in new systems — but nothing about existing deployments is automatically invalidated.
Continue under an agency risk determination. The sweep is not a revocation — systems already running a 140-2 module do not become non-compliant overnight, but the call now sits with the agency.
140-3 only. A module on the Historical List should not be included in new systems — for any new federal system after September 21, 2026, plan on a FIPS 140-3 validated module.
Still allowed. Historical modules may still be procured for existing legacy systems — replacement units, spares, and maintenance of what is already deployed remain permitted.
Still Active today — every one of them sweeps to the Historical List on Sept 22, 2026.
The bulk of the 140-2 program has already moved. The sweep finishes the job.
The pool a new system gets to draw from — and it is far smaller than the 140-2 world it replaces.
CMVP certificate counts as of July 26, 2026.
The modules below cover most real-world FIPS dependencies we see in dependency manifests. Find yours, check the certificate your build actually pins to, and read across.
| Module | Certificate(s) | Standard | Status at the sweep | What to do |
|---|---|---|---|---|
| OpenSSL FIPS Provider 3.0.8 / 3.0.9 | #4282 | 140-2 | Sunsets Sept 21, 2026 — Historical Sept 22 | Migrate to the OpenSSL FIPS Provider 3.1.2 (140-3 cert #4985 — Active, validated Mar 11, 2025, Level 1, sunset Mar 10, 2030). |
| Bouncy Castle BC-FNA (.NET) | #4416 | 140-2 only | No 140-3 validation exists for BC-FNA | .NET FIPS stacks built on BC-FNA have no like-for-like upgrade path. Anyone shipping it into a new federal system needs a plan now — before the sweep, not after. |
| Bouncy Castle BC-FJA (Java) | #4743, #4943 | 140-3 | Active | No action driven by the sunset. Confirm your dependency pins to a version covered by the 140-3 certificates. |
| Google BoringCrypto | 140-3: #4735, #5104, #5244, #5296 · 140-2: #4156, #4407, #4444 | Mixed | 140-3 certs Active; the 140-2 certs sweep to Historical | Verify which certificate your pinned BoringCrypto build actually maps to. Versions covered only by #4156 / #4407 / #4444 go Historical on Sept 22, 2026. |
| AWS-LC | #4631, #4816, #5146, #5298, #5314, #5429 | 140-3 | All Active | No action driven by the sunset. |
| OpenSSL-provider rebrands (platform FIPS modules) | RHEL 9 #4746, #4857 · Amazon Linux 2023 #5021 · AWS OpenSSL FIPS Module #5242 · Cisco FIPS Provider 3.1.2 #5160 · Oracle Linux 9 #5294 | 140-3 | Active | If your FIPS posture comes from the platform, confirm which of these certificates your OS version actually ships — and that it is the one your attestation cites. |
The one that surprises teams: Bouncy Castle BC-FNA for .NET has a 140-2 certificate (#4416) and no 140-3 validation at all. Java teams on BC-FJA are covered; .NET teams relying on BC-FNA for FIPS claims are not — no 140-3 validation exists today, so plan an alternative validated module rather than waiting.
Any system entering service after September 21, 2026 needs a FIPS 140-3 validated module. Existing deployments on 140-2 continue under an agency risk determination — which means someone at the agency now owns that determination, in writing.
If your product's FIPS story rests on a 140-2 certificate, that story stops working for new federal deployments after September 21, 2026. Procurement questionnaires will ask which certificate you ship. “FIPS validated” without a 140-3 number behind it becomes a follow-up question you don't want.
A proposed FAR rule is due December 19, 2026 that would require covered contractors to comply with NIST FIPS — including PQC algorithms — by December 31, 2030. It is a proposed rule, still subject to notice and comment, and does not bind contractors today. But cleaning up 140-2 dependencies now is the cheapest way to get ahead of it.
For National Security Systems only — this gate is not government-wide — CNSA 2.0 applies to new acquisitions starting January 1, 2027. If you sell into the NSS space, the FIPS 140-3 question and the CNSA 2.0 question land in the same procurement cycle.
Point cipherm-fips at your dependency manifests and it flags the FIPS modules your builds actually pull in — OpenSSL providers, Bouncy Castle variants, BoringCrypto, AWS-LC, platform rebrands — and which certificate each maps to, so 140-2 stragglers surface before a reviewer finds them.
The findings land in a cryptographic bill of materials — a machine-readable, diffable inventory of the modules and algorithms in use. The artifact you attach to a procurement response, an authorization package, or an agency risk determination.
A fixed-scope engagement: we inventory your FIPS module usage across code, manifests, and configs, hand-review the findings, and deliver the CBOM plus a written exposure summary keyed to the September dates. No six-month enterprise sales cycle.
CipherM identifies module usage and produces evidence. It does not perform CMVP validation, and a scan is not a certification. Validation is the CMVP's job; knowing exactly which validated modules you depend on — and which of them go Historical on September 22, 2026 — is ours.
One fixed-scope pass over your manifests and configs, one CBOM, one written answer to the question every federal buyer is about to ask: which FIPS certificate are you actually shipping?