Sovereign post-quantum migration for Irish regulated firms.

What the Programme delivers in mid-August 2026

The Ireland Quantum Security Programme launches mid-August 2026 as a 12-week structured engagement against a defined Day 1 artefact set. We do not arrive with a workshop deck. We arrive with scanners, an inventory schema, and a migration ordering matrix scoped to your environment. The deliverables that land in your hands inside the first sprint:

• Cryptographic discovery scan — passive and active enumeration of every asymmetric primitive in use across your estate. This covers TLS endpoints (handshake fingerprinting against a pinned cipher-suite catalogue), X.509 chains harvested from internal CAs and public issuers, SSH host and user keys via banner sweeps, S/MIME and PGP keyrings on user endpoints, signed artefacts (Authenticode, jarsigner, GPG-signed RPM/DEB, container image signatures), VPN tunnels (IKEv2 proposals, OpenVPN tls-crypt material), and DNSSEC zone signing keys. Output is a normalised JSON inventory keyed by algorithm, parameter set, key length, validity window, and rotation owner.
• Key-asset inventory — every RSA-2048, RSA-3072, ECDSA P-256, Ed25519, X25519, DH-2048 key in scope, mapped to the system that uses it and the data class it protects.
• Migration ordering matrix — a dependency-resolved schedule that sequences KMS/HSM, CA hierarchy, code-signing, TLS, SSH, DNSSEC, and application-layer signing. Detailed in §5.
• Hybrid TLS rollout playbook — concrete configuration for X25519MLKEM768 (the hybrid group registered in the IANA TLS registry, deployed by Cloudflare and Chrome from 2024) on the load-balancer estate you actually run: F5, NGINX with the OQS provider, HAProxy, AWS ALB/CloudFront, Cloudflare, Akamai. Includes fallback ladder, MTU implications (the ClientHello crosses the 1500-byte boundary — middlebox testing is mandatory), and observability hooks.
• HSM/KMS readiness gap report — current firmware levels and PQ algorithm support across your Thales Luna, Entrust nShield, Utimaco, AWS KMS, GCP Cloud KMS, Azure Key Vault Managed HSM. Vendor-by-vendor: which firmware track exposes ML-DSA signing, what FIPS 140-3 module validation status applies, and the cost envelope for the upgrade.
• CISO-to-board PQ-risk briefing pack — a 14-slide deck written for an audit committee, with the SNDL threat framed in regulatory rather than cryptographic terms, and a defensible spend profile across the 24-month horizon.

The Q-Day threat model — store now, decrypt later

Q-Day is the date a cryptographically-relevant quantum computer (CRQC) executes Shor's algorithm at a scale sufficient to factor RSA-2048 or solve ECDLP on P-256 in operationally useful time. Estimates from the 2023 Global Risk Institute survey place the median expert view at 2033–2040 with a non-trivial tail before 2030. The exact date is not the planning input. The planning input is the Store Now, Decrypt Later (SNDL) adversary, who is acting today.

SNDL is a passive collection pattern: a state-level adversary captures ciphertext on the wire — TLS sessions, IPsec tunnels, encrypted backups in transit, S/MIME mail crossing the public internet — and stockpiles it against future decryption. Every byte protected by a classical KEM (ECDHE, RSA key transport, finite-field DH) that is captured today is decryptable on Q-Day. Forward secrecy does not save you: the ephemeral session key was wrapped by a long-term key whose security collapses under Shor.

The triage question for a CISO is not "when is Q-Day". It is: what data did my firm transmit in 2024–2026 that is still sensitive in 2035? For an Irish retail bank: customer PII, AML investigation files, mortgage underwriting data, internal credit models, executive correspondence, RTGS settlement metadata. For a life assurer: 30-year policy data, medical underwriting, beneficiary records. For a semi-state: critical-infrastructure design documents, OT network topologies, government correspondence under the 30-year rule.

The asset classes that move first under SNDL pressure are those where (a) the data has a long sensitivity tail and (b) the ciphertext is plausibly being captured. That is overwhelmingly external TLS, site-to-site VPN, and inter-DC replication traffic. Internal east-west traffic on a private fibre is a lower SNDL priority and can follow the standards-driven schedule.

NIST FIPS 203/204/205 — the standards we migrate to

NIST published the final post-quantum standards on 13 August 2024:

• FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, formerly CRYSTALS-Kyber). Module-LWE hard problem. Replaces ECDH/RSA key transport.
• FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm, formerly CRYSTALS-Dilithium). Module-LWE/SIS. The default signature replacement for Ed25519/ECDSA.
• FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, formerly SPHINCS+). Hash-based, conservative, large signatures. The hedge against an unforeseen lattice break.

The parameter sets we deploy by default:

• ML-KEM-768 for general TLS and KMS key wrapping (NIST Category 3, ~AES-192 equivalent classical/quantum security). ML-KEM-1024 (Cat 5) for long-lived backup wrapping and root-CA key transport.
• ML-DSA-65 (Cat 3) for issuing certificates, code-signing, S/MIME. ML-DSA-87 (Cat 5) for root-CA signing and software-update root keys.
• SLH-DSA-128s (small-signature, slow-sign variant, SHA-256) reserved for root-of-trust signing where the signature volume is low and lattice-failure resistance is the priority — firmware update roots, offline root CAs, backup signing keys.

We do not pick the smallest parameter sets. ML-KEM-512 and ML-DSA-44 are at NIST Category 1 (~AES-128). Category 1 is defensible today, but the marginal cost of moving to Category 3 is small (ML-KEM-768 ciphertext is 1088 bytes versus 768 for ML-KEM-512), and the cryptanalytic margin matters for 25-year data. The Programme defaults to Cat 3 across the board and Cat 5 for roots-of-trust.

Hybrid first, pure-PQ second

For TLS in 2026, the right answer is hybrid. Specifically: X25519MLKEM768 (IANA codepoint 0x11EC), the hybrid named group standardised in draft-kwiatkowski-tls-ecdhe-mlkem and shipping in BoringSSL, the OQS OpenSSL provider, and Go's crypto/tls from Go 1.24. The handshake derives the shared secret from the concatenation of the X25519 output and the ML-KEM-768 shared secret, fed through the TLS 1.3 key schedule.

The hybrid construction gives you two properties simultaneously: (1) if ML-KEM is broken cryptanalytically — and lattice schemes are younger than ECC, this is a non-zero risk — your session is still protected by X25519; (2) if a CRQC arrives, your session is protected by ML-KEM. Cloudflare reports that as of 2024 the majority of inbound TLS to its edge from modern Chrome already negotiates this group. The deployment cost is a larger ClientHello (~1.2 KB additional) and a small CPU delta. The fragility is middleboxes that drop fragmented ClientHellos — the playbook covers detection and remediation.

Pure-PQ is the wrong default for general TLS in 2026 because the ecosystem (libraries, HSM firmware, FIPS 140-3 validations, browser support, observability) is not yet uniformly stable, and removing the classical hedge before the ecosystem matures is unnecessary risk.

Pure-PQ is the right move today for a specific class of asset: long-lived signed artefacts where the signature must remain verifiable and unforgeable for decades, and where a hybrid signature is operationally awkward. Specifically:

• Code-signing roots (Authenticode, jarsigner, Linux package signing) — sign with ML-DSA-87 or SLH-DSA-128s.
• Document signing under eIDAS where the signature must verify in 2050 — ML-DSA-65.
• Firmware update roots in OT and embedded estates — SLH-DSA-128s for the conservative hedge.
• Software bill-of-materials and supply-chain attestations (Sigstore, in-toto) — ML-DSA-65.

The migration ordering matrix — the order that minimises pain

Migration sequence is not arbitrary. It is dictated by the dependency graph: you cannot issue a PQ certificate from a CA whose signing key is still RSA, and you cannot operate a PQ-signing CA on an HSM that does not expose ML-DSA. The Programme runs the following order:

1. KMS / HSM firmware uplift — dependency: vendor firmware. 2026 readiness: Thales Luna 7.x with PQ firmware (limited), Entrust nShield 13.x roadmap, AWS KMS hybrid post-quantum TLS for API calls (already GA), Azure Managed HSM and GCP Cloud KMS PQ in preview tracks. Window: 0–8 weeks.
2. CA hierarchy — issue parallel PQ root and intermediate CAs (dual-stack PKI, not in-place migration). Dependency: HSM ML-DSA support. Window: 4–16 weeks.
3. S/MIME and code-signing — dependency: PQ CA, client support (S/MIME PQ is dependent on Outlook/Apple Mail, currently lagging; code-signing toolchains signtool/jarsigner/cosign are advancing faster). Window: 12–24 weeks.
4. TLS server certificates — dependency: PQ intermediate CA, but more importantly client compatibility. The pragmatic step in 2026 is hybrid KEM with classical signatures; PQ signatures in TLS certificates wait for browser roots to ship. Window for hybrid KEM: 8–20 weeks. PQ signatures: 2027+.
5. SSH host and user keys — OpenSSH 9.9 (Sept 2024) made mlkem768x25519-sha256 the default key exchange. Host-key signature migration to ML-DSA tracks OpenSSH 10.x. Window: 12–28 weeks.
6. DNSSEC zones — BIND 9.20+ has experimental PQ signing; production rollout depends on resolver support and the IETF dnsop working group's algorithm registration. The signature size problem (ML-DSA-65 is ~3.3 KB) interacts badly with UDP DNS. Window: 2027 for production zones.
7. Application-layer signed payloads