Quantum computing is usually presented as a future hardware story: better qubits, better error correction, bigger machines, closer to “Q-Day.” That framing misses the enterprise problem. The security system that quantum computing threatens already exists. It is embedded in TLS, VPNs, PKI, certificates, identity systems, code signing, secure software updates, APIs, hardware roots of trust and countless products supplied by third parties. The quantum computer is the future weapon. The cryptographic estate is the present exposure.

You Don’t Need a Quantum Computer to Have a Quantum Security Problem.

A cryptographically relevant quantum computer does not need to “break the internet” in one cinematic event. The important mathematical result is more specific. Shor’s algorithm gives sufficiently capable quantum computers a fundamentally faster route to solving the integer-factorisation and discrete-logarithm problems behind widely deployed public-key systems such as RSA and elliptic-curve cryptography. Those systems are not just used to encrypt files. They help establish keys, authenticate systems and people, and create digital signatures that tell software what to trust.

That distinction matters. The highest-profile quantum risk is asymmetric cryptography. Symmetric cryptography is affected differently: Grover’s algorithm gives a quadratic speed-up for brute-force search, which is why larger symmetric key sizes — such as AES-256 where appropriate — remain an important part of a long-term quantum security strategy. Quantum migration is therefore not a simple instruction to “replace encryption.” It is a redesign of the cryptographic assumptions underneath digital trust.

Harvest Now. Decrypt Later. Compromise Now, Profit Later.

The most strategically important quantum attack does not require an adversary to decrypt anything today. An attacker can capture encrypted traffic or acquire encrypted archives now and preserve them. If the information remains valuable for years and a future quantum capability can recover the underlying plaintext or compromise the relevant public-key protection, today’s secrecy becomes tomorrow’s historical record.

NIST explicitly identifies this “harvest now, decrypt later” scenario as a reason to migrate before cryptographically relevant quantum computers exist. The agency also notes that moving a new cryptographic algorithm from standardisation into the information systems people actually use can take a long time — historically, on the order of 10 to 20 years in some cases.

Your Encryption Is Not One Thing. It Is a Dependency Graph.

One of the most dangerous enterprise assumptions is that a security team can find “the encryption” and replace it. Modern cryptography is distributed across layers, products and suppliers. A customer-facing service may depend on a certificate authority, a TLS library, a cloud load balancer, an HSM, an operating-system cryptographic provider, a container image, a service mesh and a vendor-managed API — each with its own upgrade path.

This is why PQC migration is better understood as cryptographic supply-chain transformation. An enterprise can be ready internally and still be blocked by a vendor, a protocol, a hardware lifecycle or an ecosystem that has not yet adopted compatible mechanisms.

The Threat Is Asymmetric — and That Changes the Migration Strategy.

The Industry Has Run Out of the “We’re Waiting for Standards” Excuse.

NIST says three final post-quantum standards are ready to implement: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) for hash-based digital signatures. NIST’s current PQC guidance explicitly says it is time to migrate.

There is still active work around additional algorithms and ecosystem standards. That does not invalidate the first generation of final standards. In fact, the continued evolution is an argument for crypto agility: enterprises should not build a migration architecture that assumes today’s mechanism will be the last cryptographic change they ever make.

Do Not Wait for Q-Day. Work Backward From Your Migration Date.

The UK National Cyber Security Centre provides one of the clearest enterprise planning frameworks. It treats PQC migration as a multi-year technology change and sets three milestones: 2028 for discovery, goals and an initial migration plan; 2031 for completing highest-priority migration work and refining the route to full migration; and 2035 for completing migration across systems, services and products.

Milestone	What should be true	Why it matters
Now	Executive ownership, cryptographic discovery, data-lifetime classification and supplier engagement are underway.	Waiting increases dependency risk.
2028	Discovery is complete and the organisation has a credible initial migration plan.	Unknown cryptography becomes a programme blocker.
2031	Highest-priority assets are migrated and the full roadmap is refined.	Critical exposure should be shrinking.
2035	Migration is substantially complete across systems, services and products.	Quantum-vulnerable legacy should no longer define the estate.

Google Cloud is moving on a more aggressive provider-specific track, announcing an updated roadmap to migrate Google Cloud to PQC by 2029. Google explicitly frames the strategy around protecting against store-now-decrypt-later risk and building PQC into infrastructure rather than waiting for a single future event.

The important point is not whether every organisation should copy Google’s 2029 date. It should not. The important point is that large technology providers are already treating PQC readiness as an infrastructure programme. Enterprises should therefore be asking what their own providers are doing, when those capabilities will arrive, and what dependencies remain outside their direct control.

The Hardest Part May Be Finding the Cryptography You Forgot You Had.

Most organisations do not possess a clean, authoritative map of every cryptographic dependency. Cryptography can be buried inside libraries, firmware, network appliances, certificate management, identity platforms, code-signing systems, mobile applications, manufacturing systems and third-party SaaS. Some assets are actively managed. Others are inherited, embedded or effectively invisible.

NCSC makes a similar point: successful migration depends on good asset management, visibility into systems and infrastructure, and actively managed supply chains. It also flags WebPKI and industrial-control-system protocols as areas where migration can be more complicated than a simple algorithm replacement.

The Best Quantum Strategy Is Not Choosing One Algorithm. It Is Making the Next Change Cheaper.

Crypto agility is the architectural capability to replace cryptographic algorithms, parameters and protocols without rebuilding the entire application or platform. It means separating cryptographic policy from business logic, keeping algorithms configurable where practical, maintaining upgrade paths for certificates and keys, testing protocol negotiation, and making cryptographic dependencies observable.

This is bigger than quantum computing. A cryptographically agile enterprise is better prepared for newly discovered weaknesses, regulatory changes, supply-chain incidents and future algorithm transitions. PQC is therefore an opportunity to repair a structural weakness that many technology estates have tolerated for decades.

Eight Moves That Turn PQC From a Research Topic Into an Enterprise Programme.

Quantum Readiness Is Really a Test of How Well You Understand Your Own Infrastructure.

That is the deeper lesson. A company with strong asset management, clean identity architecture, modern PKI, disciplined supplier governance and upgradeable infrastructure will have a hard migration — but a manageable one. A company that cannot answer where its certificates come from, which algorithms its critical applications use, which vendors control its HSMs, or how long its most sensitive data must remain confidential has a much larger problem.

Quantum computing simply exposes it with a deadline.