Post-Quantum Compliance Is Public but Unsearchable

Every answer a federal buyer needs about post-quantum compliance is published. None of it is searchable in the database that governs the purchase.

Two of the 676 cryptographic modules currently validated under FIPS 140-3 carry both of the algorithms that CNSA 2.0 requires, and there’s no way to find that out by searching for it. Post-quantum compliance is on the public record, sitting in 676 separate PDFs. You’ve got to open all of them.

I did. The count comes from a caption-anchored census of every active FIPS 140-3 security policy on the NIST list as of August 15, 2026. It’s Laterstack’s own count rather than a published figure. The script and the per-module output are linked at the bottom so anyone can re-run it.

The count

Two modules out of 676 carry both ML-KEM and ML-DSA under an approved-algorithms table. They’re Kryptus certificate 5282 and Thales Luna T7 certificate 5450. Both go further and name ML-KEM-1024 and ML-DSA-87 specifically, which are the parameter sets NSA lists for national security systems.

Both are hardware. Kryptus describes itself as a Hardware Security Module, multi-chip embedded, overall security level 3. Thales states Module Type: Hardware, Embodiment: MultiChipEmbed. No validated software module carries both.

Nine software modules get partway. Eight of them carry ML-KEM in an approved table and one carries ML-DSA, and not a single one carries both. AWS-LC 3, certificate 5314 is the recognizable name in that group, declaring Module Type: Software with ML-KEM approved and no ML-DSA.

That split is the shape of the problem. Key establishment is arriving in software and signatures aren’t, so the eleven modules carrying any post-quantum algorithm at all break into nine that solved half the suite and two hardware boxes that solved all of it.

The list moves every week, and that’s worth sitting with. It held 666 active modules on August 8 and 676 on August 15, so ten modules got validated in seven days. Not one of them qualified.

Two databases

NIST runs two validation databases, and the searchable one isn’t the one that governs the purchase.

The Cryptographic Algorithm Validation Program is fully searchable by post-quantum algorithm. Its filter offers ML-DSA KeyGen, SigGen and SigVer, ML-KEM EncapDecap and KeyGen, SLH-DSA, and LMS. Type in what you need and you’ll get results.

CAVP validates algorithm implementations. It isn’t sufficient for procurement.

The Cryptographic Module Validation Program validates modules, which is what actually gets bought and deployed, and it’s the one a national security systems buyer is required to use. Its Algorithm filter runs AES through Triple-DES. It includes Skipjack. It includes DES. There’s no option for ML-KEM, no option for ML-DSA, no option for SLH-DSA. Certificate pages list no algorithms at all, so pulling up certificate 5313 tells you nothing about what’s inside it.

That asymmetry points the wrong way. The database that can’t govern a purchase is the one built to be searched. The one that governs it leaves the security policy PDF as the only record of what a module can actually do in approved mode.

The captions

The same algorithm string shows up several times inside a single security policy, and only one of those appearances means the module can use it.

In the Thales policy, ML-KEM-1024 appears under Table 3, a modes list, under Table 4, Approved Algorithms, and again under Table 22, pre-operational self-tests. Same string, three tables, three different meanings. A keyword search across the corpus returns all three and can’t tell them apart, which is exactly how a keyword scan overcounts.

There’s a wrinkle that makes it worse. In these documents the caption gets emitted after the table body in the extracted text, not before it, so the nearest caption above a row is usually the wrong one. In the Kryptus policy the ML-DSA-87 row sits at line 376, with “Table 3: Modes List” above it and “Table 4: Approved Algorithms” below. The one below is the one that governs. Walking backward gives you the wrong answer every time, and the census only got trustworthy after that direction was tested against a document where the right answer was already known.

Two well-known modules land on the other side of this line. Microsoft SymCrypt, certificate 5313, lists ML-KEM and ML-DSA under Table 10, Non-Approved, Not Allowed Algorithms. Apple corecrypto 18.3, certificate 5184, mentions ML-KEM and doesn’t carry it under an approved table.

Both of those are the correct disclosure, and that’s the part worth being careful about. Listing an algorithm as non-approved is exactly what a vendor is supposed to do when the code exists but hasn’t been validated for approved mode, and both companies documented it in the format NIST asks for. They’re named here because they’re the two a reader will recognize, not because they stand out from the other 60 policies that mention post-quantum algorithms. The gap isn’t in anyone’s paperwork. It’s that a buyer running a search never reaches the paperwork. Microsoft and Apple were both sent detailed questions about this reading on August 15, 2026, and told the piece would publish the following week. Microsoft answered on August 19 through its media relations agency. A Microsoft spokesperson said the company “is committed to supporting post-quantum cryptography across our products and platforms and continues to advance support for NIST-standardized algorithms, including ML-KEM and ML-DSA,” and that “SymCrypt’s current and future validation efforts are intended to align with applicable cryptographic standards and customer requirements.” Nothing in that statement disputes the reading of certificate 5313’s policy. Apple didn’t respond before publication, and that needs saying carefully: the address used is Apple’s published media helpline, so the question may never have reached anyone who works on cryptography.

The signing path

CNSA 2.0 has two signature contexts, and conflating them is the easiest way to get this wrong. General digital signature is ML-DSA-87 under FIPS 204. Software and firmware signing is LMS or XMSS under SP 800-208, which is a separate requirement with a separate validated-module picture.

Eleven modules carry LMS in an approved table. Only two of those can generate signatures instead of only verifying them, which matters quite a bit if the job is signing your own firmware.

XMSS is the stranger case. It’s permitted under SP 800-208, CAVP offers no XMSS algorithm testing at all, and no validated module carries it in an approved table. A permitted algorithm with no test path and no implementations isn’t much of an option.

One absence needs to be read correctly. Not one of the 676 modules carries SLH-DSA in an approved table, and that’s a curiosity instead of a gap: NSA’s own FAQ says SLH-DSA “is not part of CNSA and is not approved for any use in NSS.” Nobody’s missing a requirement by not shipping it, and I’d have gotten that backwards without the FAQ.

The clock

January 1, 2027 is an acquisition gate rather than a signing deadline. That distinction changes who has a problem. CNSSP 15 states that by that date, all new acquisitions for national security systems will be required to be CNSA 2.0 compliant unless otherwise noted. NSA’s Dr. Morgan Stern put the same date on a timeline slide in a March 2026 conference presentation: “2027 / New NSS acquisitions / must be QR.”

Those last four words are doing real work. “Unless otherwise noted” is the kind of phrase that decides procurement fights, and the FAQ does not say who gets to note otherwise, on what grounds, or how a vendor would find out. With a supply of two qualifying modules, how that clause gets read may end up mattering more than the deadline it is attached to.

The same presentation supplies the link that makes the module census matter at all. Stern’s verbatim line is that “CNSSP-11 lays out that commercial-off-the-shelf products intended to protect National Security Systems must be validated using the FIPS and NIAP processes.” That’s the sentence tying a policy deadline to this specific list of 676 PDFs. Without it the census is trivia. With it, the validated-module list is the supply of what a buyer’s allowed to buy.

Doug Finke, Chief Content Officer at Global Quantum Intelligence, supplied the number that actually decides whether 2027 is early or late. Finding and remediating cryptography across a complex IT estate takes five years or more, and he was specific that five is a floor and not a ceiling. Nothing in the forecasting argument touches that figure. It is a statement about how long enterprise inventory and replacement takes, and it holds whichever year the machines arrive.

On arrival, GQI expects cryptographically relevant quantum computers to start showing up in 2029. The standing expert survey does not price that specific year, and what it does show is the direction of travel. The Global Risk Institute’s 2025 Quantum Threat Timeline, published March 9, 2026, with Mosca and Piani surveying 26 experts, puts it this way: a cryptographically relevant quantum computer is “quite possible (28-49%) within the next 10 years, and likely (51-70%) in the next 15.”

Run that against the remediation number and the lead time is the whole argument. If finding and replacing cryptography across an estate takes five years at the low end, and the experts who study arrival call it quite possible inside ten, an organization starting its acquisitions in 2027 is already inside the window, whatever the odds turn out to be.

So if you’re buying for a national security system today, your shortlist is two hardware modules. That’s the entire field and not a narrow slice of it, and anyone who needs this in software is still waiting: ten modules cleared validation during the week I was counting, and not one of them changed that number.

The order

The White House reached the same conclusion about CMVP two months ago, and the fix it ordered is not the one a buyer needs. Executive Order 14412, signed June 22, 2026, tells the Secretary of Commerce through the Director of NIST to “revise the processes used by the Cryptographic Module Validation Program to accelerate validations of cryptographic modules.” That is Section 6(b), it carries a 180-day clock, and the clock runs out around December 19, 2026.

Read the verb. Accelerate. The order is about how fast modules get through the queue, and it says nothing about whether anyone can find out what came out the other end. Those are different problems and only one of them is being fixed.

Section 6(c) widens the audience considerably. It directs the FAR Council to propose a rule requiring “covered contractors to comply by December 31, 2030, with NIST’s FIPS, including all applicable FIPS incorporating PQC compliant algorithms.” So this stops being a national security systems question and becomes a federal contracting question, on a proposed rule due the same December week.

Then there’s the document that tells agencies how to actually do it. OMB memorandum M-26-15 runs eleven pages of implementation guidance and cites FIPS 203, FIPS 204, FIPS 205, FIPS 186-5, FIPS 199 and FIPS 201. It never mentions the Cryptographic Module Validation Program, FIPS 140, or a validated module anywhere in the document. The word “validated” does not appear in it.

What the memo does ask for is discovery, and the discovery points the wrong way. Agencies are told to build “a dynamic, continuously updated inventory of all cryptographic assets” using software composition analysis and SBOMs, which is a thorough answer to the question of what you already run. Nothing in the stack answers what you’re allowed to buy.

What this costs

A federal buyer who has to demonstrate post-quantum compliance today has two real options. Read 676 PDFs, and read them knowing the table captions sit below the rows and that the same algorithm string means three different things in three different tables. Or buy on a vendor’s word and find out at validation whether they’d read their own policy the same way.

For two of the 676, even reading is off the table. Certificates 4955 and 4987 link to a security policy the same way every other certificate does. The link works. What comes back is a single page, 5,725 bytes, and its entire text is four words: Security Policy Not Available. The equivalent file for Kryptus runs to 1.9 megabytes.

Neither one is a search.

Where every number came from

Every figure above traces to one of these. All were pulled and read on August 15, 2026.

NIST CMVP validated modules search, the source of the 676 count and the missing post-quantum filter: https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search
NIST CAVP validation search, which does filter by post-quantum algorithm: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search
NSA, CNSA 2.0 FAQ, Ver 2.1, December 2024, for the algorithms, the parameter sets, the January 1 2027 CNSSP 15 acquisition language and the SLH-DSA exclusion: https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
Dr. Morgan Stern, NSA, Quantum Resistant Cryptography, Cryptologic Foundation conference, 17 March 2026, for the CNSSP-11 validation requirement and the 2027 timeline slide: https://cryptologicfoundation.org/wp-content/uploads/2026/03/Dr.-Morgan-Stern-QRC_NCF_Conf_20260317.published.pdf
Global Risk Institute, Quantum Threat Timeline Report 2025, the seventh edition, Dr. Michele Mosca and Dr. Marco Piani, evolutionQ, 26 experts surveyed, published March 9 2026. This supersedes the 2024 edition, whose ten-year range was lower: https://globalriskinstitute.org/publication/quantum-threat-timeline-report-2025b/
Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks, signed June 22 2026, published in the Federal Register June 25 2026, for the Section 6(b) CMVP acceleration order and the Section 6(c) FAR rule: https://www.federalregister.gov/documents/2026/06/25/2026-12909/securing-the-nation-against-advanced-cryptographic-attacks
OMB Memorandum M-26-15, Execution of the Migration to Post-Quantum Cryptography, June 2026, the implementation guidance that never mentions CMVP or FIPS 140: https://www.whitehouse.gov/wp-content/uploads/2026/06/M-26-15-Execution-of-the-Migration-to-Post-Quantum-Cryptography.pdf
Kryptus ASI-HSM AHX5 kNET security policy, certificate 5282: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp5282.pdf
Thales Luna T7 security policy, certificate 5450: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp5450.pdf
AWS-LC 3 security policy, certificate 5314: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp5314.pdf
Microsoft SymCrypt security policy, certificate 5313: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp5313.pdf
Apple corecrypto Module 18.3 security policy, certificate 5184: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp5184.pdf
Doug Finke, Chief Content Officer, Global Quantum Intelligence, email interview August 1 2026, attribution and correction cleared by him August 15 2026: https://www.global-qi.com/
The census itself, one row per module and one row per individual mention with line numbers and governing captions, plus the script that produced both: `caption-anchor-census.py`, `pqc-caption-census-2026-08-15.csv` and `pqc-caption-hits-2026-08-15.csv`

Lamar Rice

Editor, Laterstack