New Zealand Critical Infrastructure: The First Public Post-Quantum Readiness Assessment

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.

Full methodology, target list and raw results are in the public repository at github.com/spinsphere/nzism-pqc-audit.

---

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)
• SLH-DSA — FIPS 205 — stateless hash-based signatures backup (formerly SPHINCS+)

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.

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

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?

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:

1. 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.
2. 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.
3. Historic data already captured. Anything recorded before you enabled PQC is still at HNDL risk.
4. 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.

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

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:

1. 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.
2. 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.
3. 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

• All code, the target list, the raw JSON results, and the full HTML report are in the public repository: github.com/spinsphere/nzism-pqc-audit.
• 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

[2] The Quantum Insider. (2026, April 6). “How quantum computing affects cryptography.” https://thequantuminsider.com/2026/04/06/how-quantum-computing-affects-cryptography/

[3] NIST. (2024, August 13). “NIST Releases First 3 Finalized Post-Quantum Encryption Standards.” FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA). https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards

[4] Cloudflare. (2026). “The state of the post-quantum Internet in 2025.” https://blog.cloudflare.com/pq-2025/

[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

[7] Adkins, H. and Schmieg, S. (2026, March 25). “Google’s timeline for post-quantum cryptography migration.” The Keyword / Google Blog. https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/

[8] Cloudflare. (2026, March 25). “Cloudflare targets 2029 for full post-quantum security.” https://blog.cloudflare.com/post-quantum-roadmap/

[9] The Quantum Insider. (2026, March 25). “Google shortens timeline for quantum-safe encryption transition.” https://thequantuminsider.com/2026/03/25/google-shortens-timeline-for-quantum-safe-encryption-transition/

[10] Google Research. (2026, March). “Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly.” https://research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly/

[11] The Quantum Insider. (2026, March 31). “Q-Day just got closer: three papers in three months are rewriting the quantum threat timeline.” https://thequantuminsider.com/2026/03/31/q-day-just-got-closer-three-papers-in-three-months-are-rewriting-the-quantum-threat-timeline/

[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.

[13] NIST. (2024). “NIST IR 8547 (Draft): Transition to Post-Quantum Cryptography Standards.” https://csrc.nist.gov/pubs/ir/8547/ipd

[14] NSA. (2025, May). “Commercial National Security Algorithm Suite 2.0.” https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF

[15] DPMC. (2026, February). “Supplementary Document 2: Defining critical infrastructure.” https://www.dpmc.govt.nz/sites/default/files/2026-02/nz-cyber-security-discussion-supp-doc-2-feb-2026.pdf

[16] Akamai. (2026). “Akamai enables post-quantum cryptography on the edge.” https://www.akamai.com/blog/security/akamai-enables-post-quantum-cryptography-edge

[17] AWS. (2024–2026). “ML-KEM post-quantum TLS now supported in AWS KMS, ACM and Secrets Manager.” https://aws.amazon.com/blogs/security/ml-kem-post-quantum-tls-now-supported-in-aws-kms-acm-and-secrets-manager/

[18] NZISM. “Section 2.4 — Post-Quantum Cryptography.” https://nzism.gcsb.govt.nz/

[19] DPMC. (2026, February). “Enhancing the cyber security of New Zealand’s critical infrastructure system — Discussion document.” https://www.dpmc.govt.nz/publications/discussion-document-enhancing-cyber-security-new-zealands-critical-infrastructure-system

[20] DPMC. (2026, February). “Supplementary Document 1: Policy objectives, principles and assessment of measures.” https://www.dpmc.govt.nz/sites/default/files/2026-02/nz-cyber-security-discussion-supp-doc-1-feb-2026.pdf

---

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.

Subscribe: kaysec.spinsphere.xyz  ·  Source code: github.com/spinsphere/nzism-pqc-audit