FIPS 140-2 Sunsets in September 2026. Are You Ready for FIPS 140-3?

An educational and technical deep dive into the federal cryptography standard, the September 2026 transition deadline, and what it means for your API infrastructure.

In September 2026, a quiet deadline arrives that most engineering teams have never heard of, and that some of them will discover the hard way.

Beginning Sept. 22, 2026, every remaining FIPS 140-2 certificate moves to the CMVP Historical List. Cryptographic modules that counted as current on Sept. 21 will no longer count for new federal procurements a day later. Teams selling into government, defense, healthcare, and regulated finance are about to find out whether their stack was built on current cryptography or on borrowed time.

If FIPS has always felt like an acronym that belongs to someone else's compliance team, this post is for you. Here is what the standard actually is, why it carries the force of law, what changes with 140-3, and how to think about it at the layer where most encryption actually happens in modern architectures: the gateway.

What FIPS 140 Actually Is

The Federal Information Processing Standard 140 is a U.S. government security standard, published by NIST, that defines the minimum requirements for cryptographic modules. A cryptographic module is the engine inside hardware, software, or firmware that performs encryption, hashing, key generation, digital signatures, and random number generation.

The core idea is simple: the U.S. government does not take a vendor's word that its cryptography is sound. Every module must be independently tested by an accredited laboratory and validated by the Cryptographic Module Validation Program (CMVP), a joint effort between NIST and the Canadian Centre for Cyber Security. A validated module receives a public certificate number that anyone can look up.

This creates a distinction that trips up many teams, because three claims that sound interchangeable mean three very different things:

1. A FIPS-validated cryptographic module means a module binary holds a NIST CMVP certificate for a defined operating environment. Validation stops at the module. The application linking it inherits nothing automatically.
2. A FIPS-compliant application or image means the application is built so that every cryptographic operation is routed through a validated module, with FIPS mode enforced. This is a claim about the build and the source code, and it is where the real engineering work lives.
3. A FIPS-enabled runtime means a flag was set at startup. That is a behavioral switch, not a guarantee that the binary contains a validated module or that cryptography is actually routed through one.

Here is the sentence that resolves most of the confusion in the market: NIST never validates an application or a container image. Validation applies to the cryptographic module only. Compliance is what the application layer adds on top.

When an assessor asks for evidence, they are asking for a certificate number on the CMVP list, mapped to the module your software actually executes, and increasingly for proof that the application around it was engineered to use that module correctly. Anything less is a finding.

Why It Is a Hard Requirement, Not a Guideline

FIPS validation is not a best practice you can trade off against roadmap velocity. It is a gate enforced by multiple overlapping federal mandates:

FISMA (2002, Modernized in 2014)

The Federal Information Security Management Act requires federal agencies to protect sensitive information using FIPS-validated cryptography. This is federal law.

NIST SP 800-171, Control 3.13.11

Defense contractors handling Controlled Unclassified Information (CUI) must "employ FIPS-validated cryptography," a requirement that flows down through DFARS clause 252.204-7012 to the entire defense industrial base.

FedRAMP, Control SC-13

Cloud services seeking authorization for federal use must implement FIPS-validated or NSA-approved cryptography. No validated crypto, no authorization.

CMMC

The Department of Defense's Cybersecurity Maturity Model Certification makes FIPS-validated cryptography an assessed requirement at Level 2 and above (enforcement starts in November 2026, about seven weeks after the sunset). It is consistently reported as one of the most commonly failed controls in early assessments.

The pattern is consistent: if your software encrypts, hashes, authenticates, or manages keys anywhere near federal data, the cryptography must be validated. And the requirement does not stop at the government's front door. Regulated industries from healthcare to financial services increasingly reference FIPS 140 as their bar for cryptographic assurance, because it is the only widely recognized program where an independent lab has actually verified the implementation.

From 140-2 to 140-3: What Actually Changes

FIPS 140-2 served for over two decades. FIPS 140-3 is its successor, and the transition has been underway for years:

• September 2019: FIPS 140-3 became effective, aligning the U.S. standard with the international ISO/IEC 19790 framework.
• September 2020: CMVP started accepting FIPS 140-3 submissions, with the first certificates landing in 2023.
• April 2022: CMVP stopped accepting new FIPS 140-2 submissions entirely.
• September 22, 2026: All remaining FIPS 140-2 certificates move to the Historical List.

The Historical List is the part everyone should read twice. A module on the Historical List can still be used in existing systems, and agencies set their own migration timelines. But for new procurements and new authorizations, agencies are directed toward current validations. In practice, that means a 140-2 certificate stops opening doors this September. RFPs, FedRAMP packages, and CMMC assessments will increasingly ask the same question: is your cryptography validated under 140-3?

Technically, 140-3 is an evolution rather than a revolution. It aligns with ISO/IEC 19790 and ISO/IEC 24759, tightens requirements around self-tests and integrity checks, formalizes non-invasive attack mitigation, and modernizes the algorithm lifecycle. For software vendors, the practical consequence is bigger than any single technical delta: every module must go back through the validation pipeline, and validation is slow, expensive, and unforgiving. That is precisely why so few vendors do it, and why the ones that do stand out.

The Four Security Levels

FIPS 140-3 defines four levels of increasing rigor:

Level 1 requires at least one approved algorithm and production-grade components. This is the typical target for software-only modules, including the cryptography inside gateways, proxies, and application runtimes.

Level 2 adds tamper-evidence (seals and coatings) and role-based authentication.

Level 3 requires tamper resistance, with hardware that zeroizes keys if breached, and identity-based authentication. This is the domain of HSMs.

Level 4 adds environmental failure protection against voltage and temperature attacks, and is rare outside classified environments.

For software infrastructure, Level 1 validation of the underlying cryptographic module is the requirement that matters. The point is not the level number. The point is whether the module holds a current certificate at all.

Where This Bites in Modern Architectures: The Data Path

Here is the part that turns FIPS from a paperwork exercise into an architecture question.

In a cloud native platform, the component that performs the most cryptography per second is usually not the application. It is the edge: the ingress, the API gateway, the layer that terminates TLS, manages certificates, validates JWTs, and encrypts every byte in transit. If that layer is not running validated cryptography, it does not matter how compliant the rest of the stack is. The perimeter fails the audit, and the perimeter is everything behind it.

This is where teams discover the traps:

The Library Swap Trap

Historically, getting FIPS-validated crypto into cloud native software meant bolting a C-based crypto library onto the binary through foreign function interfaces. That approach breaks cross-compilation, adds memory-unsafe code to your most exposed component, and creates a second build pipeline that drifts from the mainline product.

The "Compliant-ish" Trap

Some products enable a FIPS mode that restricts algorithms without actually executing a validated module, or point to a validation certificate for a module version they no longer ship. Assessors increasingly check the certificate against the running artifact.

The Staleness Trap

Validation freezes a module version in time. A vendor that validated once and moved on leaves you choosing between the validated build and the patched build. A serious FIPS program maintains the validated path continuously, release after release.

The Repackage Trap

A growing catalogue of third-party "FIPS images" takes public open source code, substitutes a validated cryptographic module, and recompiles. That is build wiring, not compliance engineering. The application code inside is unchanged and unaudited, which is exactly where the gap lives.

Ask any vendor in your data path four questions: Which validated module does your product execute? What is the certificate number? Is that certificate current under 140-3 after September 2026? And who audited the application code around the module? The answers separate marketing from engineering very quickly.

Compliance Lives in the Application Layer, Not Just the Module

This is the point most often misunderstood, so it deserves its own section.

The CMVP certificate covers the cryptographic module. Everything wrapped around it is the manufacturer's responsibility: the application's own cryptographic calls, its default algorithm choices, its error handling on disallowed operations, and its runtime self-tests. A FIPS-validated module wrapped around an un-audited application is an empty shell.

A genuinely FIPS-compliant application must:

1. Route every cryptographic operation through the validated module. No fallback to non-approved primitives, and no statically linked third-party crypto quietly bypassing the FIPS provider.
2. Avoid disallowed primitives entirely. SHA-1 for signing, RSA below 2048 bits, DES, MD5, and several KDF variants are out, and strict enforcement modes reject them at runtime.
3. Survive its own startup. Library initializers must not call disallowed primitives. Under a strict FIPS runtime, a single non-approved call during initialization crashes the process before it serves its first request.
4. Self-test and propagate failures. The validated module runs its CMVP-required integrity self-test on load, and the application must surface failures rather than swallow them.
5. Stay inside the tested operating environment. Running a validated module on an unsupported kernel or CPU profile invalidates the claim.
6. Publish a feature coverage matrix. Some features may be unavailable or partial under FIPS. Buyers deserve to know which, in writing, before procurement.

None of this can be added from the outside. A concrete example from Traefik's own FIPS audit makes the point: Traefik's Redis-backed rate limiter calls a cryptographic primitive at startup that is not FIPS-approved. Under a strict FIPS runtime, that single call would crash the application before it served its first request. A third party rebuilding the same public source against a validated module compiles the issue right back in, because a rebuild changes the module, not the source. Finding and fixing calls like that is source-level work that only the maintainer team has the visibility, and the mandate, to do.

The result is that the exact same source commit can ship as three very different FIPS postures: a third-party repackage (validated module, un-audited application), a runtime flag (FIPS mode switched on, with no validated module selected at build), or application-level FIPS (a validated module plus a deep audit of the codebase, with feature paths patched where required). Only the third one holds up when an assessor starts asking questions. The compliance boundary is not a label on the container. It lives in the source code.

How Traefik Approaches FIPS 140-3

Traefik Labs made a bet years ago that turns out to matter enormously here: the entire runtime is built in Go, a memory-safe language, with no dependency on C-based cryptographic libraries.

That bet paid off when the Go Cryptographic Module, the native cryptography built into the Go standard library, earned a full FIPS 140-3 validation from CMVP (certificate #5247). The module was independently audited, covers the full set of approved algorithms, and includes post-quantum key exchange (ML-KEM, standardized in FIPS 203). Because it is native Go, there are no foreign function calls, no cross-compilation compromises, and no memory-unsafe crypto code sitting at the most attacked layer of the stack.

Traefik Hub API Gateway ships dedicated FIPS images built on this validated module. What that means in practice:

Same Gateway, Validated Cryptography

The FIPS build is the same Traefik Hub, with TLS termination, certificate management, and all data-in-transit encryption executing through the FIPS 140-3 validated Go Cryptographic Module. No sidecar crypto appliances, no second architecture for regulated environments.

FIPS Enforced at the Application-Layer, Not Swapped in at the Library-Layer

The Traefik Labs maintainer team performed a deep audit of the codebase, identified calls to non-approved primitives, and patched feature paths where required. This is the compliance work that a repackaged image cannot deliver, because it is done in the source, by the people who wrote it.

Maintained by the Source, Fully Documented

FIPS fixes land on the same release lifecycle as the rest of the product, with no third-party rebuild lag. Dedicated FIPS documentation walks through deploying the FIPS build in a compliant configuration, and a public feature coverage matrix states what is fully supported, partially supported, or unavailable under FIPS. No surprises after procurement.

Memory Safety and Validated Crypto in One Artifact

Federal security guidance has spent the last several years pushing agencies toward memory-safe software. A memory-safe gateway running validated cryptography addresses both mandates in a single, static binary, which is exactly the design behind Traefik's recently introduced hardened distribution.

Aligned with 140-3, Not Racing It

Because the validated module is 140-3 from day one, the September 2026 transition is not a migration event for Traefik Hub FIPS deployments. It is the standard we are already built on.

For platform teams in federal agencies, the defense industrial base, or FedRAMP-bound SaaS providers, this collapses one of the hardest line items in the compliance matrix into a deployment choice: run the FIPS build of the gateway you already know, in Kubernetes, on Linux, or in air-gapped and on-premises environments where sovereignty requirements are strictest.

A Practical Readiness Checklist

If the September 2026 transition affects you, six questions will get you most of the way to an honest self-assessment:

1. Inventory the data path. List every component that terminates TLS or handles keys: load balancers, ingresses, API gateways, service meshes, sidecars.
2. Demand certificate numbers. For each component, identify the cryptographic module it executes and its CMVP certificate. "FIPS mode available" is not an answer.
3. Check the standard, not just the status. A certificate that is active today under 140-2 moves to the Historical List on September 22, 2026. New procurements will ask for 140-3.
4. Ask who audited the application. A validated module proves nothing about the code around it. Ask whether the application source was audited for non-approved primitive calls, who performed that audit, and whether a feature coverage matrix is published.
5. Look at the maintenance story. Ask how the vendor keeps the validated build current with security patches, and whether the FIPS path is a supported product or a one-time artifact.
6. Plan for what comes after. Post-quantum requirements are already appearing in federal guidance. A module validated under 140-3 with ML-KEM support means your transition plan and your PQC plan can be the same plan.

The Bottom Line

FIPS 140-3 is not a new bureaucracy. It is the U.S. government's way of insisting that cryptography be proven, not promised, and September 22, 2026 is the date that insistence becomes universal. For most organizations, the most exposed surface is the infrastructure layer that encrypts everything: the gateway.

Remember where the boundary sits. NIST validates the module. Compliance is built in the application. Do not let a marketing label decide your FIPS posture, because a validated module wrapped around an un-audited application is an empty shell.

The teams that treat this as an architecture decision, and choose infrastructure where validated, memory-safe cryptography is enforced at the application layer by the people who maintain the code, will find that the hardest control in the assessment becomes one of the easiest.

To learn more about running Traefik Hub API Gateway with FIPS 140-3 validated cryptography, explore the documentation or talk to our team.

Frequently Asked Questions

What is FIPS 140-3? 

FIPS 140-3 is the current U.S. government standard, published by NIST, for validating cryptographic modules. It replaced FIPS 140-2 and aligns with the international ISO/IEC 19790 framework, tightening requirements around self-tests, integrity checks, and non-invasive attack mitigation.

What is the difference between FIPS 140-2 and FIPS 140-3?

FIPS 140-3 is an evolution, not a rewrite. It aligns with ISO/IEC 19790 and 24759, formalizes non-invasive attack mitigation, and modernizes the algorithm lifecycle. The bigger practical difference: every module validated under 140-2 has to go through the pipeline again under 140-3, since certificates don't carry over.

When does FIPS 140-2 sunset? 

All remaining FIPS 140-2 certificates move to the CMVP Historical List on September 22, 2026. Modules on the Historical List can still run in existing systems, but new procurements and authorizations are directed toward current 140-3 validations.

What does it mean for a product to be FIPS compliant? 

FIPS-compliant means the application is built so every cryptographic operation routes through a validated module, with FIPS mode enforced in the build and source code. It's different from a module being FIPS-validated (NIST tested the module itself) or a runtime being FIPS-enabled (a flag was switched on with no guarantee the binary uses a validated module at all).

Is FIPS-validated cryptography the same as a FIPS-compliant application? 

No. NIST validates only the cryptographic module, never the surrounding application or container image. A validated module wrapped around an application that was never audited for disallowed calls is still not compliant.

What is FIPS-validated cryptography? 

It's cryptography that has been independently tested by an accredited lab and certified by the Cryptographic Module Validation Program (CMVP), a joint NIST and Canadian Centre for Cyber Security effort. Each validated module gets a public certificate number.

What are the requirements for FIPS 140-3? 

A compliant application has to route all crypto operations through the validated module, reject disallowed primitives (SHA-1 for signing, RSA below 2048 bits, DES, MD5), survive startup without calling non-approved primitives, run self-tests, and stay within the module's tested operating environment.

Does FedRAMP require FIPS 140-3? 

FedRAMP control SC-13 requires cloud services to implement FIPS-validated or NSA-approved cryptography for federal authorization. As 140-2 certificates move to the Historical List in September 2026, FedRAMP packages will increasingly require 140-3 validation specifically.

What are the FIPS 140-3 security levels? 

FIPS 140-3 defines four levels. Level 1 covers software-only modules like gateways and proxies. Level 2 adds tamper-evidence and role-based authentication. Level 3 requires tamper-resistant hardware (the HSM domain). Level 4 adds environmental failure protection and is reserved for classified environments.

Is Traefik Hub FIPS 140-3 compliant? 

Traefik Hub API Gateway ships dedicated FIPS images built on the Go Cryptographic Module (CMVP certificate #5247), a 140-3 validated module with no C-based crypto dependencies. Traefik Labs additionally audited the application codebase and patched non-approved primitive calls at the source level, rather than bolting a validated module onto an unaudited build.