📢 New post: A Deadline in 2030 That Starts in 2026: The Post-Quantum EO and the Crypto Nobody Inventoried · 📝 Also fresh: When the AI Itself Is the Thing That Isn't on the List: M-25-21 and High-Impact AI · 🚦 Beacon — the FedRAMP 20x KSI emitter — design partners open ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
CryptographyFedRAMPCISACompliance

A Deadline in 2030 That Starts in 2026: The Post-Quantum EO and the Crypto Nobody Inventoried

We've spent a run of posts watching short clocks start — a KEV listing inheriting a federal due date, BOD 26-04 sorting a vulnerability into a three-day band. This one is different in shape. The deadline is years out, and the temptation is to file it under "later." We'd argue the opposite: it's the kind of clock where the work has to start now precisely because the date is distant.

On June 22, 2026, the White House signed Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks." It takes what had been aspirational timelines for migrating federal systems to post-quantum cryptography (PQC) and turns them into dated mandates — and, through the Federal Acquisition Regulation, extends the schedule to the contractors who sell to government.

What the order actually does

The headline dates are firm. Federal agencies must transition their most sensitive systems to post-quantum encryption by December 31, 2030, and to post-quantum authentication by December 31, 2031. Each agency designates a PQC migration lead. Federal contractors are directed to comply with the post-quantum FIPS standards by the end of 2030 — the standards being NIST's FIPS 203 (ML-KEM), 204 (ML-DSA), and 205 (SLH-DSA), finalized last year.

There's a nearer date worth marking too, independent of the EO but pointing the same direction: NIST's CMVP is scheduled to move the remaining FIPS 140-2 module certificates to Historical status on September 21, 2026, after which only FIPS 140-3 validated modules are accepted for new federal procurement. If your boundary leans on a module that hasn't made the jump, that's a 2026 problem, not a 2030 one.

The threat model the order names out loud is the reason none of this can wait for the deadline: "harvest now, decrypt later." An adversary doesn't need a working quantum computer today to hurt you today. They need only to capture your encrypted traffic and archives now and hold them until the hardware catches up. Any data whose sensitivity outlives the gap — health records, identity material, long-lived secrets, anything classified — is effectively being exposed the moment it crosses a wire still protected by classical key exchange. The 2030 date is when the migration must be done; the risk is accruing now.

The part we want to dwell on: a cryptographic bill of materials

Buried in the order is the provision we find most telling. Within 270 days, CISA — with NIST — is directed to publish guidance on the minimum elements for a cryptographic bill of materials (CBOM): a machine-readable accounting of the cryptographic assets a piece of hardware or software uses, explicitly meant to enable the automated assessment of where and how cryptography is deployed.

If that sounds familiar, it should. It's the same argument we keep landing on, in a new domain. You cannot migrate cryptography you have never enumerated — and cryptography is the most thoroughly buried thing in any estate. It isn't a tidy list of "our crypto." It's the TLS termination on every load balancer, the SSH on every host, the certificates with their own expiry calendars, the algorithm baked into a vendor appliance's firmware, the library a service pulled in three dependencies deep, the hardcoded cipher suite nobody has looked at since the service shipped. Most organizations cannot answer "where do we use RSA-2048 for key establishment?" in less than a quarter of manual archaeology.

The CBOM is the government's bet that the only way through a migration this wide is to make the inventory automated and continuous rather than a one-time survey. We think that's exactly right, and not only for crypto. The same move — discovery you can run on demand instead of reconstruct by hand — is what turns every compliance deadline from a scramble into a query.

If you're inside a FedRAMP boundary

For a cloud service offering, post-quantum readiness lands on ground that's already mapped. SC-13 has always required FIPS-validated cryptographic protection; the EO and the FIPS 140-3 transition simply move what counts as "validated" underneath you. The work that satisfies the new expectation is recognizable:

  • Can you produce a cryptographic inventory at all? Not an architecture diagram of how you intended to do crypto, but a current accounting of the algorithms, key sizes, certificates, and modules actually in use across the boundary. If assembling that means emailing service owners, the CBOM guidance is going to formalize a gap you already have.
  • Which of it is quantum-vulnerable, and where does it protect long-lived data? That intersection — classical key exchange in front of data that still matters in 2035 — is where harvest-now-decrypt-later turns abstract. It's the prioritization that should run first.
  • What's the evidence trail? The inventory itself, the migration plan against the 2030/2031 dates, the module-validation status, the points where you've moved to ML-KEM and ML-DSA. As always, the artifact that survives the next assessment is the trail, not the intention.

None of this is exotic. It's the evidence-as-byproduct posture we've described before, pointed at a different control family.

The unglamorous capability, again

What makes a 2030 deadline calm instead of frantic is the same thing that made a KEV clock survivable: knowing what you have, in a form you can query the morning the requirement lands. A cryptographic inventory that answers in seconds. Long-lived-data sensitivity attached to the systems that hold it, so the harvest-now-decrypt-later prioritization sorts itself. The migration evidence collected as a normal byproduct of operating, not assembled the week before an assessor asks.

That's the shape of work the Novaprospect audit engine is built around — infrastructure-native discovery that finds the cryptography nobody wrote down, the same way it finds the proxy and the controller nobody wrote down. A CBOM is, in the end, just another inventory the environment should be able to produce about itself. The organizations that sail through 2030 will be the ones who could already answer "where is all our crypto?" long before an executive order made it a question with a due date.

Reference