Good news first for once.
The algorithms shipped.
The crypto you spent two years being told to wait for is sitting in your TLS library right now:
- ML-KEM and ML-DSA were finalized as FIPS 203 and 204 in August 2024 [1],
- OpenSSL 3.5 carries them natively and negotiates the X25519MLKEM768 group for hybrid [2], and
- OpenSSH has run a post-quantum key exchange by default since 9.0 in 2022, with mlkem768x25519-sha256 taking over as the default in 10.0 in April 2025 [3].
The bad news is that “the crypto exists” and “you can compliantly deploy it” are still two very different sentences, and the gap between them is mostly paperwork, not math.
Three Choices Hiding Inside “Post-Quantum”
Post-quantum deployment isn’t one decision, it’s three: hybrid key exchange, and composite or pure signatures on the signing side, with the signature choice carrying enough of its own weight to be the whole of a secondary article. For now the useful split is simpler: key establishment is the urgent move and signatures are not.
A key exchange you perform today can be recorded today and broken later once the hardware exists, so every day on classical-only key exchange is a day of recordable exposure. A signature only matters while the key is live, so its migration has more runway. The new Executive Order encodes exactly this asymmetry in its deadlines: key-establishment migration is due by the end of 2030 and digital-signature migration a full year later, by the end of 2031 [4]. The standards-writers and the policy-writers agree on the sequencing, which is rare enough to trust.
None of that urgency changes one thing, though: your randomness. ML-KEM keygen, the piece under discussion here, consumes random bytes the same way every other approved algorithm does, from an SP 800-90A DRBG seeded by an 800-90B-validated entropy source [5]. There is no post-quantum RNG standard and no new entropy gate. The one watch-item is strength matching: a Category 5 parameter set targets 256-bit security, so the DRBG seeding it has to be instantiated at that strength, not a 128-bit instance left over from a classical config. If you cleared the entropy bar for classical crypto, you carry it forward. That is the rare part of this migration that is genuinely free.
Note: Entropy & RNG/RBG is an super cool subject and reviewers of this series asked me to expand on the subject but it’s deep-end-of-the-pool and is big enough for a dedicated post. Stay tuned.
Anyway… this brings us to the wall that catches people, and it isn’t the algorithm. It’s validation. Three obstacles sit between a shipped algorithm and a deployable one:
- The FIPS provider gap
- Distribution lag between certification and deploying in a production environment
- HSM firmware validation cycles
The first is the deepest. A NIST Cryptographic Module Validation Program (CMVP) certificate validates a specific cryptographic module at an exact version, in a tested operational environment. It validates a module, not a product and not an algorithm. That makes the validated object narrow and delicate: change the version or the kernel underneath it, and the validation may no longer apply.
FIPS 140-2 has been the baseline for two decades. On September 21, 2026, every active 140-2 certificate moves to the CMVP historical list, after which it can no longer be procured to satisfy a federal cryptographic requirement [6].
The reflex is to say 140-3 has existed since 2019 so everyone has had years, but that reading is wrong. CMVP didn’t begin accepting 140-3 submissions until late 2020 and did not issue the first 140-3 certificates until December 2022. So the achievable runway was roughly 2023 to 2026, not 2019 to 2026 [6].
This isn’t something practitioners need to personally track by monitoring CMVP submissions. It’s an OEM disclosure obligation: our job is to demand the roadmap commitment, not chase the paperwork yourself, and a customer only consumes a validated product many quarters after the vendor starts the validation process, not the day the vendor announces intent.
Then factor in the validation queue. For years it ran past two years from submission to active certificate, and that backlog is exactly what made the compressed runway dangerous, because “in-process” status doesn’t satisfy a FedRAMP, FAR, or auditor requirement [7].
The queue is now easing fast: CMVP reported a 180-day backlog as of January 1 2026 and a 348-day average across its last thirty validations, with a near-zero-backlog goal for July 2026 [7]. That improves the odds for a module entering the pipeline today, but it does nothing for one that needed its certificate two years ago, and nothing at all to the retirement date. This is why so much production crypto still rides 140-2 certificates that remain lawfully valid right up to the sunset: the replacement parts aren’t all on the shelf yet.
The recent US Executive Order acknowledges this directly. Alongside the migration deadlines, Section 6(b) directs NIST to revise the CMVP process to accelerate validations, with a 180-day clock to do it [4]. In other words, the same order that sets hard post-quantum deadlines also admits the pipeline that feeds them is too slow, and orders it rebuilt. What that rebuild looks like isn’t defined yet, so treat any specific acceleration mechanism as speculative for now, and note that it is throughput-side only: nothing in the Order moves the 140-2 retirement date.
That roadmap commitment is exactly what to look for from a vendor, and here’s what it looks like in practice on F5 BIG-IP. I’m not at all prejudice on the following example. 
A concrete case: where the clock actually lands on F5 BIG-IP
On F5 BIG-IP, the FIPS-validated thing is the cryptographic module inside TMOS, not the appliance as a whole. The distinction matters the moment someone asks “is my BIG-IP FIPS.” The integrated HSM is FIPS-validated, but the BIG-IP systems are not themselves 140-2/3 Level 3 validated [8]. F5 is well into the transition: BIG-IP TMOS v17.1.0.1 achieved FIPS 140-3 Level 2 validation on rSeries and VELOS platforms as of this year. F5OS underneath TMOS is Level 2 validated. BIG-IP VE sits at 140-3 Level 1. FIPS 140-3 Level 2 validation is available as Platform FIPS on rSeries and VELOS with tamper-evident stickers [8].
The exposure is the same one the queue creates everywhere: some F5 140-2 certifications were still in process near the April 2022 submission cutoff and will not get a full five-year life because of the 2026 sunset [8]. The randomness story shows up here too, made concrete: the 140-3 BIG-IP module generates asymmetric keys per SP 800-133 Rev2 using an SP 800-90A Counter DRBG for the seed [9], the same plumbing whether the key is RSA or ML-KEM. And the upgrade gotcha is real: in 140-3 mode the platform will not generate new RSA-512, RSA-1024, EC-521, DSA, or SM2 keys [10], so a version bump can quietly break a key-generation workflow that worked fine the day before. One platform, and it carries every theme on this page at once.
The algorithms are the easy part and the validation pipeline is the hard part, which is the inversion nobody plans for. But even once the modules clear, the two halves of the migration don’t cost the same. Migrating key exchange turns out to be the gentle half. It slots into the handshake, it is already the browser and SSH default, and the worst it costs us is a chubby hello packet. Signatures are where things genuinely get messy, and the reasons are structural enough to need their own conversation.
References
[1] National Institute of Standards and Technology. FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA).
[2] OpenSSL Project. OpenSSL 3.5 Series Release Notes: native ML-KEM/ML-DSA support; X25519MLKEM768 negotiated by default.
[3] OpenSSH. Post-quantum cryptography in OpenSSH. PQ key agreement default since 9.0 (April 2022, sntrup761x25519-sha512); mlkem768x25519-sha256 added in 9.9, made default in 10.0 (April 2025); 10.1 warns on non-PQ KEX.
[4] Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” June 22, 2026. Key-establishment migration by end-2030, digital-signature migration by end-2031; NIST to revise CMVP to accelerate validations within 180 days (Sec. 6(b)). Federal Register text: 91 FR 38483.
[5] NIST SP 800-90A (DRBGs), SP 800-90B (entropy sources), SP 800-90C (RBG construction) via the SP 800-90C (Random Bit Generators). DRBGs required in FIPS 140 for all key generation; DRBG strength must meet the security strength of the key being generated.
[6] NIST Cryptographic Module Validation Program. FIPS 140-3 Transition Effort. 140-2 validations move to the historical list September 21, 2026; 140-3 submissions accepted from September 2020, first certificates issued December 2022.
[7] David Hawes (CMVP Program Manager, NIST), “Cryptographic Module Validation Program (CMVP) Status and Future Plans,” 21 January 2026. Via the CMVP project page. Historically a 2+ year queue after lab testing; reduced to a 180-day backlog as of January 1, 2026, with a 348-day average across the last thirty validations and a near-zero-backlog goal for July 1, 2026. In-process status isn’t accepted as a valid compliance state by FedRAMP, FAR, or auditors.
[8] F5, Inc. Certifications. FIPS 140-3 section. Last updated 7/1/2026. BIG-IP TMOS v17.1.0.1: Level 2 (rSeries r4800/r5900/r5920-DF/r10900/r10920-DF/r12900DS, VELOS CX410/BX110/VE); iSeries/VIPRION: Level 2. BIG-IP TMOS v17.5: Level 1 (VE), Level 2 (iSeries i15600/i15800/i15820-DF, VIPRION C2400-B2250/C4480-B4450). F5OS C v1.8.1 (VELOS CX1610-BX520, CX410-BX110): Level 2. F5OS A v1.5.1 (r4000/r5000 series incl. r5920-DF, r10000 series incl. r10920-DF): Level 2. F5OS A v1.7.0 (r12k): Level 2. F5OS C v1.6.0 (VELOS BX110, CX410): Level 1.
[9] F5, Inc. FIPS 140-3 Non-Proprietary Security Policy, BIG-IP Cryptographic Module, CMVP Cert. #4716. Section on SSP generation: cryptographic key generation for asymmetric keys per SP 800-133 Rev2 §4 (vendor affirmed), seed is a direct output of the SP 800-90A Rev1 Counter DRBG.
[10] F5 Platform FIPS administration documentation. Platform FIPS Overview (BIG-IP 17.1); generation of new RSA-512, RSA-1024, EC-521, DSA, and SM2 keys not supported in FIPS 140-3 mode, per BIG-IP 17.1.0 release notes, ID 1224125.