How to Find FIPS-Validated Base Images for Your Container Environment

Key Takeaways

• FIPS validation is not the same as FIPS-enabled. Only cryptographic modules with an active NIST CMVP certificate qualify as validated — and that distinction matters to auditors and frameworks like FedRAMP.
• Most public container images are not FIPS-compliant because they ship with unvalidated cryptographic libraries, improper build configurations, or cryptographic modules that have never been submitted for CMVP testing
• Sourcing matters. FIPS-validated base images are available from a narrow set of vendors and government-approved distributions — not from general-purpose registries like Docker Hub. Echo offers the broadest selection, with support for OpenSSL, BoringCrypto, and Bouncy Castle.
• Verification is an active process. Teams must confirm cryptographic module certificates, runtime configurations, and crypto library behavior before and after deployment — something Echo handles with purpose-built tooling.
• Compliance can break silently. Updates, dependency changes, and container rebuilds can strip FIPS compliance without any warning — making continuous lifecycle governance essential.

What FIPS Validation Means for Container Security

Federal Information Processing Standard (FIPS) 140 is a U.S. government standard that defines security requirements for cryptographic modules used in information systems. When a cryptographic module is described as FIPS-validated, it means it has been independently tested and certified through the National Institute of Standards and Technology's Cryptographic Module Validation Program (NIST CMVP)  and holds an active certificate in that database.

For container security compliance, this distinction is foundational. FIPS 140-2 and its successor FIPS 140-3 establish the requirements that cryptographic implementations must meet across four security levels. Any container image running workloads that handle sensitive federal data, or that fall under frameworks like FedRAMP, FISMA, or DoD mandates must use cryptographic modules that satisfy these requirements.

The practical implication is significant: NIST's CMVP program is explicit that non-validated cryptography provides no recognized protection. In effect, data protected by unvalidated cryptographic implementations is treated as unprotected plaintext for the purposes of compliance. If your container environment transmits or stores sensitive data, container encryption using FIPS-validated modules isn't optional; it's the floor.

Understanding what FIPS validation actually requires also clarifies why it's difficult to achieve. A validated module must map its entire cryptographic boundary to a certified certificate. Any code path that falls outside that boundary, whether through a fallback library, a dynamically linked dependency, or a misconfigured runtime, breaks the validation.

Why Many Container Images Are Not FIPS-Compliant

The overwhelming majority of base images available in public registries are not FIPS-compliant, and the reasons are structural rather than incidental.

Incompatible cryptographic libraries. Standard Linux distributions ship with OpenSSL or other crypto libraries built for general-purpose use, not FIPS validation. These libraries often include cipher suites, key exchange algorithms, or random number generators that aren't covered by a CMVP certificate. Even when a library has a FIPS-validated mode, it may not be enabled or properly bounded in an off-the-shelf image.

Missing validation modules. FIPS compliance isn't simply a matter of compiling with the right flags. The module itself - its source code, build environment, and test results - must be submitted to an accredited laboratory and reviewed by NIST. Most open-source base images are built without this process in mind, meaning no CMVP certificate exists for their cryptographic implementation regardless of what the library version number suggests.

Improper build configurations. Even images built on a FIPS-capable base can fail to enforce FIPS mode at runtime. Container encryption depends on the application actually invoking the validated module - not a default system library, a vendored dependency, or a statically linked binary that bypasses the validated code path entirely.

Fast-moving upstream changes. Public base images are updated frequently to patch vulnerabilities, often without any consideration for FIPS compliance status. A patch that updates a crypto library or re-links a dependency can silently void the validation boundary without any flag or warning in the image metadata.

This is why container compliance in regulated environments requires purpose-built images, not general-purpose ones hardened after the fact. For a deeper look at what hardening actually requires, see our guide to container image hardening beyond compliance.

Where to Find FIPS-Validated Base Images

Given how few public images meet FIPS requirements, knowing where to look is half the battle. Container security compliance teams have three primary sourcing paths.

Vendor-maintained FIPS registries. Red Hat's Universal Base Image (UBI) family includes FIPS-validated variants built on RHEL, where the cryptographic modules carry active CMVP certificates. These are a reasonable starting point for teams already operating in Red Hat environments, but they require significant additional work to reach full FedRAMP readiness — FIPS validation alone doesn't mean STIG-hardened, CVE-free, or audit-ready.

Government-approved and DoD-endorsed distributions. The Defense Information Systems Agency (DISA) publishes hardened container images through the DoD Cyber Exchange, including images aligned with Security Technical Implementation Guides (STIGs). These are particularly relevant for Defense Industrial Base (DIB) contractors and agencies operating under the Risk Management Framework (RMF), but they cover a limited range of base images and still leave teams responsible for ongoing CVE remediation and compliance reporting.

Purpose-built FedRAMP compliance platforms. For teams that need to get to FedRAMP authorization without building and maintaining a compliance infrastructure from scratch, this is the only path that actually scales. Echo delivers CVE-free, FIPS-validated, STIG-hardened container images as a managed service — covering the full compliance stack that the other two options leave to you. Every Echo image uses a CMVP-validated cryptographic module (with support for OpenSSL, BoringSSL (BoringCrypto), and Bouncy Castle) operating in a configuration consistent with its FIPS 140-3 security policy. Images are pre-hardened against DISA STIGs, ship with SBOMs in both SPDX and CycloneDX formats, and come with signed provenance attestations. Continuous CVE management keeps images remediated under strict SLAs of 7 days for fixing critical and high risk CVEs, when your CVE obligation for FedRAMP stand at 21 days. 

Critically, Echo doesn't just deliver compliant images, it provides the proof auditors require. The Echo STIG validation tool produces per-image reports covering every required STIG check. The FIPS runtime tester verifies FIPS validation at runtime by executing both approved and unapproved cryptographic algorithms and reporting observed behavior. Plan of Action and Milestones (POA&M) reporting and Conmon documentation are updated and forwarded to auditors automatically. What's worth noting across all sourcing options: the authoritative reference for any claimed FIPS validation is always the NIST CMVP database. No vendor claim substitutes for a live, active certificate in that registry — and Echo's images are built to that standard from the ground up.

You may also want to review our breakdown of hidden risks in Docker base images for additional sourcing considerations.

How to Verify FIPS Compliance in a Container Image

Sourcing an image from a vendor that claims FIPS validation is a starting point, not a guarantee. Security teams need to actively verify compliance before deployment, and the verification process- and the verification process has several distinct layers.

Check the CMVP certificate directly. Every FIPS-validated cryptographic module has a certificate number listed in the NIST CMVP database. Confirm that the specific module version bundled in your image has an active, non-historical certificate. "Historical" status means the module was once validated but is no longer current — it no longer satisfies FedRAMP or other regulatory requirements.

Audit linked libraries and code paths. Statically compiled binaries, vendored dependencies, and language-level crypto implementations may bypass the system-level FIPS module entirely, creating unvalidated code paths that break the compliance boundary. 

Validate metadata and provenance. SBOM (Software Bill of Materials) attestations can surface crypto library versions quickly, but they're only as reliable as the build process that generated them. Cross-reference SBOM entries against CMVP certificates rather than treating the SBOM as the validation itself.

For an in-depth review of how you can automate the FedRAMP scanning, read our article about automation of FedRAMP containers scanning

Maintaining FIPS Compliance Across the Container Lifecycle

One of the most underappreciated challenges in container compliance is that FIPS validation is not a one-time checkpoint; it's a property that must be preserved through every rebuild, update, and dependency change in the image's lifecycle.

Updates can break validation silently. When upstream maintainers patch a base image for a CVE, they may update the OpenSSL version, re-link crypto dependencies, or change compiler flags in ways that move the cryptographic module outside the validation boundary. Unless the vendor explicitly re-certifies the updated image, compliance is broken — often with no visible signal in the image tag or changelog.

Dependency changes introduce drift. Application-layer updates that pull in new package versions can introduce cryptographic code paths that bypass the validated module. This is especially common in ecosystems with transitive dependency trees like Java (Maven/Gradle) and Node.js (npm).

Rebuilds require re-verification. Any time an image is rebuilt — even from the same Dockerfile — the resulting cryptographic configuration should be re-verified. Build environment changes, base image digest updates, and toolchain upgrades can all affect the FIPS boundary without explicit intent.

Establish a validation gate in your CI/CD pipeline. The most effective approach is to treat FIPS compliance as a pipeline stage rather than a pre-deployment checklist. Automated checks that verify crypto module certificates and FIPS runtime mode before an image is promoted to production - this catches drift early, when it's cheapest to fix.

The relationship between compliance and security also cuts both ways: teams that maintain rigorous FIPS compliance processes tend to catch security regressions faster because they're already auditing the cryptographic layer on every change. Our post on why hardened images matter explores this connection in more depth.

FAQs

What's the difference between FIPS-enabled and FIPS-validated?

"FIPS-enabled" means a system is configured to run in FIPS mode. "FIPS-validated" means the underlying cryptographic module holds an active NIST CMVP certificate. FedRAMP explicitly requires validated modules — not just enabled ones. A FIPS-enabled image using a non-validated library doesn't satisfy compliance requirements, and auditors will flag the gap.

Which base images are FIPS 140-2 or 140-3 validated?

Echo offers the broadest selection of FIPS 140-3 validated base images available, supporting OpenSSL, BoringCrypto, and Bouncy Castle — the widest crypto-module coverage on the market. Every Echo image is also STIG-hardened and CVE-free, arriving audit-ready rather than requiring additional hardening after sourcing.

Do I need FIPS-validated images for FedRAMP authorization?

Yes. FedRAMP Rev 5 requires all data in transit — including container-to-container and intra-pod traffic — to use FIPS-validated cryptographic modules. A FIPS-enabled host OS, service mesh, or VPN alone doesn't satisfy this. Container-level FIPS validation is required, and Echo images are built specifically to meet that standard.

Can I build a FIPS-validated image myself?

Technically yes, but it requires inheriting an existing CMVP-certified module, enforcing FIPS mode at runtime, and ensuring no unvalidated code paths exist — a process that costs $127,000–$255,000 per image when built in-house. Echo handles all of it as a managed service, including ongoing CVE remediation and compliance reporting.

How do I verify FIPS validation status before deploying?

Start with the NIST CMVP database and look up the certificate number for the cryptographic module in your image - verify it's active, not historical. Inside the image, check that FIPS mode is enforced at runtime and OpenSSL reports FIPS mode active audit library linkage to confirm the application is actually invoking the validated module. Finally, review your SBOM for any crypto dependencies that fall outside the validated boundary, including vendored or statically linked libraries.