The first real test of an organisation’s post quantum cryptography strategy may arrive long before a cryptographically relevant quantum computer does. That test will not be whether the organisation has selected the right algorithm in a standards document. It will be whether teams know where cryptography actually runs, and which teams own the change path.
This is where PQC migration will succeed or fail.
Post quantum migration is not simply a cryptographic upgrade. It is an operational change across distributed systems. Without that visibility, crypto agility is just a slogan.
Why there is no big bang migration
Cryptography is not a clean architectural layer that can be lifted out and replaced. It is embedded across network infrastructure, identity providers, edge devices, and legacy application stacks. In many environments, these dependencies are either hardcoded, poorly documented, or owned by different teams.
Post quantum algorithms also introduce practical engineering constraints. Larger key material, larger signatures, different performance profiles, different certificate sizes, and different protocol behaviours can affect infrastructure that was designed around today’s elliptic curve assumptions.
A change in key exchange can affect TLS handshake size, packet fragmentation, middlebox behaviour, inspection visibility, hardware offload compatibility, certificate chain size, session establishment latency, and application availability.
Where hybrid PQC can break in practice
ML-KEM, the NIST standardised key encapsulation mechanism based on CRYSTALS Kyber, introduces significantly larger public keys and ciphertexts than classical elliptic curve key exchange mechanisms such as X25519. NIST finalised its first three PQC standards in August 2024, including FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, and FIPS 205 for SLH-DSA.
That matters in hybrid TLS. In a hybrid TLS 1.3 handshake, the client may offer a classical key share and a post quantum key share together. For example, a group such as X25519-MLKEM-768 combines X25519 with ML-KEM-768. The resulting ClientHello can become much larger than what existing network paths, middleboxes, inspection devices, or legacy appliances were originally tested to handle.
That can create failure modes that do not show up in architecture diagrams.
ClientHello messages may exceed internal thresholds. Some middleboxes may drop or mishandle oversized handshakes. TLS inspection tools may fail to parse the exchange cleanly. Network telemetry may become incomplete. Packet fragmentation may introduce unexpected behaviour. High connection rate environments may see latency during connection establishment. Devices that rely on classical cryptographic acceleration may not deliver the same performance profile under hybrid modes.
Hybrid PQC must be tested like a production protocol change. For organisations handling long lived sensitive data, this work is urgent because harvest now, decrypt later changes the risk timeline. Data captured today may become readable later if quantum capable decryption becomes viable within the lifetime of that data.
Insert cryptographic control points before you migrate everything
The practical path is to introduce cryptographic control points where policy, visibility, and enforcement can be centralised. These control points allow organisations to terminate, inspect, enforce, and re establish TLS under controlled cryptographic policy. They create a place in the architecture where hybrid key exchange can be introduced at the edge while backend systems continue to operate on existing protocols until they are ready to change.
This matters because many internal systems will not be PQC ready on the same timeline. They may depend on older libraries, limited upgrade paths, or possess regulatory constraints that make them risky to touch without regression testing.
A control point gives teams room to migrate incrementally.
At the edge, clients can negotiate hybrid key exchange. Internally, services can continue using existing cryptographic profiles while application owners prepare their own migration. Over time, cryptographic policy can be tightened, backend protocols upgraded, and legacy dependencies removed.
But this only works if the control point is observable. If security tools cannot parse hybrid handshakes, if telemetry does not show which algorithms are negotiated, or if teams cannot distinguish classical, hybrid, and post quantum paths, then the organisation has created a new blind spot while trying to reduce risk.
Hybrid is the operating model
Classical cryptography and post quantum cryptography will coexist for years. In a hybrid handshake, a classical algorithm such as ECDH works alongside a post quantum mechanism such as ML-KEM. The secrets are combined through a key derivation function. The security assumption is that the session remains protected as long as at least one component remains secure.
This gives organisations continuity. They can keep existing infrastructure running while adding protection against future quantum capable attacks. But hybrid also introduces operational complexity. Technical teams will need to manage different algorithm policies across regions, business units, application tiers, vendors, cloud environments, sovereign environments, and compliance regimes. This will be especially important across Asia Pacific, where PQC adoption will not move in lockstep.
That means technical decision makers should not assume one clean global migration path. Cryptography is becoming part of digital sovereignty. Standards, certification rules, procurement requirements, cloud policy, and vendor readiness may evolve unevenly across markets. It is whether the architecture can support different approved profiles, regional validation requirements, and migration timelines without fragmenting control.
Without central control, cryptographic posture fragments quietly. Nobody sees the full picture until an audit, outage, or incident exposes it.
The inventory gap is the real blocker
Most PQC roadmaps fail at the first serious question: where does cryptography actually sit across the enterprise? Not where the architecture diagram says it sits. Where it actually terminates, negotiates, validates, signs, encrypts, decrypts, and fails in production.
Technical teams need a working cryptographic inventory mapping TLS termination points, cipher suites, certificate chains, dependencies, infrastructure, and identity systems. In modern CI/CD environments, this inventory must be continuously automated through discovery tools, software composition analysis, and runtime telemetry.
It has to be continuously maintained because cryptographic posture changes with application releases, infrastructure upgrades, certificate rotations, vendor patches, and cloud configuration changes.
Start with APIs, identity, and sensitive data paths
The migration sequence should be driven by exposure and data sensitivity. Start with public facing APIs, login portals, customer facing applications, payment flows, partner integrations, and systems handling long lived sensitive data. These are the areas most exposed to harvest now, decrypt later risk and the most likely to encounter external client compatibility issues.
Then move inward to service to service encryption, internal APIs, VPNs, administrative access, SSH, code signing, container signing, firmware signing, and machine identity. Do not stop at TLS.
Many organisations are over focused on key exchange and under prepared for authentication. FIPS 203 addresses ML-KEM for key establishment. FIPS 204 and FIPS 205 address post quantum digital signatures through ML-DSA and SLH-DSA. ML-KEM will expand the handshake, but ML-DSA and SLH-DSA will expand certificate chain sizes, and that is where legacy hardware load balancers, older mobile clients, embedded devices, and brittle certificate validation paths may start to break.
As certificate authorities, software vendors, and infrastructure providers move toward hybrid or post quantum certificates, organisations will need to test certificate size, validation performance, trust chain compatibility, and automation workflows. Key exchange is urgent; authentication is next.
Crypto agility is the real objective
PQC migration is not about reaching one final algorithmic destination. Standards will evolve. Vendor implementations will mature. Performance tradeoffs will change. Threat models will sharpen. Regulatory expectations will diverge.
The organisations that succeed will not simply be the ones that adopt ML-KEM first. They will be the ones that can change cryptographic policy repeatedly without breaking the business. That is the real meaning of crypto agility. Most importantly, it means cryptography is no longer treated as hidden plumbing.
A mathematically strong algorithm cannot compensate for an architecture that is brittle, opaque, and difficult to change. Done poorly, PQC migration can break under its own complexity. Done well, it can strengthen the business rather than simply change the algorithm.
