The argument about when a cryptographically relevant quantum computer will exist is a distraction. The decision in front of most organizations does not depend on that date. It depends on two numbers you can estimate today: how long your data must stay confidential, and how long it will take you to replace the cryptography protecting it. If the sum of those two is larger than any credible estimate of the quantum timeline, you are already exposed. For health records, legal files, intellectual property and government information, it usually is.
This note sets out the problem and then the five steps we use to build a cryptographic inventory and turn it into a migration plan. It is written for the person who has been told to “look into post-quantum” and has not been told where to start.
What harvest now, decrypt later actually means
Most encrypted traffic on the internet is protected in two layers. A key exchange, historically RSA or elliptic curve Diffie-Hellman, lets two parties agree a shared secret. A symmetric cipher, almost always AES, then encrypts the data with that secret. Shor’s algorithm, run on a large enough quantum computer, breaks the key exchange. It does not meaningfully break AES.
That distinction is the whole threat model. An adversary who records your encrypted traffic today cannot read it. But they hold the ciphertext and the key exchange that protected it. When a sufficiently capable machine exists, they recover the session keys and read everything they stored. The data did not need to be stolen from a server. It was captured in transit, years earlier, from a network they had access to.
Two consequences follow. First, anything you encrypt in transit today with classical key exchange should be assumed readable at some future date. Second, the exposure is not uniform. A password reset email has a shelf life of hours. A patient record has a shelf life of a lifetime. The inventory exists to tell those apart.
Where the standards stand
The uncertainty that used to justify waiting is gone. In August 2024 NIST published the first three post-quantum standards: FIPS 203 (ML-KEM, for key establishment), FIPS 204 (ML-DSA, for digital signatures) and FIPS 205 (SLH-DSA, a hash-based signature scheme). In March 2025 NIST selected HQC as a second key establishment algorithm to be standardized as a backup to ML-KEM. Further signature standards are in progress.
Governments have attached dates. NIST’s draft transition guidance (NIST IR 8547) proposes deprecating RSA and elliptic curve algorithms at the 112-bit security level after 2030 and disallowing them after 2035. In June 2025 the Canadian Centre for Cyber Security published the Government of Canada’s roadmap: departmental migration plans by April 2026, high-priority systems migrated by the end of 2031, and remaining systems by the end of 2035. The United Kingdom’s National Cyber Security Centre has set the same 2031 and 2035 milestones, with discovery complete by 2028. These dates bind governments directly and their suppliers indirectly, through procurement.
Deployment has started without waiting for mandates. Major browsers and content networks have shipped hybrid key exchange (classical X25519 combined with ML-KEM) as a default, which means a large share of ordinary web traffic is already protected against harvest-now-decrypt-later, provided the server supports it. Yours may not.
The five steps
The sequence below is the one we run in a quantum readiness engagement. Each step produces something you keep.
Step 1: Decide what has a long shelf life
Start with data, not cryptography. List the classes of information your organization holds or transmits and, for each, write down how long it must remain confidential. Be honest about the long tail: archived email, backups, legal holds, research data, anything subject to a retention schedule measured in years.
Then set a threshold. If a data class must stay confidential beyond the point at which you believe your migration will be complete, it is in scope for priority treatment. This is the step that turns a vague technology concern into a defensible business decision, and it is the step most organizations skip.
What you keep: a data classification with confidentiality lifetimes, signed off by the people who own the data.
Step 2: Discover where cryptography lives
Cryptography is everywhere and documented almost nowhere. The inventory has to cover at least these places:
- Public certificates and TLS endpoints, found from certificate transparency logs, DNS and external scanning.
- Internal PKI: root and issuing certificate authorities, the certificates they have issued, and what trusts them.
- VPNs, IPsec tunnels, SSH, and site-to-site links, including the ones your vendors operate.
- Code signing, firmware signing and software update mechanisms.
- Hardware security modules, key management services and the keys they hold.
- Databases, file systems and backups encrypted at rest, and the key hierarchies above them.
- Application code and dependencies: the libraries that implement cryptography and the configuration that selects algorithms.
- Devices with long lives: network equipment, operational technology, medical and industrial devices, anything with firmware you do not control.
- Software as a service: what your vendors use to protect your data, which you can only learn by asking.
Tooling does most of the collection. Network and certificate scanners, software composition analysis, cloud configuration exports and key management inventories each cover part of the ground. The emerging practice of producing a cryptographic bill of materials (a CBOM, now part of the CycloneDX standard) gives you a format to hold the results. But every automated inventory we have reviewed missed things a person found in an afternoon: the hard-coded algorithm in a build script, the vendor appliance nobody owns, the backup tapes encrypted by a product that went out of support.
What you keep: a cryptographic inventory as a living register, not a report.
Step 3: Classify each use and score the exposure
Not every entry in the inventory is exposed to harvest now, decrypt later. The threat applies to confidentiality: key exchange and the encryption of data that will still matter years from now. It applies much less to authentication and signatures, where an attacker needs the quantum computer at the moment of the attack, not years later. A TLS certificate that expires in ninety days is not a long-lived secret, even though the key exchange it protects might be.
For each entry, record the algorithm, key length, purpose (confidentiality, integrity, authentication), the data classes it protects (from step 1), and the realistic path to upgrade. Then score. We use four factors: data lifetime, algorithm exposure, how far the data travels over networks you do not control, and the difficulty of change. The result is a heat map that puts a small number of systems at the top. Those are where the money goes first.
What you keep: an exposure score for every inventory entry, with the reasoning written down.
Step 4: Check your agility
Crypto-agility is the ability to change algorithms without redesigning the system. Most organizations have far less of it than they assume. For each high-exposure system, answer three questions. Can the algorithm be changed by configuration, or is it in code? Does the protocol in use support post-quantum or hybrid modes today? Is the vendor committed, in writing, to a timeline?
The answers sort your systems into three groups. Systems you control and can reconfigure. Systems you control but must re-engineer. Systems you depend on others to change. Each group has a different plan, a different cost and a different owner. The third group is where procurement language earns its keep: new contracts should require post-quantum support and a published roadmap, so the backlog stops growing while you work through it.
What you keep: an agility assessment per system and a set of contract clauses for new purchases.
Step 5: Sequence the migration
The plan is a sequence, not a big bang. The ordering that works for most organizations:
- Hybrid key exchange at the edge. Enable hybrid TLS (classical plus ML-KEM) on public endpoints, load balancers and content networks. This is often a configuration change and it addresses the largest volume of harvested traffic immediately.
- VPNs and site-to-site links. These carry the most sensitive internal traffic over networks you do not control. Vendors are shipping post-quantum options; test and deploy them.
- New PKI hierarchies. Stand up certificate authorities that can issue post-quantum and hybrid certificates alongside the classical ones, so new systems can be issued correctly from day one.
- Code and firmware signing. Signatures are less exposed to harvesting, but signing keys live for years and devices in the field must be able to verify the new algorithms before you can switch. Start the long lead time now.
- Data at rest and backups. Re-encrypt the long-lived data classes under key hierarchies that are themselves protected by post-quantum key establishment. Retire or destroy archives that are past their retention date rather than migrating them.
- Everything that depends on a vendor. Track roadmaps, test releases as they arrive, and escalate through the contract when dates slip.
Keep the inventory alive while you do this. Add CBOM generation to the build pipeline, put cryptographic review into the architecture process, and make the register the place where every new system is recorded before it goes live. The migration you are planning now will not be the last one.
What you keep: a sequenced roadmap with owners, dates and cost ranges, mapped to the external deadlines that apply to you.
What to do this quarter
If you have nothing yet, three things fit in a quarter. Complete step 1 with the people who own your data; it costs meetings, not money. Run the external discovery from step 2 against your public perimeter, because that is where harvesting is easiest and the fix is cheapest. And enable hybrid key exchange wherever your edge infrastructure already supports it, which for many organizations is a setting they have not turned on.
The full inventory and plan take longer. They are also the only way to answer the question your board, your regulator and your largest customers are going to ask: which of our secrets will still be secret in 2035, and how do we know?