HSM and KMS roadmap for Irish regulated firms — Thales, Entrust, AWS CloudHSM, GCP Cloud KMS PQ readiness

1. The exact problem: HSM-bound keys are not exempt from harvest-now-decrypt-later

Irish regulated firms — pillar banks, payment institutions licensed under the Central Bank, life assurers, and the public-sector bodies under NIS2 — overwhelmingly anchor their cryptographic root of trust in hardware security modules: Thales Luna 7, Entrust nShield Connect XC, AWS CloudHSM (Cavium-derived), GCP Cloud HSM (Marvell LiquidSecurity), and Azure Managed HSM. The operational assumption inside most Dublin SOCs is that because the private key never leaves FIPS 140-2 Level 3 / 140-3 Level 3 boundary, the key is safe.

That assumption is wrong against a CRQC adversary. The HSM protects key extraction; it does not protect the ciphertext on the wire. An attacker capturing TLS 1.3 handshakes today where the server presents an RSA-2048 or secp256r1 certificate and the KEX is X25519 can store the transcript and, on Q-Day, recover the ephemeral ECDH shared secret via Shor's algorithm and decrypt the entire session. The HSM-protected long-term signing key is irrelevant to that attack: the confidentiality break is on the key-agreement, not the signature.

The roadmap problem is therefore: which HSM/KMS estates can issue ML-DSA signatures, wrap symmetric keys with ML-KEM, and sign X.509 certificates with hybrid composite algorithms in production, and on what timeline. As of mid-2026 the answer is uneven, and the procurement decisions made in H2 2026 will determine whether a firm is migrated by 2030 or stranded.

2. Primitives the HSM must perform: ML-KEM-768, ML-DSA-65, SLH-DSA-SHA2-128s

The relevant FIPS-203/204/205 parameter sets for regulated workloads in Ireland map to NIST Category 3 (192-bit classical equivalent), which is the floor the ENISA PQ migration guidance and the BSI TR-02102-1 2025 update both push toward.

ML-KEM-768 (FIPS 203, formerly Kyber768): module-LWE over R_q = Z_q[X]/(X^256 + 1) with q = 3329, k = 3, η₁ = 2, η₂ = 2, du = 10, dv = 4. Public key 1184 bytes, ciphertext 1088 bytes, shared secret 32 bytes. Security goal: IND-CCA2 via Fujisaki–Okamoto transform from an IND-CPA PKE. Hardness reduces to MLWE and MLWR over the cyclotomic ring.

ML-DSA-65 (FIPS 204, formerly Dilithium3): Fiat–Shamir with aborts over module lattices. Parameters (k,l) = (6,5), η = 4, τ = 49, γ₁ = 2¹⁹. Public key 1952 bytes, signature 3293 bytes. Security goal: SUF-CMA (strictly stronger than EUF-CMA) in the QROM under MLWE and MSIS.

SLH-DSA-SHA2-128s (FIPS 205, stateless SPHINCS+): hash-based, security rests solely on the second-preimage and PRF properties of SHA-256 — no structured-lattice assumption. Signatures are 7856 bytes, signing is slow (hundreds of ms), but the conservative security argument makes it the correct choice for long-lived code-signing roots and CA root keys that must survive cryptanalytic advances against lattices.

For HSM procurement, the key engineering question is not "does it support Kyber" but "does the firmware expose CKM_ML_KEM_KEY_PAIR_GEN, CKM_ML_KEM_ENCAPSULATE, CKM_ML_KEM_DECAPSULATE and CKM_ML_DSA_* mechanisms via PKCS#11 v3.2, and are those mechanisms FIPS 140-3 validated or only vendor-attested?".

3. Vendor and reference-implementation state, mid-2026

• Thales Luna 7: firmware 7.13.x ships ML-KEM and ML-DSA as functionality modules (FM); FIPS 140-3 validation for the PQ mechanisms is in CMVP queue, not yet on the active list. SLH-DSA available but not validated.
• Entrust nShield: Security World 13.6 exposes ML-DSA-44/65/87 and ML-KEM-512/768/1024 through the CodeSafe SDK; PKCS#11 mechanism URIs follow the PKCS#11 v3.2 draft. CC EAL4+ recertification ongoing.
• AWS KMS: pq-hybrid TLS to the KMS endpoint has been generally available since 2023 (X25519+Kyber768, now migrating to X25519+ML-KEM-768 per draft-ietf-tls-hybrid-design). KMS does not yet sign with ML-DSA; the data-plane is hybrid-protected, the keys it holds are still classical.
• AWS CloudHSM: SDK 5.12 exposes ML-DSA via PKCS#11; ML-KEM in preview.
• GCP Cloud KMS: ML-DSA-65 and SLH-DSA-SHA2-128s available for asymmetric signing in HSM protection level (Marvell LiquidSecurity2 backend). ML-KEM not yet exposed at the API layer.
• Azure Managed HSM: Marvell-backed; ML-DSA in private preview, no public ML-KEM.
• liboqs 0.11: reference and AVX2 implementations of all three FIPS algorithms; the API is stable but liboqs is still labelled "not for production" by Open Quantum Safe — use it for test rigs, not for prod.
• OpenSSL 3.5 LTS (April 2025): native ML-KEM, ML-DSA, SLH-DSA via the default provider. This is the pivot release.
• BoringSSL: hybrid X25519MLKEM768 (codepoint 0x11EC) shipped to Chrome stable.
• OpenSSH 9.9+: sntrup761x25519-sha512 default since 9.0; mlkem768x25519-sha256 default from 9.9 (Sep 2024).
• BIND 9.20: ML-DSA DNSSEC signing per draft-ietf-dnsop-dnssec-pqc, experimental.

4. Deployment pattern: hybrid CA hierarchy with HSM-bound ML-DSA issuing CA

The pattern that survives audit is a composite/hybrid X.509 hierarchy: an offline SLH-DSA-SHA2-128s root, an online ML-DSA-65 issuing CA whose private key lives in the HSM, and end-entity certificates that are composite (RFC draft draft-ietf-lamps-pq-composite-sigs) carrying both ECDSA-P256 and ML-DSA-65 signatures so that legacy verifiers continue to function during the transition.

# Generate ML-DSA-65 issuing CA key inside Thales Luna via PKCS#11
pkcs11-tool --module /usr/safenet/lunaclient/lib/libCryptoki2_64.so \
  --login --pin-source env:LUNA_PIN \
  --keypairgen --key-type ML-DSA-65 \
  --label "pq-issuing-ca-2026" --id 0x02

# Issue a composite end-entity cert (ECDSA-P256 + ML-DSA-65)
openssl req -new -provider default -provider pkcs11 \
  -key "pkcs11:object=pq-issuing-ca-2026;type=private" \
  -keyform engine -sigopt composite:ecdsa-p256+ml-dsa-65 \
  -subj "/C=IE/O=Acme Bank plc/CN=api.acme.ie" \
  -out api.acme.ie.csr

# Sign with hybrid chain
openssl x509 -req -in api.acme.ie.csr \
  -CA pq-issuing-ca.pem -CAkey "pkcs11:object=pq-issuing-ca-2026" \
  -extfile v3_hybrid.cnf -days 90 -out api.acme.ie.pem

TLS termination at the edge (HAProxy 3.0 with OpenSSL 3.5, or nginx 1.27 linked the same way) negotiates X25519MLKEM768 for KEX and presents the composite certificate for authentication. The HSM performs only the ML-DSA signing operation per handshake; symmetric work stays in CPU AES-NI.

5. What breaks in production

• Handshake size blow-up. A composite cert chain with ML-DSA-65 leaf + ML-DSA-65 intermediate

  Schedule a sovereign-cryptography assessment

  Book a security call →