FIPS 140-2 sunsets in:
28
days
:
04
hours
:
49
minutes
:
07
seconds
Application-Level FIPS 140-3
Validated Module in a Compliant Application Out-of-the-Box
The market is full of "FIPS images" that swap in a validated cryptographic module and stop there. Traefik Hub enforces FIPS 140-3 in the application layer itself: a validated module, a deep audit of the codebase by the maintainer team, and feature paths patched where required.
Validated Module:CMVP #5247
Airgap Ready:On-prem & sovereign
Application-Level:Audited in source
Memory-Safe:One static Go binary
140-3 Native:No migration event
Documented:FIPS deployment guide
TRAEFIK LABS IS TRUSTED BY LEADING ENTERPRISES WORLDWIDE
The Directive
The Clock Runs Out on September 22, 2026
Every remaining FIPS 140-2 certificate moves to the NIST CMVP Historical List by September 22. From that point, new federal procurements will ask for FIPS 140-3, and increasingly they will ask application-level questions, not just module questions.
SEP 2020
CMVP begins accepting FIPS 140-3 submissions. The first certificates are not issued until 2023.
APR 2022
CMVP stops accepting FIPS 140-2 submissions for new validation certificates.
SEP 2026
All remaining FIPS 140-2 certificates move to the Historical List.
NOV 2026
CMMC Level 2 enforcement begins, roughly seven weeks after the sunset.
FISMA
Federal law. Validated cryptography required to protect sensitive information.
NIST 800-171 · 3.13.11
Validated crypto for CUI, flowed to the defense industrial base via DFARS 252.204-7012.
FedRAMP · SC-13
No authorization without FIPS-validated or NSA-approved cryptography.
CMMC · Level 2+
One of the most commonly failed controls in early assessments.
#5247
CMVP certificate of the FIPS 140-3 module Traefik Hub executes
0
Applications or container images NIST has ever validated
4
Overlapping federal mandates that make validated crypto a hard gate
The Challenges
FIPS Validated ≠FIPS Compliant
A FIPS-validated cryptographic module wrapped around an unaudited application is an empty shell. Four traps separate the marketing label from a gateway that survives an assessment.
The Repackage Trap
Third-party "FIPS images" substitute a validated module and recompile public source. Build wiring only. The application code inside is unchanged and unaudited.
The Runtime Flag Trap
A FIPS-mode flag set at startup is a behavioral switch. It guarantees neither a validated module in the binary nor that cryptography routes through one.
The Startup Trap
Under a strict FIPS runtime, a single non-approved primitive call during initialization crashes the process before the first request. Unaudited code fails in production, not in review.
The Silent Degradation Trap
Capabilities injected at build time by the maintainer are absent from outside rebuilds. The container looks identical. The product inside is not.
The Solution
Three FIPS Implementations. Only One Survives an Audit.
Repackaged Image
Third-Party Rebuild
Validated module bundled
No audit of the codebase
Build wiring only
Silent feature degradation
VS
Application-Level FIPS
Traefik Hub FIPS Images
FIPS 140-3 validated Go Cryptographic Module
Deep audit by the maintainer team
Feature paths patched where required
Dedicated FIPS deployment documentation
Public feature coverage matrix per release
VS
Runtime Flag Only
FIPS Mode Switched On
Flag active at runtime
No CMVP-validated module at build
No audit of the codebase
Not FIPS validated
NIST validates modules. It never validates applications. The work that turns a validated module into a compliant gateway happens in the source code, and only the maintainers can do it. That is the work we ship.
Sudeep Goswami
Chief Executive Officer, Traefik Labs
Key Benefits
Compliance You Can Put in Front of an Assessor
Compliant by Construction
Every cryptographic operation is routed through the validated module. Non-approved primitives are identified and replaced in source. Self-tests are propagated, not swallowed.
Compliant Wherever It Lands
Kubernetes, Linux, and Nomad. Airgapped, on-prem, and sovereignty-focused environments. Same gateway, same configuration, validated cryptography.
Maintained and Documented by the Source
FIPS fixes land on the product release lifecycle with no third-party rebuild lag. Dedicated FIPS documentation covers deploying the FIPS build in a compliant configuration, alongside a public feature coverage matrix per release. You're supported by the team that wrote the code.
The Comparison
Repackaged FIPS vs. Application-Level FIPS
| Repackaged FIPS Image | Traefik Hub Application-Level FIPS |
|---|---|
| Cryptographic Module | |
| Validated module bundled | Go Cryptographic Module · FIPS 140-3 · CMVP #5247 |
| Application Code | |
| Recompiled unchanged, unaudited | Deep audit by the maintainer team, non-approved calls patched |
| Strict-mode Startup | |
| Unknown until it crashes | Audited initialization paths, self-tests propagated |
| Build-time Capabilities | |
| Missing from outside rebuilds | Complete product, dashboard and features intact |
| Fixes and Patches | |
| Third-party rebuild lag | Same release lifecycle as the product |
| Deployment Guidance | |
| Nothing beyond the base image | Dedicated FIPS documentation: required configuration, validated boundary, supported environments |
| Feature Transparency | |
| No coverage matrix | Public matrix: supported, partial, unavailable under FIPS |
| Standard | |
| Frequently inherits 140-2 | 140-3 native, including ML-KEM post-quantum key exchange |
Frequently Asked Questions
A validated module holds a NIST CMVP certificate. A compliant application routes every cryptographic operation through a validated module with FIPS mode enforced. An enabled runtime is a flag set at startup, with no guarantee behind it. NIST validates modules only; compliance is what the application layer adds on top.
The Compliance Boundary Lives in the Source Code
Do not let a marketing label decide your FIPS posture. Run the gateway where FIPS 140-3 is enforced at the application layer by the people who maintain the code.