The Clock on Your Cryptography Is Already Running

Steampunk clocktower with quantum state symbols, counting down to the Dec 31, 2031 deadline

There’s a peculiar property of cryptography that makes it unlike almost any other technology you’ll ever migrate: it can fail retroactively.

Your database can’t be breached in the past. Your firewall can’t be bypassed last year. But every encrypted packet you’ve ever transmitted is, potentially, sitting in an adversary’s storage array right now, waiting for the day the math that protects it stops working. The intelligence community has a name for this: “Harvest Now, Decrypt Later”. Collect the ciphertext today, break it when the hardware catches up.

That hardware is a cryptographically relevant quantum computer (CRQC) — a machine capable of running Shor’s algorithm at scale against the public-key cryptography that underpins nearly everything: TLS handshakes, code signing, PKI, VPNs, firmware updates, secure boot. Nobody can tell you the year it arrives. But in 2026, the U.S. Department of War published its Post Quantum Cryptography Strategy and did something more useful than predicting a date: it set deadlines anyway. All systems must support post-quantum cryptography by the end of 2030, and must use it by the end of 2031.

You don’t have to run a weapons program for those dates to matter to you. The strategy is one of the clearest public case studies we have in what it actually takes to migrate cryptography across a massive, heterogeneous, safety-critical enterprise — and the failure modes it warns about are the same ones waiting inside your fintech stack, your medical device fleet, or your IoT product line.

Here’s what it teaches.

Mosca’s inequality: if data shelf life plus migration time exceeds the time to a quantum computer, you are already exposed

Lesson 1: You cannot migrate what you cannot see

Ask any engineering team “where do we use RSA?” and watch the confidence drain from the room.

Cryptography is not a component you installed once. It’s a substrate. It’s in your TLS libraries, yes — but it’s also in your firmware signing pipeline, your license validation, your JWT tokens, your database’s transparent encryption, the TPM on every laptop, the HSM in your data center, the vendor SDK you linked five years ago, and the embedded controller from a supplier who has since been acquired twice.

This is why the first and most important artifact of any post-quantum program is a cryptographic inventory — increasingly called a Cryptographic Bill of Materials, or CBOM, by analogy to the software bill of materials. The DoW strategy makes inventory its own line of effort, mandated before roadmaps, before prioritization, before anything. The logic is brutal and correct: quantum resistance isn’t achieved when you deploy new algorithms. It’s achieved only when the vulnerable ones are fully deprecated across the entire data pathway — supply chain, development, at rest, in transit. One legacy RSA dependency buried in a mission thread, and the thread isn’t quantum resistant. Full stop.

For most organizations, the honest starting position is: you don’t know where your cryptography lives. Automated cryptographic discovery tooling exists and is maturing fast. Start there. Everything else is downstream of the map.

Lesson 2: The new algorithms are heavier, and physics doesn’t negotiate

The good news: the replacement math exists. NIST has standardized lattice-based algorithms — ML-KEM (Kyber) for key establishment and ML-DSA (Dilithium) for signatures — and the NSA’s CNSA 2.0 suite tells U.S. national security systems exactly which parameter sets to use.

The less-good news: these algorithms are not drop-in replacements at the systems level. An ML-KEM-1024 public key is roughly 1,500 bytes where an ECDH P-256 key was 65. ML-DSA signatures run several kilobytes where ECDSA signatures were dozens of bytes. For a web server, this is a rounding error. For a constrained embedded processor, a satellite link with a tight power budget, a tactical radio, a smart meter, or a medical implant, it can blow the size, weight, power, and latency budget entirely.

This is where cryptographic migration stops being a security project and becomes a systems engineering project. Handshakes get bigger. Certificate chains get bigger. Firmware images carrying signed updates get bigger. If your protocol assumed a signature fits in one radio frame, that assumption is now a design review. The organizations that benchmark PQC primitives on their actual target hardware early will make quiet, cheap adjustments. The ones that don’t will discover the problem in integration testing, where every fix costs ten times more.

Bar chart comparing classical and post-quantum public key and signature sizes on a log scale

Lesson 3: Crypto-agility is the real requirement — the algorithm is almost incidental

Here’s an uncomfortable thought: ML-KEM and ML-DSA might not be the last word either. Lattice cryptography is well-studied, but well-studied is a statement about the past. The deeper lesson of the quantum transition is that “any” algorithm can age out — and the organizations suffering most right now are the ones who hard-coded their crypto in the 1990s and 2000s.

The strategic answer is cryptographic agility: architecting systems so algorithms are swappable without redesigning the system around them. Concretely, that means abstraction layers between application logic and cryptographic primitives, field-updatable cryptographic modules, and protocol-level algorithm negotiation. If your product can’t change its cryptography with a software update, you haven’t migrated — you’ve just scheduled your next crisis.

One critical caveat the defense strategy nails: agility mechanisms are themselves attack surface. Algorithm negotiation invites downgrade attacks, where an attacker-in-the-middle convinces both ends to fall back to the broken legacy suite. Your test program needs to actively attempt downgrades — at every proxy, load balancer, and traffic-inspection middlebox — because any intermediate device that permits fallback silently defeats the entire migration.

Layered architecture diagram showing application logic, a cryptographic abstraction layer, and swappable algorithm modules, with a downgrade-attack warning

Lesson 4: Beware the shortcuts — some “quantum-safe” is neither

Under deadline pressure, tempting shortcuts appear. The DoW strategy explicitly bans several, and its reasoning generalizes:

Pre-shared symmetric keys as a quantum fix. Symmetric cryptography (AES-256) is indeed quantum-resistant, so why not just distribute pre-shared keys everywhere and skip the hard asymmetric migration? Because key distribution at scale without asymmetric cryptography reintroduces the exact key-management nightmare that public-key crypto was invented to solve — and every new node with access to keying material is new attack surface.

Quantum Key Distribution (QKD). It sounds like the obvious answer — fight quantum with quantum — and vendors market it aggressively. But QKD requires specialized point-to-point hardware, doesn’t authenticate anything, doesn’t scale like software, and adds new trusted components to your architecture. The strategy’s position is blunt: quantum communication technologies will not be used as a security solution for quantum resistance. Post-quantum cryptography is math, not hardware, and math deploys everywhere.

PQC proxies. Wrapping a legacy system in a quantum-safe tunnel at the network edge feels like compliance. But the vulnerable cryptography still runs inside, the data pathway is only partially protected, and you’ve added an appliance with access to everything. Proxies can be an interim mitigation with an expiration date — never the destination.

The common thread: a migration that introduces new security risks while chasing quantum risk is a net loss. Confidentiality-only migrations that skip authentication don’t count either — forged signatures on a firmware update are every bit as catastrophic as decrypted traffic.

Lesson 5: The bottleneck is people and process, not math

The final lesson is the least technical and the most predictive of success. In the defense world, the pacing constraints are certification queues, supplier readiness, and funding cycles that move slower than the mandate. In the commercial world, swap in vendor roadmaps, compliance audits, and the fact that your crypto is mostly “other people’s code”.

Your TLS is OpenSSL’s problem until it’s yours. Your hardware root of trust is your TPM vendor’s roadmap. Your cloud provider’s KMS, your CDN’s handshake, your SaaS vendors’ token signing — your post-quantum posture is the intersection of a dozen supply chains you don’t control. The practical countermeasure is contractual and organizational: put PQC readiness into procurement language now, demand cryptographic transparency from suppliers, and assign actual ownership. Cryptography that belongs to everyone is maintained by no one.

And triage honestly. Not everything migrates. Some systems get upgraded in place, some get re-platformed, and some — this is the option teams forget they have — get a retirement date instead of a migration plan. Sunsetting a legacy service by the deadline is a fully legitimate quantum-resistance strategy.

Flow diagram from inventory to triage to three outcomes: migrate in place, re-platform, or retire the service, with guardrails listed below