The date of the quantum computer is the wrong starting point
No responsible person can give an exact date for a cryptographically relevant quantum computer. That uncertainty is routinely used as a reason to defer action. The more useful calculation runs in the opposite direction. How long must the information remain confidential? How long will it take to discover and replace the cryptography protecting it? Could an adversary collect the encrypted material now and wait? If the required secrecy life plus the migration time extends beyond the plausible life of the current protection, the exposure already exists as a planning problem.
Standards have moved from research to implementation
NIST finalized its first three post-quantum cryptography standards in 2024 and now urges organizations to begin migration. That does not mean every system should be changed immediately. It means “we are waiting for standards” is no longer a complete position. The hard part is not selecting an algorithm from a list. It is discovering where public-key cryptography exists across applications, devices, certificates, protocols, vendors, archives, signing workflows and recovery systems—and then changing it without breaking trust or interoperability.
Start with the secrets
A useful readiness programme begins with information longevity.
- Ephemeral — value collapses quickly: routine session data, short-lived operational coordination.
- Medium-lived — material for several years: transaction data, contracts, commercial strategy, active investigations.
- Long-lived — sensitive across a decade or more: identity records, private-client history, health information, family structures, protected communications, strategic archives.
- Enduring — consequence may persist for a generation: state, fiduciary, family or institutional secrets whose disclosure cannot be repaired.
This classification determines priority. A system processing enduring information may deserve attention before a larger system carrying data whose sensitivity expires quickly.
Build a cryptographic inventory that can drive a decision
The inventory should record more than algorithms.
- Business process and information protected.
- Required confidentiality and integrity life.
- System, application, protocol and environment.
- Use of encryption, signing, key exchange or identity certificates.
- Key and certificate ownership.
- Hardware, software and provider dependencies.
- Ability to update algorithms or negotiate hybrid modes.
- Data already captured outside the organization’s control.
- Replacement window, test requirement and likely operational impact.
An inventory that cannot connect cryptography to information and service consequence will become a technical catalogue rather than a migration instrument.
The four readiness decisions
1. What must move first?
Prioritize long-lived confidentiality, high-authority identity, signing and systems whose upgrade window is long. Do not simply start with the easiest visible web service.
2. What can be made crypto-agile?
Crypto-agility is the ability to change algorithms, keys, certificates and protocols without redesigning the entire service. Procurement and architecture should stop embedding one cryptographic assumption into a system expected to live for a decade.
3. Which providers control the timetable?
Cloud, banking, identity, device, messaging and specialist platforms may determine when a migration is technically available. The organization needs evidence of product roadmaps, test capability, interoperability and exit—not a marketing statement that a service is “quantum ready.”
4. How will transition be tested?
Migration will be incremental. Classical and post-quantum mechanisms may coexist. Certificates, message sizes, performance, hardware limits and partner compatibility can create failure. Testing must therefore occur in controlled environments with rollback and observation, not as an emergency fleet change.
Questions for procurement and renewal
- Which current functions use quantum-vulnerable public-key cryptography?
- Which NIST-standardized mechanisms are supported, and in which production versions?
- Can algorithms and certificates be changed without replacing the product?
- What hybrid or transitional modes are available?
- How are backups, archives and signed historical records affected?
- Which subcontractors or protocols can block migration?
- What evidence demonstrates interoperability and performance?
- What happens if the provider’s timetable is later than the client’s required secrecy life?
A 90-day readiness sequence
- Days 1–30 — appoint an accountable owner; define information-longevity classes; select the first critical workflows.
- Days 31–60 — discover cryptographic dependencies; interview system and provider owners; identify immovable constraints.
- Days 61–90 — rank migration paths; add procurement requirements; select one controlled test; place unresolved vendor dependencies on an executive risk register.
The output is not a declaration of quantum safety. It is a credible map of what must change, who controls the change and which secrets cannot wait.
The decision
Post-quantum readiness is not a bet on a machine arriving next year. It is a refusal to discover, too late, that the information needing the longest protection was tied to the slowest systems and least cooperative providers. The quantum timeline for a long-lived secret begins when the secret is created—not when the computer capable of reading it is announced.