Building Quantum-Safe Infrastructure: A Complete Guide for Irish Enterprises | Michael English

Enterprise Security Architecture | Ireland | EU

Meta Description: Complete guide to quantum-safe infrastructure for Irish enterprises by Michael English (IMPT.io CTO). Cryptographic inventory, hybrid deployment, PKI migration, HSM selection, and EU compliance.

Target Keywords: quantum-safe infrastructure Ireland, post-quantum migration guide, PQC enterprise deployment Ireland EU, quantum-safe PKI Ireland, quantum migration enterprise Ireland, Michael English quantum infrastructure

Introduction: Moving from Awareness to Action

There is no shortage of awareness of the quantum threat in Irish enterprise security circles. NIST's finalised standards, ENISA's recommendations, NSA's CNSA Suite 2.0 mandates, and the Central Bank of Ireland's DORA guidance have collectively raised the conversation from "theoretical future risk" to "current operational priority."

What is still lacking for most Irish organisations is a concrete, step-by-step roadmap for actually building quantum-safe infrastructure. That's what this guide provides. Based on my experience architecting blockchain infrastructure at IMPT.io — where we completed our own quantum-safe migration programme — I'll walk you through every phase of the journey.

Phase 0: Leadership Alignment and Scope Definition (Week 1)

Before any technical work begins, you need executive sponsorship and clear scope. Quantum-safe migration touches every system that uses asymmetric cryptography — which is virtually every system that communicates over a network.

Getting Leadership Buy-in

The business case for quantum-safe migration centres on three pillars:

Regulatory compliance: NIS2, DORA, GDPR, and forthcoming EU Cyber Resilience Act requirements create legal obligations. Non-compliance risks fines, sanctions, and loss of operating licences.

Data protection liability: If personal data is encrypted with classically-vulnerable algorithms and later decrypted by a quantum adversary, GDPR breach notification obligations apply. The Organisation is responsible for ensuring "appropriate technical measures."

Reputational and commercial risk: Procurement increasingly includes security questionnaires that ask about quantum readiness. Government contracts and large enterprise contracts will soon mandate PQC suppliers.

Defining Scope

Scope the migration in three rings:

Ring 1 — Customer-facing systems: Web applications, APIs, mobile apps, payment processing. Protect these because customer data is directly at risk.

Ring 2 — Internal infrastructure: Server-to-server communication, database connections, internal PKI, VPN, SSH. Protect these because internal breach exposes all Ring 1 systems.

Ring 3 — Data at rest and archives: Long-lived sensitive data encrypted with asymmetric key wrapping. Protect these because harvested ciphertexts have the longest exposure window.

Phase 1: Cryptographic Inventory (Weeks 2–8)

You cannot migrate what you cannot see. A cryptographic inventory is a complete catalogue of every asymmetric cryptographic operation in your systems.

What to Catalogue

For each cryptographic touchpoint, record:

Algorithm and key size (RSA-2048? ECDSA P-256? Which ECC curve?)
Purpose (key exchange? authentication? code signing? data encryption key wrapping?)
Location (which system, which service, which library, which version)
Data lifetime (how long does data encrypted with this key need to stay confidential?)
Migration complexity (certificate? regenerate. Hardcoded? Requires code change. Protocol? Requires vendor support)
Dependencies (which other systems depend on this certificate/key?)

Inventory Tools

Automated scanning:

nmap --script ssl-enum-ciphers — scan hosts for TLS cipher suites
testssl.sh — comprehensive TLS configuration analysis
sslyze — Python-based TLS scanner
govtech-sg/certificate-inventory — scan certificate stores
Commercial tools: Keyfactor, Venafi Discovery (comprehensive cert inventory)

Code scanning:


# Find hardcoded cryptographic references in code
grep -r "RSA\|ECDSA\|secp256\|P-256\|sha1WithRSA" --include="*.java" --include="*.py" --include="*.go" /your/codebase

# Find OpenSSL cipher string references
grep -r "TLSv1\|AES128\|DHE\|ECDHE" /etc/nginx/ /etc/apache2/

Certificate inventory:


# List all certificates in a Java keystore
keytool -list -v -keystore /path/to/keystore.jks

# Check server certificate
openssl s_client -connect your-server.com:443 | openssl x509 -noout -text | grep "Public Key"

# List certificates in system store (Linux)
ls /etc/ssl/certs/ | head -20

Prioritisation Matrix

After inventory, prioritise migration by:


Priority = (Data Sensitivity × Data Longevity) / Migration Complexity

High Sensitivity × Long-lived × Low complexity = Migrate First
Low Sensitivity × Short-lived × High complexity = Migrate Last

Phase 2: Hybrid TLS Deployment (Weeks 4–10)

Hybrid TLS deployment is the highest-impact, lowest-risk first step. It adds quantum-safe key exchange to all TLS connections without removing classical security.

Nginx Configuration


# Enable hybrid key exchange in Nginx 1.25+ with OpenSSL 3.x + OQS provider
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;

# Configure hybrid key exchange groups
ssl_ecdh_curve X25519MLKEM768:x25519:secp256r1:secp384r1;
# X25519MLKEM768 = hybrid X25519 + ML-KEM-768

HAProxy Configuration


global
    ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:...
    ssl-default-bind-options ssl-min-ver TLSv1.3

frontend https_front
    bind *:443 ssl crt /path/to/cert.pem alpn h2,http/1.1
    # HAProxy 2.8+ supports OQS curves through OpenSSL integration

AWS ALB / CloudFront

AWS began rolling out PQC hybrid TLS in 2024. Enable it through:

AWS Console → EC2 → Load Balancers → Security Policy
Select ELBSecurityPolicy-TLS13-1-3-2021-06 or newer PQC-enabled policy (check current AWS documentation for availability)
No application changes required

Cloudflare

Cloudflare has deployed X25519MLKEM768 globally on its edge network. Irish businesses using Cloudflare receive quantum-safe TLS automatically for:

CDN-protected websites
Cloudflare Access (Zero Trust)
Cloudflare Gateway
API Shield

Phase 3: Certificate and PKI Migration (Months 3–9)

Your Public Key Infrastructure (PKI) — the Certificate Authorities that issue, sign, and revoke certificates — must be migrated to support PQC.

Understanding Your PKI Topology

Most organisations have:

Root CA — self-signed, very long-lived (20+ years), stored in HSM
Intermediate CAs — signed by root, 5–10 year validity
Leaf certificates — server certs, client certs, code signing certs (1–3 year validity)

Migration order: Migrate roots first (most impactful, longest lived), then intermediates, then leaf certs.

Commercial CA Quantum Readiness

DigiCert: Committed to issuing PQC-hybrid certificates and ML-DSA certificates. Participating in NIST PQC trials. Check DigiCert's website for current PQC certificate availability.

Sectigo: Has issued test PQC certificates and published PQC readiness roadmap.

Let's Encrypt: For free certificates (DV only), Let's Encrypt will follow browser/CA policy. Watch CABF (CA/Browser Forum) for PQC certificate policy timelines.

Internal CA Migration with Microsoft Active Directory CS


# Check current CA configuration
certutil -getreg CA\CSP\Provider

# For internal PKI migration, use Windows Server 2025's PKCS#11 interface
# with an OQS-capable HSM provider
# Steps:
# 1. Upgrade HSM firmware to support ML-DSA
# 2. Generate new ML-DSA root CA key pair in HSM
# 3. Create hybrid root CA (dual-signed with existing ECDSA root)
# 4. Issue new intermediate CA from ML-DSA root
# 5. Begin issuing hybrid leaf certificates

Dual-Stack Certificate Deployment

For maximum compatibility, deploy both classical and PQC certificate chains:


# Serve both ECDSA and ML-DSA certificates (dual-stack)
ssl_certificate     /etc/ssl/ecdsa_cert.pem;
ssl_certificate_key /etc/ssl/ecdsa_key.pem;

ssl_certificate     /etc/ssl/mldsa_cert.pem;
ssl_certificate_key /etc/ssl/mldsa_key.pem;
# TLS 1.3 clients that support ML-DSA will use the PQC certificate
# Legacy clients fall back to ECDSA

Phase 4: HSM and Key Management Migration (Months 6–18)

Hardware Security Modules (HSMs) are the most critical and most challenging component of quantum migration.

Assessing Your HSM Vendor Roadmap

Vendor	PQC Status (2025)
Thales Luna (nShield)	Firmware upgrade available for ML-KEM, ML-DSA on select models; new HSM 4.0 line PQC-ready
Utimaco	PQC-ready firmware for CryptoServer series; ML-KEM and ML-DSA supported
AWS CloudHSM	Preview PQC support for ML-KEM; full GA expected 2025-2026
Azure Dedicated HSM	Using Thales Luna hardware; follows Thales firmware roadmap
Entrust nShield	PQC firmware updates available; contact vendor for upgrade path
YubiKey (Yubico)	YubiKey 5 Series: no PQC support yet. Future YubiKey hardware required

Key question to ask your HSM vendor: "What is your roadmap for FIPS 140-3 certification of ML-KEM and ML-DSA operations?"

Software KMS Migration

For cloud-native organisations using software KMS:


# Python: hybrid key wrapping using OQS library
import oqs
import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

def quantum_safe_key_wrap(plaintext_key: bytes) -> dict:
    """Wrap a symmetric key using hybrid ML-KEM-768 + X25519"""
    
    # ML-KEM-768 key encapsulation
    with oqs.KeyEncapsulation("ML-KEM-768") as kem:
        public_key = kem.generate_keypair()
        ciphertext_mlkem, shared_secret_mlkem = oqs.KeyEncapsulation("ML-KEM-768").encap_secret(public_key)
    
    # Derive AES-256 wrapping key from combined shared secrets
    import hashlib
    wrap_key = hashlib.sha256(shared_secret_mlkem).digest()
    
    # Wrap the plaintext key
    nonce = os.urandom(12)
    aead = AESGCM(wrap_key)
    wrapped_key = aead.encrypt(nonce, plaintext_key, None)
    
    return {
        'wrapped_key': wrapped_key,
        'mlkem_ciphertext': ciphertext_mlkem,
        'mlkem_public_key': public_key,
        'nonce': nonce
    }

Phase 5: Application-Level Migration (Months 9–24)

Application-level migration addresses asymmetric cryptography embedded in application code — JWTs, API authentication, code signing, and custom cryptographic protocols.

JWT Migration

JSON Web Tokens (JWTs) using RS256 or ES256 must migrate to ML-DSA-65:


# pip install PyJWT oqs-python

import jwt
import oqs
import json
from datetime import datetime, timedelta

# Generate ML-DSA-65 key pair
with oqs.Signature("ML-DSA-65") as sig:
    public_key = sig.generate_keypair()
    secret_key = sig.export_secret_key()

# Create and sign JWT with ML-DSA-65
# Note: Standard JWT libraries need PQC extension; use custom implementation during transition
payload = {
    'sub': 'user-id-123',
    'iss': 'https://auth.impt.io',
    'iat': datetime.utcnow().timestamp(),
    'exp': (datetime.utcnow() + timedelta(hours=1)).timestamp()
}

SSH Key Migration


# Generate ML-KEM-768 SSH key pair (using OpenSSH + liboqs)
# Standard OpenSSH does not yet support PQC natively;
# use OQS-OpenSSH fork for testing

# With standard OpenSSH: use large classical keys as interim
ssh-keygen -t ed25519 -C "user@organisation.ie"  # Most quantum-resistant classical option

# Monitor openssh.com for native PQC support (expected 2025-2026)
# OpenSSH 9.x drafts include experimental support for ML-KEM hybrid

Code Signing Migration


# Migrate code signing to ML-DSA using OQS tools
# For production: use vendor-certified solutions (DigiCert, Sectigo)

# Test with OQS command line tools:
openssl cms -sign -in software-package.zip -signer ml-dsa-cert.pem \
  -inkey ml-dsa-key.pem -outform DER -out signature.p7s \
  -provider oqsprovider -provider default

Phase 6: Testing and Validation

Quantum-Safe Testing Checklist

[ ] TLS cipher negotiation: Verify hybrid key exchange is actually used (Wireshark capture and inspect key exchange)
[ ] Certificate chain validation: Verify full chain from ML-DSA leaf to ML-DSA root
[ ] Performance testing: Benchmark PQC operations under production load (ML-KEM adds ~15-20% to TLS handshake time — acceptable)
[ ] Interoperability: Test all clients (browsers, mobile apps, API consumers) for compatibility
[ ] Fallback behaviour: Verify graceful fallback to classical for legacy clients
[ ] Monitoring: Update intrusion detection and monitoring for PQC cipher suites

Compliance Documentation

NIS2 and DORA Evidence Package

Document your quantum-safe migration for regulatory auditors:

Cryptographic inventory report (output of Phase 1)
Algorithm selection rationale (reference NIST, ENISA, NCSC guidance)
Hybrid deployment confirmation (capture TLS handshake showing hybrid key exchange)
PKI migration plan (timeline, responsible parties, test results)
HSM vendor quantum readiness certification (vendor letters/documentation)
Incident response procedure (what to do if PQC algorithm is compromised — cryptographic agility)

Budget and Timeline Estimates

Small Irish Business (20–100 employees)

Activity	Effort	Cost Estimate
Cryptographic inventory	3 days internal	€0–€2K
Hybrid TLS (CDN/cloud)	1 day	€0 (Cloudflare/AWS config)
SSH key rotation	1 day	€0
Certificate migration	2 days	€200–€500/year cert costs
Total	~1 week	€500–€3K

Medium Irish Business (100–1000 employees)

Activity	Effort	Cost Estimate
Cryptographic inventory	2–3 weeks	€5K–€15K (internal + tooling)
Hybrid TLS deployment	1 week	€2K–€5K engineering
PKI migration	4–8 weeks	€10K–€30K
HSM firmware upgrade	2 weeks	€5K–€15K (vendor support)
Application migration	2–6 months	€20K–€80K
Total	6–12 months	€42K–€145K

Conclusion

Building quantum-safe infrastructure is not a single project — it's a multi-year programme. But the journey begins with a single step: the cryptographic inventory. Everything else follows from knowing what you have.

The good news for Irish enterprises: the tools, standards, and vendor support all exist now. The investment required is proportionate to organisational size and risk profile. And the regulatory environment — NIS2, DORA, GDPR — is increasingly compelling action regardless of internal risk appetite.

Start with Phase 1 today. The inventory is low-cost, immediately valuable, and positions you to make every subsequent decision from a place of knowledge.

Michael English is Co-Founder & CTO of IMPT.io, which has completed quantum-safe migration of its blockchain infrastructure serving EU carbon markets. He advises Irish enterprises on PQC migration. Based in Clonmel, Co. Tipperary, Ireland.

impt.io

Keywords: quantum-safe infrastructure guide Ireland, post-quantum migration enterprise, PQC deployment Ireland enterprises, quantum-safe PKI Ireland, quantum infrastructure migration EU, Michael English quantum infrastructure Ireland

Michael English — Co-Founder & CTO, IMPT.io

Michael English is Co-Founder & CTO of IMPT.io, a blockchain-based carbon credit platform operating across the EU. He writes on quantum computing, carbon markets, AI, and sustainable technology infrastructure. Based in Clonmel, Co. Tipperary, Ireland.

impt.io · mike-english.com