What the 2026 post-quantum mandates require, and where Starlight already fits

This spring the government turned post-quantum cryptography from a planning topic into a set of dated obligations. The Department of War published its Post Quantum Cryptography Strategy on April 1, 2026, signed by the DoW CIO. Ten weeks later, on June 22, the White House issued two executive orders, one on securing federal systems against advanced cryptographic attacks and one on US quantum innovation. We have a new whitepaper out on how Starlight maps to all three, and this is the short version of why they matter and where we already line up.

The threat all three documents are answering

Post-quantum cryptography, or PQC, means encryption and digital-signature algorithms that run on the ordinary processors we field today but are designed to survive attack by a future quantum computer. The specific concern has a name that appears word for word in both the DoW strategy and the White House order: harvest now, decrypt later. An adversary does not need a working quantum computer this year to do damage. It can record your encrypted traffic now, store it, and decrypt it later once what the strategy calls a cryptographically relevant quantum computer, a CRQC, exists. Anything with a long secrecy life, weapons telemetry, intelligence product, personnel data, is already exposed to collection that is happening today.

The deadlines, and who they reach

The DoW strategy sets two hard dates. By December 31, 2030, every DoW system has to support PQC or be retired. By December 31, 2031, every DoW system has to actually use it. National security systems are pointed at a specific algorithm set, the NSA's Commercial National Security Algorithm Suite 2.0, or CNSA 2.0.

The June executive order on cryptographic attacks puts federal civilian systems on a parallel timeline, and it directs a change to the federal acquisition rules so that covered contractors must meet the NIST standards, post-quantum algorithms included, by the end of 2030. If you build for defense, this migration is moving into your contract language whether or not you went looking for it.

Those NIST standards are concrete, not theoretical. ML-KEM (FIPS 203) covers key establishment, the step where two parties agree on a shared secret. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) cover digital signatures, which is how a system proves that a software update or a message is authentic and unaltered. They are built to drop into the same places RSA and elliptic-curve cryptography sit now. The strategy's Commercial Solutions Track is, at bottom, a plan to pull these algorithms into commodity IT, the operating systems, browsers, and network gear that most systems already run, instead of building everything as custom high-assurance hardware.

Three things in the DoW strategy worth planning around

The strategy changes how you should plan, not only when, and a few points deserve attention.

The first is what it calls vulnerability deprecation. Turning on PQC is not the finish line. The strategy counts a mission thread as quantum resistant only once the vulnerable algorithms are gone from the entire data pathway, supply chain and build pipeline and data-at-rest and data-in-transit included. One legacy library left in the chain keeps the whole thread exposed. That turns the job from "add PQC" into "find and account for every place cryptography lives," which is a far larger inventory problem than most programs expect.

The second is the warning not to trade one risk for another. A migration that covers only confidentiality, without moving authentication to PQC as well, does not count as finished. The strategy also tells planners to avoid introducing new entities or network points that touch keying material, and it names several approaches it treats as dead ends for quantum resistance, including quantum key distribution and non-local quantum randomness generation. Defense vendors should read that list carefully.

The third is cryptographic agility, the requirement that systems be built so algorithms can be swapped again later without re-architecting. Today's choices are a first move, and the government wants room to change them as the analysis matures.

Where Starlight sits

Starlight is a PQC-ready operating system, which is one of the explicit objectives under the strategy's Commercial Solutions Track. It ships the NIST post-quantum suite, ML-KEM, ML-DSA, and SLH-DSA, so the algorithms every one of these mandates points to are in the platform today rather than on a roadmap.

Because Starlight is built as an immutable, image-based operating system, every node is a known, versioned artifact. The cryptographic inventory the strategy demands becomes something you read off the image instead of discovering host by host, and that same property feeds the cryptographic bill of materials the June order asks CISA to define. Starlight Secure, the hardened variant, gives programs a FIPS-aligned baseline to build on. And because the platform is designed for the edge and for disconnected or contested networks, it lands directly on the secure edge systems the strategy calls out as a deployment priority.

Starlight also strengthens what sits underneath the keys. Key generation depends on high-quality randomness, called entropy, and entropy runs thin on freshly booted, headless, or disconnected machines, which is the normal state of things at the tactical edge. Starlight builds quantum entropy from Qrypt into the operating system itself, so every node generates its keys locally from a pool that already includes a quantum-sourced, US-built input. Nothing has to be fetched from an outside service at runtime, which is what you want on a system that may operate disconnected for long stretches. We treat the quantum entropy as defense in depth around local key generation, with the NIST algorithms carrying the compliance weight.

The point of the whitepaper

The whitepaper takes each requirement above and maps the exact mandate language to the platform feature that answers it. For a program facing the 2030 and 2031 deadlines, the real question is how much of the migration you can inherit from the platform you field on, instead of building it yourself. That is the case we lay out.

Read the whitepaper →