Federal Information Processing Standards (FIPS) cover several areas of information security, with FIPS 140 setting requirements for validated cryptographic modules.
FIPS 140-2 validations became historical after September 21, 2026, so new federal systems should use FIPS 140-3 while existing systems follow applicable agency guidance.
Compliance challenges include kernel dependencies, lack of visibility, and drift, as application, module, or environment changes can affect approved cryptographic operation.
Chainguard simplifies FIPS compliance with FIPS container images that include validated modules, supporting validation evidence, and maintenance of its own cryptographic module.
Federal Information Processing Standards (FIPS) compliance is required for many organizations, particularly those who work with the U.S. government or serve customers that require validated cryptography. Developed by the National Institute of Standards and Technology (NIST), FIPS includes several different standards with varying security requirements, depending on the work you’re doing.
For applications subject to FIPS 140 requirements, teams must verify that their software actually uses validated cryptography and recheck it when software changes.
What is FIPS compliance?
FIPS compliance means that a system, product, or component meets the Federal Information Processing Standards that apply to it. The requirements — and how compliance is demonstrated— depend on the particular standard and the system’s intended use.
Several FIPS standards exist and cover cryptographic modules, encryption algorithms, and identity verification. FIPS 140 is the core of most compliance work, setting the requirements for validated cryptographic modules. Others cover encryption algorithms (FIPS 197) and identity systems (FIPS 201).
FIPS 140: Cryptographic modules
FIPS 140 defines security requirements for cryptographic modules that handle encryption, digital signatures, and other data protection functions. To meet these requirements, you must use modules validated through NIST’s Cryptographic Module Validation Program (CMVP) and follow the module’s security policy.
The specific module version and its operating environment also matter, since the security policy describes the module’s approved services and conditions for operation.
Independent, accredited laboratories test cryptographic modules, and the CMVP reviews the results before issuing a validation. Validated modules receive a certificate number and a listing in NIST’s validated modules database.
A product that includes a validated module isn’t automatically a validated product. The application must use the module correctly for the cryptographic functions subject to the requirement.
Two versions of FIPS 140 are relevant today:
FIPS 140-3, the current version, aligns with international standards (including ISO/IEC 19790). It defines four increasing security levels, with requirements covering areas including authentication, physical security, self-tests, and the management of cryptographic keys and other sensitive values. These levels describe the module’s security requirements, separate from the strength of any encryption algorithm. Your system’s requirements will determine which level you need.
FIPS 140-2 validations became historical on September 22, 2026. New federal systems should use FIPS 140-3 validated modules, and existing systems using these historical modules must follow the applicable agency’s risk and transition guidance.
FIPS 197: Advanced Encryption Standard
FIPS 197 defines the Advanced Encryption Standard (AES). Using AES alone does not meet the standards for FIPS 140 compliance. Where validated cryptography is required, the module implementing the algorithm must also have the appropriate validation.
FIPS 201: Personal Identity Verification
FIPS 201 establishes requirements for Personal Identity Verification (PIV) systems for federal employees and contractors. These systems use identity credentials to authenticate people accessing federal facilities and information systems.
Who needs to be FIPS compliant?
You need FIPS compliance when a regulation, contract, or security policy requires it. These requirements can extend beyond federal agencies to contractors, service providers, and other private organizations.
Federal agencies and contractors: Federal agencies using cryptography to protect sensitive information are required **to use FIPS 140–validated modules, and that extends to modules operated for agencies under contract.
Regulated private sectors: In financial services, healthcare, and critical infrastructure, many organizations adopt FIPS voluntarily as their security baseline. Sometimes a specific customer contract or internal security policy turns that voluntary baseline into a hard requirement.
Technology vendors: Software vendors selling to federal or other heavily regulated customers may need to offer products that support those customers’ FIPS requirements, including operating systems, application frameworks, and container images.
Common challenges in implementing FIPS compliance
Environment restrictions, limited visibility into cryptographic operations, and configuration changes can complicate compliance with FIPS 140 requirements. Containerized applications can become particularly challenging, as they require teams to account for both the image’s contents and the environment where it runs.
Kernel dependencies and environment mismatch
FIPS module validations cover specific operating environments. When deploying to a new platform or updating systems, teams need to confirm that the environment supports validated use of the module and apply the required configuration.
Some modules also require a FIPS-enabled host kernel. Meeting that requirement can be difficult on infrastructure where teams have limited control over host configuration, such as managed Kubernetes or serverless platforms.
Lack of visibility and verification
Teams may struggle to verify whether their applications use validated modules and approved services for the cryptographic operations that require them. Without that evidence available, configuration errors can go undetected and teams may struggle to demonstrate compliance during an audit.
Ongoing maintenance and compliance drift
System updates, security patches, and dependency changes can affect which cryptographic module an application uses or whether it meets the module’s required operating conditions. A modified cryptographic module does not automatically inherit the original version’s validation, which means the provider may need to complete CMVP revalidation. Updates outside the module can also leave its validation intact while changing how the application uses it, so teams need to repeat the affected verification checks.
What does it take to achieve FIPS compliance?
For workloads subject to FIPS 140 requirements, the core work is to use validated cryptographic modules, verify that applications use their approved services under the required conditions, and keep supporting documentation. The specific implementation path will vary depending on your infrastructure, compliance context, and technology stack.
Before deploying, use these checks to connect your application to the module’s validation:
Identify the requirement and the application’s relevant cryptographic operations with your security or compliance owner.
Match the deployed module’s vendor, name, and version to its record in the
CMVP validated modules database, and confirm that its validation status meets your system’s requirements.
Check the security policy and vendor guidance for the required environment and configuration, including whether the module may be used on your target platform.
Verify that the application uses the module’s approved services for the relevant operations, as in the example below.
Retain the module, deployment, and test records, with a review date and owner, and repeat affected checks when the software or environment changes.
Choose a validated module that fits your application
Start with cryptographic modules that hold active FIPS 140-3 validations. Simply using software labeled as “FIPS-capable” does not establish that the module is validated. Use the CMVP validated modules database and search for the module you plan to deploy, including its vendor, name, and version. Then review the module’s security policy to confirm that it provides approved services for the cryptographic operations your application requires, as well as supporting use in your target operating environment.
Configure and verify the application’s cryptography
Follow the module’s security policy and vendor guidance to configure the application for its approved cryptographic services. A system-wide “FIPS mode” setting does not necessarily enforce every application choice, including algorithms and key sizes.
For example, a container image may include a validated module while the application encrypts stored records through a separate, unvalidated implementation. Encryption can succeed without meeting the applicable FIPS 140 requirement. The team needs to correct the integration and verify that record encryption uses the validated module under the required conditions.
The specific configuration and verification steps depend on your technology stack. Follow the relevant module and runtime documentation, test the cryptographic operations subject to the requirement, and retain the results. Verifying one operation does not establish that every cryptographic operation in the application meets the requirement.
Maintain compliance as software changes
Document your use of validated modules, including certificate numbers, operational modes, and security policies. This documentation will be especially important for audits and compliance assessments. As part of this, keep the deployed image digest and relevant build records alongside the module documentation and application-test results. A Software Bill of Materials (SBOM) can also help you document included components, but it won’t prove which cryptography the application used at runtime.
Review the validation status of deployed modules periodically, even when the software hasn’t changed, since module validations can become historical or revoked. Historical status does not automatically mean a module has a security flaw. Continued use in existing systems depends on the applicable agency or program rules. However, a revoked validation can no longer demonstrate FIPS 140 compliance.
After any software or environment changes, repeat the affected verification checks and update your records to reflect the deployed configuration.
Simplify FIPS compliance with Chainguard
Chainguard Containers reduces the operational burden of FIPS compliance by delivering FIPS variants with validated cryptographic modules. This lets your team start with an existing validated implementation rather than needing to submit your own module for validation.
Chainguard also helps with deployment, documentation, and ongoing maintenance:
Kernel-independent cryptography in supported operating environments reduces dependence on FIPS-enabled host kernels.
Signed software inventories and verifiable build provenance help your team document what’s in an image and how it was built. For FIPS images, those inventories also include references to module validation certificates, making it easier to gather evidence for compliance reviews.
Maintenance of Chainguard’s own FIPS Provider for OpenSSL includes fixes within its cryptographic boundary and submissions for validation.
Talk to an expert to learn how Chainguard can streamline your path to FIPS compliance.
Frequently Asked Questions
Related articles