Quantum Safe Security
Post-quantum cryptography for business leaders: why the migration is already underway, what it involves, and how to plan it without panic or procrastination.
1. What it is, in one paragraph
2. How the threat actually works
3. The current state: standards, regulators, and timelines
4. The algorithm landscape — what you'll be deploying
5. Where it matters for your business — which is to say, everywhere
6. What implementing PQC actually looks like
7. The honest economics
8. Crypto-agility, the most important architectural decision you'll make
9. A practical five-phase migration roadmap
10. Common pitfalls to avoid
11. When to act — spoiler: now
Almost all the encryption that protects the world's digital infrastructure today — HTTPS, VPNs, banking, digital signatures, identity, blockchain, software updates, messaging — relies on two mathematical problems: integer factorisation (RSA) and elliptic curve discrete logarithms (ECC, ECDSA). These problems are hard for classical computers. They are not hard for a sufficiently large quantum computer. A quantum algorithm known as Shor's algorithm, running on a future fault-tolerant machine, would break them in hours. Quantum-Safe Security — also called Post-Quantum Cryptography, or PQC — is the global effort to replace that cryptography with new algorithms that resist both classical and quantum attack, before the quantum machine exists. The work has been underway for a decade, the first standards were finalised in 2024, and every serious organisation is now either migrating or planning to.
If you remember one thing from this page: this is not a theoretical problem for the next decade. It is an operational problem for the current one.
To decide how to respond, you need to understand two things about the threat: what the quantum computer will break, and when it will break it.
What it will break. Shor's algorithm breaks public-key cryptography — the algorithms used to establish secure channels, sign software, and authenticate identities. Specifically: RSA (any key size), elliptic-curve systems (ECDH, ECDSA, Ed25519), Diffie-Hellman, and most of what secures TLS, SSH, VPNs, code-signing, and document signatures today. It does not break symmetric cryptography (AES, ChaCha20) or most cryptographic hash functions (SHA-256, SHA-3) — for those, a related algorithm called Grover's reduces effective security by half, which is why AES-128 should be upgraded to AES-256, but the systems don't need to be replaced.
When it will break it. Credible estimates for a cryptographically-relevant quantum computer (roughly a million high-quality physical qubits, organised into several thousand logical qubits) range from 2030 to 2040. No one knows the exact year. This uncertainty is not a comfort — it's the core of the problem.
The "harvest now, decrypt later" threat. The most important security concept in this entire field. Adversaries — nation-states, organised crime, industrial espionage actors — are already recording encrypted traffic in bulk and storing it, betting that they will be able to decrypt it later when quantum computers arrive. Every piece of sensitive information your organisation sends over TLS today that an adversary can intercept and store (and there is a lot of it) is potentially compromised the moment a quantum computer runs Shor's, even if that moment is in 2035. If your data has a secrecy lifetime longer than the time-to-quantum — intellectual property, legal records, personal data under GDPR, trade secrets, strategic plans, medical records — the clock is already running. It has been running for years.
This is why the migration cannot wait for the quantum computer to exist. By then, a decade of your organisation's sensitive traffic is already decryptable.
After an eight-year global competition run by the US National Institute of Standards and Technology (NIST), the first Post-Quantum Cryptography standards were finalised in August 2024. This is the single most important milestone in the field. Before 2024, organisations could prepare but could not migrate — there were no approved algorithms to migrate to. That barrier is now gone.
The finalised standards are:
FIPS 203 — ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism), based on the algorithm previously known as CRYSTALS-Kyber. The primary replacement for RSA/ECDH key exchange.
FIPS 204 — ML-DSA (Module-Lattice-based Digital Signature Algorithm), based on CRYSTALS-Dilithium. The primary replacement for RSA and ECDSA signatures.
FIPS 205 — SLH-DSA (Stateless Hash-based Digital Signature Algorithm), based on SPHINCS+. A backup signature algorithm with different mathematical assumptions, for cases where diversity matters.
FIPS 206 — FN-DSA (Falcon), a fourth standard still being finalised, offering smaller signatures than ML-DSA for constrained systems.
In March 2025, NIST also selected HQC as a backup Key-Encapsulation Mechanism, to hedge against unexpected mathematical progress against lattice-based schemes. This matters because it establishes the principle of algorithmic diversity: serious deployments should be ready to switch algorithms if one is broken.
Regulatory timelines are now concrete:
United States: the National Security Memorandum NSM-10 and the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) require federal agencies and national security systems to migrate to PQC by 2033, with specific milestones starting in 2025. Federal contractors will be pulled along.
European Union: ENISA, BSI (Germany), ANSSI (France), and NCSC-NL have all published migration guidance aligned with the NIST standards. The EU's NIS2 directive implicitly applies to critical infrastructure. The European Commission's formal PQC roadmap was published in 2024 with 2030 as a key milestone for critical systems.
United Kingdom: the NCSC published detailed migration guidance in 2024, with 2035 as the end-state for national infrastructure.
Finance: the Monetary Authority of Singapore, the Bank for International Settlements, and the New York Department of Financial Services have all issued quantum-readiness guidance. Expect similar from EU regulators in the coming years.
Industry: the main technology providers (Microsoft, Google, Apple, AWS, Cloudflare) have already deployed hybrid PQC in significant parts of their infrastructure. Signal, iMessage, and Chrome all use PQC today.
The industry consensus — confirmed by NIST, ENISA, NCSC, and the major consulting firms — is that a full enterprise migration takes five to ten years. That means organisations starting in 2026 finish between 2031 and 2036, which aligns uncomfortably well with the expected quantum threat window.
You are not early. You may already be late.
You don't need to understand how these algorithms work mathematically. You do need to understand their practical characteristics, because those drive deployment decisions.
ML-KEM (Kyber) — key exchange. Replaces RSA and ECDH in TLS, VPNs, and anywhere a session key needs to be established. Mature, standardised, fast, reasonably compact (public keys ~1 KB, ciphertexts ~1 KB). This is what 99% of your migration will use for key exchange.
ML-DSA (Dilithium) — digital signatures. Replaces RSA and ECDSA signatures. Standard general-purpose signature algorithm. Signatures are larger than classical ones (2–5 KB vs 64–256 bytes for ECDSA) which matters for some bandwidth-constrained systems.
SLH-DSA (SPHINCS+) — backup signatures. Much larger signatures (~8–50 KB) and slower, but based on different mathematical assumptions (hash-based, not lattice-based). Useful for long-lived signatures and scenarios where algorithmic diversity is a security requirement.
FN-DSA (Falcon) — signatures with small size. Comparable signature size to classical ECDSA. Attractive for embedded systems, smartcards, and firmware. Harder to implement securely than Dilithium.
HQC — backup KEM. Different mathematical basis than ML-KEM. Expected final standard around 2026–2027.
AES-256 and SHA-384 / SHA-512. Symmetric cryptography. Already considered quantum-safe with sufficient key sizes. If your systems still use AES-128 or SHA-1, upgrade for reasons independent of quantum.
Hybrid modes. The current industry norm during the transition: use classical (ECDH) and post-quantum (ML-KEM) in parallel, so the connection is secure as long as either is unbroken. Cloudflare, Google Chrome, Apple iMessage, and Signal all deploy in hybrid mode today. This is also the approach recommended by ENISA, NCSC, and BSI for the transition period.
Not standardised, don't deploy yet. Beware of any vendor selling PQC based on algorithms not on the NIST list (or equivalent national standards). The "almost standardised" space is a graveyard: SIKE was broken by a classical laptop in 2022 after being a NIST finalist. Stick to finalised standards.
Unlike quantum computing, which matters only to specific sectors, quantum-safe security matters to every organisation that uses cryptography — which means essentially every organisation. The variation across sectors is not whether you need to migrate, but how urgent and how complex your migration is.
Finance and banking have the highest combination of urgency and complexity. Regulatory pressure is concrete (DORA, NYDFS, MAS), data is long-lived (contracts, account records, transaction histories), the attack surface is enormous (thousands of APIs, payment rails, inter-bank channels), and adversaries are sophisticated. Most large banks have started. Mid-size banks are behind.
Healthcare and life sciences hold data that must remain confidential for decades (medical records, genomic data, clinical trial results). HNDL is a specific, real, and regulatorily-relevant threat under HIPAA, GDPR, and equivalent frameworks. Migration complexity is compounded by legacy medical devices that cannot easily be updated.
Government, defence, and critical infrastructure face both the strongest regulatory mandates (CNSA 2.0, NIS2) and the highest-value adversaries. National security systems are typically ahead; civil government and critical infrastructure (energy, water, transport, telecom) are a mixed picture.
Technology and SaaS providers must migrate not only their own systems but the cryptography in products their customers depend on. The large hyperscalers are well underway. Mid-market SaaS is often dangerously behind — and their customers' data is at stake.
Manufacturing, automotive, aerospace face a special problem: products with long lifecycles and embedded cryptography. A car, aircraft, industrial robot, or satellite sold today must remain secure for 15–30 years. PQC-capable firmware and key management are now table-stakes in product design.
Telecommunications underpin everything else. Core networks, subscriber authentication (SIM/eSIM), 5G/6G signalling, and lawful-intercept systems all use classical cryptography that must migrate. Operators are beginning; most are behind the infrastructure vendors.
Retail, consumer goods, media, services face less long-lived-data risk, but still depend on TLS, payment cryptography, and digital identity. Migration complexity is lower, but the dependency on vendors (payment providers, SaaS platforms) means the migration is largely not in your hands — it's in theirs. Your job is to know who they are and track their roadmaps.
Legal, professional services, consulting hold confidential client data under professional-secrecy obligations. If your client documents from 2026 are readable by an adversary in 2035, the breach is real even if you are no longer the custodian. HNDL applies directly.
SMEs. Most do not run their own cryptography — they use vendors. For SMEs the question is: are your key vendors (email, cloud, payments, identity) quantum-ready? Raising this with vendors is itself useful pressure.
Unlike quantum computing — where implementation means writing new applications — quantum-safe security means replacing cryptography deep inside your existing systems. The difficulty is almost never the mathematics. It is the plumbing.
Cryptography is everywhere. A medium-sized enterprise typically has cryptographic dependencies in: TLS on hundreds of services; VPNs and remote access; code-signing and software supply chain; email (S/MIME, DKIM); identity (OAuth, SAML, certificates, smartcards, SSH keys); database encryption; file encryption; backups; HSMs; document signatures; payment systems; IoT device authentication; blockchain interactions; messaging; and firmware signing for every device it manufactures or operates. A complete inventory typically reveals two to five times more cryptographic dependencies than the security team expected.
Not everything is under your control. A substantial portion of your cryptography lives in commercial products: operating systems, browsers, databases, SaaS platforms, firewalls, VPN appliances, HSMs, payment terminals. Your migration depends on your vendors' migrations. Part of the work is tracking their roadmaps and, where possible, pushing them forward.
Crypto-agility is the architectural principle. The central lesson of the past decade is that cryptographic algorithms are not forever. SHA-1 was deprecated, TLS 1.0 was deprecated, SIKE was broken mid-standardisation. The right architectural response is to design systems where the cryptographic algorithm is a configuration parameter, not a hard-coded assumption. This means centralised key management, abstracted cryptographic APIs, modern TLS libraries, and processes that allow an algorithm to be swapped without rewriting the application. Every pound spent on crypto-agility today pays back many times over as algorithms change — and they will change again.
The tooling is maturing. OpenSSL 3.5 ships with native PQC support. AWS KMS, Azure Key Vault, and Google Cloud KMS all support hybrid PQC in some form. HSM vendors (Thales, Entrust, Utimaco) have PQC-capable firmware. Windows, macOS, and the major Linux distributions are rolling in PQC support. Most major TLS libraries (OpenSSL, BoringSSL, rustls) now support ML-KEM hybrids. The tools are ready; the work is deployment.
The team you need. PQC migration is not a research project. It is primarily a programme-management and engineering discipline. A typical migration team in a large enterprise includes: a programme lead with cryptographic literacy; a cryptographic architect (internal or external); infrastructure engineers covering each major domain (network, identity, applications, products, third-party dependencies); procurement and legal for vendor contracts and SLAs; a compliance lead for regulator communication. External advisors help with initial cryptographic inventory, risk prioritisation, and vendor negotiation.
The cost of PQC migration varies enormously with the size and complexity of the organisation. Useful rules of thumb:
A full enterprise cryptographic inventory typically costs €80K–€300K for a mid-to-large organisation, depending on whether it is done with external specialists or by existing teams.
A structured risk-prioritisation and roadmap exercise (using the inventory) adds €50K–€150K.
Pilot migrations of a few key systems (TLS, a VPN, one identity system) run €200K–€600K depending on complexity and how much of the work is internal.
Full migration for a mid-size enterprise typically runs €2M–€10M over 4–7 years, spread across infrastructure, applications, product firmware, and vendor-driven work.
Large banks, telcos, and critical infrastructure operators will spend €20M–€100M+ over a decade.
The return on investment is not a line item. It is the avoidance of: regulatory non-compliance fines; catastrophic breach of historical data; customer trust loss; product security downgrades that cost design-wins; and the much higher cost of a rushed migration in the face of a security incident.
The cost of not migrating, phrased as an expected loss, is very difficult to bound — which is exactly why prudent boards are funding migration now rather than waiting for certainty.
If your organisation does only one thing in response to PQC, make it this: move toward an architecture where cryptographic algorithms can be changed without rewriting applications.
Concretely:
Centralise cryptographic policy and key management. Stop letting each application bring its own library and algorithm choices.
Use modern, well-maintained TLS libraries and keep them current. Ban your own implementations of cryptographic primitives.
Wrap signature and encryption operations in internal APIs that abstract away the algorithm.
Build inventory and monitoring capabilities that can answer, at any time: where is each algorithm used, which version, with which parameters.
Procurement: require vendors to commit to crypto-agility and PQC support in contracts. Treat this as a non-negotiable line item.
A crypto-agile organisation can absorb the PQC migration as a controlled, measurable programme. A crypto-rigid organisation faces every algorithm change as a firefighting exercise. The difference is not one of security — it's one of cost.
The standard industry roadmap, used in different forms by ENISA, NIST, NCSC, and major consultancies, has five phases. They overlap; no organisation runs them strictly sequentially.
Phase 1 — Governance and awareness (3–6 months). Board- and C-level briefing. Appointment of a quantum-readiness owner, usually in the office of the CISO. First risk register entry. Initial regulatory mapping. Budget authorised for Phase 2.
Phase 2 — Cryptographic inventory (6–12 months). Discovery of every cryptographic asset across networks, applications, identity systems, products, and third-party dependencies. Automated discovery tools help but do not cover the full estate alone. Output: a data-rich, maintainable cryptographic bill of materials ("CBOM").
Phase 3 — Risk prioritisation and roadmap (3–6 months). For each cryptographic asset: what data does it protect, what is that data's secrecy lifetime, who controls the migration, what is the migration cost. Rank. Produce a dated, budgeted migration plan. Communicate to the board and regulators.
Phase 4 — Pilot migrations (6–12 months). Migrate a small number of high-value, well-understood systems — typically an internal TLS endpoint, a VPN, a code-signing pipeline — to hybrid PQC. Measure operational impact, tooling maturity, vendor responsiveness. Learn before scaling.
Phase 5 — Progressive migration and maintenance (3–7 years). Work through the CBOM in priority order. Track vendor progress on third-party dependencies. Maintain crypto-agility and readiness for the next round (HQC, future algorithm changes). Integrate PQC requirements into all new system procurement and design.
At every phase, communication with regulators, auditors, customers, and the board is part of the work. A migration that is technically underway but invisible to stakeholders fails politically.
Treating PQC as a technical problem. It is primarily a programme and governance problem. The mathematics is done; the deployment is what's hard.
Skipping the inventory. Every organisation that skips the inventory discovers, two years in, that their migration is far larger than assumed.
Deploying non-standard algorithms. Ignore vendors selling "patented PQC" or algorithms not on the NIST list. There is no legitimate reason to use anything else.
Deploying PQC only, not hybrid. During the transition, run classical + PQC together. Pure PQC deployments remove your fallback if a new cryptanalytic result emerges.
Forgetting firmware and long-lived devices. Anything shipped today that will be in service in 2035 and uses cryptography needs a PQC plan now.
Not pushing vendors. Your major suppliers' migration timelines are your migration timelines. Make PQC a contractual question. Renewals are leverage.
Treating PQC and QKD as alternatives. They are not. PQC replaces your current cryptography everywhere, at software speed, and is the answer for the vast majority of use cases. QKD (see our Quantum Communications pillar) is a specialised physical-layer technique for a narrow set of high-security scenarios. The industry consensus — from NSA, ENISA, NCSC, ANSSI — is: PQC is the mainline response; QKD is niche.
The answer is unusually clear for this pillar. Every organisation should be at least in Phase 1 (governance and awareness) by 2026. Any organisation in a regulated sector, or with data whose secrecy lifetime exceeds five years, should be in Phase 2 (inventory). Large financial institutions, telcos, critical infrastructure operators, defence contractors, and any organisation with government customers should already be running Phase 3 or 4.
If you are in one of these categories and have not started, the first step is not to panic. It is to schedule a board-level briefing within the next quarter, appoint an owner, and commission an inventory. The gap between "we haven't started" and "we have a credible plan" is typically three to six months of deliberate work. The gap between "we have a credible plan" and "we are migrated" is several years — which is exactly why starting now matters.
If you are a small organisation with no in-house cryptography, your action list is shorter but not empty: identify your three to five most important cryptographic vendors (email, cloud, identity, payments, file storage) and ask each of them, in writing, for their PQC roadmap. Their answers — or non-answers — tell you how exposed you are.