FIPS 140-2 vs 140-3: What's the difference?

For more than twenty years, FIPS 140-2 has defined how the U.S. and Canadian governments evaluate cryptography. However, that standard is now being upgraded: in 2019, the National Institute of Standards and Technology (NIST) introduced FIPS 140-3, the new federal information processing standard. 140-3 and 140-2 both serve the same function; they outline the rules for cryptographic modules—hardware, software, or firmware—that protect sensitive information. Both are enforced through the Cryptographic Module Validation Program (CMVP) run jointly by NIST and the Canadian Centre for Cyber Security.

The timeline for organizations that rely on FIPS 140-2 validation certificates is clear: new submissions to 140-2 stopped being accepted in 2022, and all existing certificates will be retired by September 2026.

This article explains the official transition, the key differences between FIPS 140-2 and FIPS 140-3, and what steps teams can take to prepare.

The official transition from FIPS 140-2 to 140-3

FIPS 140-3 doesn’t patch or extend 140-2; significant parts of the standard have been rewritten. The Cryptographic Module Validation Program (CMVP) stopped accepting new FIPS 140-2 validation submissions in 2022, and on September 21, 2026, every existing FIPS 140-2 certificate will be archived. After that day, the only validation that counts—for the U.S. government, the Canadian government, and most regulated industries—will be FIPS 140-3.

Unfortunately, validating a new module can take many months, and the process has limited capacity, so it will only take longer to complete as more folk decide to migrate to 140-3. CMVP testing means documenting cryptographic keys, showing your self-tests, proving your interfaces and roles, and surviving months of lab review. Even a minor firmware update or config tweak can trigger revalidation.

The more you can rely on others’ validation of your work, the better. To save time, organizations often rely on container images with built-in validated cryptography rather than bolting compliance onto existing systems. For example, this strategy can be implemented by baking FIPS-approved crypto modules directly into minimal, reproducible container images. That means less time waiting in lab queues, fewer surprises when patching, and a smoother path from 140-2 before the cliff arrives.

FIPS 140-2 vs FIPS 140-3: Key differences and enhancements

If you’ve ever looked at FIPS 140-2 validation, you know the drill: approved cryptographic algorithms, required self-tests, and a certificate that says your module is good to go. FIPS 140-3 keeps the same basic idea but raises the bar in ways that hit closer to how modern systems actually work.

Here’s a quick side-by-side of some of the biggest changes:

In sum, FIPS 140-3 requires more rigorous self-tests, stricter documentation of critical security parameters (CSPs), and more precise module boundaries that reflect how we deploy software today.

From self-hosted to cloud native: Why FIPS 140-3 hits closer to home

The FIPS 140-3 updates are aimed squarely at how modern systems are built and run. They more explicitly target practical cloud use cases than 140-2 did. For hybrid and cloud-native teams, these differences translate into real engineering challenges.

Rigorous full life cycle self-testing

One of the most impactful shifts is in testing requirements. FIPS 140-2 only requires modules to run self-tests at startup. FIPS 140-3 adds conditional and runtime checks, forcing cryptography to prove it works throughout its lifecycle. That’s a significant change for ephemeral workloads that may only exist for a few minutes. Teams that adopt reproducible build pipelines and rely on hardened, kernel-independent images can demonstrate consistency and avoid falling out of compliance with minor changes.

Operational and user roles rolled into interface definitions

The new standard also expands how roles and interfaces are defined. Where FIPS 140-2 was relatively loose, FIPS 140-3 tightens definitions for the crypto officer and user roles and introduces more precise boundaries around control-output interfaces. This requires careful documentation of where keys are generated, stored, and accessed across distributed systems. Minimal, purpose-built base images can simplify boundary definitions by stripping modules down to essentials, making the boundaries easier to describe and validate.

Greater alignment with international standards

FIPS 140-3 is now globally aligned and maps to ISO/IEC 19790 and 24759, so one validation can be recognized internationally. The harmonization means a single validation can often serve multiple jurisdictions, saving time and resources.

Finally, 140-3 raises the bar for higher security levels. At Level 4, multi-factor authentication and tamper-evidence become non-negotiable. Secure defaults and strong access controls reduce the chance of misconfigurations that might derail validation.

How to prepare your software for FIPS 140-3 compliance

Still relying on FIPS 140-2? You’re living on borrowed time. Every certificate has an expiration date, and September 2026 is closer than it looks. Getting through CMVP means months of documentation, self-tests, and lab reviews. Miss the window, and you’re stuck explaining why your validation is on the ‘historical’ list. Start early, and with the right tools, you can glide through instead of firefighting.

The first step is a self-audit. Inventory which modules in your stack are currently validated, and which dependencies they rely on. This includes versions of OpenSSL, kernel modules, or other cryptographic libraries that are likely to be covered by and might not comply with the new standard. List your vendors, and check—you may need to contact vendors for a roadmap for FIPS 140-3 support or plan for replacements.

Next, consider how cryptography is distributed across your architecture. FIPS 140-3 expects boundaries to be clearly defined and documented. You’ll have to isolate cryptography inside clear modules rather than let it sprawl across init containers, sidecars, and microservices. You can use minimal, purpose-built base images to make those boundaries more straightforward to define and defend.

Also, authentication and access control are explicitly required to be modern. FIPS 140-3 requires strict identity-based controls at higher security levels, including multi-factor authentication. Building these protections into sensitive workflows will save you from redesigning things later.

Finally, align your compliance efforts with your software supply chain. FIPS 140-3 emphasizes lifecycle assurance and drift prevention, and requires reproducible builds, SBOMs, and verifiable provenance. Some container platforms now generate signed SBOMs and provenance by default, which can be handed to auditors without manual work.

Preparing early smooths the transition and reduces the risk of downtime, audit failures, and revalidation headaches when users complete their transition to 140-2.

How Chainguard supports FIPS 140-2 and 140-3 compliance

Compliance today means juggling two realities for many teams: you still need FIPS 140-2 certificates for contracts and possibly for private-sector clients that require it, but you must also prepare for FIPS 140-3. Chainguard helps you handle both without piling on engineering toil.

Chainguard’s support starts with FIPS-compliant Chainguard Containers. These container images are minimal, hardened, and built with validated crypto modules out of the box. By cutting out extra OS packages, they shrink the validation scope and avoid common lab failures. Unlike most solutions, Chainguard provides kernel-independent cryptographic support. Traditional FIPS modules depend on a specific Linux kernel for entropy, complicating portability. Kernel-independent images solve this with a userspace entropy source, so validated cryptography works consistently across dev, staging, prod, and any cloud environment.

Chainguard also provides a modern validation path for 140-3. For example, their support includes upgrading cryptographic modules like OpenSSL to meet the new requirements and submitting their modules for validation with emerging standards like FIPS 186-5.

And it’s all designed for cloud-native teams. Whether your cryptographic functions run in containers, hybrid modules, or ephemeral workloads, Chainguard images are built for distributed environments from the ground up.

Where other vendors force you to adapt your systems to fit compliance, Chainguard adapts compliance to your systems, making FIPS 140-3 attainable, repeatable, and auditable by default. Contact the Chainguard team to learn more about their solution.