Good news: nobody has a cryptographically relevant quantum computer yet. Shor’s against RSA-2048 still wants more error-corrected qubits than anyone has shipped, and the public roadmaps remain firmly in “soon” territory. Pop the champagne — your AES-256 backups are safe. For now.
The “for now” is doing the heavy lifting, of course, which is why the responsible adults have spent the last few years rolling out hybrid post-quantum key exchange like X25519MLKEM768 to defang harvest-now-decrypt-later. AWS is visibly doing the work: Secrets Manager now negotiates hybrid X25519+ML-KEM on a simple client-side bump (Agent 2.0.0, Lambda extension 19, recent SDKs), and they’ve even shipped Cachee, a Rust in-process cache built specifically to swallow the new oversized PQC keys — because ML-KEM-1024 publics are 1,568 bytes versus ECDH’s 32, SLH-DSA-256f signatures are nearly 50 KB, and Redis was choking on 0.9 ms reads for a 17 KB signature. The migration is real and the engineering is impressive.
And then CVE-2026-2673 lands. If your OpenSSL 3.5 or 3.6 server config uses the DEFAULT keyword in its groups list, an implementation bug flattens the tuple structure, the server skips the Hello Retry Request, and the handshake quietly settles for whatever classical curve the client led with. No error, no warning — just a harvestable session and a future quantum adversary sending you a thank-you card. Upgrade to 3.5.6 / 3.6.2 the moment they ship, audit anything using DEFAULT, and remember the eternal lesson of crypto migrations: the algorithm is almost never the weakest link. The config is.
Our submission focuses on a gap we identified across all three published consultation documents: there is no substantive mention of cryptography, cryptographic agility, post-quantum cryptography (PQC), or NZISM Section 2.4. A full-text search of the main document and both supplementary documents returns only incidental matches — “NZISM” cited in passing when defining a “serious impact” incident, and “quantum” used in its legal sense (“penalty quantum”).
This matters because the framework being proposed will govern how New Zealand’s most essential services defend themselves for the next decade — a period during which the cryptographic foundations of the internet are expected to change fundamentally.
What we submitted
Our submission makes three recommendations:
Measure 5 should explicitly require a cryptographic inventory as part of the mandatory risk management programme — so that critical infrastructure entities know which cryptographic primitives their essential services depend on.
The framework should recognise harvest-now, decrypt-later (HNDL) as a material cyber risk for data with long confidentiality tails — health, legal, financial, state-related, and industrial IP.
NZISM should be explicitly listed among the acceptable cyber security frameworks under Measure 5, alongside NIST CSF and ISO/IEC 27001:2022 — and compliance with any listed framework should include its cryptographic controls, not just governance and process controls.
The evidence base
The submission is backed by our NZ Critical Infrastructure PQC Readiness Assessment — a scan of 118 NZ critical infrastructure entities across all seven DPMC essential service sectors. The headline finding: 52.6% of endpoints negotiate post-quantum TLS, but the majority of that is delivered transparently by CDNs. Only 13 entities (11%) run post-quantum key exchange on infrastructure they operate themselves.
We also set out how the threat timeline has hardened over the last twelve months — Gidney’s 2025 qubit reduction, Google and Cloudflare’s 2029 migration targets, and Google Quantum AI’s March 2026 ECC paper — and why New Zealand is currently alone among the Five Eyes in not having set a formal PQC migration deadline.
We consented to full publication under the Official Information Act 1982. We believe this conversation should be had in the open.
What happens next
DPMC will review submissions and use them to inform the drafting of the Critical Infrastructure Bill, expected to be introduced later in 2026. We hope the final framework recognises that cryptographic posture is not a niche concern — it is foundational to every other cyber security control the regime proposes.
If your organisation handles data with a long confidentiality tail and you want to understand your own cryptographic exposure, get in touch.
Kaysec is the post-quantum security practice of Spinsphere, a New Zealand-based quantum technology company. We help NZ organisations with cryptographic inventory, HNDL risk assessment, and PQC migration planning.
Published: 15 April 2026, 7:30AM NZT Author: Simon McCorkindale Read time: ~14 min
Summary
This is the first external, public, sector-wide post-quantum cryptography (PQC) readiness assessment of New Zealand’s critical infrastructure system. Using a purpose-built open-source TLS scanner, we measured whether the public web endpoints of 118 NZ critical infrastructure entities — covering all seven Department of the Prime Minister and Cabinet (DPMC) essential service sectors — will negotiate the NIST-standardised post-quantum hybrid key exchange X25519MLKEM768 (NIST FIPS 203).
Headline findings:
61 of 116 successfully scanned endpoints (52.6%) negotiate a post-quantum hybrid key exchange today.
48 of those 61 PQC results are delivered transparently by content delivery networks (Cloudflare, Imperva, AWS CloudFront). Those providers enabled post-quantum TLS by default between 2024 and early 2026.
Only 13 entities (11%) run post-quantum TLS on infrastructure they operate themselves. Whatever your CDN provides, these 13 are the only organisations in our scan demonstrably making their own cryptographic choices.
The Drinking Water & Wastewater sector has zero self-hosted PQC endpoints.
Four entities sit behind Fastly, which has not yet rolled out default post-quantum TLS. Those endpoints have neither CDN-delivered nor origin-side PQC protection.
The DPMC critical infrastructure consultation — submissions close 19 April 2026 — contains no substantive mention of cryptography, post-quantum cryptography, cryptographic agility, or NZISM Section 2.4.
Why this matters: the short version for the person who does not work in security
Almost every website you visit protects your connection using a handshake that combines a symmetric cipher (good against quantum attackers) and a key-agreement step (not good against quantum attackers). When a sufficiently powerful quantum computer exists, it will be able to run Peter Shor’s 1994 algorithm and solve the math underpinning that key-agreement step, recovering the session key from a recorded handshake [1].
The words to remember are harvest now, decrypt later (HNDL): an adversary with enough storage can capture encrypted traffic today, keep it, and decrypt it once the necessary quantum computer exists. As The Quantum Insider summarised in its April 2026 explainer, “intelligence agencies are already harvesting encrypted communications with the intention of decrypting them once quantum computers become available” [2].
That changes the threat clock. The quantum risk to cryptography is not only a when-quantum-arrives problem — for any data with a long confidentiality tail (health records, legal matters, industrial IP, state information, financial retention records), it is already a today problem.
NIST finalised the first post-quantum cryptography standards in August 2024 [3]:
ML-KEM — FIPS 203 — key encapsulation (formerly CRYSTALS-Kyber)
ML-DSA — FIPS 204 — digital signatures (formerly CRYSTALS-Dilithium)
For web TLS specifically, browsers, servers and the major TLS libraries have converged on X25519MLKEM768 — a hybrid that runs classical X25519 and ML-KEM-768 side-by-side, so the connection is safe if either primitive holds. Chrome, Firefox, Safari, OpenSSL, Go and recent Apple operating systems all enable it by default [4]. Our scanner checks whether the server will actually negotiate that hybrid when a client offers it.
The post-quantum trajectory — what changed in the last 18 months
Until mid-2024, it was defensible to treat PQC as a 2030-and-beyond problem. That is no longer defensible. Three developments between May 2025 and April 2026 have tightened the timeline materially.
Figure 6 — The post-quantum trajectory
May 2025 — Craig Gidney lowers the bar for RSA. Gidney (Google Quantum AI) published an arXiv pre-print [5] showing that a 2048-bit RSA integer could be factored in under a week by a quantum computer with fewer than one million noisy qubits — a 20× reduction from his own 2019 estimate of 20 million qubits [6] in six years, under identical hardware assumptions (0.1% gate error rate, 1 μs surface code cycle, 10 μs reaction time). The reduction comes from algorithmic improvements — approximate residue arithmetic, yoked surface codes, smaller magic state distillation footprints, over 100× improvement in Toffoli gate count relative to 2024 designs. Nothing about the underlying hardware assumption changed. The estimate just got sharper, and it got sharper in the direction that shortens the window.
25 March 2026 — Google announces a 2029 migration target; Cloudflare matches it the same day. Google’s Heather Adkins (VP, Security Engineering) and Sophie Schmieg (Senior Staff Cryptography Engineer) published an industry-moving blog post setting 2029 as Google’s deadline for completing post-quantum cryptography migration across Google-operated systems [7]. Cloudflare pulled its existing 2030/2031 internal target forward to match [8]. The public framing from Google was that quantum hardware progress, error-correction advances, and the falling qubit estimates from papers like Gidney 2025 justify moving the deadline forward. Google is also shipping ML-DSA digital signature protection in Android 17, with testing in the next beta and general availability expected with the stable release around mid-2026 [9].
30 March 2026 — Google Quantum AI lowers the bar for elliptic curve cryptography. A whitepaper from Google Quantum AI reported that elliptic curve cryptography (the basis of almost all modern TLS key agreement, Bitcoin and Ethereum signatures, and NIST P-256) could be broken with fewer than 500,000 physical qubits in runtime measured in minutes rather than days — roughly a 20× reduction versus the previous best estimate from Litinski (2023) at 9 million qubits on a photonic architecture [10]. The Quantum Insider described March 2026 as “three papers in three months… rewriting the quantum threat timeline” [11].
This is what the trajectory looks like: the number of physical qubits estimated to be required to break the cryptography underpinning the modern internet has moved from “tens of millions” (Gidney-Ekerå 2019), to “roughly one million” (Gidney 2025), to “fewer than 500,000” for ECC specifically (Google Quantum AI 2026) — and the migration deadlines from the largest infrastructure providers in the world have moved from “2030-ish” to “2029”. No credible voice in the field claims a cryptographically relevant quantum computer exists today. Many voices claim the honest window between “doesn’t exist” and “does exist” is shorter than most organisations’ capacity to migrate.
Boston Consulting Group’s widely-quoted position — included in Google’s recent announcements — is that “starting in 2030 will already be too late” [12]. NIST’s own transition report (IR 8547) [13] calls for quantum-vulnerable algorithms including RSA-2048 and ECDSA-P-256 to be deprecated after 2030 and disallowed after 2035. The NSA’s Commercial National Security Algorithm Suite 2.0 [14] requires new acquisitions of US national security systems to be CNSA 2.0-compliant from 1 January 2027, with deployed software using CNSA 2.0 signatures by 2030, intermediate targets in 2033 and full quantum resistance across all US national security systems by 2035.
New Zealand, alone among the Five Eyes, has not yet set an equivalent migration deadline.
This is the environment in which our scan was run.
Scan design
Tool:nzism-pqc-audit v0.1.0, an open-source Rust CLI, MIT-licensed. Source, commit history, target list and report templates are all public at github.com/spinsphere/nzism-pqc-audit.
Method: for each target, open a TLS 1.3 handshake to host:443 offering a set of key share groups including X25519MLKEM768 (FIPS 203, hybrid mode). Record the negotiated TLS version, cipher suite, and key exchange group. Separately, perform an HTTP fetch and inspect response headers for CDN fingerprints (Cloudflare, AWS CloudFront, Akamai, Fastly, Imperva/Incapsula). The scanner does not validate certificates — we are assessing PQC posture, not trust.
Target list: 118 entities across the seven DPMC essential service sectors, selected to approximate the draft thresholds in DPMC Supplementary Document 2 [15]: Communications & Data, Defence, Energy, Finance, Health, Transport, Drinking Water & Wastewater. The list is published in the repository and the selection logic is documented.
Scan date: 14 April 2026.
What this does not measure: internal cryptography, certificate signature algorithms (ML-DSA adoption), data-at-rest, SSH, any non-TLS protocol, key management quality, or organisational cryptographic posture generally. A PQC-positive TLS handshake is necessary but not sufficient for post-quantum readiness.
Responsible disclosure: sector-level aggregates are published here. Individual entity results are only named where the entity is already publicly and deliberately in a PQC-positive state (our “origin PQC” honour roll below).
Headline results
Metric
Value
Targets scanned
118
Successful scans
116
Handshake errors
2
TLS 1.3 support
107 (92.2%)
PQC hybrid (X25519MLKEM768) negotiated
61 (52.6%)
Behind a CDN
54 (46.6%)
52.6% is, at first read, a reasonable number for a country that has not set a migration deadline. When we split it by whether the endpoint is CDN-fronted or self-hosted, the read changes:
Class
Endpoints
PQC negotiated
Rate
CDN-fronted
54
48
88.9%
Self-hosted (origin)
62
13
21.0%
Edge-tier cryptography is almost fully post-quantum. Origin-tier cryptography is almost entirely not. The 52.6% headline is real, but almost all of it was delivered to the NZ critical infrastructure sector by CDN vendors — Cloudflare [4], Imperva, Akamai [16], and AWS [17] — in the 6 to 18 months before our scan.
Sector breakdown
Figure 2 — PQC status by sector
Sector
Scanned
Total PQC
PQC (CDN)
PQC (Origin)
No PQC (CDN)
No PQC (Origin)
Errors
Communications & Data
18
9 (50%)
8
1
3
6
0
Defence
6
5 (83%)
2
3
1
0
0
Drinking Water & Wastewater
9
3 (33%)
3
0
0
6
0
Energy
30
14 (48%)
9
5
0
15
1
Finance
14
7 (50%)
3
4
0
7
0
Health
16
12 (80%)
12
0
0
3
1
Transport
25
11 (44%)
11
0
2
12
0
Total
118
61 (52.6%)
48
13
6
49
2
Health — 80% total, 0% origin. Every PQC-positive health endpoint we observed is behind Imperva/Incapsula. Health NZ / Te Whatu Ora consolidated the former DHB web estate behind a shared WAF during the 2022 reform, and the termination layer of that WAF — not the hospital origin servers themselves — is doing the post-quantum work. This is protective for users whose request terminates at the edge, but it is not an organisational PQC posture.
Defence — 83% total, 50% origin. Defence and intelligence is the only sector in our scan where origin-side PQC is both present and meaningful relative to sector size. GCSB, NZSIS and the Department of Internal Affairs (which operates RealMe) all negotiate X25519MLKEM768 on their own infrastructure. It is encouraging to see the agencies responsible for New Zealand’s cryptographic policy practising what NZISM Section 2.4 [18] preaches.
Drinking Water & Wastewater — 33% total, 0% origin. Zero water utilities in our scan run origin-side post-quantum TLS. Three (Hamilton, Tauranga, and Auckland via Watercare’s edge configuration) have CDN-delivered PQC. Six do not. This matches our broader expectation — water utilities are among the least-resourced critical infrastructure sectors on cyber security globally — and is a natural priority for the DPMC framework’s minimum risk management programme.
Energy, Transport — mixed. 14 of 30 energy entities show PQC, with five of those on self-hosted origin infrastructure (Meridian, Firstgas, Manawa, Pioneer, Marlborough Lines). The larger grid operators — Transpower, Vector, Mercury — do not yet have origin PQC. Transport shows 11 PQC-positive endpoints, all of them CDN-delivered; no transport entity in our scan runs origin-side PQC.
Finance — 50% total, 29% origin. ANZ NZ is the only “big-4” systemically important bank in our sample with origin-side PQC; ASB, BNZ, Westpac, Kiwibank, and NZX do not show it. SBS Bank, The Co-operative Bank, and Vero Insurance do. For an industry that is supposed to operate at the highest cyber-security standard in the country, the big-4 result is weaker than a first-time reader might expect.
Communications & Data — 50% total, 6% origin. Only Tuatahi First Fibre (the Waikato/Bay of Plenty/Taranaki Local Fibre Company) has self-hosted PQC. None of the major telecommunications providers — Spark, One NZ, 2degrees, Chorus, Vocus, Devoli — show origin-side PQC. All three mobile network operators are running TLS that a 2030-grade quantum computer could read.
The CDN question: is “we’re behind Cloudflare” enough?
Figure 3 — CDN provider PQC coverage
Short answer: for the browser-to-edge handshake, Cloudflare, Imperva and AWS CloudFront will give you post-quantum TLS today at no cost. The long answer is that edge PQC only covers the first leg of the connection, and the first leg is the easy half.
CDN provider
NZ CI entities fronted
PQC negotiated
Rate
Cloudflare
29
28
97%
Imperva / Incapsula
17
17
100%
AWS CloudFront
4
3
75%
Fastly
4
0
0%
Cloudflare published in early 2026 that 57.4% of all browser-initiated connections to its network include a post-quantum key share, and 65% of human traffic to Cloudflare is post-quantum encrypted [4]. Akamai made hybrid ML-KEM + X25519 the default for client-to-edge connections across all Ion and Dynamic Site Accelerator customers starting February 2026, and began rolling out PQC on the Akamai-to-origin leg as a default on 31 January 2026 [16]. AWS has shipped ML-KEM across KMS, ACM, Secrets Manager, S3 and CloudFront during 2024–2026 [17]. Fastly is publicly committed to PQC but as of our scan date does not yet enable it by default.
Four NZ critical infrastructure entities are behind Fastly. None of them had post-quantum TLS at the edge on scan day. For those entities, this is a question to raise with their Fastly account team in April 2026 as a planned Q2/Q3 rollout.
But the bigger issue is that edge PQC only covers what happens between a browser and the nearest CDN POP. It does not cover:
CDN → origin. The back-end leg from the CDN to your own servers may still be classical. A state-level adversary observing that leg can still harvest-and-decrypt. Akamai began defaulting this leg to PQC in early 2026; for other CDNs, it is still a per-customer configuration choice. If you have not explicitly enabled it, you probably do not have it.
Internal east-west traffic. Database replication, service mesh, VPN, Active Directory, document signing, code-signing pipelines, email encryption, S/MIME, backups — none of these benefit from edge TLS PQC.
Historic data already captured. Anything recorded before you enabled PQC is still at HNDL risk.
Signatures. ML-DSA (FIPS 204) for certificates is a separate, later migration. As of April 2026 the public Web PKI still runs on ECDSA and RSA; no production Certificate Authority issues ML-DSA chains yet, though that work is underway.
Edge PQC from a CDN is roughly 40–50% of the answer. The other half requires the organisation itself to do something.
The 13 entities running origin-side PQC
These are the 13 entities (of 118, 11%) whose own infrastructure — with no CDN in front of it — negotiates post-quantum key exchange on their public web endpoint. In our view, they are the only organisations in the scan for whom a PQC-positive result reflects an actual, observable cryptographic decision rather than an upstream vendor default.
Figure 4 — The 13 origin-PQC entities
Defence / Intelligence (3): GCSB, NZSIS, DIA. The agencies responsible for NZ cryptographic policy are running the cryptography they publicly recommend. The Department of Internal Affairs’ infrastructure serves RealMe — New Zealand’s federated digital identity service — making this particularly welcome.
Energy (5): Meridian Energy, Firstgas, Manawa Energy, Pioneer Energy, Marlborough Lines. Mostly entities with modern, recently-rebuilt public web infrastructure. Firstgas is notable — it is the national gas transmission and distribution operator, and its origin has kept pace with cryptographic developments.
Finance (4): ANZ New Zealand, SBS Bank, The Co-operative Bank, Vero Insurance. ANZ is the only big-4 bank on this list.
Communications & Data (1): Tuatahi First Fibre — the Local Fibre Company serving the central North Island.
If your organisation is on this list: keep going, and thank you. If your organisation is not on this list, and you are fronted by Cloudflare, Imperva or Akamai: you are getting a meaningful amount of PQC protection from your vendor for free, but you do not yet have a cryptographic posture of your own. If your organisation is not on this list and is not behind one of those CDNs: you have work to do.
The DPMC consultation — and a significant omission
Figure 5 — DPMC consultation and cryptography
DPMC’s discussion document “Enhancing the cyber security of New Zealand’s critical infrastructure system”[19], published in February 2026, proposes a six-measure regulatory framework for approximately 200 NZ critical infrastructure entities across the seven essential service sectors. The central pillar (Measure 5) requires covered entities to implement a cyber risk management programme aligned with an NCSC-endorsed or internationally-recognised cyber security framework such as NIST CSF or ISO/IEC 27001:2022. Submissions close at 11:59pm on 19 April 2026.
We read all three consultation documents — the main discussion paper, Supplementary Document 1 (Policy objectives, principles and assessment of measures) [20], and Supplementary Document 2 (Defining critical infrastructure) [15]. We searched for the terms quantum, cryptography, cryptographic, cryptographic agility, PQC, ML-KEM, post-quantum, and NZISM Section 2.4.
We found no substantive matches. The only hits are incidental: NZISM generally referenced in the context of defining a “serious impact” cyber incident (p. 14 of the main document), and the word “quantum” used in its non-technical sense (“penalty quantum”) on page 20.
This is a significant gap. NZISM Section 2.4 already requires agencies to monitor PQC developments and to inventory cryptographic systems [18]. The DPMC framework does not extend those obligations to the broader critical infrastructure population, and its proposed risk management programme — despite being designed to last the next decade or more — does not identify cryptographic agility as a required outcome.
Our submission to DPMC (published today alongside this report) recommends three specific additions:
Cryptographic inventory as a minimum outcome of Measure 5. Covered entities should be required to know which cryptographic primitives their essential services depend on, where, and in what quantities.
Harvest-now-decrypt-later recognised as material cyber risk under Measure 5. Any data subject to a long confidentiality tail — health records, legal matters, industrial IP, state information, long-retention financial records — should be treated as materially exposed to HNDL today, regardless of whether a cryptographically relevant quantum computer arrives in 5, 10 or 20 years.
NZISM in the accepted frameworks list. The accepted-frameworks list under Measure 5 should include NZISM alongside NIST CSF and ISO/IEC 27001:2022, and compliance with any accepted framework should be required to include that framework’s cryptographic controls — not only its process controls.
The consultation closes in four days. If you run a critical infrastructure entity, or work on cyber risk for one, this is a cheap moment to put cryptographic agility on the regulatory map before Cabinet sees the final proposals.
What should organisations actually do?
In rough order, assuming most NZ organisations are not yet doing any of this:
Months 1–2: inventory. Catalogue every system that performs a cryptographic operation — web front-end, VPN, database encryption, SSH keys, code-signing pipeline, document signing, email encryption, backups, IoT/OT. For each, record algorithm, key length, library and version, and data retention requirement. This is the single highest-leverage thing you can do, and the precondition for every subsequent decision.
Months 2–3: classify by HNDL risk. Which of those systems touch data that must remain confidential for 10+ years? Health records, legal files, commercial IP, financial records with statutory retention, customer PII, M&A documents, state-related information. Those are the migration priorities.
Months 4–6: easy wins. For most web properties, enabling post-quantum TLS is a configuration change, not a rebuild. Talk to your CDN and confirm which key exchange groups are negotiated by default. Upgrade TLS libraries. Ship X25519MLKEM768 in the client-facing handshake. Measure it — monitoring is cheap.
Months 6–18: the harder layers. Certificate issuance (ML-DSA), VPN (IKEv2 hybrid modes), SSH, S/MIME, code-signing, database-at-rest, HSM-held keys. The ecosystem is still maturing but the direction of travel is settled.
Year 2+: cryptographic agility as a design principle. Stop hardcoding algorithms. Treat the primitive as a policy decision that can be rotated. ML-KEM will not be the last word — cryptographic agility is the real long-term protection.
Spinsphere, through our Kaysec practice, helps New Zealand organisations with exactly this — cryptographic inventory, HNDL risk assessment, PQC migration planning, and NZISM Section 2.4 alignment. Our typical engagement is a scoped inventory and gap assessment for small-to-medium NZ businesses that handle long-lived secrets (legal, health, engineering IP, financial records, anything subject to statutory retention) and need help thinking through what a credible migration plan looks like. If anything in this report matters to your organisation, get in touch.
Methodology notes, caveats, and where the data lives
A “PQC-positive” scan result means the server negotiated X25519MLKEM768 when offered by the scanner. A “PQC-negative” result means the server did not negotiate any post-quantum key exchange group, usually falling back to classical X25519 or, in a small number of cases, to TLS 1.2 with classical ECDHE.
CDN detection is by HTTP response header fingerprint. It is not perfect — some entities use multiple CDN layers, and header normalisation at the edge can mask provider identity. We list the provider our detector reported.
The two handshake errors (Wellington Electricity, Southland Hospital) are transient and do not reflect a deliberate absence of TLS.
A PQC-positive TLS handshake is necessary, but not sufficient, for post-quantum readiness. It measures one observable public-facing signal. It does not measure the cryptographic posture of any other surface.
We will be wrong about something. If you see an error, tell us: simon [at] spinsphere.xyz.
Closing thought
Sixteen months ago, a cryptographically relevant quantum computer looked like a 2035-and-beyond problem. Today it looks like a 2030 problem with significant uncertainty bars on either side. The organisations that will handle this transition well are the ones that begin their cryptographic inventory in 2026 and work the list down for the following three years. The organisations that will struggle are the ones that wait for certainty, because certainty on this question arrives one day too late.
There is no prize for going last.
References
[1] Shor, P. W. (1994). “Algorithms for quantum computation: discrete logarithms and factoring.” Proceedings 35th Annual Symposium on Foundations of Computer Science. doi:10.1109/SFCS.1994.365700
[5] Gidney, C. (2025). “How to factor 2048 bit RSA integers with less than a million noisy qubits.” arXiv:2505.15917. https://arxiv.org/abs/2505.15917
[6] Gidney, C. and Ekerå, M. (2019). “How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits.” arXiv:1905.09749. https://arxiv.org/abs/1905.09749
[12] As referenced in Adkins and Schmieg, 2026 [7]. Boston Consulting Group’s position that “starting in 2030 will already be too late” has been widely quoted in industry briefings on PQC migration urgency during 2026.
Kaysec is the post-quantum security practice inside Spinsphere, a New Zealand quantum technology company. We build tools, publish research, and help organisations plan their post-quantum migration. If your organisation has long-lived secrets and no cryptographic inventory, get in touch.
