Table of contents
- Why quantum computers are a true game-changer
- The state of standards: what NIST is doing
- Understanding post-quantum algorithm families
- Real threat vs. hype: where we stand with quantum hardware
- A quantum-safe roadmap for organizations: crypto-agility first
- Focus: critical infrastructure (energy and transport)
- Regulatory landscape: EU and U.S.
- Practical example: generate quantum-safe keys with liboqs-python
- Bringing TLS into the post-quantum era: hybrid and controlled rollout
- PKI and code-signing: what security teams must tackle
- Performance and engineering challenges
- 90-Day “quantum-safe” starter plan
- Act now with crypto-agility; govern the change
- (Appendix) Extra operational snippets
The promise and the threat of the quantum era is now tangible. Quantum computers are advancing fast, and with them rises the danger that today’s ubiquitous asymmetric algorithms RSA and ECC will eventually become breakable in practical time.
This article provides a technical yet accessible guide to why quantum computing undermines classical cryptography, what the National Institute of Standards and Technology (NIST) and other agencies are doing to define post-quantum standards, and how to build a quantum-safe roadmap for your organization through crypto-agility, hybrid cryptography, and key-inventory management.
You’ll also find practical Python code examples using post-quantum libraries, insights for critical infrastructure sectors like energy and transport, and regulatory updates from the U.S. and the European Union.
Why quantum computers are a true game-changer
In classical computing, the security of public-key systems relies on the infeasibility of certain mathematical problems: integer factorization (the basis of RSA) and elliptic-curve discrete logarithm (for ECC). A sufficiently large quantum computer, running Shor’s algorithm, can solve both in polynomial time, meaning that once we have enough logical qubits, an attacker could derive private keys directly from public keys, shattering confidentiality and authentication across modern cryptography.
Symmetric systems (like AES or SHA-2/3) are less vulnerable: Grover’s algorithm halves their effective key strength, which can be countered by simply doubling key lengths (e.g. AES-256). Thus, the main risk concerns asymmetric cryptography.
Two crucial risk concepts to remember:
- Harvest now, decrypt later
Today, encrypted data with long-term value such as healthcare records, financial information, and industrial secrets is being intercepted and stored with the expectation that it can be decrypted in the future once sufficient quantum computing capabilities become available. Even a threat that is five to ten years away requires immediate action when the data involved retains its value over time. - Cryptographic dependency inertia
Encryption is everywhere: TLS, PKI, VPNs, SSH, IoT, firmware signing, industrial protocols.
Replacing all these components safely can take many years so planning must start now.
The state of standards: what NIST is doing
In 2024, NIST released the first three quantum-resistant FIPS standards:
- FIPS 203 (ML-KEM, from CRYSTALS-Kyber) – for key establishment;
- FIPS 204 (ML-DSA, from CRYSTALS-Dilithium) – for general digital signatures;
- FIPS 205 (SLH-DSA, from SPHINCS+) – for conservative hash-based stateless signatures.
In 2025, NIST also announced HQC (Hamming Quasi-Cyclic) as an additional code-based KEM candidate, expanding algorithmic diversity.
The NSA, via its CNSA 2.0 suite, published migration timelines: transition starts now, prioritizing software and firmware signing, with full quantum-safe adoption projected between 2031 and 2035 for U.S. national-security systems.
In Europe, the European Commission launched a Coordinated Implementation Roadmap (2025) to synchronize Member States, essential service operators, and supply chains in adopting post-quantum cryptography under NIS2 and related cyber security frameworks.
Understanding post-quantum algorithm families
Post-quantum algorithms are not based on factorization or discrete logarithms, but on problems considered resistant to quantum attacks: lattice-based schemes (such as Kyber/Dilithium), hash-based schemes (SPHINCS+), code-based schemes (HQC), multivariate schemes (less widely adopted today), and isogeny-based schemes (largely scaled back following critical cryptanalytic attacks). Each family involves trade-offs in terms of key sizes, performance, ciphertext or signature size, and security properties.
A reasonable best practice for enterprise environments includes:
- Favoring lattice-based KEMs (e.g., ML-KEM/Kyber) for key agreement in protocols such as TLS, and ML-DSA/Dilithium signatures for code signing and server authentication.
- Using SLH-DSA/SPHINCS+ in scenarios where conservative, hash-based robustness (stateless) is a priority and larger signature sizes are acceptable.
- Staying up to date on the security profiles of standards and implementations (FIPS versions, approved parameters, certifications).
The Open Quantum Safe (OQS) project website provides a solid overview of supported algorithms and parameters, making it particularly useful for prototyping and testing.
Real threat vs. hype: where we stand with quantum hardware
IBM has publicly shared a roadmap toward fault-tolerant quantum systems (e.g., the Quantum Starling project planned for 2029), signaling accelerated industrial momentum toward logical qubits and large-scale error correction. While a practical RSA-breaking machine is not imminent, investment and progress make early migration essential especially for data requiring decades-long secrecy.
IBM’s Quantum Safe suite (Explorer, Remediator, Guardium Quantum Safe) already helps enterprises discover, assess, and remediate cryptographic dependencies.
National cyber security centers (like the UK NCSC) also recommend 2035 as a reasonable horizon for critical infrastructure to complete the quantum-safe transition.
A quantum-safe roadmap for organizations: crypto-agility first
The quantum-safe transformation is not (just) about replacing RSA with Kyber. It is a program: multi-year, cross-functional, with governance and measurable outcomes. What follows is an operational outline that can be adopted as a migration plan.
1) Build your cryptographic inventory
Identify where and how encryption is used:
- Channels
TLS, VPN, SSH, IPsec, Wi-Fi Enterprise - Objects
X.509 certificates, tokens, firmware signing, encrypted backups - Software
Libraries like OpenSSL, WolfSSL, brokers, databases - Devices
IoT, ICS/SCADA, 5G/Edge components
Discovery tools (source and binary scanners, traffic analysis, PKI inventories) help estimate the impact: how many keys, which algorithms, and with what lifetimes? (IBM Quantum Safe Explorer and Remediator are a commercial reference for this phase.)
2) Assess data lifetime risk
Classify data flows based on the required secrecy and integrity horizon:
- Long-value data (healthcare, intellectual property, defense, telco core, regulated financial data) should be protected now using quantum-resistant or hybrid schemes.
Transient data can tolerate a later migration, but only if crypto-agility is already in place.
3) Embrace crypto-agility
Crypto-agility means you can update algorithms and keys without redesigning your entire system:
- Configuration layers separated from application code
- Abstracted KEM/SIG APIs
- Algorithm configuration via policies
- Automated testing pipelines for regression and algorithm rotation
- PKI support for post-quantum OIDs and CSR formats
- HSM/KMS compatibility with PQC schemes
4) Adopt hybrid cryptography
Combine classical and post-quantum primitives, e.g. X25519 + ML-KEM, or ECDSA + ML-DSA.
If one scheme fails, the other preserves security. This approach is endorsed by IETF and major TLS vendors.
5) Prioritize firmware/code signing
CNSA 2.0 guidelines and common sense converge on one point: prioritize code and firmware signing immediately (supply chain!) Move early to ML-DSA (Dilithium) or SLH-DSA (SPHINCS+) for signing bootloaders, embedded systems, and critical devices.
6) End-to-end upgradability
Design secure update channels (firmware over the air, certificate management) that can handle larger key and signature sizes, increased latency, and memory usage. Assess the impact on MTU, fragmentation, heavier handshakes, and hardware accelerators (HSMs, TLS offload NICs).
7) Establish governance and metrics
Define KPIs: % of traffic covered by post-quantum/hybrid KEM, % of binaries signed with ML-DSA/SLH-DSA, Mean Time to Crypto-Change (time required to rotate algorithms/parameters), compliance with EU roadmap and industry-specific requirements (payments, healthcare, energy). Document everything in the risk register.
Focus: critical infrastructure (energy and transport)
For operational technology (OT), migration is complex: legacy devices, minimal downtime, real-time constraints, and distributed assets.
Recommended practices:
- Segmentation and “crypto gateways”
If you cannot update the PLC, encrypt and authenticate upstream, using an Edge gateway that terminates hybrid TLS 1.3 or a “quantum-safe” tunnel to the control center. - Firmware signing first
Ensure that only firmware signed with a post-quantum scheme can be installed, even if communication remains legacy for a period. - Remote control
For low-bandwidth connections (RM/PMR, VSAT), plan compact signature formats (e.g., ML-DSA with appropriate parameters) and key rotation with pre-positioning. - Supply chain
Enforce quantum-safe requirements in specifications, requesting proof of crypto-agility from vendors (roadmaps, labs, FIPS compliance).
The UK NCSC suggests milestones to complete migration by 2035: useful as a temporal reference for essential operators who must plan well in advance.
Regulatory landscape: EU and U.S.
- European Union
The 2025 Coordinated Implementation Roadmap aligns with NIS2 and defines national migration guidelines. - United States
FIPS 203/204/205 finalized; CNSA 2.0 defines mandatory adoption timelines. - ENISA
Technical and adoption overviews (algorithm families, mitigations). Excellent for setting internal policies and training materials.
Practical example: generate quantum-safe keys with liboqs-python
To experiment quickly, the Open Quantum Safe community provides liboqs (C) and liboqs-python (“oqs” on PyPI). With just a few lines, you can try ML-KEM (Kyber) for key exchange and ML-DSA (Dilithium) for signing. (Perfect for development environments and PoCs; in production, follow FIPS guidelines and your certification/HSM requirements.)
Requirements: Python 3.10+, pip install oqs (liboqs bindings)
KEM example – ML-KEM (Kyber)
import oqs
kem_name = "ML-KEM-768"
with oqs.KeyEncapsulation(kem_name) as server_kem:
public_key = server_kem.generate_keypair()
with oqs.KeyEncapsulation(kem_name) as client_kem:
ciphertext, shared_secret_client = client_kem.encap_secret(public_key)
shared_secret_server = server_kem.decap_secret(ciphertext)
assert shared_secret_client == shared_secret_server
print(f"Shared secret ({len(shared_secret_client)} bytes) established quantum-safely.")Digital signature example – ML-DSA (Dilithium)
import oqs
sig_name = "ML-DSA-65"
message = b"Critical message to sign"
with oqs.Signature(sig_name) as signer:
public_key = signer.generate_keypair()
signature = signer.sign(message)
with oqs.Signature(sig_name) as verifier:
ok = verifier.verify(message, signature, public_key)
print("Signature verified:", ok)These snippets show minimal KEM and signature operations, useful for TLS handshake, useful for application-level TLS prototypes, secret exchange for symmetric encryption (e.g., AES-256-GCM), and gradual replacement of RSA/ECDSA signatures in code-signing pipelines. For C examples and OpenSSL 3 integration with the OQS provider (including TLS demos and X.509), see the official examples.
Bringing TLS into the post-quantum era: hybrid and controlled rollout
A realistic approach:
- Map TLS terminators (ingress, API gateways, load balancers, proxies) and update the stack to a version that supports modern ciphersuites and KEMs, preferably with hybrid support (e.g., X25519 + ML-KEM).
- Pilot deployments on low-risk internal domains, then on critical internal services (mTLS), and finally on public front-ends monitoring latency, CPU usage, and client compatibility (browsers, SDKs, legacy agents).
- Certificate rotation
Start with dual certificates (ECDSA + ML-DSA) or delegated credentials where available, to avoid breaking un-updated clients. - Observability
Collect handshake metrics (failures, fallbacks), KEM negotiation, and client version distribution. - Policy
Set server-side algorithmic preferences, maintaining a temporary compatibility baseline but with clearly defined expiration dates.
PKI and code-signing: what security teams must tackle
- CA hierarchies
You will need new CAs and X.509 profiles with extensions/OIDs for post-quantum algorithms. Verify that your HSMs can generate/manage ML-DSA/SLH-DSA keys (or use software pre-provisioning with later migration to HSM). - CRL/OCSP
Signature and key sizes increase; stress-test latency and response sizes, and adjust TTL and caching accordingly. - Time-stamping and supply chain
Use post-quantum signatures for build artifacts, containers, packages (signed SBOMs), drivers, and firmware. CNSA 2.0 encourages doing this now, since devices will remain in the field for years.
Performance and engineering challenges
- Key size
Ciphertexts and signatures are bigger plan for MTU limits. - Latency
Lattice-based KEMs are fast but differ from ECDH; benchmark on real hardware. - Compatibility
Legacy clients won’t understand PQC OIDs use hybrid rollout. - Toolchains
Ensure compilers, libraries, and HSMs support PQC algorithms.
90-Day “quantum-safe” starter plan
Days 0–30
- Appoint a Crypto Program Owner.
- Launch key and algorithm discovery.
- Pick 2–3 pilot cases: code signing, mTLS, firmware signing.
Days 31–60
- Implement dual-signing in CI/CD (ECDSA + ML-DSA).
- Test mTLS with hybrid KEM.
- Design your quantum-ready PKI.
Days 61–90
- Expand pilots to low-risk production systems.
- Measure performance and compatibility.
- Define a 12–24-month migration roadmap.
(Commercial tools like IBM Quantum Safe can assist with discovery and remediation.)
Act now with crypto-agility; govern the change
The shift to post-quantum cryptography is not a routine update. It requires governance, new PKI, hybrid protocols, and most importantly crypto-agility. The standards are ready (FIPS 203/204/205, CNSA 2.0, EU PQC Roadmap); the risk is real (“harvest now, decrypt later”).
Organizations that act today starting with code signing, hybrid TLS, and key inventory will be better positioned for a secure digital future. In the quantum age, preparation is protection.
Frequently asked questions
- What’s the difference between “post-quantum” and “quantum-safe”?
“Post-quantum” describes algorithms resilient to quantum attacks; “quantum-safe” covers the broader goal of end-to-end resistance, including processes and migration. - Should I drop RSA and ECC right now?
Not yet, but plan for it. Start using hybrids (X25519+ML-KEM, ECDSA+ML-DSA) and prioritize code signing. Build crypto-agility. - Are symmetric algorithms affected?
Less so. Increase key sizes (AES-256) and use strong hashes (SHA-256+). Quantum attacks reduce their effective strength by √n. - Which standards apply?
Follow FIPS 203/204/205, CNSA 2.0, and the EU PQC Roadmap under NIS2. - Which algorithms are safe to adopt today?
ML-KEM (Kyber) for key exchange, ML-DSA (Dilithium) for signatures, SLH-DSA (SPHINCS+) for conservative use cases, HQC as emerging alternative. - What about performance?
Benchmark on real hardware; overheads are manageable for IT systems, heavier for OT. Use gateways or edge offload when needed. - What does “harvest now, decrypt later” mean?
Attackers capture encrypted traffic today to decrypt it in the future. Long-term data must be protected immediately. - Impact on critical infrastructure?
High. Devices have long lifecycles; prioritize firmware signing and hybrid gateways. UK NCSC targets full migration by 2035. - Open-source tools for testing PQC?
Yes: Open Quantum Safe, liboqs, and oqs-python, plus OpenSSL-OQS integrations. - What’s IBM’s role?
IBM leads in quantum hardware and provides Quantum Safe tools (Explorer, Guardium QS, Remediator) for enterprise migration.
(Appendix) Extra operational snippets
Quick OpenSSL compatibility check (OQS provider in a lab)
Note: For test environments, OQS maintains a provider for OpenSSL 3 with reference post-quantum algorithms. For the full procedure, consult the official documentation and the examples.
# Lab environment only, not for production:
# 1) Build/install the OQS-OpenSSL provider following the official docs
# 2) List signature/KEM algorithms available from the provider
openssl list -signature-algorithms -provider oqsprovider -provider default
openssl list -keyexchange-algorithms -provider oqsprovider -provider default
# 3) Generate an ML-DSA keypair and a test CSR
openssl genpkey -algorithm ML-DSA-65 -provider oqsprovider -out server-ml-dsa.key
openssl req -new -key server-ml-dsa.key -out server-ml-dsa.csr -subj "/CN=example.com"
# 4) (Demo) self-signed certificate with ML-DSA
openssl req -x509 -key server-ml-dsa.key -in server-ml-dsa.csr \
-provider oqsprovider -days 30 -out server-ml-dsa.crt
Policy schema for crypto-agility (pseudocode)
crypto_policy:
version: 1
default_kem: ML-KEM-768 # preferred post-quantum KEM (FIPS 203)
fallback_kex: X25519 # for hybrid mode and compatibility
default_sig: ML-DSA-65 # post-quantum signature (FIPS 204)
dual_sign: true # enable hybrid/dual signatures during rollout
symmetric:
cipher: AES-256-GCM # robust even against Grover
hash: SHA-384
rotation:
cert_ttl_days: 180
key_ttl_days: 90
telemetry:
tls_handshake_metrics: true
kem_negotiation_breakdown: true
enforcement:
deadline_hybrid_all: "2026-12-31"
deadline_pq_only_critical: "2028-12-31"