Most post-quantum migration plans look complete on paper. They name ML-KEM and ML-DSA, lay out a timeline, and end with a tidy 2035 box. Then reality intervenes. A load balancer quietly falls back to classical TLS. Almost no validated HSM firmware can sign with ML-DSA yet. A supplier says they’re post-quantum ready and means the marketing page.
The latest readiness surveys point the same way: 87 per cent of organisations are planning, testing or implementing post-quantum cryptography, while fewer than 7 per cent have deployed hybrid or quantum-safe certificates at scale. That gap is normal across the industry.
Answer three questions and the roadmap becomes a programme you can execute, fund and defend: can your infrastructure carry post-quantum cryptography, what evidence separates a real supplier capability from a claim, and how do you fund a sceptical board’s approval phase by phase. None of the three stands alone — each depends on the wider post-quantum readiness picture, from the regulatory clock to the inventory that scopes the work.
Can your HSMs, load balancers and certificate authorities actually support post-quantum cryptography?
Start with the dependency stack. Your keys live in HSMs and KMS, your TLS terminates on load balancers, and identity runs through certificate authorities and trust stores, each with its own firmware, validation and refresh cycle. The slowest one sets your critical path. If your cloud provider’s managed load balancer doesn’t support hybrid TLS yet, you cannot migrate those endpoints.
“Support” is a word vendors use loosely. For an HSM it means four things: ML-KEM encapsulation and decapsulation, ML-DSA signing and verification, larger-key storage, and a validation status your auditors accept. A roadmap item does not meet that bar. As of August 2026, two of the 676 modules validated under FIPS 140-3 carried both ML-KEM and ML-DSA in an approved-algorithms table (Kryptus and the Thales Luna T7), and no validated software module carries both. A CA can only sign ML-DSA with a validated module, so the CA migration waits on validated signing capability. The CMVP‘s validation backlog runs 14 to 22 months, which pushes CA migrations into 2027 or 2028.
Load balancers have their own quiet failure mode. The hybrid ClientHello for X25519MLKEM768 (the hybrid key-exchange group) carries a 1,216-byte key share, and when a server doesn’t understand the hybrid group there is no protocol-level error; TLS negotiates a classical group and moves on. F5’s BIG-IP added the NIST groups in v21.1, but that release won’t run on legacy platforms, so an upgrade becomes a hardware migration.
Certificates are the slowest dependency of the three. An ML-DSA-87 signature is 4,627 bytes, and public CAs have issued zero ML-DSA roots into the major trust stores. Certificate transparency logs impose fixed size limits that make those larger chains hard to issue in the first place. Australia’s ISM turns this into a procurement rule: new equipment, applications and libraries must support ML-DSA-87 and ML-KEM-1024 by 2030.
What should you ask a supplier before accepting a “post-quantum ready” claim?
Once your own stack is sequenced, the next dependency is someone else’s infrastructure. For most organisations, most of the migration is other people’s infrastructure. Data held by a supplier is protected by the supplier’s cryptography, not yours. Their algorithms set your exposure, their keys are trusted by your systems, and their roadmap caps your date. Supplier evidence is where the migration is decided.
The trick is to ask specific questions, because general questions produce general answers. Asking whether a supplier is quantum safe reliably returns a yes that means nothing. Organise your questions by evidence type: what exactly is post-quantum; which component and version; whether it’s validated and under which scheme; what you still have to change; what commitment applies if the capability regresses; and whether you can test it yourself. ASD has published its own set of vendor questions, structured around its LATICE framework, worth reading before your next renewal.
Then watch for the four claims that tell you nothing. “Quantum-safe” meaning symmetric-only hardening. Hybrid at the CDN edge with a classical origin behind it. A roadmap date with no version number. Assurance that stops at the TLS endpoint while data at rest is still wrapped with RSA. IBM found 62 per cent of respondents expect vendors to handle the transition for them, an expectation that usually disappoints.
Your leverage exists at renewal, tender or material change to services. Use those moments to demand named algorithm disclosure with a refresh obligation, a dated commitment, subprocessor disclosure, a crypto-SBOM and customer-managed keys. Subprocessor disclosure matters because most organisations can list their direct suppliers and almost none can map the fourth-party chain.
How do you frame a PQC deadline for a sceptical board and defend the spend?
Once you hold the supplier evidence, the next question is who funds the work. Leave the physics at the door. Boards approve budgets to meet dates, so frame the conversation around the dates and contracts they already care about. The honest range for what quantum computers will actually break and when is a side note; the decision is about dates. Three arguments survive scrutiny.
First, retention and contractual exposure. How long must this data stay secret, and what did you promise? Any data that must stay confidential into the 2030s is already exposed under harvest-now-decrypt-later, which turns retention schedules into present-day financial exposure. Find the contracts where post-quantum language is appearing at renewal, calculate the revenue attached, and flag renewals within 18 months as compliance cliffs.
Second, customer-driven deadlines. For many organisations the 2030, 2031 and 2035 dates bind mostly through customers and contracts, not direct regulation. Procurement offices and supervisors turn guidance into obligations well before any legislature does.
Third, the cost curve. One estimate puts emergency remediation at three to five times the cost of an ordered programme. That’s the price of waiting, and it answers the “why now” question.
Use the gap data to normalise your position: 87 per cent planning against 7 per cent deployed means you’re not late, but the 2030 key-establishment date means the sequencing decision can’t slip past the next budget cycle.
Then present the five-phase programme as the funding frame: discovery and planning, pilots, prioritised migration including 2030 key establishment, signature migration in 2031, and full migration by 2035. Put a decision in front of the board per phase, and fund discovery first, because the inventory sets the scope and cost. A defensible budget is structured in phases, each funded from the deliverables of the previous one, rather than a whole-programme estimate before discovery.
When competing priorities come up, answer plainly. “We cannot answer which systems hold long-lived secrets today” is a governance gap that exists regardless of quantum timelines, and it turns quantum into an operational problem the board can act on. A cryptographic inventory is the artefact that closes that gap.
The three questions are one programme. Each widens the frame, from a slow hardware dependency to inherited supplier exposure to the board that funds phase by phase, and each forces an ownable answer. Once you can answer them, the plan is a programme your organisation can run.
Frequently Asked Questions
Do we have to replace our HSMs, or can a firmware update handle post-quantum cryptography?
Usually a firmware update is enough, provided the vendor ships a validated version that supports ML-KEM and ML-DSA and the module can store the larger keys. Treat replacement as the exception, not the default. Budget for it anyway: HSM vendor lead times run 6 to 18 months, and hardware replacement can absorb 15 to 30 per cent of total programme spend.
Should we deploy hybrid or pure post-quantum cryptography first?
Hybrid first, almost always. A hybrid handshake such as X25519MLKEM768 keeps a classical algorithm alongside ML-KEM, so you retain protection if the new algorithm is broken and stay compatible with peers that have not moved. Key exchange is already in production at browser scale; pure post-quantum signatures come later, once certificate chains and the devices that validate them catch up.
How do we know whether our certificate authority can issue post-quantum certificates?
Ask for the specific certificate profile and the root and intermediate chain it will sit in, not a general statement of support. Larger ML-DSA signatures inflate chains and can breach size limits in some clients and certificate transparency systems, so test issuance against every device and library that validates your certificates. If your CA cannot give a dated version, plan the transition before renewal.
What do we do about devices that will never support post-quantum cryptography?
Put them behind something that does. Terminate post-quantum TLS on infrastructure you control, keep the legacy device on an isolated segment with its own trust anchor, and shorten how long anything it touches is retained. Then record the exception in your risk register with an owner and a review date, because an unwritten exception is the one that fails an audit.
Will a post-quantum migration mean rewriting application code?
Mostly no. If your applications use a maintained TLS library and standard certificate handling, the work sits in configuration, dependencies and certificates rather than business logic. The exceptions are the expensive ones: hard-coded cipher suites, custom protocols, certificate pinning, and embedded clients that cannot be updated. Find those before you scope, because they set the real effort.
Can we rely on our cloud provider’s post-quantum support?
Only for the parts they operate. A provider can enable hybrid TLS at the edge while your origin, internal services, key management and stored data remain classical, and your configuration can still negotiate a classical fallback. Ask for the specific service, region and version, then verify with your own traffic measurements rather than accepting a badge on a marketing page.
Do we need to worry about data at rest and backups, or only TLS?
Data at rest matters more than TLS for most companies, because that is where the long-lived secrets sit. Archives, backups and database fields wrapped with RSA stay exposed to harvest now, decrypt later collection for as long as they must remain confidential. Ask suppliers how they wrap stored data, not just how they terminate TLS, and put both in the same inventory.
How do we test post-quantum readiness without breaking production?
Test in a duplicate path first, then measure in production rather than assuming. The useful signals are the percentage of TLS sessions negotiating a post-quantum key exchange, whether any connection still falls back to classical, and whether older clients break when the hybrid is enforced. Run this against your own load balancers, because the failure usually appears as a silent fallback, not an error.
Is it cheaper to wait until the hardware and standards settle?
No, and waiting usually costs more. The algorithms are settled: ML-KEM and ML-DSA have been final since 2024, so the remaining uncertainty sits in firmware and validation, which resolve on vendor timelines you do not control. Waiting shrinks the window before 2030 and pushes work into the most expensive mode, a change forced at short notice.
What is a crypto-SBOM, and do we actually need one?
A cryptographic software bill of materials lists the algorithms, libraries, keys and certificates each system depends on, including the ones inherited from suppliers. You need one because you cannot sequence a migration across dependencies you have not named, and because it turns supplier claims into a verifiable inventory. It is also the artefact that lets you answer which systems hold long-lived secrets.
Is it illegal to keep using RSA after 2030 in Australia?
No. The 2030 date is a procurement and approval line, not a blanket legal prohibition: ASD guidance expects new systems to support ML-DSA-87 and ML-KEM-1024, and classical algorithms fall outside approved use beyond that point. The practical force arrives through contracts and tenders, where customers begin requiring post-quantum support as a condition of doing business.
How much should a mid-sized Australian company budget for a post-quantum migration?
Treat published ranges as anchors, not quotes. Benchmarks put mid-market programmes at roughly $500,000 to $5 million over 12 to 24 months, while organisations without on-premise infrastructure spend far less and inherit most of the cost through supplier pricing. For a 50 to 500 person company, fund discovery first: the inventory turns a range into a number the board can approve.
