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 standalone, 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 U.S. federal government is targeting the transition away from vulnerable public-key cryptography by around 2030, according to NIST and NSA guidance. SEALSQ’s QSOC constellation targets full operational capability in 2033. That is roughly a three-year window where a globally available, sovereign-grade satellite answer does not yet exist, and SEALSQ Corp, a small Nasdaq company, is among those racing to build one.

What QSOC Actually Is

The Quantum Spatial Orbital Cloud is a 100-satellite low-Earth-orbit constellation jointly operated by SEALSQ and WISeSat.Space, both subsidiaries of WISeKey International Holding. The deployment runs from now through 2033, when SEALSQ targets Full Operational Capability. As of June 2026, 21 satellites are already in orbit. The constellation is designed to deliver quantum key distribution, quantum random number generation, and post-quantum identity services as a subscription offering to enterprises and governments worldwide.

Carlos Moreira, SEALSQ’s CEO, told Laterstack the recent Miraex acquisition “strengthens our execution capabilities and enhances vertical integration across critical components of the ecosystem.” The company “does not foresee any material delay to the deployment roadmap.”

That is the on-record commitment to 2033. The cryptography migration timeline, meanwhile, does not move.

The Three-Year Gap

NIST’s post-quantum cryptography migration guidance points to 2030 as the practical window for federal contractors to begin retiring RSA-2048 from production systems. The NSA’s CNSA 2.0 suite references the same window, and FedRAMP guidance points at it. Several studies published in 2025, which Laterstack covered, suggested that advances in quantum computing could compress estimates for when RSA-2048 becomes vulnerable, raising concern about the 2030 transition timeline.

QSOC reaches Full Operational Capability in 2033. That gap is roughly three years where federal customers know they have to migrate and a globally available, sovereign-grade satellite-based post-quantum infrastructure may not yet exist. It is a window that does not appear on the FedRAMP procurement calendar, in CNSA 2.0, or in NIST’s published migration guidance.

The trade press has covered the cryptographic timeline. It has covered the QSOC deployment. In our reading, it has not yet connected the two.

Who QSOC Is Built For

Moreira would not name specific QSOC customers, citing confidentiality. He did name the five buyer categories SEALSQ is actively engaged with: government agencies, defense and security organizations, sovereign digital infrastructure operators, critical infrastructure providers, and financial institutions. The demand, he said, is being driven by “the growing need for quantum-resilient communications, trusted digital identities, and secure data sovereignty solutions in preparation for the post-quantum era.”

Five buyer classes is a market structure, not a customer list. It is the slate of federal-and-equivalent purchasers every G7 procurement office is preparing for, and SEALSQ is positioning itself as one of the few companies publicly pursuing all five segments through a single integrated platform.

Trust Infrastructure Root to Qubit

Moreira sums up what SEALSQ is building in a single phrase: “an end-to-end trust infrastructure root to qubit.” In plain terms, that is one company running the whole chain, the chips, the digital identities, the satellites, the networks, and the cloud that ties them together.

That matters because most of the industry has not built it that way. Companies like IBM, Cisco, and Toshiba are strong in specific parts of the post-quantum puzzle. SEALSQ is betting on putting all of those parts under one roof. Moreira expects the market to move his way. He told Laterstack he sees “increasing consolidation and partnerships across the industry as organizations recognize that post-quantum security is not a standalone product but an ecosystem challenge.”

That is the bet underneath the satellite race. The way we read it, one of two things happens. Either the all-in-one approach proves right and SEALSQ becomes a serious early player in post-quantum infrastructure for governments and large institutions, or a bigger company copies the model, buys its way to the same setup, and SEALSQ ends up as the one that proved it could work.

What It Means For The Apps You Use

Most consumers will not interact with QSOC satellites directly. The infrastructure runs above the apps, not inside them. If you have a bank account, government benefits, healthcare records, or any service that depends on encryption for privacy, that encryption is on the migration calendar.

The banks, insurance carriers, and healthcare providers that move early on post-quantum infrastructure are better positioned to maintain trust after 2029. Institutions that delay migration may face significantly higher long-term security risks.

Consumers will likely see more banks, insurers, and healthcare providers publicly communicating their post-quantum migration strategies in the years ahead.

The Prediction

The bigger question is whether the major vendors adopt a similar approach. IBM, Cisco, and Toshiba all have the balance sheets to do it, and none has moved publicly so far. If the integrated-stack thesis proves correct, larger vendors may feel growing pressure to pursue similar strategies through partnerships, acquisitions, or internal development.

In our reading, the consolidation question is tied to which institutions maintain trust past 2029. The three-year gap, from the roughly 2030 transition target to QSOC’s 2033 timeline, is the procurement officer’s planning problem more than the cryptographer’s. Watch the procurement orders as much as the press releases.

Either way, post-quantum infrastructure is moving from a research milestone into a procurement question.

Frequently Asked Questions

What is the Quantum Spatial Orbital Cloud (QSOC)?

QSOC is a planned 100-satellite low-Earth-orbit constellation jointly operated by SEALSQ and WISeSat.Space, both subsidiaries of WISeKey International Holding. It is designed to deliver quantum key distribution, quantum random number generation, and post-quantum identity services as a subscription offering. Deployment runs from now through 2033, when SEALSQ targets Full Operational Capability. As of June 2026, 21 satellites are already in orbit.

Who is SEALSQ Corp?

SEALSQ Corp (Nasdaq: LAES) is a Geneva-based semiconductor and quantum technology company, and a subsidiary of WISeKey International Holding. Carlos Moreira is the CEO.

What is the 2030 cryptographic migration window and why does it matter?

NIST’s post-quantum cryptography migration guidance points to 2030 as the practical window for federal contractors to begin retiring RSA-2048 from production systems. The NSA’s CNSA 2.0 suite and FedRAMP guidance reference the same window. Several studies published in 2025 suggested that advances in quantum computing could compress estimates for when RSA-2048 becomes vulnerable, raising concern about the 2030 transition timeline.

What are the main alternatives to QSOC for post-quantum satellite infrastructure?

Companies like IBM, Cisco, and Toshiba are strong in specific parts of the post-quantum puzzle, but none has publicly committed to a sovereign satellite-grade post-quantum infrastructure deployment. SEALSQ is positioning itself as one of the few companies publicly pursuing the full integrated stack: semiconductors, identities, satellite communications, quantum-resilient networks, and trusted cloud services.

Related Stories:

Lamar Rice
Editor, Laterstack