This Shit is Hard: Making FIPS boring, fast, and post

The transformation of FIPS compliance involved several key engineering steps to address pre-existing systemic issues with cryptographic validation. The initial problem stemmed from the fragmented nature of FIPS validation, where certificates were issued for frozen snapshots of crypto libraries, leaving systems vulnerable to unvalidated updates and vendor lock-in. To resolve this, the approach focused on decoupling FIPS compliance from host operating system dependencies by moving entropy sources into the container environment, ensuring full entropy regardless of the underlying kernel.
Subsequent steps involved internal security hardening through cryptographic agility, where obsolete algorithms were removed rather than merely disabled, and rapid remediation for vulnerabilities occurring within the boundary. The initiative expanded operational scope by testing across a wide array of environments, including diverse Linux distributions and embedded systems like the Raspberry Pi 5. Finally, leapfrogging addressed future threats by implementing post-quantum cryptography (PQC) algorithms and removing legacy algorithms like SHA-1 to achieve full compliance with anticipated standards such as CNSA 2.0.

* FIPS validation previously required shipping frozen snapshots of crypto libraries.
* Vendors tied FIPS modules to host kernels, creating vendor lock-in.
* Entropy sources were moved into the container via the Chainguard FIPS Provider for OpenSSL, using the CPU Time Jitter RNG Entropy Source validated to SP 800-90B (certificate #E191).
* Kernel-independent FIPS was launched in November 2024 and extended to Java FIPS images in August 2025.
* Cryptographic agility involved removing obsolete algorithms (e.g., X9.42 Diffie-Hellman) from submissions before validation.
* Vulnerabilities within the boundary were fixed inside the module before validation, including CVEs like CVE-2026-31790 and CVE-2026-28386.
* Testing environments included RHEL 9/10, Ubuntu 20.04 through 26.04 LTS, Debian 12/13, SUSE Linux Enterprise Server 15/16, AlmaLinux, Rocky Linux, CentOS Stream, Amazon Linux, Azure Linux, Bottlerocket, and Google's Container-Optimized OS, as well as the Raspberry Pi 5.
* The FIPS Provider for OpenSSL 3.6 received validation on September 15, 2026 (certificate #5523), including ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205).
* SHA-1, MD5, and MD4 were removed from the security policy; only verification-only exhibits remain.
* The project resulted in a guidance document (IG D.S, Key Encapsulation Mechanisms) published September 2, 2025.

The narrative centers on shifting FIPS compliance from a retrospective, vendor-dependent checkbox to a proactive, inherently secure foundation built through cryptographic agility and architectural independence. The pattern observed is the friction created when regulatory adherence relies on static snapshots rather than dynamic assurance—a structural vulnerability where security reality (CVEs) diverges from documented compliance. The process effectively inverts the traditional compliance model: instead of checking a compiled artifact against an external standard, the system asserts its internal state based on verifiable, actively managed components. This moves the burden from post-hoc auditing to continuous, provable engineering within the boundary itself.
The implication is a demand for systems where validation is inherent, not appended. The leapfrogging of PQC standards and the removal of museum cryptography highlight a tension between slow, bureaucratic standardization bodies (NIST) and rapid, evolving cryptographic science. The choice to remove legacy algorithms like SHA-1, even when it causes downstream software breakage, demonstrates a principle prioritizing future security integrity over immediate operational convenience. This challenges the assumption that compliance must be achieved by merely adhering to existing frameworks; instead, true resilience requires engineering solutions that anticipate the evolution of both the threat landscape and the standards themselves.
Bridge Questions: If security is built into the module from inception rather than layered on afterward, what obligations does this place on the maintainers of legacy infrastructure? How can industry mechanisms evolve to reward proactive cryptographic agility over static certification timelines? What are the downstream societal costs when operational speed conflicts with the rigorous demands of verifiable post-quantum migration?