Most boards still treat quantum computing as a research curiosity rather than a migration deadline. That is a mistake. The cryptographic algorithms that protect today's TLS connections, VPNs, code signing and stored data rely on problems that a sufficiently capable quantum computer would solve efficiently. The machines that could do this at scale may still be years away, but the data being encrypted today can be harvested now and decrypted later, and the migration itself takes years to complete properly. Enterprises that wait for certainty about the threat timeline will run out of runway before the migration is done.
Why "harvest now, decrypt later" changes the urgency calculation
The conventional argument for delay is that no cryptographically relevant quantum computer exists yet, so there is no immediate risk. This reasoning ignores that adversaries with long time horizons, including some state actors, are already capturing encrypted traffic and data exports with the expectation of decrypting them once capable hardware exists. For information with a long confidentiality shelf life, health records, intellectual property, national security material, long-term contracts, the exposure window opened the moment the data was encrypted with a vulnerable algorithm, not the moment a quantum computer arrives.
This reframes the planning question. It is not "when will quantum computers break RSA" but "how long does our most sensitive data need to stay confidential, and does that period extend past the point at which decryption becomes plausible." For most regulated enterprises, the answer is that some data categories are already in the exposure window, which means migration planning is not a future project but a current one.
Building a cryptographic inventory before choosing algorithms
The organisations struggling most with post-quantum migration are not the ones that lack access to the new algorithms; NIST finalised the first standards in 2024 and vendor support is maturing quickly. They are the ones that do not know where cryptography is used across their estate. Certificate lifecycles are usually tracked centrally, but cryptographic dependencies embedded in application code, hardware security modules, IoT device firmware, legacy protocols and third-party libraries are frequently undocumented.
A cryptographic inventory is the necessary first step: cataloguing every system that performs encryption, signing or key exchange, the algorithm and key length in use, the data sensitivity and required confidentiality lifespan, and whether the component can be updated in place or requires replacement. This inventory work is unglamorous and takes months in a large estate, but every enterprise that has run a real migration has found that discovery, not implementation, consumed the majority of the effort.
Sequencing the migration by exposure, not convenience
Once the inventory exists, sequencing should be driven by risk rather than by which systems are easiest to change first. Prioritise systems handling data with long confidentiality requirements, systems facing external, high-value adversaries, and cryptographic components that are hardest to change later, such as embedded devices with long field lives or signing keys baked into firmware that cannot be remotely updated. Internal systems with short-lived data and straightforward update paths can reasonably wait.
Crypto-agility should be an explicit design goal for every system touched during this sequencing exercise, whether or not it is migrated to post-quantum algorithms immediately. A system built so that its cryptographic algorithms can be swapped through configuration rather than code changes will absorb the next transition, and the one after that, at a fraction of the cost. Treat this migration as the forcing function to retire hard-coded algorithm choices across the estate.
Hybrid schemes as the practical near-term posture
Very few enterprises will move directly from classical to post-quantum algorithms in a single step. The pragmatic intermediate posture is hybrid cryptography, combining a classical algorithm with a post-quantum one so that an attacker must break both to compromise the exchange. This protects against the possibility that a newly standardised post-quantum algorithm has an undiscovered weakness, while still providing quantum resistance against the harvest-now threat.
Major browser vendors, cloud providers and protocol maintainers have already begun shipping hybrid key exchange support, which means enterprises can often adopt this posture by upgrading dependencies and configuration rather than rewriting cryptographic code. The practical work is testing for interoperability and performance impact, since post-quantum algorithms generally have larger key and signature sizes that affect handshake latency and message size limits in constrained environments.
Governance, budget and vendor accountability
A migration of this scale needs an accountable owner, typically within the security or architecture function, with a mandate that spans the whole estate rather than a single business unit. It also needs a multi-year budget line, because the work will not complete inside a single financial year and will compete for funding against more visible priorities unless it is protected as a named programme.
Vendor accountability matters as much as internal execution. Enterprises should be asking every strategic technology supplier, cloud provider, HSM vendor, identity provider, network equipment manufacturer, for their post-quantum migration roadmap and timeline, and should be building contractual expectations around cryptographic agility into renewals happening now. A vendor with no credible answer to this question today is a supply chain risk that will surface at the least convenient moment.
A post-quantum readiness checklist
- Build and maintain a cryptographic inventory covering every system that encrypts, signs or exchanges keys, including embedded and third-party components.
- Classify data by required confidentiality lifespan and identify what is already inside the harvest-now, decrypt-later exposure window.
- Sequence migration by exposure and difficulty of later remediation, not by ease of the next sprint.
- Adopt hybrid classical and post-quantum key exchange where supported, and test for interoperability and performance impact.
- Design new and refactored systems for crypto-agility so future algorithm transitions do not require code rewrites.
- Assign a named accountable owner and a protected multi-year budget line for the migration programme.
- Require post-quantum roadmaps from strategic vendors and build cryptographic agility expectations into contract renewals.
What good looks like
Enterprises that are genuinely prepared can produce a cryptographic inventory on request, can point to a documented sequencing plan tied to data sensitivity, and have already enabled hybrid key exchange on their highest-exposure external connections. Their new systems are built so that changing a cryptographic algorithm is a configuration change, not a re-architecture, and their vendor contracts contain explicit expectations rather than silent assumptions.
The organisations that get caught out will not be the ones that moved too early. They will be the ones that treated an inevitable, multi-year migration as a future problem until the deadline arrived with the discovery work still undone.
Post-quantum readiness is a long migration that rewards an early, well-sequenced start. If you want help building a cryptographic inventory and a realistic migration plan, email sales@halfteck.com.