FIPS 140 2 vs FIPS 140 3 for Container Images and Cryptographic Modules

Cryptography is only secure when standards back it. This article explains what FIPS 140-2 and FIPS 140-3 are, why the transition happened, how validation works, which systems and container images require FIPS, how FIPS mode is enabled, and what the future of cryptographic compliance looks like.

What Is FIPS 140 2 and FIPS 140 3?

FIPS 142 and FIPS 143 are Federal Information Processing Standard publications that define security requirements for cryptographic modules used to protect sensitive information with approved cryptographic algorithms (for example, encryption). A “cryptographic module” is the component that performs cryptographic operations, such as an operating system crypto library or a validated OpenSSL-based module, and it is assessed against defined requirements and a security level model.

FIPS 140-2 is the earlier cryptographic module security standard, while FIPS 140-3 is the newer standard that modernizes validation by aligning with international requirements and CMVP-managed guidance rather than keeping all requirements inside the publication itself. Both are enforced through the Cryptographic Module Validation Program (CMVP), a joint program led by NIST and the Canadian Centre for Cyber Security, and only modules validated to FIPS 140-2 or FIPS 140-3 meet FIPS module requirements for protecting sensitive information when cryptographic functions are deployed inside a container that packages the module, its dependencies, and the runtime environment.

Which Systems Require FIPS Validated Cryptography?

Systems that require FIPS validated cryptography are the ones where policy or procurement rules mandate using validated cryptographic modules (rather than “FIPS compliant” claims). In practice, that means systems must use a validated module under FIPS 142 or FIPS 143 through the Cryptographic Module Validation Program (CMVP) led by NIST and Canada’s program partner.

The following points are related to systems that require FIPS validation for cryptographic security and compliance.

1. U.S. federal agency information systems: They protect government sensitive data using cryptography, where using FIPS validated modules is the required compliance posture for cryptographic protection.
   

2. Products and platforms sold into U.S. government environments (hardware, software, cloud services): When their cryptographic operations must be performed by FIPS validated modules to meet government procurement requirements.
   

3. Canadian federal government procurement environments: They select CMVP validated products and rely on FIPS certificates as the acceptance signal for cryptographic modules that underpin container security controls, such as encryption, key management, and integrity verification for container images and runtime workloads.

4. Operating systems and security stacks configured to run in FIPS mode (for example, systems using an OpenSSL FIPS provider or OpenSSL FIPS object module): When the environment’s compliance requirement is specifically “use only validated cryptographic modules and approved algorithms.

What Is the Difference Between FIPS 140 2 and FIPS 140 3?

Given below are the differences

Why Did FIPS 140 2 Transition to FIPS 140 3?

The following points are related to why FIPS 140-2 transitioned to FIPS 140-3.

• To modernize the FIPS standards framework: So cryptographic module requirements could evolve without rewriting a single, self-contained document each time.
  

• To align U.S. FIPS requirements with international cryptographic standards: By basing FIPS 140-3 on ISO and IEC module and testing standards, improving consistency across global validation ecosystems.
  

• To improve the CMVP validation process: By using the SP 800-140 series to define and update derived test requirements and evidence expectations for FIPS 140-3 validation.
  

• To provide a clearer compliance with FIPS transition path: By shifting new validations to FIPS 140-3 while managing existing FIPS 140-2 certificates through CMVP’s defined transition handling, and by ensuring cgroups enforce resource isolation and limits that keep crypto services predictable under load in containerized deployments.

What Are the FIPS Compliance Requirements for Cryptographic Modules?

The following points are related to the FIPS compliance requirements for cryptographic modules under FIPS 140-2 and 140-3.

1. The module must be validated under FIPS 140-2 or FIPS 140-3: Through the CMVP evaluation workflow; “FIPS compliant” claims do not substitute for a validated module.  

2. The module must meet defined requirement areas: Covering secure design, implementation, and operation, including module specification, interfaces, roles and authentication, software or firmware security, operating environment, physical security, sensitive security parameter management, self-tests, lifecycle assurance, and mitigation of other attacks.
   

3. The module must conform to a FIPS security level (Levels One through Four): It matches the deployment risk and assurance needs, including higher assurance options such as Level Four for strong physical and environmental protections.
   

4. For FIPS 140-3 compliance, the module must follow the ISO and IEC-based structure: Adopted by the program, with CMVP-managed variances and evidence requirements handled through the SP 800-140 series.
   

5. If an organization uses FIPS mode: The system configuration must ensure cryptographic operations route through the validated module and do not fall back to non-validated crypto paths; a Dockerfile enforces this by defining the FIPS-capable base image, required crypto libraries, and runtime settings that keep the container from silently using non-validated implementations.

Why Do Container Images Need FIPS Validated Modules?

The following points are related to why container images need FIPS validated modules to meet FIPS 140 compliance.

1. Container images often ship the cryptographic libraries used at runtime. If those libraries are not FIPS 140-2 validated or FIPS 140-3 validated, the workload cannot credibly claim it uses validated cryptography in regulated environments, and the container entrypoint must explicitly start the application in FIPS mode and fail fast if the validated module or required configuration is missing.
   

2. “Enable FIPS mode” is a configuration state. It does not replace validation. If crypto falls back to non-validated paths, the system can fail FIPS compliance expectations in audits.
   

3. Reused base images multiply risk. Using built with FIPS images and controlled FIPS packages reduces the chance of spreading non-validated crypto across many services.
   

4. The compliance requirement is module validation under CMVP. NIST’s CMVP describes validation as the mechanism for approving cryptographic modules for federal use.

How Does FIPS 140 3 Strengthen Container Image Security?

The following points are related to how FIPS 140-3 strengthens container image security.

1. It raises the assurance bar for the cryptographic module inside the image: By requiring conformance to FIPS 140-3 security requirement areas such as roles and authentication, software or firmware security, operating environment controls, self-tests, life-cycle assurance, and mitigation of other attacks.
   

2. It makes validation more test-driven and maintainable: Because FIPS 140-3 is validated using ISO and IEC-aligned test requirements plus NIST’s derived test requirement updates, reducing ambiguity in how “compliant with FIPS” is evaluated across vendors and builds across container orchestration platforms that standardize how validated crypto configurations are deployed, enforced, and audited at scale.
   

3. It improves enforceability in regulated deployments: Because a container image that uses a FIPS 140-3 validated module provides a stronger compliance signal than “supports FIPS” claims or environments where “FIPS mode may” be enabled but crypto paths are not validated.
   

4. It preserves the same security level model (including higher assurance options): While updating the underlying requirements and testing structure, which helps container images meet FIPS requirements in higher-risk environments without changing the operational goal.

Which Cryptographic Modules Support FIPS Compliance in Containers?

The following points are related to cryptographic modules that support FIPS compliance in containers when the container image is built to use FIPS approved cryptography from a validated module (rather than a “supports FIPS” claim), and when the container runtime enforces execution, isolation, and crypto path integrity so that all cryptographic operations are consistently handled by the validated module.

1. OpenSSL FIPS Provider (OpenSSL 3.x): For modern FIPS implementations used in container images, when your build links crypto operations to the validated provider.
   

2. OpenSSL FIPS Object Module 2.0: For legacy FIPS 140-2 validation environments that still depend on OpenSSL 1.0.x era integrations.
   

3. Bouncy Castle FIPS Java API: For Java workloads in containers that need a validated crypto module for compliance-driven deployments.
   

4. wolfCrypt module (wolfSSL): For containerized applications that embed wolfCrypt as the cryptography library and require FIPS 140-3 validation signals.

How Are FIPS Compliant Container Images Built?

The following points are related to how FIPS compliant container images are built.

1. Choose a base OS image that supports running the underlying system in FIPS mode and keep the OS packages consistent with that FIPS configuration.
   

2. Use a validated cryptographic module (a module validated under FIPS 140-2 or FIPS 140-3) and pin the exact version that is covered by its validation boundary.
   

3. Build the image so application cryptography routes through the validated module path, not through alternative crypto libraries bundled by the app or language runtime, and publish it to a container registry that stores, versions, and distributes the approved image so teams consistently deploy the same validated-crypto build.
   

4. Keep the operational environment consistent across build and runtime nodes, because “FIPS mode is enabled” is enforced at the system level and must match how the module was intended to operate.
   

5. Verify the resulting image behaves as expected in a FIPS-enabled environment (for example, non-approved algorithms are rejected and FIPS-approved crypto remains available).

What Limitations Exist When Running Applications in FIPS Mode?

The following points are related to limitations you can expect when running applications in FIPS mode.

1. Non-approved algorithms are blocked or force the crypto module out of approved mode: Which can break features that depend on those algorithms (for example, legacy ciphers or signature schemes).
   

2. TLS and interoperability can be constrained: Because cipher suites and key sizes must meet FIPS and related NIST requirements, which can cause handshake failures with older clients or servers.
   

3. Applications may fail at startup after “FIPS mode is enabled”: If they implicitly initialize crypto in non-approved ways or rely on defaults that are not valid in approved mode.  

4. Some functionality must be reconfigured or replaced: Because FIPS mode is primarily a compliance posture and disables certain behaviors even if they were previously accepted in non-FIPS environments, and an SBOM documents the exact cryptographic libraries and versions in the build so you can confirm which components must change to remain FIPS-aligned.
   

5. Performance can change: Because FIPS-approved configurations may require different implementations and additional self-test or integrity behaviors in validated modules.

What Is the Future of FIPS and Cryptographic Compliance?

The future of FIPS and cryptographic compliance is a continued shift from FIPS 140-2 vs FIPS 140-3, where FIPS 140-3 introduces an ISO and IEC-aligned validation framework that can be updated through NIST guidance without rewriting the core standard, while older FIPS 140-2 validations move toward end-of-life handling.

The following points are related to what will define “must comply with FIPS” programs over the next few years.

1. FIPS 140-3 becomes the durable baseline: New validations run under FIPS 140-3, and the program continues to evolve via updated derived test requirements and implementation guidance.  

2. FIPS 140-2 sunsets operationally: NIST’s transition materials indicate FIPS 140-2 continues “through 2026,” after which FIPS 140-2 validations shift to historical treatment, tightening what “comply with FIPS” means for new procurements and new deployments.  

3. Crypto-agility becomes a compliance expectation: Cryptographic compliance is increasingly tied to the ability to swap algorithms and modules safely as guidance changes, especially in long-lived systems.
   

4. Post-quantum cryptography enters the FIPS ecosystem: NIST finalized initial post-quantum cryptography standards as FIPS publications (for example, FIPS 203, 204, 205), which will drive future “approved algorithm” roadmaps alongside FIPS 140 module validation requirements.
   

5. Security levels remain a procurement signal, but assurance evidence tightens: The “level” model (including higher-assurance targets such as Level 4) remains a way buyers express required protection, while the validation evidence and testing expectations increasingly standardize under the FIPS 140-3 structure, and Kubernetes enforces these expectations by standardizing how workloads are deployed, isolated, and configured so validated cryptography is used consistently across clusters.

FAQs:

1. Is FIPS Compliance Mandatory for all Organizations?
   
   No. FIPS is mandatory for U.S. federal agencies and contractors but optional for private organizations unless required by regulation or contract.
   

2. Can a System Claim FIPS Compliance Without Validated Modules?
   
   No. Only cryptographic modules validated under the CMVP qualify as FIPS validated; configuration alone is insufficient.
   

3. Does Running in FIPS Mode Automatically Make Applications Compliant?
   
   No. FIPS mode enforces restrictions, but applications must still use validated cryptographic modules correctly.  

4. Can Containers use Host-Level FIPS Validation?
   
   Partially. Containers inherit host enforcement, but cryptographic libraries inside the image must still align with the validated module boundary.
   

5. How Long Does FIPS 140-3 Validation Typically Take?
   
   Validation often takes several months to over a year, depending on module complexity and CMVP testing queue timelines.
   

6. Will FIPS 140-2 Validated Modules Stop Working After Deprecation?
   
   No. They continue functioning technically, but may no longer satisfy compliance or procurement requirements once listed as historical.