Owning the boundary: Introducing the Chainguard FIPS Provider for OpenSSL 3.4.0

Beginning March 17, 2026, all Chainguard FIPS container images will upgrade to the newly validated Chainguard FIPS Provider for OpenSSL 3.4.0 (CMVP #5132). Chainguard is the first to FIPS-validate OpenSSL 3.4, and with this release, we now own the validated cryptographic module that powers our FIPS images. That means we can directly remediate in-boundary vulnerabilities on our timeline rather than waiting on third parties.

In regulated environments, a FIPS certificate is often treated like the finish line. Once the module is validated and the certificate number is on the paperwork, it is assumed that the cryptography question is settled. In practice, the certificate is a milestone. Keeping the validated module current after issuance is the ongoing work.

A FIPS module remains validated over time, but the security posture of the code inside the validated boundary does not stand still. Vulnerabilities are disclosed, fixes are developed, and teams still have to reconcile two ongoing requirements: applying updates while staying within the scope of the validated module and its CMVP certificate. 

For many vendors, the practical way to ship FIPS-capable software has been to rely on an existing validated OpenSSL module, often via a rebranded provider. That approach is common, and it solves an important problem: it gives their customers a validated module they can point to for compliance. The tradeoff is that the operational lifecycle of that module, especially CVE remediation and resubmission, is ultimately controlled by the module owner. When new issues are disclosed inside the validated boundary, downstream consumers cannot influence timelines.

We have been in that world, too. And over time, we have seen that the control point matters.

Owning the boundary changes the outcome

When we control the validated module, we control the operational lifecycle inside that boundary.

That means when an in-boundary vulnerability is disclosed, remediation is not dependent on a third party. Instead, we can incorporate fixes and take responsibility for the resubmission process required to keep the module aligned with its validated status. The certificate does not become a static artifact while the code drifts. The boundary evolves with the threat landscape.

At launch, the Chainguard FIPS Provider for OpenSSL 3.4.0 incorporates fixes for CVE-2023-6237, CVE-2024-4603, and CVE-2024-13176 that were present in prior module generations. The fixed advisory will be published on March 31, 2026. The module launches with no known CVEs, and we are committing to submit updates for any in-boundary CVE regardless of severity. That commitment reflects the operational reality that compliance and vulnerability management cannot be separated.

This is the practical difference between inheriting a validated module and operating one.

Built on OpenSSL 3.4

The module is built on OpenSSL 3.4, and the Chainguard FIPS Provider is the only OpenSSL 3.4–based module to receive FIPS 140-3 validation. Customers benefit from the performance improvements and architectural refinements in the 3.4 release line, along with a validated boundary that remains current over time.

This is not simply a version upgrade from OpenSSL 3.1.2 (CMVP #5102) to OpenSSL 3.4.0 (CMVP #5132). It is a transition to a module that aligns with current and forward-looking NIST guidance.

2030-ready cryptography

The Chainguard FIPS Provider for OpenSSL 3.4.0 completes all required, planned, and draft algorithmic transitions necessary to align with NIST SP 800-131A guidance through 2030.

The module adds support for FIPS 186-5 Ed25519 digital signature generation and validation in approved mode, implemented fully in userspace with assurance of generated key strength. It also enforces modern security baselines, including the minimum 8-character password length requirements for PBKDF.

At the same time, algorithms that no longer meet current strength requirements have been removed in accordance with FIPS 140-3 and NIST guidance. The result is a module that reflects the present state of cryptographic standards rather than a snapshot from a previous decade.

A self-contained, portable design

The Chainguard FIPS Provider for OpenSSL 3.4.0 is the first and only software cryptographic module to provide full entropy assurance via a statically linked SP 800-90B kernel-independent entropy source. Sensitive security parameters are generated with validated entropy without relying on kernel-specific implementations.

The module operates fully in userspace and is not dependent on a FIPS-enabled kernel, which gives you more flexibility in where you run FIPS workloads and a more consistent runtime experience across local development, test, staging, and production. It is portable to any Linux ELF execution capable environment with glibc 2.34 or higher and validated across 57 tested or vendor affirmed operating environments, including major Linux distributions such as Amazon Linux, Google COS, Red Hat Enterprise Linux 10, Ubuntu 24.04, Azure Linux, Debian, SUSE Linux Enterprise, and Raspberry Pi 5, as well as all major public cloud platforms.From edge systems to hyperscale cloud deployments, the same validated boundary applies.

Broad algorithm and architecture coverage

The module includes 39 CAVP algorithm testing certificates covering both software and hardware-accelerated implementations on x86_64 and ARM64. Hardware-accelerated paths were tested through Intel Sapphire Rapids (AVX-512) and Neoverse V1 (SVE), so the fast paths are covered in the validation work and not treated as a separate case.

Moving the finish line

FIPS validation remains a necessary foundation for regulated workloads. What changes with this release is who is responsible for what happens next.

"Meeting compliance requirements while staying ahead of new vulnerabilities has always been a challenge for organizations in regulated industries," said Orbby Chang, Senior Architect, Trend Micro. "Efforts that bring validated cryptography and vulnerability management closer together are an important step forward for the broader security community. It’s encouraging to see the ecosystem moving toward more proactive, collaborative approaches to compliance and security."

By building and validating our own FIPS provider, Chainguard can align the validated boundary with how our images are actually built, maintained, and patched. The certificate still matters, but so does the operational work required to keep the validated module current as vulnerabilities and requirements evolve.

For the latest FIPS updates, follow the CMVP Certification Upgrades with FIPS 140-3 knowledge base article. The current set of validated cryptography modules is always listed on the Chainguard FIPS commitment page. If you have questions, our team is available at support.chainguard.dev.