2.3 Out of 10: Why Post-Quantum Migration Stalls After the Awareness Phase

On 27th July the Hong Kong Monetary Authority did something regulators rarely do with a long-horizon risk. It put a number on it. The HKMA published a quantum preparedness whitepaper and a Quantum Preparedness Index, scored the local banking sector at 2.3 out of 10, and said it wants the sector at a 10 by 2030.¹²

The breakdown is more interesting than the headline score. Roughly 68% of banks have started something, whether awareness work, planning, or a pilot. About half have held board-level discussions. Around a third have tested anything at all. And close to half still have no formal roadmap for adopting post-quantum cryptography.² Read those together and a specific picture emerges. The sector knows. The sector has talked about it at board level. The sector has, for the most part, not moved.

That gap between knowing and moving is the actual problem, and it is not unique to Hong Kong banks.

I have been chewing on this since April, when Philip Mok ran a technical sharing session on post-quantum readiness for the ISACA China (Hong Kong) Chapter. Credit to him for putting it in front of the local security community well before a regulator forced the conversation, and for framing it the way it deserves: less speculation about Q-Day, more attention to cryptographic discovery, harvest-now-decrypt-later, and building agility rather than picking a winner. What follows is my own read on the step after a session like that, because that is where most programmes quietly stop.

The technical picture is more settled than people assume#

A common reason for delay is the belief that the standards are still in flux. They are mostly not. NIST published FIPS 203, 204 and 205 on 13 August 2024, covering key encapsulation and two signature schemes. HQC was selected on 11 March 2025 as a backup key encapsulation mechanism built on different mathematics, and FIPS 206 covering FALCON remains in development.³ The core toolkit you would migrate to has been sitting on the shelf for two years.

Hardware has kept moving in the meantime. IBM’s published roadmap runs through Kookaburra in 2026 and Cockatoo in 2027, targeting Starling in 2029 as a fault-tolerant machine running 100 million gates across 200 logical qubits.⁴ Google demonstrated below-threshold error correction with Willow, meaning error rates fell as the code grew rather than rising.

But the number that should have changed planning assumptions is not a hardware announcement at all. In May 2025 Craig Gidney published a resource estimate showing a 2048-bit RSA integer could be factored in under a week by a machine with fewer than a million noisy qubits. His own 2019 estimate had been 20 million.⁵ Nobody built anything to achieve that twentyfold reduction. It came from better algorithms and better error correction.

This is the part worth carrying into a board conversation. Q-Day forecasts move when someone publishes sharper arithmetic, not only when a lab racks up more qubits. Planning against a date is therefore fragile. Planning against your own capability to change algorithms is not.

Several clocks now point at 2030#

The regulatory picture has firmed up considerably, and the dates cluster in a way that should register with anyone signing multi-year contracts.

NIST’s transition guidance deprecates RSA and elliptic curve cryptography after 2030 and disallows them after 2035.⁶ The NSA’s CNSA 2.0 suite expects new national security system deployments to comply from 1 January 2027, with equipment incapable of supporting it phased out by the end of 2030.⁷ The UK’s NCSC asks organisations to complete discovery and build a migration plan by 2028, finish high-priority upgrades by 2031, and complete migration by 2035.⁸ The HKMA wants a 10 by 2030.¹

Put those next to your asset refresh cycle. Network hardware, payment infrastructure, industrial controllers and medical devices bought this year will still be running in 2030. Any procurement decision made in the next eighteen months is, whether the buyer realises it or not, a post-quantum decision.

Awareness is saturated. Deployment is stuck.#

The survey data makes the stall unusually visible. DigiCert’s 2026 research, covering 1001 IT & security decision makers across the US, UK and Australia, found 87% planning, testing or implementing post-quantum initiatives, and 84% believing some of their encrypted data is already exposed to harvest-now-decrypt-later collection. Only 7% had actually deployed quantum-safe or hybrid cryptography across most of their certificates, a rise of two percentage points year on year. Around 44% had built a cryptographic inventory alongside a transition plan.⁹

Two points of movement in a year, against a 2030 cluster of deadlines, is not a migration. It is a holding pattern.

Compare that to the public internet, where the picture is genuinely different. More than 65% of human traffic reaching Cloudflare is already post-quantum encrypted, and the company has published a roadmap to full post-quantum security, including authentication, by 2029.¹⁰ The contrast is instructive rather than embarrassing. The internet edge moved because a small number of browser and infrastructure vendors changed defaults, and no enterprise had to raise a change request for it to happen. Inside your own estate, nothing changes by default. Every certificate, every appliance, every hardcoded cipher suite requires somebody to decide, fund, and schedule it.

Why it stalls, and it is not technology#

Three things explain most of the inertia I see.

1. Cryptography has no owner. It is present in TLS termination, code signing, VPN concentrators, database and disk encryption, payment hardware security modules, firmware update chains, backup archives, and dozens of SaaS products you do not control. Each of those belongs to a different team, and for every one of those teams it ranks somewhere around tenth priority. A risk distributed across everybody is a risk owned by nobody.
2. There is also no forcing function inside the current budget year. Y2K worked as a programme because the date was non-negotiable and visible to the board. A 2030 or 2035 deadline behaves differently. It stays comfortably in the future right up until it becomes a two-year problem with a procurement queue attached.
3. The third reason is that discovery is harder than it sounds, and people who have not attempted it consistently underestimate the effort. A cryptographic inventory is not a scan you run over a weekend. It means finding algorithms hardcoded in application code, cryptography buried inside vendor appliances you cannot inspect, certificates issued years ago by teams that no longer exist, and protocol choices frozen into firmware that ships from a supplier with no upgrade path. It is closer to archaeology than to asset management, and it is the single most common place these programmes die.

Rank by data shelf life, not by system criticality#

Here is where quantum risk inverts normal security prioritisation, and it is the idea I would most want a leadership team to take away.

Standard risk ranking asks what happens if a system fails or is breached today. That produces a list topped by high-availability, high-transaction systems. Quantum risk asks a different question: how long does this data need to stay confidential?

An adversary capturing encrypted traffic now is making a bet on future decryption, so the exposure scales with the secrecy lifetime of what you are protecting, not with how busy the system is.

Work the arithmetic. If data must remain confidential for X years, migration takes Y years, and a cryptographically relevant quantum computer arrives in Z years, you have a problem whenever X plus Y exceeds Z. Thirty-year mortgage files, life insurance underwriting records, health data, merger documents, source code and design IP, diplomatic and defence material all carry long values of X. Many of them sit on systems that would never reach the top of a conventional criticality ranking.

A Federal Reserve working paper from September 2025 makes the sharpest version of this point in the context of distributed ledgers. Networks can adopt post-quantum cryptography to protect future transactions, but the confidentiality of records already written and already copied cannot be restored after the fact.¹¹ That conclusion generalises well beyond blockchains. Migrating protects tomorrow’s traffic. It does nothing for what an adversary quietly collected last year.

Buy agility, not an algorithm#

The instinct to wait until the standards fully settle is understandable and mostly wrong, but the instinct to standardise hard on one algorithm today is also wrong. HQC exists precisely because NIST wanted a fallback built on different mathematics in case lattice assumptions weaken. During the selection process, both SIKE and Rainbow were broken after reaching advanced rounds. Signature standards are still being added.

The deliverable, then, is not “we adopted ML-KEM.” It is the ability to change cryptographic primitives without running a project each time. In practice that means centralised certificate and key management with an inventory that is actually accurate, materially shorter certificate lifetimes so rotation is routine rather than exceptional, negotiated protocol suites instead of hardcoded ones, and contract language obliging vendors to deliver algorithm upgrades within a defined window. Hybrid key establishment, classical and post-quantum together, is the sensible default for anything you migrate now, because it fails safe if either component disappoints.

What to actually do this quarter#

1. Fund discovery as a named project with an owner and an end date. Not a workstream inside someone’s day job. If the HKMA index has any lasting value, it is that it converts a vague obligation into a number somebody can be asked about in a meeting.
2. Build the shelf-life list next. Identify every data class with a confidentiality requirement extending past 2035, and treat those systems as the front of the queue regardless of where they sit on your usual criticality ranking.
3. Change procurement language now, because this costs nothing and compounds. Anything with a service life beyond 2030 gets a clause on algorithm agility and a supplier commitment to post-quantum support.
4. Push vendors for dates rather than positions. “We are monitoring developments in post-quantum cryptography” is a marketing sentence, not a roadmap, and the difference matters when you are the one carrying the residual risk.

Then migrate one real thing this year. Pick an external-facing service, move it to hybrid key exchange, and find out what breaks. The operational surprises, certificate size, handshake latency, middleboxes that choke on larger messages, legacy clients that fail silently, are the knowledge you cannot get from a workshop or a whitepaper.

The sector scored 2.3 because someone finally measured. That is progress, not embarrassment.

The organisations that come out of this well will be the ones that can answer three questions without a three-month exercise: what cryptography do we use, where does it live, and how long does the data it protects need to stay secret. Answer those now and the migration becomes a schedule. Leave them unanswered and it becomes an emergency with a procurement queue in front of it.