FIPS 140-2 Explained: The engineer’s guide to compliance

“We have to become FIPS 140-2 compliant.” Your sales or product team just delivered this message from customers, auditors, or procurement. Now what?

If you’re building in a containerized or cloud-native environment, this request can feel daunting. As a cryptographic standard, FIPS 140-2 is both decades-old and unforgiving. Modern cloud infra and build pipelines aren't built for it. We finally have a more modern replacement, FIPS 140-3, but that won’t save you. Many contracts still explicitly ask for FIPS 140-2. Here’s how you can become (and stay) compliant without going nuts.

This article will break things down and explain:

• What FIPS 140-2 is and how it works

• Its security levels and technical requirements

• Why validation is onerous

• Who needs 140-3 and how to prep for the eventual transition

• How to sidestep common pitfalls and simplify compliance with Chainguard

What is FIPS 140-2?

Think of FIPS 140-2 as the rulebook for encryption technology that the U.S. (and Canada) trusts. It’s the official federal information processing standard for checking whether cryptographic modules—the hardware, software, or firmware that lock and unlock data—are secure enough for sensitive use. FIPS compliance offers levels, which can be tuned based on each application’s requirements.

The Cryptographic Module Validation Program (CMVP), run by the National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security, oversees this process. Modules and interfaces must undergo formal lab testing before earning the “FIPS validated” stamp.

Though originally designed for federal government systems, this security standard has existed since 2001 and is now in use well outside of government. It will often show up in banking audits, hospital security policies, and tech vendor checklists. FIPS 140-3 was officially approved for use in 2019, but adoption has been slow. So 140-2 remains the common standard. It will probably be a box that many customers insist on ticking for the foreseeable future.

FIPS 140-2 security levels explained

The standard offers flexibility across four security levels, ranging from basic software protections to advanced tamper resistance. Organizations match their cryptographic controls and FIPS 140-2 level to the sensitivity of the data and the risks in their environment. Understanding these levels is the first step to determining where your system fits and how to get there.

Level 1–Basic Security Requirements

Level 1 covers minimal physical and computer security and is focused on using approved cryptographic algorithms in software. Its use cases include general-purpose operating systems or commercial apps without special hardware needs.

Level 2–Tamper Evidence

Level 2 introduces moderate physical security, such as tamper-evident seals or locks, and tightens digital access controls and monitoring by requiring role-based authentication, for example. The goal is to detect and prove tampering, not necessarily to resist it. Commercial hardware appliances in branch offices or mid-security data centers will likely aim for level 2 compliance.

Level 3–Tamper Resistance & Identity-Based Authentication

Level 3 adds protection from physical and logical attacks. It also requires identity-based authentication and safeguards keys if breached. For example, this level might apply to payment processors, regulated financial systems, or healthcare data servers.

Level 4–Maximum Physical & Environmental Security

This level is extreme and rarely required in practice. Requirements for it cover environmental monitoring and automatic key zeroization on intrusion attempts. Some applications are in cryptographic devices for defense, intelligence, or classified government operations.

Technical requirements for FIPS 140-2 compliance

Hitting FIPS 140-2 standard compliance is more than “turning on strong encryption.” The standard lays out strict rules for how cryptographic modules are built, used, and maintained. In cloud-native environments, these requirements are especially tricky. In practice, teams often get stuck. Modules are typically locked to certain kernel versions, FIPS mode can behave differently across environments, and dependency drift can quietly break compliance — and meeting the standard ultimately comes down to three core requirements: algorithms, key management, and self-tests.

Approved cryptographic algorithms and functions: Only NIST-approved algorithms—such as AES, DSA, or ECDH—are allowed, and only in approved modes. Any deviation means non-compliance. One way to reduce drift is to use pre-hardened images. Chainguard's containers ship with validated crypto modules already configured for approved algorithms and maintained for compliance.

Key management and access control: **Keys must be generated within a validated module, stored only in protected form, and securely destroyed when no longer needed. Access control must match your target level: role-based for Level 2, identity-based for Level 3+. Kernel-independent modules and signed software bill of materials (SBOM) give verifiable proof of approved cryptographic components in every environment.

Self-tests and module integrity checks: Modules must run startup and conditional self-tests to confirm correct operation, halting if a failure occurs. Reproducible builds, image hardening, and kernel-independent images keep integrity checks valid across environments, avoiding costly revalidation after updates.

Addressing these requirements early, using FIPS-approved tooling from the ground up, turns compliance from a multi-month project into a drop-in upgrade.

The validation process for FIPS 140-2

FIPS 140-2 validation runs through the CMVP. The process follows a set sequence: submit your module to an accredited lab, complete testing (and documentation), and—if successful—receive a FIPS 140-2 certificate and a public listing in NIST’s database.

It sounds straightforward, but in practice, it’s often slow and resource-intensive. Common blockers include:

• Limited lab capacity

  : Only a few accredited labs can perform FIPS testing, and backlogs can stretch for months.

• Heavy documentation

  : Labs require detailed descriptions of algorithms, cryptographic key management, self-tests, physical protections, and usage scenarios.

• Revalidation on minor changes

  : Even a small code change, dependency update, or configuration tweak can reset the process.

This combination of limited validation resources and strict change controls can stall releases and make ongoing maintenance painful.

Pre-validated cryptographic components dramatically reduce your scope. For example, Chainguard’s FIPS-validated container images already include approved algorithms, correct configurations, and required documentation artifacts. Relying on them means you’ll only have to validate your integration points, cutting effort and time to market.

By reducing the number of moving parts in your validation submission, you’ll likely avoid months of delay, keep development velocity high, and still meet compliance requirements.

How to achieve and maintain FIPS compliance

FIPS 140-2 validation is a continuous process, and passing your initial audit is just the first step. Compliance can quietly slip away—a problem known as compliance drift—when patches, OS upgrades, or dependency changes alter your cryptographic modules or configurations. Even small changes can invisibly break validation.

Updates are the most common culprits: a library patch that swaps in a non-approved algorithm, a kernel upgrade that invalidates FIPS mode, or a container rebuild that pulls in unvalidated components. Without active monitoring and documentation, these changes can go unnoticed until an audit—or a failed procurement review—exposes the gap.

That’s why ongoing documentation is critical. Auditors need verifiable proof of which cryptographic modules you’re using, their exact versions, and the configurations in place. Generating this evidence manually is time-consuming and prone to error.

Achieving and maintaining FIPS compliance depends on reproducible processes, automatic SBOMs and attestations, and rapid vulnerability responses. You’ll need a strategy for maintaining compliance as you update your OS versions, integrate validated modules, and guarantee that you continue to restrict your systems to approved algorithms.

By automating documentation and maintaining FIPS-validated modules across updates, Chainguard makes staying compliant as straightforward as getting there in the first place.

Who needs to be FIPS compliant?

FIPS 140-2 isn’t meant to be just a government checkbox—though for some, it’s precisely that.

Federal agencies and contractors must use FIPS-validated cryptography under mandates like FISMA, FedRAMP, and DoD IL4/IL5. Compliance is an ongoing cost of doing business if you’re handling sensitive federal data.

Finance, healthcare, and critical infrastructure providers also voluntarily adopt FIPS widely. These industries see FIPS as a high standard they can adopt to pass audits, manage risk, and prove strong encryption practices to regulators and customers.

Software vendors and open source maintainers that support regulated industries often need to ship FIPS-compliant builds, even if they aren’t regulated themselves. Procurement teams increasingly include a simple line item: “Must support FIPS mode.”

Meeting these demands can burn engineering cycles on compliance engineering. Small changes can force teams to rebuild and revalidate entire cryptographic stacks. Chainguard’s pre-validated, kernel-independent FIPS images offer a different approach to building software, eliminating much of the hard and time-consuming work.

Transitioning from FIPS 140-2 to FIPS 140-3

FIPS 140-3 is the successor to 140-2, aligning more closely with international standards and introducing stricter requirements. The goals remain the same—validating cryptographic modules—but the bar is raised to match 20 years’ worth of industry progress:

• Testing rigor: More formalized, structured testing procedures

• Physical security: Expanded protections against side-channel and non-invasive attacks

• Standardized evidence: Mandated formats for documentation and validation artifacts

The transition is already underway. NIST will stop accepting FIPS 140-2 validations after 2026, meaning teams that haven’t planned ahead may find themselves stuck revalidating under tougher rules on short notice.

Why prepare early? Compliance cycles are slow. Between lab backlogs, documentation requirements, and revalidation risks, waiting until the last minute can derail release schedules. Some design and technology choices can make planning very straightforward—for example, Chainguard provides 140-3 compliant containers and modules, which can quickly replace the 140-2 compliant ones.

FIPS 140-2 common challenges (and how to overcome them)

The hardest part of FIPS 140-2 isn’t understanding the complicated rules. It’s keeping up with and maintaining them in modern, cloud-native environments.

Kernel dependencies and environment mismatch

Traditional FIPS modules are attached to specific kernel versions, and upgrades and portability are painful. Teams can lose weeks to compatibility issues across dev, staging, and prod environments. Chainguards’ novel kernel-independent FIPS modules are decoupled from host OS version dependencies. They provide validated, consistent, cross-environment cryptography.

Lack of visibility and verification

Auditors often expose gaps that organizations aren’t aware of. Without the right monitoring, documentation, and alerting, you might think you’re “running in FIPS mode” but not be able to prove it or notice if you slip. Signed SBOMs with verifiable provenance add both visibility and a quick way to verify compliance. Ask Sage, for example, satisfied auditors in record time by using Chainguard artifacts in their Authority to Operate process.

Ongoing maintenance and compliance drift

Every patch, library update, or container rebuild risks silently invalidating FIPS compliance. It’s difficult to stay secure and validated simultaneously.

Reproducible builds and continuous updates resolve this tension. Chainguard’s images bring those guarantees by default, enabling even projects not designed for FIPS, like Apache Spark, to reach validation.

Simplify FIPS compliance with Chainguard

As we’ve seen, FIPS compliance is never “done.” It’s complex, constantly changing, and costly to maintain. Chainguard makes it simple by baking FIPS into the foundation. We’ll help keep your release cycles snappy, avoid frustrating developers, and release the pressure from constant monitoring for small changes that can trigger expensive revalidations.

We remove that friction by baking compliance into the software supply chain itself:

• Pre-hardened FIPS images (140-2 & 140-3): Validated cryptography built in from the start

• Kernel-independent crypto modules: Free from OS version lock-in, so validated modules work across environments

• Reproducible builds + signed SBOMs: Verifiable provenance and audit-ready documentation, automatically

• Continuous updates: Zero-CVE images that keep you compliant without breaking validation

FIPS may keep evolving, but with Chainguard, you can start compliant, remain compliant, and avoid the costly surprises frequently associated with a DIY approach. Whatever your motivation—whether you’re following a strict federal mandate, looking to simplify audits in a regulated industry, or meeting customer demands to implement a “FIPS mode”—we’ve got you covered.

Let's talk. We'll help you turn FIPS compliance from a major headache to just another part of the process.