Post-Quantum Cryptography: What It Is and When to Start Migrating

Post-quantum cryptography is a set of encryption algorithms built to survive attacks from quantum computers. NIST finalized the first three in August 2024. Federal systems and contractors must move by December 31, 2030. You've probably heard the phrase in a board meeting, on a prime contractor's supplier questionnaire, or buried in a cyber insurance renewal. Post-quantum. Quantum-safe. Quantum-resistant. Same idea, three labels.

What makes it urgent isn't the quantum computer. Most companies frame this as a technology problem that shows up on some future date, and plan accordingly, which is to say they don't plan at all. It's a data problem that started years ago. Anything encrypted and copied off your network today can sit in an archive until the math catches up. Your contracts. Your drawings. Your CUI, the controlled unclassified information a defense contract obligates you to protect. Encryption doesn't expire, but your protection does, and that gap is where a managed cybersecurity program either has an answer or doesn't.

Calendar's filled in fast. Standards landed in 2024. A federal deadline landed in June 2026. And on September 21 of this year, a validation deadline hits that has nothing to do with quantum computing and everything to do with whether your encryption still counts as compliant.

What is post-quantum cryptography?

Post-quantum cryptography replaces the encryption math that quantum computers can break. RSA and elliptic curve cryptography both rest on problems a large quantum computer solves quickly. The replacements rest on problems it doesn't.

Worth being precise about what's actually at risk, because the panic version of this story overstates it. Symmetric encryption, the kind protecting data sitting on a drive, survives. AES-256 stays fine. What breaks is public-key cryptography, the part that lets two systems that have never met agree on a secret and prove who they are, and it breaks because a quantum computer running Shor's algorithm solves the factoring and discrete-logarithm problems underneath RSA and ECC in hours instead of the billions of years a classical machine would need. Key exchange and digital signatures. That's the whole exposure. Two things.

Which sounds narrow until you list what depends on it. Every HTTPS session. Every VPN tunnel. Every code-signing certificate. Your internal certificate authority, your SSH keys, your firmware updates, your MFA tokens, the TLS between your ERP and the shop floor. If you want the underlying physics, we covered how quantum computing works separately. This post assumes you've already accepted the premise and want to know what to do about it.

The three standards NIST actually finalized

After an eight-year public competition, NIST published its first three post-quantum standards in August 2024. These aren't proposals. They're federal standards with FIPS numbers.

Two more are coming. HQC was selected in March 2025 as a second key-exchange option deliberately built on unrelated math, insurance in case someone finds a crack in the lattice approach both ML-KEM and ML-DSA share. FIPS 206, the FN-DSA signature standard, is expected to finalize around late 2026 or early 2027.

You don't need to understand lattices. You need to know that ML-KEM is the one that shows up first in real products, because key exchange is where harvest-now-decrypt-later bites, and because swapping a key exchange doesn't require reissuing every certificate you own.

Why waiting for a quantum computer is the wrong trigger

Because the attack starts before the computer exists. Encrypted traffic captured today can be stored and decrypted years later. Security teams call it harvest now, decrypt later. The data you send this week is the target.

An adversary doesn't need a working quantum computer to start. They need storage, patience, and a tap on traffic that matters. Three cheap things. Nation-state programs have all of them in abundance, and the cost of hoarding encrypted traffic against a maybe is trivially low compared to what's inside it. For a defense supplier moving CUI between a prime, three subs, and an engineering share controlled under ITAR, the arms-export rules governing who may see defense technical data, that traffic has a shelf life measured in program lifecycles.

In 2019, Google's Craig Gidney and Martin Ekerå at KTH estimated that breaking a 2048-bit RSA key would take roughly 20 million noisy qubits running for 8 hours. In May 2025, Gidney published a revised estimate. Under 1 million qubits, in under a week. A 20-fold reduction in six years, from the person best positioned to know.

Nobody has built either machine. That's not the point. The point is which direction the estimate keeps moving, and it has never once moved the other way. Every serious forecast now puts a cryptographically relevant quantum computer somewhere in the 2030 to 2035 window, and every revision to date has pulled that window closer rather than pushing it out.

So the honest framing isn't "when will quantum break encryption." It's "how long does the data I'm sending today need to stay private, and does that number reach past 2032?"

Which deadlines already have your name on them

Four dates matter before 2031, and two more set the outer boundary. FIPS 140-2 certificates go historical on September 21, 2026. CNSA 2.0 gates national security acquisitions January 1, 2027. Federal contractors face December 31, 2030.

These aren't all the same kind of deadline, and treating them as one blob is how companies end up either panicking about a procurement gate that doesn't apply to them or ignoring a legal obligation that does. Some are procurement gates. Some are risk-acceptance thresholds. One is law.

Sources: NIST CMVP FIPS 140-3 transition, NSA CNSA 2.0, and Executive Order 14412.

That deprecated-versus-disallowed distinction in NIST IR 8547 is the one most people skim past, and it's the one that determines your real deadline. Deprecated is survivable. You write the memo, your CISO signs it, you move on. Disallowed isn't. And the frameworks that borrow from NIST tend to borrow the disallowed list first.

What CMMC does and doesn't require today

Straight answer, because there's a lot of vendor noise on this one. Post-quantum cryptography is not a CMMC Level 2 assessment requirement right now. NIST SP 800-171 Rev 2, which CMMC Level 2 assesses against, requires FIPS-validated cryptography for CUI. It does not require post-quantum algorithms.

What's coming at you is the FIPS 140-3 transition. If a module protecting your CUI carries a 140-2 certificate, that certificate goes historical in September, and your next assessment or contract renewal is where that surfaces. Any vendor telling you that CMMC mandates post-quantum today is selling ahead of the standard. If you're working through the underlying controls, our breakdown of how NIST 800-171 maps to CMMC covers the assessment mechanics, and CMMC for defense subcontractors covers what primes push onto you contractually.

Flow-down is where this gets real before the regulation does. Primes write supplier requirements that run ahead of the federal acquisition rules. A questionnaire asking about your PQC roadmap in 2027 isn't a compliance requirement. It's a scoring criterion. You either have an answer or you're the supplier who didn't.

How to tell if your data is already exposed

There's a formula for this, and it's genuinely useful, which is rare for security frameworks. Michele Mosca, a mathematician at the University of Waterloo, framed it as three spans of time.

• X is how long your data has to stay confidential
• Y is how long your migration takes
• Z is how long until someone can break your current encryption

When X plus Y is greater than Z, you're already late. Not going to be late. Are.

Run it for a real profile. Take a 180-person aerospace supplier holding CUI under a program with a 7-year retention obligation, plus engineering drawings that stay commercially sensitive well past that. X is 7 at absolute minimum, realistically 10 or more. Migration for a company that size, starting from no cryptographic inventory, runs 5 to 7 years by the published estimates. Call Y 6. Z, on the consensus window, is somewhere around 2032, which is 6 years out.

7 plus 6 is 13. Against 6.

That's not a close call, and it doesn't get better by waiting a year, because waiting a year adds to Y and subtracts from Z at the same time. The inequality moves against you twice per year of delay. Which is a mathematically obnoxious property for a problem to have.

Run the same math for a 45-person contract manufacturer with no federal work, no CUI, and a data set where nothing matters commercially past 24 months. X is 2. Y is maybe 2. Z is still 6. Four against six. That company is fine, and should stop reading marketing emails about this.

What a migration actually involves

Three phases, and the middle one takes the longest. Discovery, hybrid operation, replacement.

Discovery means building a cryptographic inventory. Every algorithm, key, certificate, library, and protocol in your environment, and critically, which system depends on which. NIST's NCCoE migration project names cryptographic inventory as the first step, and it comes first for an unglamorous reason. You cannot migrate what you cannot see.

Hybrid means running classical and post-quantum together. A hybrid TLS handshake does X25519 and ML-KEM at the same time, and an attacker has to break both. This is where the industry lives right now, and it's the right posture, because if a weakness turns up in the new algorithms you haven't torn out the old ones yet.

Replacement is the long tail. Legacy applications with hard-coded algorithms. Embedded controllers on the plant floor that ship a crypto library from 2014 and can't be updated. Vendors who haven't shipped support, won't commit to a date, and happen to sit in the path of every transaction between your ERP and the four systems downstream of it that nobody documented when it went in. That last one isn't your engineering problem, it's your procurement problem, and it's the reason migration timelines slip by years rather than months.

Across enterprise migrations studied so far, swapping the actual algorithms accounts for roughly 10 to 20 percent of total program cost. The other 80 to 90 percent is application refactoring, vendor coordination, testing, recertification, and running hybrid in parallel. Teams that scope this as replacing the crypto discover the real shape of it about 18 months in. Usually the hard way.

Published timelines by organization size land around 5 to 7 years for companies under 500 employees, 8 to 12 for mid-market, and past 12 for large enterprises with heavy legacy. Those numbers assume you start with a mess, which most companies do.

Teams consistently miss the same thing, and it isn't the hard part. It's the invisible part. Everyone finds the public HTTPS endpoints, because those are easy to scan. Internal certificate authorities, code-signing pipelines, service account credentials with 10-year lifetimes, and machine-to-machine certs nobody has looked at since deployment are where the real exposure sits. Those are also the ones with no dashboard, no renewal reminder, and no owner listed anywhere.

Where a 20 to 500 user company starts

Start with inventory, not algorithms. You're almost certainly not writing cryptography. Your vendors are. Your job is knowing what you run, pressuring the vendors who lag, and timing contract renewals so you don't buy a five-year appliance that can't do ML-KEM.

Five moves, in order.

1. Build the cryptographic inventory. Scan certificates, TLS configurations, VPN tunnels, code-signing, and internal CAs. Capture it as a CBOM, a cryptography bill of materials, in CycloneDX format so it's machine-readable and you can diff it next year. This is a 6 to 12 week exercise for a company your size, not a multi-year program.
2. Sort by data lifetime. Anything with a confidentiality requirement past 2032 goes to the top. CUI, engineering IP, M&A material, long-term contracts, HR files. Everything else waits.
3. Turn on hybrid where it's already free. Chrome 131 and later, Firefox 135 and later, and Cloudflare all negotiate hybrid ML-KEM today. Modern firewall firmware does too. A meaningful chunk of your exposure closes through firmware updates you were going to apply anyway.
4. Put PQC language in your next three vendor renewals. Not a requirement to ship it today. A requirement to publish a roadmap and support it within the contract term.
5. Assign an owner. Not a committee. One person who owns the inventory and reports on it quarterly. Federal agencies were required to name a migration lead by July 2026 for exactly this reason.

If you don't know where your controls stand today, a structured look at where your controls actually stand is a cheaper starting point than a crypto discovery project, because companies that call about post-quantum often turn out to have older gaps that matter more this year. In manufacturing environments specifically, the plant-floor equipment usually determines the timeline, and that inventory takes longer than the IT side by a wide margin.

What to ask your vendors before the next renewal

The vendors have moved further than most people assume. FortiOS has supported post-quantum key exchange for IPsec since version 7.6. PAN-OS 12.1 added all three NIST algorithms. Microsoft shipped ML-DSA in Active Directory Certificate Services on Windows Server 2025 in May 2026. Cloudflare reports that over two-thirds of browser traffic reaching its network is already protected with post-quantum encryption.

So the useful question isn't whether a vendor supports it. It's whether the version you're running supports it, and whether they'll commit in writing.

• Which release of your product supports ML-KEM, and which release are we on?
• What's the published date for post-quantum digital signature support, not just key exchange?
• Do your FIPS 140-3 validated modules include the post-quantum algorithms, or only the classical ones?
• When our current hardware reaches end of support, will its replacement do CNSA 2.0?
• Will you put a PQC roadmap commitment in the contract?

That last one separates the vendors who have a plan from the vendors who have a webpage.

One caveat on scope. Post-quantum key exchange is deployed at scale, but public post-quantum certificates barely exist yet, and broad certificate availability isn't expected before 2027. So authentication lags encryption by a year or more no matter how aggressive you are, and any roadmap claiming otherwise is describing a product that doesn't ship. This is also why zero trust architecture is worth more than it was five years ago. When you can't fully trust the certificate layer's timeline, you want authorization decisions that don't rest on it alone.

When it's fine to wait

Some companies genuinely should do nothing this year beyond an inventory. If you hold no federal contracts, no CUI, and nothing in your data set carries a confidentiality obligation past 2032, the math says you have room. Build the inventory, put PQC language in renewals, and spend this year's budget on the gaps that will actually get you breached, which for a company under 100 users is usually identity, backups, and email.

Skip the vendor pitch entirely if a salesperson tells you CMMC requires post-quantum today. It doesn't. Skip it if they can't explain the difference between deprecated and disallowed, because that difference is the whole timeline. And if someone quotes you a quantum-safe appliance without naming FIPS 203 or 204, they're selling a label.

The companies that shouldn't wait are narrower and easier to identify. Defense suppliers holding CUI. Anyone touching National Security Systems, directly or through a prime. Companies with IP that stays valuable for a decade. If you're in that group, the inventory should be underway this quarter, not budgeted for next year, because Y is the only variable in Mosca's inequality you control and it only gets bigger the longer you wait to start.

The short version

Somewhere in 2024 this stopped being a research topic and became a compliance calendar. 2026 is the year the dates grew teeth. FIPS 140-2 validation goes historical next month. CNSA 2.0 gates procurement in January. Federal contractors have a 2030 obligation now written into an executive order. Three separate clocks.

Two things to take from this. First, your exposure is set by how long your data has to stay private, not by when someone builds a quantum computer, which means the risk is already priced in for anyone holding CUI or long-lived IP. Second, at 20 to 500 users, this is an inventory and vendor management problem, not a cryptography problem, and the companies that treat it that way finish years ahead of the ones waiting for a product to buy.

If your organization handles CUI or long-lived intellectual property and you don't yet have a cryptographic inventory, that's the gap worth closing this quarter. Speak to a cybersecurity expert about where a cybersecurity assessment would put this on your roadmap, or look at how a vCISO engagement keeps algorithm lifecycle on the same roadmap as everything else you're managing.