FIPS 140-3: Everything you need to know

FIPS 140-2 has felt outdated for years now. It’s a 2001 standard trying to govern software in the 2020s. The change is now official: as of 2022, all new validations must use FIPS 140-3, and by 2026, all 140-2 validations will be sunset.

That’s a significant shift. And it’s not just government teams who care. Today, banks, hospitals, and SaaS consider cryptographic assurances table stakes. FIPS compliance is standard across procurement checklists and is a shared concern across engineering, security, and business.

FIPS standards are complex, slow-moving, and notoriously difficult to reconcile with modern software development. Validation can take months, and compliance drift is typical.

The opportunity: using infrastructure aimed at compliance, such as pre-validated, hardened container images, can dramatically accelerate timelines and reduce complexity. Instead of treating FIPS as a blocker, you can turn it around and use it to build customer trust and win contracts.

This post explains FIPS 140-3, how it differs from 140-2, who needs to comply, and how to navigate its requirements. We’ll also discuss simplifying and accelerating the process with special-purpose tools (such as those provided by Chainguard). You can make compliance fit into, not fight against, your workflow.

What is FIPS 140-3?

FIPS 140-3 is the current U.S. and Canadian standard for validating cryptographic modules—the hardware, software, or firmware that provides encryption and key management. Introduced in 2019 by NIST, it replaced the older FIPS 140-2 and is enforced through the Cryptographic Module Validation Program (CMVP), run jointly by NIST and the Canadian Centre for Cyber Security.

Think of FIPS 140-3 as the safety inspection for your cryptography. Just as a restaurant must pass a safety inspection before serving food, cryptographic software and hardware can’t be used in sensitive government systems without being FIPS-validated.

In practice, FIPS 140-3 provides a common yardstick for measuring trust in cryptographic software. It defines a range of 4 security levels, specifies which algorithms are allowed for each, and dictates how validation works. It is the benchmark against which government and many private-sector systems are measured. Because the standard is so strict, many teams will choose to build on top of products and services that are already compliant. We'll show you how some use Chainguard’s offerings—for example, by building with hardened, FIPS-ready containers.

Who needs to comply with FIPS 140-3?

If you work with U.S. government agencies or a contractor handling sensitive data, you must use validated cryptographic modules, which soon will mean FIPS 140-3. Various compliance frameworks, including FISMA, FedRAMP, and DoD Impact Levels, will dictate which level of FIPS you’ll have to comply with.

Some regulated industries have also come to rely on FIPS validation as an assurance signal. Banks use it to prove strong cryptography in audits. Healthcare providers lean on it for HIPAA compliance. Critical infrastructure operators require it for risk management. FIPS validation has become the default way to prove encryption practices, and that’s unlikely to change anytime soon.

Software vendors and open source projects aren’t exempt. Procurement checklists often include “must support FIPS mode” as a gating requirement. You’ll likely be excluded from sales cycles if your modules are not validated.

FIPS 140-3 vs FIPS 140-2: What’s changed?

FIPS 140-2 was published in 2001—practically a lifetime ago in software years. It’s been the backbone of cryptographic assurance for over two decades and was way overdue for an update. In 2019, NIST finally delivered a refresh with FIPS 140-3.

So what’s different? A few big things stand out:

• Global alignment: adoption of ISO/IEC 19790 and 24759 means a single validation works internationally

• Stricter documentation/testing: more detail required for entropy sources, self-tests, and role definitions

• Clearer module boundaries: tighter scoping, especially useful for containerized systems

• Modular algorithm rules: NIST’s special publications (SP) 800-140 now govern algorithms and self-tests separately

The timeline is already in motion. In April 2022, NIST stopped accepting new 140-2 submissions. Existing validations will remain valid until 2026, but after that, 140-2 should be gone for good, at least for all government contractors. Other industries might lag for some time.

These deadlines won’t bite forward-looking teams, though. Domino Data Lab, for example, started adopting Chainguard’s 140-3-ready images early. This cut down on revalidation risk and eased their path into regulated markets. Their story shows the bigger lesson—it’s entirely possible to prepare now and avoid the pains of a rushed transition.

Why FIPS 140-3 matters for modern software development

Cryptography is now the backbone of SaaS, microservices, and critical infrastructure. That’s why FIPS 140-3 is such a milestone: it gives customers, auditors, and procurement teams a quick way to trust what’s inside, like a nutrition label for software security.

FIPS 140-3 matters because it:

• Provides higher assurance with tougher tests, entropy requirements, and clearer scoping.

• Applies beyond government, and is increasingly demanded in finance, healthcare, and infrastructure. FIPS 140-3 improves on 140-2 by supporting broader adoption.

• Builds customer trust; a “FIPS validated” checkmark is shorthand for “we take security seriously.”

• Serves as a procurement requirement in frameworks like FedRAMP, HIPAA, and PCI DSS.

This shift is already visible for security vendors. GitGuardian adopted Chainguard’s hardened FIPS images to eliminate CVEs and reassure enterprise buyers. For them, compliance stopped being a checkbox and became a way to prove their platform’s security posture.

FIPS 140-3 security levels explained

FIPS 140-3 defines four assurance levels so teams can match controls to their risk profile:

• Level 1—Basic: NIST-approved algorithms, no physical protections. Common in SaaS and containerized services.

• Level 2—Tamper Evidence & Role-Based Access: Adds tamper-evident seals/logs and role-based authentication. Typical in branch office appliances, mid-tier SaaS, or healthcare products.

• Level 3—Tamper Resistance & Identity Authentication: Stronger physical resistance, stricter key management, and identity-based access. Used in strictly regulated finance and healthcare systems.

• Level 4—Maximum Security: Environmental monitoring, auto key zeroization, and maximum tamper resistance. Rare outside defense or intelligence.

In the real world, companies span multiple levels; Shift5, for example, spans Levels 2 (with telemetry systems) and 3 (support for defense platforms). By standardizing on Chainguard’s kernel-independent modules, they avoided maintaining multiple separate crypto stacks for the different levels.

Cryptographic requirements and approved algorithms

FIPS 140-3 also defines exactly how crypto modules must operate. This is a world where copy-pasting snippets of code from the likes of Stack Overflow or auto-generating them with AI just won’t work:

• NIST-Approved Algorithms Only: AES, SHA-2, RSA, ECDSA. Anything else—custom or experimental—won’t pass.

• Key & Entropy Management: Keys must be generated, protected, and destroyed inside validated modules. Entropy quality is heavily scrutinized.

• Self-Tests & Integrity Checks: Modules must prove they work correctly during startup and operation.

That’s why reproducibility matters so much. You’ll want to use pre-validated components and images whenever possible, since they blend compliance into your process sustainably. Domino Data Lab, for example, lessened its compliance burden by adopting Chainguard’s pre-validated images. Instead of manually documenting every configuration, they had cryptographic assurances “baked in”.

The FIPS 140-3 validation process and governance

Validation happens through the CMVP. Following the guidelines isn’t enough; unlike some other frameworks, you can’t self-attest to compliance. You must be validated through an accredited lab. Some good practices to follow as you do this:

• Scope Your Module: Define what counts as a module (library, device, container). This is trickiest for cloud-native teams.

• Submit to an Accredited Lab: Labs require detailed docs: entropy, algorithms, self-tests. Paperwork is often the most challenging part.

• Validation and Listing: NIST issues a certificate and adds you to the public CMVP list if you pass.

Sounds easy, right? In practice, this process can take months, and even the smallest changes can trigger a revalidation. Especially with the 2026 deadline looming, some labs might get severely backed up. Ask Sage tackled this head-on by building on Chainguard’s pre-validated modules, simplifying and speeding up validation on the way to DoD IL5 accreditation. Validation isn’t fast or free, but it’s much smoother if you start with the right building blocks.

Common FIPS 140-3 challenges and best practices

The one thing almost every team discovers when tackling FIPS 140-3 is that compliance isn’t a one-and-done milestone. Once you pass validation, keeping your modules compliant can be just as hard.

Here are three of the most common challenges:

• Defining Module Boundaries: Microservices blur lines. It’s hard to tell what to validate—the service? Container? Or just some of the libraries? Best practice: keep modules minimal and purpose-built.

• Documentation Overload: Labs require exhaustive detail and documentation for entropy sources, tests, role definitions, and more. Reproducible builds create artifacts that double as documentation and can cut much of the repetitive documentation work.

• Compliance Drift: Updates, even trivial ones, can silently break FIPS mode and move you out of compliance. Continuous validation and SBOMs prevent nasty surprises.

This sounds hard, but is eminently doable in the real world. GitGuardian, for example, avoided drift by using Chainguard’s reproducible builds. Instead of scrambling at audit time, they produced signed SBOMs on demand—keeping engineers focused on features, not firefighting.

How Chainguard supports FIPS 140-3 compliance

By now, it should be clear that FIPS 140-3 is complex, strict, and constantly evolving. Passing validation once is a sprint, but staying compliant (while shipping quickly) is a marathon. That’s where Chainguard comes in.

Think of us as the autopilot for compliance—you set the course, and we’ll keep you aligned when conditions change, with:

• FIPS 140-3 Compliant Images: Chainguard provides hundreds of container images with validated cryptographic modules already baked in. No patching, no guesswork.

• Kernel-Independent Crypto Support: Traditional FIPS modules are tied to specific kernel versions, creating headaches during upgrades. Chainguard’s kernel-independent approach lets validated crypto run consistently across environments.

• Built-in SBOMs and Provenance: Every Chainguard image comes with signed attestations for each component, validating what it is and where it came from. It is easy to share these necessary artifacts with auditors without last-minute scrambles.

• Secure-by-Default Configs and Continuous Updates: Chainguard continuously rebuilds and ships updates, keeping modules compliant over time.

The message is simple: compliance is painful when bolted on. With Chainguard, it’s baked in from the start. Talk to our experts; we’ll help you meet today’s FIPS 140-2/140-3 needs and make your compliance process sustainable.