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.

Related Laterstack reporting: Post-Quantum Infrastructure Has a Three-Year Gap, Google Says Organizations Need Post-Quantum Cryptography by 2029, and US Government Mandates Post-Quantum Cryptography.

Lamar Rice
Editor, Laterstack

The Federal Government Just Put a Clock on Quantum Security

CISA Acting Director Madhu Gottumukkala did not soften the message. “The advent of quantum computing poses a real and urgent threat to the confidentiality, integrity, and accessibility of sensitive data,” he said on January 30, 2026, announcing new federal procurement mandates for post-quantum cryptography (PQC).

The guidance stems from President Trump’s Executive Order 14306, signed in June 2025. The directive is blunt: when a product category appears on CISA’s published list as having widely available PQC capabilities, federal agencies must procure only quantum-resistant products in that category. No exceptions. No phase-in.

What the Mandate Requires

CISA, working with the National Security Agency (NSA), published a list of hardware and software product categories where quantum-resistant alternatives already exist. Vendors selling to the federal government now face a binary choice — support PQC standards or lose access to the largest technology buyer on the planet.

The technical foundation rests on NIST’s finalized PQC standards from August 2024: FIPS 203 (ML-KEM) for general encryption, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) as a backup signature scheme. NIST selected HQC as an additional key encapsulation mechanism in March 2025, with a draft standard expected in early 2026 and finalization by 2027.

Key deadlines: TLS 1.3 adoption required by January 2, 2030. Full deprecation of quantum-vulnerable algorithms by 2035. The Office of the National Cyber Director projects the total government-wide migration cost at approximately $7.1 billion.

Follow the Money

The timing tracks. Quantum computing companies raised $3.77 billion in equity funding during the first nine months of 2025 — nearly triple the $1.3 billion raised in all of 2024. Q1 2025 alone pulled in over $1.25 billion, a 128% year-over-year surge.

PsiQuantum hit a $7 billion valuation after a $1 billion Series E led by BlackRock, Temasek, and Baillie Gifford. Government commitments globally reached $10 billion by April 2025, anchored by Japan’s $7.4 billion pledge. The market is projected to hit $20.2 billion by 2030 at a 41.8% CAGR. As we previously reported, quantum computing could break Bitcoin and change the future of crypto — and this mandate signals Washington agrees the timeline is accelerating.

The Threat Is Not Theoretical

New algorithmic improvements revealed in 2025 reduced the hardware requirements for breaking encryption by approximately 95% — where previous estimates suggested 20 million physical qubits, researchers now believe fewer than one million qubits could crack current encryption in less than a week. The security community calls the active threat “harvest now, decrypt later”: nation-states stockpiling encrypted government, financial, and health data today, betting they can crack it once quantum hardware matures.

Laterstack Editorial Take

Laterstack exists to sharpen critical thinking by connecting tech, policy, and power to everyday life — across class, industry, and influence. This mandate tells you everything about the real threat timeline if you read it correctly. Washington does not issue procurement mandates for science fiction. The lawmakers who signed Executive Order 14306 and the defense contractors scrambling to comply know the harvest-now-decrypt-later window is not 2035 — it is the last decade of data already sitting in adversary hands. The question for every CISO, every appropriations committee member, and every CEO selling to the federal government: who benefits from the migration timeline being this slow?

What This Means for Everyday People

If your bank, hospital, or cloud provider sells to the federal government — and most major ones do — they are now on the clock to upgrade their encryption. Every system that touches federal data must go quantum-resistant. That includes the infrastructure protecting your health records, financial transactions, and personal data. The Bitcoin selloff driven by tariff fears already showed how fragile digital financial systems are to external shocks. Quantum decryption would be orders of magnitude worse.

The Bottom Line

Washington does not mandate standards for hypothetical threats. The money is moving. The standards are finalized. The mandate is live. Post-quantum cryptography just shifted from a research project to a compliance requirement.

 

 

What is post-quantum cryptography and why does it matter now?

 

 

Post-quantum cryptography (PQC) uses encryption algorithms designed to resist attacks from quantum computers. It matters now because nation-states are already harvesting encrypted data with plans to decrypt it once quantum hardware matures — a strategy called “harvest now, decrypt later.”

 

 

 

 

When must federal agencies switch to quantum-resistant encryption?

 

 

Under Executive Order 14306, federal agencies must immediately procure quantum-resistant products in categories where CISA has identified widely available PQC options. TLS 1.3 adoption is required by January 2, 2030, with full migration to quantum-resistant cryptography by 2035.

 

 

 

 

How much has quantum computing funding grown?

 

 

Quantum computing companies raised $3.77 billion in equity funding during the first nine months of 2025, nearly triple the $1.3 billion raised in all of 2024. The global quantum computing market is projected to reach $20.2 billion by 2030.