Migrating to post-quantum cryptography is not like patching a vulnerability. There is no single fix to deploy. It is a multi-year programme that touches cryptographic libraries, protocols, certificates, hardware, vendor relationships, and governance frameworks simultaneously. The organisations that will complete migration successfully are the ones that start planning now, and the starting point is less technical than most security teams expect.
The first thing to understand is the scope. Cryptography is embedded in modern IT infrastructure in ways that are often invisible until you go looking for it. TLS secures web traffic and API calls. SSH secures remote access. IPsec secures VPN tunnels. Code signing certificates authenticate software updates. PKI underpins identity and access management. Every one of these uses public-key cryptography that will be vulnerable to a quantum computer running Shor’s algorithm.
Start with a cryptographic inventory
Before anything else, you need to know what you have. A cryptographic inventory is a catalogue of every algorithm, key length, certificate, protocol, and cryptographic library in use across your organisation. That includes your own systems, your cloud environments, your on-premises infrastructure, and critically, the third-party services and vendors that handle cryptography on your behalf.
Most organisations discover they have significantly more cryptographic surface area than they thought. Custom applications that implement their own cryptography. Legacy systems with hardcoded algorithms that have not been touched in a decade. Dependencies on vendors who have no public position on post-quantum migration. Certificates with multi-year validity periods that will still be in use in 2030.
Prioritise by what you cannot afford to lose
Not all systems carry the same migration urgency. The key dimension is the intersection of sensitivity and data longevity. Systems that handle data requiring long-term confidentiality, financial records, health information, intellectual property, legal communications, are immediately exposed to harvest now, decrypt later attacks. They should be at the top of your migration queue regardless of when a quantum computer is expected.
Within that priority tier, key exchange protocols come first. TLS, SSH, and IPsec are the primary HNDL attack surface. They protect data in transit, and that traffic is the most likely to have been collected. Replacing ECDH with hybrid X25519 + ML-KEM in TLS stops new traffic from being vulnerable, even if data from the past has already been harvested.
Deploy hybrid first, not post-quantum only
Hybrid cryptography is the recommended transitional approach, and for good reason. Combining classical ECDH with ML-KEM means that if either algorithm is secure, the combined scheme is secure. You get post-quantum protection without betting your security posture entirely on a new algorithm that, despite years of scrutiny, has not been in production as long as the algorithms it replaces.
This is not excessive caution. It is how TLS post-quantum deployment has worked at Google and Cloudflare. The pattern is proven and the tooling, OpenSSL 3.x, BoringSSL, liboqs, supports it today.
Your vendor ecosystem is part of the problem
A significant portion of the cryptographic infrastructure in most enterprise environments is not directly controlled by the organisation. Cloud providers, SaaS platforms, payment processors, network equipment vendors, hardware security module manufacturers. They all implement cryptography, and their migration timelines are their own.
Include post-quantum readiness as a standard question in vendor assessments starting now. Under DORA and NIS2, vendor cryptographic posture is a legitimate third-party risk dimension, and regulators are beginning to ask about it.
PKI migration needs its own plan
Migrating your public key infrastructure is the most complex part of a PQC programme for most organisations. Certificate hierarchies are deeply embedded in operating systems, browsers, and applications. Root CA certificates can have validity periods of twenty years or more. You cannot simply swap them out.
The practical approach is phased and dual-algorithm: stand up a parallel post-quantum CA hierarchy, begin issuing hybrid certificates for high-priority services, expand gradually as compatibility is confirmed, and deprecate classical-only certificates over a defined transition period. Plan two to four years for a full PKI migration in a large organisation. Starting the planning now means you are on track. Starting in 2027 means you are behind.