Seven Weeks Later: NZ Critical Infrastructure PQC — The June 2026 Update

On 2 June 2026 we re-ran our post-quantum cryptography (PQC) readiness scanner against the same 118 New Zealand critical infrastructure entities we assessed on 14 April 2026. Seven weeks is a short interval for a cryptographic migration story — and the headline number reflects that: the overall PQC rate moved from 52.6% to 52.2%, essentially flat.

But the number underneath has shifted substantially. Origin-side PQC — endpoints where the organisation itself, without a CDN in front, negotiated X25519MLKEM768 — nearly doubled from 13 to 25 entities. The cause is not a wave of organisations enabling post-quantum TLS. It is a CDN infrastructure change: Imperva is no longer detected in front of 13 entities that were Imperva-fronted in April. For 11 of those (health-sector entities), the underlying origin servers were already running post-quantum TLS. For one of them (KiwiRail), the origin was not — and it lost post-quantum protection when the CDN layer disappeared.

Key findings from the June scan:

• 60 of 115 successful scans (52.2%) negotiate X25519MLKEM768 — flat vs April.
• Origin-side PQC: 13 → 25 entities — but mostly explained by CDN layer changes, not new enablements.
• Southern Cross Cables (the international submarine cable operator) is the one genuine new enablement: not CDN-fronted in April, not CDN-fronted in June, and now negotiating X25519MLKEM768 on origin.
• KiwiRail lost post-quantum protection. It had PQC in April only via Imperva CDN. Imperva is gone; the origin negotiates classical X25519.
• Health sector: 0 → 11 origin-side PQC — revealing that NZ’s public hospital network has genuine PQC capability on origin servers, previously masked by the CDN layer.
• Fastly still 0%. Four NZ critical infrastructure entities behind Fastly still have no post-quantum TLS at the edge — unchanged from April.
• New error: Taranaki Base Hospital is now returning an SNI mismatch error. Wellington Electricity and Dunedin Hospital persist from April.

Why we ran this again

Post-quantum cryptography adoption is not a single transition event — it is an infrastructure state that changes as TLS library versions roll out, as CDN configurations update, as contracts change, and (occasionally) as organisations deliberately enable it. A one-time snapshot answers the question “what is the state today?”. A recurring scan answers the more useful question: “what is actually changing and why?”

The numbers at a glance

Metric	April 2026	June 2026	Change
Targets	118	118	—
Successful scans	116	115	−1
Errors	2	3	+1
TLS 1.3	107 (92.2%)	106 (92.2%)	flat
PQC negotiated	61 (52.6%)	60 (52.2%)	−1
Behind a CDN	54 (46.6%)	41 (35.7%)	−13
PQC via CDN	48	35	−13
PQC via origin	13 (11.2%)	25 (21.7%)	+12
No PQC, CDN-fronted	6	6	0
No PQC, origin	49	49	0

The structure of that table tells most of the story. Total PQC is almost unchanged. CDN count dropped by 13. Origin PQC rose by 12 (one additional entity, Taranaki Base Hospital, is now erroring rather than returning a result). Every entity that was CDN-fronted via Imperva in April that changed state in June is in the health sector or is KiwiRail. Cloudflare, AWS CloudFront, and Fastly counts are all unchanged.

What actually changed: the Imperva story

In April, Imperva and Imperva/Incapsula were detected in front of 17 NZ critical infrastructure entities. 16 of them were in the health sector, fronted through Health NZ / Te Whatu Ora’s centralised WAF. One (KiwiRail) was in transport. All 17 negotiated PQC — Imperva has had default PQC enabled for some time, so this was edge-delivered, not origin-delivered.

In June, Imperva/Incapsula is detected in front of 4 entities: Ministry of Defence, NCSC, Christchurch City Council (Water), and NZTA. The other 13 no longer show Imperva headers.

We do not know the cause. We observe the effect: 12 health entities and KiwiRail are no longer behind an Imperva edge. Their origin servers are now directly visible to our scanner.

The health sector: hidden capability revealed

For 11 of those 12 health entities, the origin server negotiates X25519MLKEM768. Health NZ / Te Whatu Ora, Waikato Hospital, Tauranga Hospital, Wellington Regional Hospital, Christchurch Hospital, Palmerston North Hospital, Hutt Hospital, Nelson Hospital, Hawke’s Bay Hospital, Rotorua Hospital, and Southland Hospital all now appear on the origin PQC honour roll.

This is a meaningful positive finding. The NZ public hospital network appears to run post-quantum TLS natively on its origin infrastructure — capability that existed in April but was invisible to us because all scanner traffic terminated at the Imperva WAF.

The caveat matters: these hospitals are not on the honour roll because they made a new cryptographic decision between April and June. They are on it because the layer in front of them changed, revealing a state that was already there. The nature of that underlying change — whether losing CDN protection introduces other risk — is a separate question we cannot answer from a TLS handshake scan.

Three health entities (Auckland City Hospital, Middlemore Hospital, North Shore Hospital) have no CDN detected and no origin PQC in June. These are the same three that had no PQC in April.

And one — Taranaki Base Hospital — is now returning a TLS error (UnrecognisedName, an SNI mismatch). That is a configuration issue, not a policy decision, and it should be fixed regardless of post-quantum status.

KiwiRail: the CDN dependency risk, illustrated

KiwiRail had post-quantum TLS in April. It had it because Imperva provided it. Imperva is no longer detected. The origin negotiates classical X25519.

This is the CDN dependency risk in concrete form: if your post-quantum TLS is entirely a function of a CDN contract, then your post-quantum TLS is as stable as that CDN contract. The public-facing endpoint of a nationally significant rail and ferry operator is now running classical key exchange.

The fix is straightforward — X25519MLKEM768 is supported by all major TLS libraries including OpenSSL (3.x), Go, BoringSSL, and the Rust rustls stack. Enabling it is usually a configuration change, not a rebuild. But you have to do it before the CDN goes away, not after.

Sector-by-sector: June vs April

Sector	Scanned	PQC total	PQC via CDN	PQC origin	April PQC origin	Change
Communications & Data	18	10 (55.6%)	8	2	1	+1
Defence	6	5 (83.3%)	2	3	3	0
Drinking Water & Wastewater	9	3 (33.3%)	3	0	0	0
Energy	30	14 (46.7%)	9	5	5	0
Finance	14	7 (50.0%)	3	4	4	0
Health	16	11 (68.8%)	0	11	0	+11
Transport	25	10 (40.0%)	10	0	0	0

Defence — unchanged and still leading. GCSB, NZSIS, and DIA continue to run origin-side X25519MLKEM768. This has not changed and we do not expect it to.

Finance — unchanged. ANZ, SBS Bank, The Co-operative Bank, and Vero Insurance remain the origin PQC names in finance. BNZ, ASB, Westpac, Kiwibank, and NZX are unchanged in their classical posture. The Reserve Bank and Payments NZ are CDN-delivered PQC (Cloudflare).

Energy — unchanged. Meridian, Firstgas, Manawa, Pioneer, and Marlborough Lines retain origin PQC. The major grid operators (Transpower, Vector, Mercury, Genesis) remain without origin PQC.

Communications & Data: +1. Southern Cross Cables — the operator of the SCCN and NEXT submarine cable systems that provide New Zealand’s primary international internet connectivity — now negotiates X25519MLKEM768 on its origin. It was classical-origin in April; it is PQC-origin in June. This is the one entity in this scan that we can say with confidence enabled post-quantum TLS between our two measurement points. Southern Cross joins Tuatahi First Fibre as the two Communications & Data origin heroes.

Health: +11 (CDN change, not new enablement). As described above. The headline movement is real — 11 public hospitals now visible as origin PQC — but it is a consequence of infrastructure change, not a deliberate migration.

Transport: −1 (KiwiRail loses PQC). Net transport PQC dropped from 11 to 10. KiwiRail’s loss. No transport entity has origin-side PQC. Air New Zealand, Auckland Transport, Wellington Airport, the Cook Strait ports, most of the port network — all still running classical TLS.

Drinking Water & Wastewater: unchanged. Still 0 origin PQC. Auckland (Watercare), Tauranga, and Christchurch have CDN-delivered PQC. The remaining six have nothing at all. Water utilities remain the weakest sector on self-hosted cryptographic posture.

The CDN picture in June

CDN provider	Entities fronted	PQC	Rate	vs April
Cloudflare	29	28	97%	unchanged
AWS CloudFront	4	3	75%	unchanged
Imperva (incl. Incapsula)	4	4	100%	was 17
Fastly	4	0	0%	unchanged

Cloudflare and AWS: stable. Imperva: 17 → 4. Fastly: still nothing.

On Fastly: as of June 2026, Napier Port, Hawke’s Bay Airport, RNZ, and NZ Defence Force all sit behind Fastly with no post-quantum TLS at the edge. Fastly has publicly stated its intention to enable PQC, but has not done so by default as of this scan. These four organisations need a specific conversation with Fastly about their timeline and whether opt-in is available now.

The updated origin honour roll: 25 entities

Retained from April (13): GCSB, NZSIS, DIA — Meridian Energy, Firstgas, Manawa Energy, Pioneer Energy, Marlborough Lines — ANZ New Zealand, SBS Bank, The Co-operative Bank, Vero Insurance — Tuatahi First Fibre.

New to June (12):

• Southern Cross Cables (Communications & Data) — genuine new enablement.
• Health NZ / Te Whatu Ora, Waikato Hospital, Tauranga Hospital, Wellington Regional Hospital, Christchurch Hospital, Palmerston North Hospital, Hutt Hospital, Nelson Hospital, Hawke’s Bay Hospital, Rotorua Hospital, Southland Hospital — origin PQC revealed by CDN change.

We distinguish these two categories in the honour roll because the source of change matters. Southern Cross Cables made a cryptographic decision. The health entities’ origin configuration existed in April; we can observe it now. Both are positive. Only one is evidence of new deployment activity.

What has not changed

Some things that we noted in April bear repeating, because seven weeks later they are identical.

The underlying 49 classical origins are still classical. No CDN arrival, no enablement. Air New Zealand, KiwiRail (which has now lost its edge PQC), the Auckland transport network, Wellington Airport, every seaport other than the three that are Cloudflare-fronted — the same entities that were classical-origin in April are classical-origin in June, now with one fewer week of lead time before 2029.

The Finance big-4 split has not changed. ANZ runs origin PQC. ASB, BNZ, Westpac, and Kiwibank do not. For institutions with legally required data retention on customer financial records, this is a relevant gap.

No new TLS 1.2 departures. Nine endpoints were TLS 1.2-only in April; nine are TLS 1.2-only in June. These endpoints cannot negotiate X25519MLKEM768 regardless of configuration — TLS 1.3 is a prerequisite. TLS 1.2 deprecation is a precursor step for PQC enablement.

NZISM Section 2.4 obligations remain without a public enforcement mechanism. The DPMC consultation submissions period closed on 19 April. We do not yet have visibility into whether the final framework will add explicit cryptographic inventory or PQC migration requirements. The absence of external accountability is one reason the 49 classical-origin entities have no particular deadline pressure.

A note on methodology and what this scan cannot tell you

This scan measures one thing: whether a publicly-reachable TLS endpoint will negotiate X25519MLKEM768 with a modern client. It does not measure:

• Internal east-west traffic (VPNs, database replication, service mesh, SSH, email)
• Certificate signature algorithms — ML-DSA adoption on public PKI is a separate, later migration
• CDN-to-origin back-end leg PQC
• Key management quality or HSM posture
• Whether the absence of Imperva detection reflects a genuine CDN removal, a change in Imperva’s response headers that defeats our fingerprinting, or something else

The CDN detection caveat is worth being explicit about in this update. Our fingerprinting works off HTTP response headers. It is possible that some entities we now classify as “non-CDN origin” are still CDN-fronted by Imperva, and that Imperva’s response headers changed in a way that our detector no longer catches. In that scenario, what looks like “origin PQC” would still be “CDN PQC”. We cannot tell from a TLS handshake whether a CDN has normalised the response headers. If you are one of the health entities in question and your Imperva contract is unchanged, let us know.

The CDN dependency lesson

The KiwiRail finding is a useful illustration of a broader pattern. Organisations that have CDN-delivered PQC and assume they are “done” on post-quantum TLS are making a bet that has two conditions:

1. The CDN contract stays in place.
2. The CDN continues to enable PQC by default.

Condition 2 has held well for Cloudflare and Imperva, and shows no sign of changing. Condition 1 is a business decision, not a security one.

The more durable position is CDN-delivered PQC and origin-side PQC — then a CDN change is a CDN change, not a security regression. Enabling X25519MLKEM768 at the origin is not a large project for most web infrastructure: upgrade to a current TLS library, configure the key share groups, deploy. It is a configuration afternoon, not a programme. It should be on the list for every organisation that currently has CDN-only PQC.

Where things stand heading into the second half of 2026

The milestone pressure on the other side of this is Google’s 2029 migration target, which Cloudflare matched on the same day it was announced in March 2026. “2029” sounds distant in June 2026. It is three and a half years. For an organisation that needs to inventory its cryptographic systems, assess which surfaces carry HNDL-relevant data, update libraries across multiple environments, get vendors to certify new versions, test them, and deploy — three and a half years is not a long runway.

The organisations on the origin honour roll have at least addressed one visible surface. The 49 classical-origin entities in this scan have not addressed even the easiest one.

The timeline on the quantum hardware side has not relaxed between April and June. Google’s 2029 commitment is based on their read of the Gidney 2025 paper (sub-one-million-qubit RSA factoring) and their own internal quantum programme progress. Nothing in the last seven weeks has made that assessment less credible.

We will continue to run this scanner on a regular basis and publish the results in the open repository. If you have made a change and want us to know about it — either because you have enabled post-quantum TLS and want it documented, or because you think our scan is misattributing your CDN — contact us at simon [at] spinsphere.xyz.

---

Scan errors in June

Entity	Sector	Error	vs April
Wellington Electricity	Energy	HandshakeFailure	Persistent
Dunedin Hospital	Health	Timeout	Persistent
Taranaki Base Hospital	Health	UnrecognisedName (SNI mismatch)	New

Wellington Electricity and Dunedin Hospital have been erroring since our first scan in March 2026. Taranaki Base Hospital is a new error — the UnrecognisedName alert means the server rejected the TLS handshake because the hostname in the SNI extension does not match any certificate it holds. This is typically a TLS configuration or DNS routing issue rather than a deliberate rejection. Taranaki Base Hospital should audit their TLS configuration independently of any PQC discussion.

Data and methodology

All code, target lists, and scan results are open source and public:

• Tool: nzism-pqc-audit v0.1.0 — github.com/spinsphere/nzism-pqc-audit
• June 2026 results: results/2026-06-02/ — summary.json, summary.md, origin-honour-roll.md
• April 2026 results: results/2026-04-14/ — for comparison
• Target list: targets/nz/critical-infrastructure.csv — unchanged from April, 118 entities across all seven DPMC sectors

Scanner methodology: for each target, open a TLS 1.3 handshake to host:443 offering key share groups including X25519MLKEM768, record the negotiated group and TLS version. CDN detection via HTTP response header fingerprint. pqc_supported: true means the server negotiated X25519MLKEM768. Entity results are published at sector-aggregate level only; individual entities are named only where PQC-positive at origin.

---

Kaysec is the post-quantum security practice inside Spinsphere, a New Zealand quantum technology company. We run this scanner to maintain a public, recurring baseline of NZ critical infrastructure PQC posture. If your organisation has long-lived sensitive data and no cryptographic inventory, get in touch.

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