Marin Ivezic
In August 2024, the National Institute of Standards and Technology (NIST) published its first three post-quantum standards: ML-KEM (formerly Kyber) for key establishment, ML-DSA (formerly Dilithium) and SLH-DSA (formerly SPHINCS+) for signatures. Post-quantum cryptography, the family of algorithms designed to survive attack by a large quantum computer, now has settled specifications and running code. The programs deploying it are where the schedule slips.
Five failure modes come up often enough to plan around. Four of them are technical. The fifth causes the other four.
Treating PQC as a library swap
The most expensive scoping error is booking post-quantum migration as a code change. A developer drops in an ML-DSA signature, the unit tests pass, and the ticket closes. Then the certificate authority rejects the request, because the certificate profile doesn’t recognize the new object identifier, the numeric code a certificate uses to name an algorithm. Or the signature reaches a database column sized for what came before it. An ECDSA P-256 signature is 64 bytes of raw r and s values. An ML-DSA-65 signature is 3,293 bytes, per the parameter sets in FIPS 204.
The surrounding machinery is public key infrastructure: the certificate authorities that issue certificates, the profiles that describe what a valid certificate looks like, and the validation logic on every client that checks one. All three need changes, and none of them belong to the application team.
Bring the PKI team in at kickoff rather than at integration. Test the full chain end to end, from certificate request through issuance to client validation, before any production traffic touches it. Decide early how revocation will work, since CRLs and OCSP responses carry post-quantum signatures of their own and get larger for that reason rather than because the certificates they cover did. OCSP stapling and shorter certificate lifetimes are the usual mitigations, and both change the issuance workflow.
Handshake size and the network path
Post-quantum key shares and signatures are bigger, so TLS handshakes are bigger. A first handshake message that used to fit inside one packet may no longer fit. Most network paths carry roughly 1,500 bytes per packet, the MTU, and a message past that gets split across two.
That split is where old assumptions surface. In April 2024, Chrome 124 turned on hybrid post-quantum key exchange by default, and the larger first message that comes with it can stall on firewalls and inspection devices written on the assumption that the first handshake message arrives whole. From the user’s side this looks like an intermittent connection failure with no error worth reading, which is a difficult thing to diagnose under time pressure.
Measure handshake sizes after the change, not before. Test against the oldest inspection device anywhere in the path, since that is the one that will break. Roll out by site or by segment so a single office’s proxy fails in front of a small population rather than all of them. Where the traffic pattern allows it, session resumption spreads the cost of one full handshake across many connections.
HSM and key management assumptions
A hardware security module is the tamper-resistant appliance that generates and stores private keys. A key management service is the managed equivalent, holding keys on a team’s behalf. Vendor documentation for both has been running ahead of shipped capability.
Support claimed in a datasheet can mean several different things. It can mean keys generated in hardware, or it can mean an algorithm running in software on the appliance at a fraction of the throughput. It can mean keys that back up and restore the way existing keys do, or keys that cannot leave the device at all, which changes the disaster recovery plan rather than the cryptography.
Put three questions to every vendor in writing, and hold the answers against a real workflow rather than a demo. Is the key generated in hardware. Can it be exported under wrap for backup, and if not, what replaces the current backup procedure. Do the certificate automation tools already in use speak the new mechanisms, and on what date. A verbal yes from a sales engineer is not a plan, and a proof of concept that skips backup and restore has tested the easy half.
The inventory that looks complete
A cryptographic bill of materials, or CBOM, lists the algorithms, keys and certificates a system depends on. A signed-off CBOM that misses whole segments of the estate is worse than an unfinished one, because it converts an open question into a false answer.
The segments that go missing are consistent. Operational technology, the control systems on a plant floor or in a substation, often runs proprietary or long-frozen cryptography that no network scan will report cleanly. Embedded devices such as badge readers carry keys in firmware. Mainframes run their own TLS stacks. SaaS providers holding data with a fifteen-year confidentiality requirement carry that exposure on the customer’s behalf, and nobody asked them what they encrypt with. Inside the data center, scripts using GPG and database-level transparent encryption sit outside the reach of a port scan.
Use more than one discovery method and expect them to disagree. Network scanning, source code scanning, vendor SBOMs (the software bill of materials a supplier provides listing the components inside a product), and a direct survey to system owners will each find things the others miss. Cross-check the results: if the CBOM shows no instance of an algorithm a known product depends on, that gap is a finding about the discovery process.
Treat the inventory as a standing process with an owner and a refresh cycle. When something turns up late, and it will, fix the class rather than the case. Missing one connected device means the discovery method cannot see connected devices.
Work that nobody owns
The organizational failure is the one that produces the others. Post-quantum migration touches PKI, network, application development, procurement, and third-party risk, and it is the first-priority workload of none of them. When the program is everyone’s problem, the certificate profile work waits on the network test, the network test waits on the HSM decision, and the steering deck reports amber for two quarters.
Name a program lead with budget authority and a reporting line to the executive sponsor. Name a single owner for each domain, by person rather than by team. Give each one a dated deliverable. Ownership is what turns the four technical failures above into work that appears on somebody’s objectives.
Five questions for the next steering meeting
Ask them in this order, and treat any unqualified yes as an unanswered question:
- Has a certificate travelled the full path, from request through issuance to client validation, on the new algorithms?
- What are the handshake sizes now, and which device in the path is the oldest?
- Which HSM and automation capabilities have been demonstrated on a real workflow, including backup and restore, and which are still roadmap items with dates?
- Which discovery methods produced the inventory, and where did they disagree?
- Who owns each of the above by name?
The pattern across all five is the same. Migration programs fail where one team’s assumption meets another team’s system, and every one of those seams sits between two owners rather than inside one.
For migration methodology in more depth, pqcframework.org sets out the phased approach these checks belong to, and PostQuantum.com covers the underlying cryptography for readers who want the technical detail.
If you are running one of these programs and want the discovery methods, certificate testing sequence and governance model taught as a working method rather than a reading list, our post-quantum migration training at Quantum Academy is built for exactly that role.