Post-Quantum Cryptography: A DevOps Engineer's Migration Playbook

The Clock Is Ticking

Gartner's latest advisory is unambiguous: asymmetric cryptography that organizations rely on today will be unsafe by 2030. The threat isn't theoretical — "harvest now, decrypt later" attacks are already underway, with adversaries collecting encrypted data today to decrypt once quantum computers mature.

For DevOps teams, this isn't a distant concern. The migration to post-quantum cryptography (PQC) is a multi-year infrastructure project, and the window to start is now.

Understanding the Threat Model

What Quantum Computing Breaks

Quantum computers using Shor's algorithm will efficiently factor large numbers and compute discrete logarithms, breaking:

• RSA (all key sizes)
• ECDSA/ECDH (all curves)
• DH key exchange (all groups)
• DSA signatures

This means TLS, SSH, VPNs, code signing, certificate authorities, and JWT tokens are all vulnerable.

What Remains Safe

Symmetric algorithms (AES-256) and hash functions (SHA-256, SHA-3) remain quantum-resistant with doubled key sizes. Grover's algorithm only provides a quadratic speedup against these, so AES-256 becomes equivalent to AES-128 strength — still secure.

The NIST PQC Standards

NIST finalized the first wave of post-quantum standards in 2024:

• ML-KEM (FIPS 203): Key encapsulation mechanism based on CRYSTALS-Kyber. Use for TLS, SSH, VPN key exchange.
• ML-DSA (FIPS 204): Digital signature algorithm based on CRYSTALS-Dilithium. Use for code signing, certificates, JWT.
• SLH-DSA (FIPS 205): Stateless hash-based signature scheme based on SPHINCS+. Use as a conservative backup for signatures.

The Migration Playbook

Phase 1: Inventory and Assessment (Weeks 1-4)

Step 1: Cryptographic inventory

Scan your infrastructure for all cryptographic usage:

# Find all certificate files
find /etc -name '*.pem' -o -name '*.crt' -o -name '*.key' 2>/dev/null

# Check TLS cipher suites on your services
nmap --script ssl-enum-ciphers -p 443 your-service.example.com

# Audit SSH key types across your fleet
for host in $(cat hosts.txt); do
  ssh $host 'cat /etc/ssh/ssh_host_*_key.pub' 2>/dev/null | awk '{print $NF, $1}'
done

Step 2: Classify data sensitivity

Prioritize migration based on data longevity:

• Urgent: Data that must remain confidential for 10+ years (healthcare, finance, government)
• High: Authentication and signing systems (certificates, SSH, code signing)
• Medium: Session-based encryption (TLS for web traffic with ephemeral data)
• Lower: Internal-only services with short-lived data

Phase 2: Hybrid Implementation (Weeks 5-12)

The industry consensus is to deploy hybrid cryptography — combining classical and post-quantum algorithms. If either is broken, the other provides protection.

TLS Migration:

OpenSSL 3.5+ supports hybrid key exchange. Update your Nginx/Traefik configuration:

ssl_ecdh_curve X25519MLKEM768:X25519:secp384r1;
ssl_protocols TLSv1.3;

This uses X25519+ML-KEM-768 hybrid key exchange for TLS 1.3 connections.

SSH Migration:

OpenSSH 9.x supports PQC key exchange:

# Generate hybrid SSH keys
ssh-keygen -t ml-kem-768-x25519 -f ~/.ssh/id_pqc

# Update sshd_config
KexAlgorithms mlkem768x25519-sha256,curve25519-sha256

Certificate Authority:

Deploy hybrid certificates that contain both classical and PQC signatures. This ensures backward compatibility while adding quantum resistance.

Phase 3: Testing and Validation (Weeks 13-16)

Compatibility testing:

• Test all clients and services with hybrid TLS
• Verify SSH connectivity across your fleet
• Check that older clients gracefully fall back to classical algorithms
• Load test to measure PQC performance overhead (expect 10-30% increase in handshake time)

CI/CD integration:

# Add PQC compliance checks to your pipeline
pqc-audit:
  stage: security
  script:
    - pqc-scanner --config pqc-policy.yml --fail-on classical-only
    - openssl s_client -connect $SERVICE:443 | grep -i 'kem\|kyber'
  allow_failure: false

Phase 4: Full Migration (Weeks 17-24)

1. Rotate all certificates to hybrid PQC certificates
2. Update VPN configurations to use PQC key exchange
3. Migrate code signing to ML-DSA signatures
4. Update JWT token signing to PQC algorithms
5. Deprecate classical-only cipher suites

Performance Considerations

PQC algorithms have larger key sizes and slightly higher computational costs:

For most web services, the overhead is negligible. For high-throughput API gateways, benchmark carefully and consider hardware acceleration.

Common Pitfalls

1. Don't wait for perfect standards — NIST standards are finalized. Hybrid deployment protects you now.
2. Don't forget embedded systems — IoT devices, HSMs, and firmware may need separate upgrade paths.
3. Don't ignore key management — PQC keys are larger. Update your key management infrastructure.
4. Don't skip the inventory — You can't migrate what you don't know about.

The Timeline

IBM's roadmap targets a quantum-safe ecosystem by 2030. That means:

• 2026: Start cryptographic inventory and hybrid deployments
• 2027-2028: Complete migration of all externally-facing services
• 2029: Migrate internal services and legacy systems
• 2030: Deprecate all classical-only cryptography

Starting today gives you a four-year runway. Starting in 2028 makes it a fire drill.

Getting Started This Week

1. Run a cryptographic inventory scan on your infrastructure
2. Update OpenSSL to 3.5+ and enable hybrid key exchange in your reverse proxy
3. Generate PQC SSH keys for your team
4. Add PQC compliance checks to your CI/CD pipeline
5. Brief your security team on the migration timeline

The quantum threat is real, the standards are ready, and the tools exist. The only missing piece is execution.