What is FIPS?

FIPS compliance is a basic requirement for any organization working with the U.S. government, handling sensitive information, or operating in regulated industries like healthcare and finance. As software supply chains grow more complex and government scrutiny intensifies around cybersecurity, FIPS compliance has become non-negotiable for teams building secure systems or serving federal markets.

The Federal Information Processing Standards (FIPS) define how cryptographic modules must be validated to protect sensitive data. Developed by the National Institute of Standards and Technology (NIST), they establish rigorous guidelines and testing procedures that encryption algorithms and cryptographic systems must pass before they can be trusted with government data or deployed in regulated environments.

This guide breaks down what FIPS compliance means in practice, which standards matter most, and how modern teams can achieve compliance without derailing development timelines or introducing operational risk.

What is FIPS compliance?

FIPS compliance means your systems use cryptographic modules validated through NIST's Cryptographic Module Validation Program (CMVP). It proves that your encryption meets government-grade security requirements.

Cryptographic modules are software components that handle encryption, digital signatures, and other data protection functions. For FIPS compliance, it doesn't matter where they're implemented, just that the specific implementation (whether software, hardware, or hybrid) has been tested and validated by NIST.

The CMVP guides how these cryptographic modules are tested and certified. When a module passes the validation process, it receives a certificate number a listing in NIST's validated modules database. This certification proves the software encrypts data correctly and protects sensitive information according to government security standards.

Using FIPS-validated modules isn't optional for organizations working with federal agencies or handling sensitive data. It's mandated by regulations like the Federal Information Security Management Act (FISMA) and required for FedRAMP authorization. Furthermore, many private sector organizations have adopted FIPS standards for their own data security and compliance requirements.

Key FIPS standards to know

Several FIPS standards work together to create a framework for secure cryptographic operations. Let’s explore some of these to help you choose the right approach for your environment.

FIPS 140-2 and its security levels

FIPS 140-2, though over two decades old, remains the most widely implemented standard for validating cryptographic modules. It defines four security levels that determine how thoroughly a module protects against tampering and unauthorized access:

• Level 1: Software-only implementations with basic security requirements

• Level 2: Adds tamper-evident features and role-based authentication

• Level 3: Requires tamper-resistant hardware and stronger authentication

• Level 4: Highest level with mechanisms that respond to tampering by automatically deleting encryption keys when physically attacked

Most software applications target Level 1 or Level 2 validation, while specialized government applications may require Level 3 or 4. The FIPS 140-2 standard is gradually being replaced by FIPS 140-3 and is expected to be retired as a federal requirement in September 2026. However, many non-governmental organizations may continue to follow it for years to come.

FIPS 140-3 and the transition from 140-2

FIPS 140-3 represents the next generation of crypto validation, aligning with international standards like ISO/IEC 19790. The newer standard includes additional testing requirements, updated security policies, and better support for newer crypto algorithms.

The improvements in FIPS 140-3 also include updated requirements for key management and authentication, better support for software-based implementations, and enhanced documentation and security policy requirements.

NIST is phasing out 140-2 in favor of the newer FIPS 140-3 standard. If you're building new systems today, you should target FIPS 140-3 to avoid migrating down the line, since 140-3 isn’t backwards compatible. Chainguard has early support for FIPS 140-3 and 140-2, supporting companies during this transition period.

Other Critical Standards: FIPS 197 and FIPS 201

FIPS 197 defines the Advanced Encryption Standard (AES), the encryption algorithm that forms the foundation of most FIPS-validated cryptographic modules. Understanding AES requirements is fundamental to implementing compliant systems.

FIPS 201 establishes standards for Personal Identity Verification (PIV) cards used in federal identity systems. While not a cryptographic module validation itself, FIPS 201 compliance often requires FIPS-validated crypto components for secure authentication.

Who needs to be FIPS compliant?

FIPS compliance requirements span multiple sectors, driven by regulation, contracts, and security best practices. The scope extends beyond federal agencies to include contractors, service providers, and private organizations handling sensitive information.

Federal agencies and government contractors

Any U.S. federal agency must use FIPS-validated cryptographic modules under FISMA requirements. This mandate extends to government contractors handling sensitive data, creating a ripple effect throughout the supplier ecosystem.

FedRAMP reinforces these requirements for cloud and SaaS providers serving government agencies. Achieving FedRAMP authorization requires demonstrating FIPS compliance across your entire technology stack. For organizations that want to do business with the federal government, or as a subcontractor to one that does, compliance is non-negotiable.

Financial services, healthcare, and critical infrastructure

Heavily regulated industries often adopt FIPS standards to align with NIST cybersecurity guidance and meet security audit requirements. Banks implement FIPS-compliant encryption to protect financial transactions and customer data.

Many private sector organizations voluntarily adopt FIPS standards as security best practices. Energy providers use FIPS-compliant solutions to protect smart grids and utility systems, while cloud service providers implement FIPS-compliant encryption to meet customer expectations and regulatory requirements. Even healthcare organizations often use FIPS to demonstrate compliance with HIPAA requirements.

Technology providers and open source projects

Software vendors selling products to federal or regulated customers must offer FIPS-compliant builds. This includes everything from operating systems to application frameworks to container images.

In addition, open source projects like OpenSSL maintain FIPS-compatible versions to meet downstream demand from government users. Open source communities often create separate FIPS-validated branches of their projects to serve government use cases separate from the general community. The FIPS branches get frozen and can take a long time to update, while the community branches need to keep fixing bugs and adding features for the general community.

Common challenges in implementing FIPS compliance

Unfortunately, FIPS compliance is often complex and error-prone, especially in containerized environments. Understanding common pitfalls helps teams avoid expensive mistakes and compliance misses.

Kernel dependencies and environment mismatch

Most FIPS-approved encryption software only works with specific versions of Linux and certain system setups. This creates extra work when teams deploy across different cloud providers or need to update their systems, such as testing compatibility on each platform, manually configuring specific system requirements, and carefully coordinating updates when moving between cloud providers.

The traditional approach of relying on FIPS-hardened host kernels becomes problematic in environments where you don't control the underlying infrastructure. Container platforms, serverless computing, and managed Kubernetes services often don't provide the specific kernel configurations required for traditional FIPS implementations. Chainguard's approach works independently of the underlying operating system so teams can achieve FIPS compliance in any cloud environment without infrastructure constraints.

Lack of visibility and verification

Teams often can't verify whether their systems are actually running in FIPS mode or using validated modules. The lack of visibility creates compliance risk and makes it difficult to detect configuration drift or module expiration.

Traditional approaches provide limited documentation around crypto operations and module usage. Without clear visibility, organizations can't confidently demonstrate compliance during audits or quickly catch when their systems fall out of compliance.

Ongoing maintenance and compliance drift

System updates, security patches, and dependency changes can invalidate FIPS compliance without warning. Teams need to make sure that routine maintenance doesn't inadvertently introduce non-validated crypto modules or disable FIPS mode operation. The challenge becomes especially acute in containerized environments where base image updates, dependency updates, and configuration changes happen frequently.

Chainguard prevents compliance drift through deterministic builds and continuous validation. Every image update maintains FIPS compliance while incorporating security patches and dependency updates.

What does it take to achieve FIPS compliance?

The core requirements for FIPS compliance are straightforward: use validated cryptographic modules, run them in FIPS mode, and keep the right documentation. However, the implementation path varies quite a bit depending on your infrastructure, compliance context, and technology stack.

Use a FIPS-validated cryptographic module

Start with cryptographic libraries that have completed validation under FIPS 140-2 or FIPS 140-3. Simply using software labeled as "FIPS-capable" is generally not sufficient. For actual compliance, the module must be running in its validated configuration and version exactly as tested by the lab.

This requirement can be complicated for teams that want flexibility to update dependencies and patch vulnerabilities quickly. Traditional approaches often lock you into specific versions of operating systems and crypto libraries, limiting your ability to respond to security issues. When a critical vulnerability is found, teams face a choice: patch quickly and lose FIPS compliance, or stay compliant but remain vulnerable until a new validated version is available (which can take months), putting teams in a lose-lose situation.

Chainguard addresses this dilemma by shipping container images with FIPS-validated modules already integrated and configured correctly. Automatically compliant updates eliminate the guesswork around module selection and configuration while maintaining the flexibility teams need for faster development workflows.

Configure systems to operate in FIPS mode

Running in "FIPS mode" means your system only uses approved cryptographic algorithms and rejects all non-validated crypto operations. Enforcement typically requires kernel-level configuration, environment variables, and application-specific settings.

Because FIPS solutions only work with specific Linux kernel versions, teams run into problems when they deploy containers across different cloud providers or when their hosting platform updates its underlying systems. FIPS compliance can break simply because the host environment changed, even though your application code stayed the same.

Chainguard's kernel-independent approach solves this problem by providing crypto modules that don't depend on the host's kernel crypto implementations. This makes achieving FIPS compliance in Kubernetes, cloud platforms, and air-gapped environments possible without infrastructure lock-in.

Document and maintain certification

FIPS compliance requires maintaining documentation that proves your use of validated modules, including certificate numbers, operational modes, and security policies. This documentation is especially important during audits and compliance assessments.

Module validations have expiration timelines. When modules expire or get revoked, systems using them fall out of compliance until they're updated to use current validations.

Chainguard's reproducible builds and signed Software Bill of Materials (SBOMs) provide the traceability needed for ongoing compliance documentation. Every image includes verifiable provenance that shows exactly which FIPS-validated modules are included and how they were configured.

Simplify FIPS compliance with Chainguard

Chainguard removes the operational burden of FIPS compliance by delivering secure-by-default, FIPS-ready containers and tooling. Instead of spending months configuring and validating your own FIPS implementations, you can start with hardened images that meet compliance requirements out of the box.

Key features include

• Pre-hardened, FIPS 140-2 and 140-3 validated container images

• Kernel-independent crypto modules for portable compliance across platforms

• Reproducible builds with signed SBOMs and verifiable provenance

• Regular updates and long-term support to prevent compliance drift

• Secure-by-default configurations that reduce CVEs and audit effort

• Purpose-built designs for air-gapped, highly regulated, and FedRAMP environments.

This approach lets teams focus on building applications instead of worrying about cryptographic compliance. Organizations get the FIPS validation they need without the complexity and maintenance overhead of old-school tools.

Talk to an expert to learn how Chainguard can streamline your path to FIPS compliance.