In full
Most conversations about quantum computing and encryption stall on the same question: when will a machine actually be able to break RSA? It is the wrong question, and asking it is why so many organisations have not started.
One calculation decides your urgency, and you can do it today. Take the data you send across a network, ask how many years it must stay confidential, and subtract that from any plausible date for a capable quantum computer. For a payment instruction the answer is comfortable. For a medical record, a legal settlement, a merger discussion or a client identity file, the answer is that your deadline is already behind you. Your first task is not migration, it is discovery: a list of where cryptography is used, what each use protects, how long that protection must hold, and which of it you control rather than a supplier.
The threat does not wait for the machine
Harvest now, decrypt later, sometimes written as store now, decrypt later, describes a strategy that requires no quantum computer at all today. An adversary intercepts encrypted traffic, cannot read a byte of it, and stores it anyway. The decryption happens years later, when the capability exists. CISA, the NSA, the UK NCSC, ENISA and the ACSC have each formally confirmed this as an active approach.
The deadline is not the day the machine arrives. It is that day minus the number of years your data must stay secret.
That single subtraction is the whole argument. A payment instruction has a confidentiality life measured in days. A medical record, a legal settlement, a merger discussion, a client identity file, a source code repository: those have lives measured in decades. For anything in the second group that has already crossed a network, the exposure is already booked.
The standards exist, which removes the usual excuse
The waiting-for-standards argument expired. NIST has published the quantum-resistant algorithms as FIPS 203, 204 and 205, and has set out technical requirements for migration. The UK NCSC expects organisations to have completed discovery and produced an initial migration plan by 2028, with quantum-vulnerable algorithms fully prohibited from the relevant standards by 2035.
Those dates sound distant until you look at the size of the job. Published estimates put large enterprise migration at eight to fifteen years, and industry surveys suggest only around 13% of organisations have post-quantum cryptography in production while roughly 60% have not meaningfully begun. Read alongside a 2028 planning expectation, that is not a comfortable position.
Why it takes years rather than months
Cryptography is not a component you swap. It is distributed through everything: TLS on every public endpoint, certificates and their issuance chains, VPNs, code signing, database encryption at rest, backup archives, hardware security modules, embedded devices with firmware nobody has touched since installation, and every third-party service that terminates a connection on your behalf.
The first task is therefore not migration. It is discovery: knowing where cryptography is used, which algorithms, which key lengths, which certificates, which expiry dates, and which of those you actually control versus which sit inside a supplier's product. Most organisations cannot answer that today, and the answer is the prerequisite for every decision that follows.
A sensible order of work
- Inventory your cryptography. Public-facing first, because that is what an adversary can reach without help. Internal and supplier-held next.
- Rank by confidentiality lifetime. Data that must stay secret longest carries the most harvest-now risk, and should move first regardless of how convenient the system is.
- Ask your suppliers in writing. A great deal of your cryptography is somebody else's implementation. Their timeline becomes yours.
- Build for crypto-agility. The specific algorithm matters less than whether you can change algorithm without a rebuild. Systems that hard-code a cipher will be migrated twice.
- Start with the things that expire anyway. Certificate renewal cycles are a natural migration point and one you are already staffed for.
The honest position
Nobody can tell you the year a cryptographically relevant quantum computer arrives, and anyone who states it with confidence is guessing. That uncertainty is exactly why the confidentiality-lifetime calculation is the right frame: it lets you make a decision now without needing to predict a date.
The unglamorous version of this work is discovery. Knowing what you have, where it runs, and how long each piece must stay secret is most of the value, and it is useful even if the timeline slips by a decade. It is also the part that takes longest, which is why it is the part to start.
Harvest now, decrypt later means the exposure is created when data crosses the network, not when it is decrypted. Work out how long each class of your data must stay confidential, subtract that from any plausible arrival date, and you have your real deadline. For long-lived data it has passed. Start with discovery: an inventory of where cryptography is used, what it protects, and who actually controls it.