Reports

The algorithm is ready. The infrastructure isn’t.

by Simon McCorkindale

Three papers published in the second week of May 2026 cover different parts of the post-quantum migration stack: a new NIST report on the next generation of digital signature candidates, a proof-of-concept PQC deployment inside a production bank, and a working FN-DSA implementation on Raspberry Pi hardware. Read together, they deliver the same message from three angles — the algorithms are no longer the problem. The operations are.

NIST is hedging its bets

On 14 May, NIST released IR 8610, advancing nine algorithm candidates to the third round of its Additional Digital Signatures process. The nine survivors — FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign, and UOV — span four distinct mathematical families. Five candidates were eliminated.

The reason NIST launched this process is worth stating plainly. Two of its three existing post-quantum signature standards, ML-DSA (FIPS 204) and FN-DSA (FIPS 206, expected 2027), are lattice-based. If someone breaks the Module-LWE hardness assumption, both fall simultaneously. SLH-DSA (FIPS 205) would survive, but its signatures run up to 17 KB — too large to be the only option left standing. NIST is building insurance.

The headline number belongs to SQIsign: 148-byte signatures at NIST security category 1, smaller than RSA-2048. For DNSSEC, firmware signing, and IoT authentication, that compactness is transformative. HAWK offers integer-only arithmetic, removing the floating-point requirement that makes FN-DSA difficult to deploy securely on microcontrollers without dedicated FPUs. The multivariate candidates (the UOV family) survived despite enduring the 2025 wedge attack — NIST kept them because their signature compactness is unique, but standardisation will take longer than the rest.

None of this changes what organisations should be doing in 2026. ML-DSA and SLH-DSA are final standards. The additional signature process won’t produce finals before 2028–2030 at the optimistic end. The practical implication of IR 8610 is narrower but important: treat algorithm selection as a policy decision that can be rotated, not a constant baked into code. NIST is explicitly running a parallel track to its own recently published standards. Crypto-agility is the only rational response.

The operational bottleneck

The NTU/OCBC paper addresses something more immediately pressing: why hasn’t the migration that can happen today actually happened?

The research team built an automated TLS configuration-parsing framework and applied it to 8,443 real-world Nginx config files from public GitHub repositories. The quantum vulnerability finding is unambiguous: post-quantum hybrid key exchange adoption is exactly zero in the measured corpus. X25519MLKEM768 appears in four configurations — 0.8% of those that explicitly specify a curve at all. More immediately concerning: 28.9% use RSA key exchange with no forward secrecy, a pre-quantum vulnerability requiring no quantum hardware to exploit — only a future key compromise. A further 21.8% still permit TLS 1.0 or 1.1.

The paper’s core argument is that the bottleneck is operational, not algorithmic. X25519MLKEM768 is available in current OpenSSL and BouncyCastle. The algorithms exist. The libraries support them. What organisations lack is precise visibility into what each TLS endpoint is actually configured to permit — not what it negotiates in a live handshake, but what fallbacks are sitting dormant in config files, invisible to any network scanner.

To demonstrate that migration is tractable once visibility is established, the team deployed hybrid PQC at OCBC Bank in Singapore: an Apache web server and a Java/Spring Boot API gateway, both migrated to X25519MLKEM768. Zero changes to the banking application. Performance overhead: +23% on connection establishment (24.7 ms to 30.4 ms), +1.3% end-to-end latency, zero errors under 100 concurrent clients. The lesson is that TLS termination can be migrated independently of the applications it protects. The one caveat worth flagging: organisations with HSM-backed private keys need to assess HSM firmware compatibility before migration begins. Discovering HSM incompatibilities mid-migration is a common failure mode that pre-deployment scanning can prevent.

PQC on constrained hardware

Feingold and Yu put FN-DSA (FALCON-1024) on three Raspberry Pi 5s running an MQTT motion-sensor network using the liboqs, oqs-provider, OpenSSL, and mosquitto open-source stack. The finding runs counter to common assumption: FALCON-1024 certificate generation averaged approximately 69 ms versus RSA-2048’s 320 ms on the same hardware — roughly 4.5 times faster. RSA certificate generation is dominated by large-integer primality testing and modular exponentiation; FALCON uses NTRU lattice polynomial arithmetic and fast Fourier transforms, which are genuinely more efficient at equivalent security levels on constrained silicon.

The honest caveat: FALCON’s Gaussian sampling relies on floating-point arithmetic, which creates timing leak and side-channel risk. For IoT deployments in physically accessible environments, SOLMAE — a similar scheme designed explicitly for side-channel resistance — is identified as the logical next step.

The practical point is the open-source stack: liboqs + oqs-provider + OpenSSL + mosquitto, all publicly available, all running on off-the-shelf ARM hardware today.

The NZ read

Our April scan found zero origin-side PQC across NZ’s water, wastewater, and transport sectors. Health was 80% PQC-positive in total and zero at origin — every result was CDN-delivered. The NTU/OCBC paper explains the mechanism: organisations don’t know what their own TLS configurations actually permit as fallbacks, let alone what internal service meshes and API gateways are running. A CDN enabling post-quantum TLS by default is useful; it measures the edge, not the perimeter.

The OCBC proof-of-concept is the “this is what starting looks like” template for NZ banks that haven’t moved. ASB, BNZ, Westpac, and Kiwibank all showed no origin-side PQC in the April scan. The NTU/OCBC deployment demonstrates that a comparable institution can migrate its TLS termination layer with manageable overhead and no application changes. The operational template exists.

The FALCON-on-Raspberry-Pi result dismantles the remaining excuse for NZ’s water and energy IoT estate. The DPMC Critical Infrastructure Bill is expected later in 2026. Organisations that begin their cryptographic inventory now will be compliant by default when it arrives.

There is no prize for going last.

References:

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, TLS configuration auditing, and PQC migration planning. Get in touch.