Post-Quantum Cryptography: The Deadline Hiding in Your Compliance Roadmap

You don't need a quantum computer for quantum computing to become your problem this year

If you ask a room of executives when quantum computing will affect their business, most will say "five to ten years" — and then move on to the next agenda item. For nearly every category of quantum risk, that's a defensible answer.

For one category, it's already wrong.

The deadline that already started

In August 2024, NIST finalized its first set of post-quantum cryptography standards — FIPS 203, 204, and 205 — after nearly a decade of evaluation. That's the "the standards exist, there's no more waiting for them" milestone, and it quietly removed the most common reason organizations gave for not starting migration planning.

Those NIST standards are voluntary technical specifications — they define the algorithms. Separately, and on a much harder clock, the NSA's CNSA 2.0 framework sets actual mandates for US national security systems:

January 2027 — software and firmware signing must move to exclusive use of quantum-safe algorithms, in CNSA 2.0 contexts.

2030 — quantum-safe algorithms required across applications more broadly, in CNSA 2.0 contexts.

2033 — operating systems, custom applications, and cloud services reach exclusive use of CNSA 2.0.

2035 — full quantum resistance required across national security systems, per NSM-10.

Read those dates again. The first one is next year.

If you're not a US federal agency or a defense contractor, your instinct might be that this doesn't apply to you. Two things make that instinct wrong, or at least premature.

First: compliance cascades. CNSA 2.0 is a national security mandate, but if your organization sells into government, defense, healthcare, financial infrastructure, or critical infrastructure supply chains — directly or as a vendor's vendor — these requirements tend to flow downstream as procurement and certification requirements long before they're legally mandated for you specifically.

Second, and more importantly: harvest now, decrypt later.

The retroactive deadline

A sufficiently capable quantum computer would be able to break the public-key cryptography (RSA, ECC) that currently protects most encrypted data in transit and at rest. Nobody credible is claiming that computer exists today. But here's the thing: an adversary doesn't need it today. They need it whenever it arrives — and they can harvest your encrypted data now, store it, and decrypt it retroactively the moment the capability exists.

For data with a short shelf life, this is a non-issue. For data that needs to remain confidential for years — M&A plans, health records, IP, government communications, long-term financial positions, anything with a "still sensitive in 2035" quality — the relevant question isn't "when will quantum computers be able to break encryption." It's "how long does this specific data need to stay confidential, and is that longer than the time it'll take us to migrate."

For a lot of data categories, the answer to that comparison is already uncomfortable. Which means the encryption decisions your organization is making this week are decisions with a quantum-era deadline attached, even though no quantum computer is involved.

What this actually requires — and what it doesn't

This is not a "buy quantum-safe technology" initiative. The algorithms are classical. They run on the computers you already have. This is a cryptography migration — closer in nature to a TLS version upgrade or a certificate authority transition than to any kind of quantum procurement.

It is, however, a genuinely large migration for any organization with cryptography embedded across legacy systems, third-party software, hardware security modules, and supply chain dependencies — many of which the organization doesn't have a complete inventory of. The risk of waiting isn't symmetric: starting the migration eighteen months before you strictly need to costs you a structured program with reasonable timelines. Starting it eighteen months after a hard deadline costs you a crisis program, likely under regulatory or customer scrutiny.

What to put in motion this quarter

Cryptographic inventory — where, and how, does the organization currently use public-key cryptography? Most organizations don't have a complete answer.

Data-retention review — which data categories need to remain confidential past 2030–2035, and what's currently protecting them?

Vendor questionnaire updates — does your third-party risk process ask about PQC migration plans yet? It will be a standard question soon.

Migration roadmap — even a rough, multi-year sequencing plan is the difference between a tracking item and a future crisis program.

The board-level question

If I were putting one question on a board agenda this quarter, it would be this: "Do we have a current inventory of where and how we use public-key cryptography, and a migration plan with a timeline — even a rough one?"

If the answer is yes, this is a tracking item, not a crisis. If the answer is "I'd need to check," that's worth knowing now rather than in a regulatory inquiry eighteen months from now, when "I'd need to check" stops being an acceptable answer.

The irony of post-quantum cryptography as a topic is that it's the most concrete, near-term, budgetable consequence of quantum computing — and it's also the one most likely to get lost in conversations about qubit counts and architecture races, because it doesn't sound like quantum computing. It sounds like IT infrastructure. Which is exactly what it is, and exactly why it's the first quantum-era deadline most organizations will actually hit.

Originally published on LinkedIn on July 7, 2026.