Why We Shipped Post-Quantum Crypto on Day One

Post-quantum encryption is not a future concern. It is a current procurement requirement for any system that will still be running in 2030.

What’s actually happening

The NSA published a schedule for moving every federal system off today’s encryption and onto a new, quantum-resistant kind. The schedule is published, dated, and binding:

• 2025 — deadline for code signing (already past)
• 2027 — deadline for networking equipment
• 2030 — deadline for general-purpose computing
• 2033 — full cut-over; the old encryption is no longer acceptable
• 2035 — a White House memo makes the new encryption a national mandate

Any system designed today that will outlive 2030, and is not already built for encryption that can be swapped out without rewriting the code, is on borrowed time.

Why changing it later is expensive

When the federal government moved from an older encryption standard to the current one (AES), retrofit studies found that the all-in cost was roughly ten times the cost of designing for it up front.

That multiplier came from three things stacking up:

• Every piece of software that encrypts traffic had to be rebuilt or reconfigured. There are always more of these than anyone remembers.
• Every signing path — for releases, for audit records, for configuration snapshots — had to switch to the new algorithm, and every piece of software downstream had to learn the new keys.
• Every piece of signed evidence accumulated under the old algorithm had to be re-signed, or the verification chain downstream broke.

The new post-quantum encryption is worse than that move on every dimension. The new keys and signatures are much larger — roughly ten times larger for some pieces, and more than a hundred times larger for others. That means every system that stores, transmits, or verifies them has to be re-sized for them.

You do not want to find this out in 2029.

What we built instead

We designed the substrate around three pieces, and they all went in on day one.

A wrapper that makes the algorithm swappable. Every service in Writ calls a shared crypto library, not a specific algorithm. Swapping algorithms is a configuration change, not a code change. Every service also emits a machine-readable record of which algorithms it’s currently using — so when the next migration happens, the starting state is already documented.

Post-quantum TLS at the edge, on by default. When a user’s browser or another system talks to Writ over the public internet, the encryption is already the quantum-resistant kind. If the other side doesn’t know the new algorithm, it falls back to the classical kind — so nothing breaks. But the default is the new kind. We migrated the outward-facing edge first because that’s where eavesdropping-and-storing-for-later is a real threat.

Quantum-resistant signing across the release pipeline. Every image we ship, every list of software components, every piece of audit evidence, is signed with the new algorithms. The fleet’s master signing key — the root of the whole chain — is hash-based (a kind of signature that quantum computers don’t weaken), lives on an offline piece of hardware, and never touches the network.

Where we are compared to the rest of the field

IBM is the only platform vendor meaningfully ahead of us on this, and only in a narrow way — they sell a closed platform, and their accreditation ceiling is lower than ours, so they aren’t a substitute for the audience we serve. But they have roughly a two-year head start in their control plane.

We match them in the control plane within twelve months. The internal parts of our platform — where services talk to each other — move to post-quantum encryption by default in 2027. By 2028, we’ll have four-plus years of records showing which algorithm was in use when, which is exactly what an auditor wants to see.

Behind us: Google Cloud’s post-quantum support is targeted for 2029. Cloudflare is targeting 2029. AWS and Azure’s government clouds are partial. When the 2027 deadline lands, they will be scrambling.

Any award being written today can require post-quantum encryption. Writ is already shipping it.

What “post-quantum-native” means on paper

For anyone comparing us to a competitor’s roadmap:

• Outward-facing encryption: the new quantum-resistant kind (hybrid X25519 + ML-KEM-768) on by default, with a classical fallback for systems that don’t know the new algorithm yet.
• Service-to-service encryption inside the platform: the new kind opt-in today; default in 2027.
• Signing for software releases and audit records: the new quantum-resistant kind (ML-DSA-65).
• The master signing key for the whole fleet: a hash-based algorithm (SLH-DSA), on an offline piece of hardware, never on the network.
• Algorithm swapping: a configuration change, not a code change.

None of these are future promises. They’re all in v0.1.

If you’re writing an award right now

The procurement language that locks this in:

“Offeror shall demonstrate hybrid post-quantum key exchange (for example, X25519 + ML-KEM-768 or equivalent) on all tenant-facing and inter-enclave encrypted endpoints at award. Offeror shall publish a Crypto Bill of Materials (CycloneDX 1.6 or equivalent) per release, and shall demonstrate a crypto-agility configuration pathway to CNSA 2.0 compliance without source-code modification.”

Writ answers every clause in that paragraph with yes, today. Not on a roadmap. Today.