Why Businesses Can No Longer Afford to Wait on PQC
The most common objection to post-quantum cryptography investment is a reasonable-sounding one: quantum computers capable of breaking today’s encryption do not yet exist at scale, so why act now? The answer lies in two converging pressures — one technical, one regulatory — that have made waiting genuinely costly.
The ‘harvest now, decrypt later’ threat explained
Nation-state actors and sophisticated adversaries are already collecting encrypted network traffic today, storing it at scale, and waiting. The plan is straightforward: once a cryptographically relevant quantum computer (CRQC) exists, they will decrypt the archived data retrospectively. For businesses that handle data with long sensitivity lifespans — legal records, health data, financial agreements, intellectual property, government contracts — the protection window required extends years or decades into the future. By the time a CRQC arrives, the data will already have been harvested. This “harvest now, decrypt later” attack is not hypothetical; it is a documented operational concern cited by the NCSC, the NSA, and intelligence communities across the Five Eyes alliance.
The implication is stark: the relevant question is not “when will quantum computers break encryption?” but “when was the data we need to protect created, and how long must it remain confidential?” For many organisations, that calculation already justifies migration.
NIST finalisation of PQC standards (2024) and what it means in 2026
In August 2024, the National Institute of Standards and Technology (NIST) formally published its first three post-quantum cryptography standards: FIPS 203 (ML-KEM, based on Kyber), FIPS 204 (ML-DSA, based on Dilithium), and FIPS 205 (SLH-DSA, based on SPHINCS+). This was the conclusion of an eight-year standardisation process and removed the most significant remaining technical uncertainty for enterprise planning. These are not draft recommendations — they are ratified, implementable standards, and major cryptographic libraries, cloud providers and hardware vendors began shipping support through 2025 and into 2026. Businesses waiting for “the standards to settle” no longer have that justification. The standards are settled.
UK and EU regulatory pressure: NCSC guidance, NIS2 and the Charter of Trust timelines
Regulatory framing has tightened considerably. The UK’s National Cyber Security Centre (NCSC) has published dedicated post-quantum cryptography guidance positioning PQC readiness as a strategic priority for UK organisations, particularly those operating critical national infrastructure or handling sensitive government data. The NCSC recommends organisations begin migration planning now, with a particular focus on systems that will still be in operation in 2030 and beyond.
At the EU level, the NIS2 Directive — which came into force across member states through 2024 and 2025 — requires organisations in scope to adopt state-of-the-art cryptographic practices as part of their risk management obligations. While NIS2 does not mandate a specific PQC timeline, legal analysis published by CMS Law in September 2026 frames PQC readiness as increasingly relevant to demonstrating NIS2 compliance, particularly for entities processing critical data. The Charter of Trust, a cybersecurity alliance including Siemens, IBM and Airbus, published a PQC migration timeline in April 2026 recommending that organisations achieve initial PQC deployment by 2028 and full quantum-safe posture by 2030. UK businesses with EU operations or supply-chain relationships with NIS2-regulated entities need to treat both regulatory contexts seriously.
Step 1 — Cryptographic Discovery: Know What You Are Protecting
No migration can proceed without knowing what you are migrating. Cryptographic discovery — building a complete picture of every cryptographic primitive, protocol and credential in use across your organisation — is the essential first step, and the one most frequently underestimated in scope.
How to build a cryptographic inventory across systems, APIs and supply chains
A cryptographic inventory goes significantly further than listing the TLS certificates you manage. It should capture: every application that performs asymmetric encryption or digital signing operations; every API endpoint that negotiates a cipher suite; every VPN, code-signing pipeline, authentication system or database with encrypted fields; and — critically — every third-party supplier, SaaS platform and managed service that handles your data using cryptography you do not directly control. This last category is the most commonly overlooked, yet represents a substantial portion of real-world exposure for most mid-size organisations.
The IETF’s July 2025 guidance on migration to post-quantum cryptography explicitly calls out supply-chain cryptographic dependencies as a first-class concern, noting that an organisation’s quantum-safe posture is only as strong as the weakest link in its cryptographic chain.
Tools and frameworks for automated crypto discovery
Manual inventory is feasible for small environments but impractical at scale. A growing set of commercial and open-source tools can scan codebases, network traffic and certificate stores to identify cryptographic primitives in use. Network-level scanners can enumerate TLS negotiation parameters across exposed services; static analysis tools can identify RSA and ECC usage in application code; certificate management platforms can map X.509 certificate lifespans, issuers and key sizes. The MITRE PQC Migration Roadmap, published via the Post-Quantum Cryptography Coalition, recommends formalising discovery outputs into a Cryptography Bill of Materials (CBOM) — an artefact modelled on the Software Bill of Materials (SBOM) concept that is increasingly familiar in supply-chain security contexts.
What to document: algorithms in use, key lengths, certificate lifespans
For each cryptographic asset identified, document at minimum: the algorithm (e.g. RSA-2048, ECDSA P-256), the protocol context (TLS 1.3, SSH, S/MIME, code signing), the key length and generation date, the certificate expiry date and renewal process, the owning system and responsible team, and whether the asset is exposed externally or internal-only. This CBOM becomes the working foundation for the risk analysis in Step 2 and the migration planning in Step 4.
Step 2 — Risk Analysis: Prioritise Your Migration Workload
Once you have a cryptographic inventory, the question becomes: what do you migrate first? Not everything can be migrated simultaneously, and not everything carries equal risk. A structured prioritisation framework prevents both paralysis and misallocation of budget.
Data sensitivity classification and exposure window calculation
The core of any PQC risk model is the intersection of two variables: how sensitive is the data protected by a given cryptographic asset, and for how long must it remain confidential? A session token used in a consumer-facing application has a near-zero exposure window. A signed legal contract, a health record, or an encrypted government communication may need to remain confidential for ten, twenty or thirty years. The “exposure window” — the period between now and when the data loses its sensitivity — determines how much time an adversary has to harvest and later decrypt it before it matters.
Identifying high-risk assets: long-lived data, PKI roots, VPNs, code signing
Applying this lens across your CBOM will surface a small set of genuinely high-risk assets that warrant early migration. These typically include: PKI root certificates and intermediate certificate authorities, whose compromise has ecosystem-wide consequences; VPN infrastructure that protects long-lived communications; code-signing keys, where a future-forged signature could undermine software trust retrospectively; and any system that encrypts data retained for regulatory or archival purposes. NIST IR 8547, NIST’s internal report on PQC migration guidance, provides a structured migration priority classification system that aligns broadly with this logic — recommending that organisations prioritise key establishment and digital signature mechanisms protecting long-lived data and critical infrastructure above other use cases.
Aligning risk priority with NIST IR 8547 migration guidance
A practical prioritisation matrix scores each asset across three dimensions: data sensitivity (low / medium / high / critical), exposure window (months / years / decades), and migration complexity (straightforward / moderate / complex). Assets scoring high on the first two dimensions and low on the third should head the migration queue regardless of business line. Assets with high migration complexity but long exposure windows need early planning even if immediate execution is not feasible. This three-axis scoring approach gives programme sponsors a defensible, auditable rationale for prioritisation decisions — which matters when justifying investment to board-level stakeholders.
Step 3 — Algorithm Selection and Testing: Choosing the Right NIST Standards
With priorities established, the next step is selecting the appropriate quantum-safe algorithms for each use case and validating them in your environment before wide deployment. The good news is that for most enterprise applications, the algorithm selection question has a clear answer from the NIST standards published in 2024.
NIST-selected algorithms in 2026: ML-KEM (Kyber), ML-DSA (Dilithium), SLH-DSA (SPHINCS+)
NIST’s three ratified standards cover the two most common cryptographic use cases in enterprise systems. For key encapsulation — replacing RSA and ECC in scenarios where two parties need to establish a shared secret — the standard is ML-KEM (formally FIPS 203), derived from the Kyber lattice-based cryptography scheme. ML-KEM is the algorithm that answers the frequently searched question: “which algorithm is part of NIST’s selected PQC standard for key encapsulation?” The answer is ML-KEM.
For digital signatures, NIST has standardised two complementary options. ML-DSA (FIPS 204, based on Dilithium) is a lattice-based signature scheme offering strong performance for most enterprise use cases. SLH-DSA (FIPS 205, based on SPHINCS+) is a hash-based scheme that serves as a diversity option — its security assumptions are different from ML-DSA, providing algorithmic diversity if lattice-based assumptions are ever challenged. For most deployments, ML-DSA will be the primary choice, with SLH-DSA as a secondary or niche option.
Hybrid classical/PQC schemes: why they matter during transition
During the transition period, deploying a pure PQC algorithm alone introduces its own risk: PQC implementations are newer, less battle-tested, and may carry implementation vulnerabilities not yet discovered. The consensus recommendation from the IETF and NCSC is to use hybrid classical-PQC schemes — combining, for example, X25519 (classical ECDH) with ML-KEM in a key encapsulation mechanism (KEM) that requires an adversary to break both the classical and quantum-safe components simultaneously. This provides a security floor of at least the classical algorithm’s strength, while adding quantum resistance. Hybrid schemes are supported in TLS 1.3 via IETF draft extensions and are now available in OpenSSL 3.x, BoringSSL and other major libraries.
Performance trade-offs: latency, key size and bandwidth implications for enterprise systems
PQC algorithms are not drop-in replacements with identical performance characteristics. ML-KEM public keys and ciphertexts are larger than their RSA equivalents — ML-KEM-768 produces public keys of approximately 1,184 bytes and ciphertexts of approximately 1,088 bytes, compared to 256 bytes for an X25519 public key. In high-frequency API environments, TLS handshake sizes, connection establishment latency and certificate chain sizes all increase meaningfully. SLH-DSA signatures are notably large, which makes it unsuitable for bandwidth-constrained environments. Organisations should benchmark these trade-offs in representative test environments before committing to a specific algorithm profile at scale, particularly for latency-sensitive applications such as financial trading platforms or real-time communications infrastructure.
Step 4 — Planning and Executing a Controlled Migration
Algorithm selection and testing produces a validated technical approach; this step translates it into a governed, phased programme of work. PQC migration is emphatically not a single IT project — it is a multi-year governance programme, as CMS Law’s September 2026 analysis emphasises, requiring sustained executive sponsorship and structured delivery.
Phased rollout: pilot environments, canary deployments and interoperability testing
A controlled migration begins with a well-scoped pilot: select one or two high-priority, lower-complexity systems identified in your risk analysis, deploy hybrid PQC support in a staging environment, and validate end-to-end functionality including interoperability with external counterparties. Canary deployments — routing a small percentage of live traffic through PQC-enabled configurations — allow real-world performance and compatibility monitoring before full cutover. Interoperability is a genuine concern: not all endpoints you communicate with will support PQC simultaneously, which is precisely why hybrid schemes are recommended during this phase. Document all observed issues, latency impacts and compatibility gaps before widening the rollout.
Vendor and procurement considerations: checking supplier PQC roadmaps
Your migration roadmap is only as effective as your vendors’ support for it. As part of migration planning, assess every significant technology supplier against a simple set of questions: Do they publish a PQC roadmap? Have they committed to support for FIPS 203/204/205? Have they shipped hybrid PQC support in current product versions? For new procurement, vendor PQC support should be an explicit evaluation criterion. The MITRE PQC Migration Roadmap recommends incorporating PQC requirements into standard procurement templates and supplier assurance questionnaires — a relatively low-cost governance measure with significant long-term leverage.
Governance structure: who owns the PQC programme (CISO, CTO, board)?
PQC migration cuts across information security, IT infrastructure, software development, legal, and procurement. A single accountable executive owner — typically the CISO or CTO, depending on organisational structure — should hold programme authority, with a cross-functional working group drawing in representatives from each affected domain. Board-level visibility is appropriate given the timescales and costs involved: migration programmes for complex enterprises are routinely multi-year endeavours with seven-figure budgets. Framing PQC migration as a risk management programme — analogous to Y2K or GDPR readiness — tends to resonate with non-technical board members more effectively than leading with algorithm names.
UK-specific considerations: NCSC, public sector deadlines and financial services guidance
UK organisations operating in regulated sectors face specific considerations. The NCSC’s post-quantum guidance explicitly addresses UK government and public sector contexts, and central government departments are expected to align with NCSC timelines. Financial services firms regulated by the FCA and PRA should note that systemic risk considerations around cryptographic infrastructure are likely to feature in future supervisory expectations, consistent with the operational resilience framework. UK organisations with EU operations or data flows remain subject to NIS2 requirements in relevant member states, and should ensure their migration programmes account for both NCSC and EU-facing regulatory obligations.
Step 5 — Hardware Security and Key Management in a Post-Quantum World
Software-level algorithm changes are necessary but not sufficient. The security of any cryptographic system ultimately depends on how the underlying keys are generated, stored and managed. In a post-quantum context, the hardware and key management layer deserves specific attention.
Why software-only PQC is not enough: the role of HSMs
A Hardware Security Module (HSM) provides a tamper-resistant environment for cryptographic key operations — generation, storage and use — isolated from the general computing environment. For high-assurance use cases such as PKI root CA operations, code signing, and payment systems, HSM protection remains essential regardless of which algorithms are in use. The question for PQC migration is whether your current HSMs support the new NIST algorithms. Many legacy HSMs are firmware-updateable to add ML-KEM and ML-DSA support; others will require hardware replacement. Organisations should audit their HSM inventory against vendor PQC roadmaps early in the planning phase, as HSM procurement and deployment timelines can be substantial. Look for FIPS 140-3 validated HSMs, which represents the current validation standard.
Updating PKI roots, CAs and certificate lifecycles
PKI infrastructure — root certificate authorities, intermediate CAs, and the certificate issuance processes built around them — represents some of the most complex and highest-stakes migration work. PKI root of trust changes are architecturally disruptive and operationally risky; they require extensive planning, staged rollout, and careful management of the trust chain during transition. The good news is that most enterprise PKI platforms and commercial Certificate Authorities are publishing PQC migration roadmaps. The NCSC guidance recommends organisations review their CA dependencies and begin engaging their CA vendors on hybrid certificate support now, given that full PKI transitions typically take eighteen months to three years in complex environments.
Quantum-safe key storage and lifecycle management best practices
Key lifecycle management — how keys are generated, rotated, revoked and retired — becomes more consequential under quantum-safe requirements. Longer key sizes in some PQC algorithms mean storage requirements increase. More importantly, the logic that makes “harvest now, decrypt later” attacks possible also applies prospectively: keys generated today with inadequate protection may be compromised in future. Quantum-safe key storage means ensuring that key material is protected not just by access controls and classical encryption, but by HSM hardware, strong entropy sources, and documented lifecycle processes that include rotation schedules tied to the sensitivity and exposure window analysis from Step 2.
Step 6 — Achieving Crypto-Agility: Future-Proofing Beyond the First Migration
Completing a PQC migration is a significant achievement — but treating it as a one-time project would repeat the mistake that created today’s challenge. Classical cryptography was embedded so deeply into infrastructure over decades that replacing it now requires enormous effort. The strategic lesson is that cryptographic agility — the architectural property that allows cryptographic algorithms to be updated without full system re-architecture — must be designed in from this point forward.
What crypto-agility means and why it is now a board-level requirement
Crypto-agility means that the choice of cryptographic algorithm in any given system is a configuration parameter, not a hardcoded assumption. A crypto-agile TLS implementation can negotiate ML-KEM today and switch to a successor algorithm in five years without a full application rewrite. A crypto-agile certificate management system can issue both classical and PQC certificates in parallel and cut over as relying parties update their trust stores. The Charter of Trust’s April 2026 guidance explicitly positions crypto-agility as a strategic enterprise capability, not merely a technical nicety. For boards and executive teams, the framing is simple: the cost of the current migration is largely a debt payment for decades of non-agile design; crypto-agility is the insurance policy against repeating that debt.
Designing systems to swap algorithms without full re-architecture
Practical crypto-agility requires deliberate design choices: abstracting cryptographic operations behind well-defined interfaces rather than calling algorithm-specific functions directly; externalising algorithm selection to configuration or policy rather than code; using CBOM tooling to maintain a continuously updated inventory of cryptographic dependencies; and adopting zero-trust architecture principles that reduce the blast radius of any single cryptographic component’s compromise. These are not exotic requirements — they are good engineering practice that happens to have significant security benefits in a rapidly evolving threat landscape.
Monitoring for new vulnerabilities: lessons from classical crypto deprecations
The history of classical cryptography is a sequence of algorithm deprecations: MD5, SHA-1, DES, 3DES, RSA-1024, and others have all moved from standard practice to deprecated status, sometimes faster than organisations could respond. PQC algorithms will not be immune to this pattern. There is already active cryptanalysis research on all three NIST-standardised algorithms. While none has been broken, the appropriate organisational response is to maintain awareness of NIST, NCSC and academic publications on PQC cryptanalysis, and to treat algorithm deprecation as a routine operational event rather than a crisis — which is only possible if crypto-agility is already in place.
PQC Migration Timeline: What Businesses Should Do in 2026 and Beyond
The following timeline consolidates guidance from NIST, the NCSC, the IETF (July 2025), and the Charter of Trust (April 2026) into a practical horizon for enterprise planning.
2026 immediate priorities: inventory and risk triage
The non-negotiable 2026 priority is cryptographic discovery and risk triage. Organisations that have not yet completed a CBOM should treat this as an urgent gap. Alongside inventory work, 2026 is the right moment to establish governance (identify the programme owner, form the cross-functional working group), assess vendor PQC readiness, and begin piloting hybrid PQC in low-risk environments. Critically, 2026 is also the year to begin incorporating PQC requirements into new procurement — a policy change with zero capital cost and significant long-term leverage.
2027–2028: pilot migrations and vendor upgrades
The 2027–2028 window is the primary execution phase for most mid-size enterprises. High-priority systems identified in the risk analysis — PKI infrastructure, VPNs, code-signing pipelines, long-lived data stores — should complete migration to hybrid PQC schemes during this period. Vendor platform upgrades supporting FIPS 203/204/205 should be deployed. PKI transition planning, which requires the longest lead times, should be in active execution. The Charter of Trust’s target of initial PQC deployment by 2028 aligns with this window.
2030+ horizon: full PQC deployment and classical algorithm deprecation
NIST’s published guidance anticipates the deprecation of RSA and ECC for most use cases by 2030, with a full prohibition in new systems. Organisations that have followed a structured migration programme from 2026 should reach full quantum readiness before or around this horizon. The 2030+ period will also see the transition from hybrid schemes to pure PQC configurations as the broader ecosystem matures. Critically, quantum readiness is not a destination but an ongoing programme state — organisations maintaining crypto-agility and active cryptographic governance will be well positioned to adapt as the threat and standards landscape continues to evolve.
Frequently Asked Questions on PQC Migration
How long does a full PQC migration take for a mid-size business?
For a mid-size organisation with moderate cryptographic complexity, a realistic full migration timeline is three to five years from initial discovery to complete deployment. This includes six to twelve months for inventory and risk analysis, twelve to eighteen months for pilot migrations and vendor upgrades, and a further twelve to twenty-four months for full rollout and PKI transition. Organisations with complex PKI infrastructure, heavily regulated environments or large third-party ecosystems should plan toward the longer end of this range.
Are NIST PQC algorithms already available in commercial products?
Yes. Following NIST’s finalisation of FIPS 203, 204 and 205 in August 2024, commercial availability has expanded significantly. ML-KEM and ML-DSA support is present in OpenSSL 3.x, BoringSSL, AWS KMS, Azure Key Vault, and major HSM vendors including Thales and Entrust. TLS library support for hybrid key exchange is available in current versions of most widely deployed libraries. Enterprises should verify the specific version support in their existing vendor contracts rather than assuming availability.
What is the difference between post-quantum cryptography and quantum key distribution (QKD)?
Post-quantum cryptography (PQC) uses classical computing hardware and mathematical problems believed to be hard for quantum computers — such as lattice problems — to construct quantum-resistant algorithms implementable in software. Quantum key distribution (QKD) uses the physical properties of quantum mechanics to distribute cryptographic keys over specialised optical fibre infrastructure, with security guaranteed by physics rather than computational hardness. PQC is practical for most organisations today using existing networks and hardware; QKD requires dedicated physical infrastructure, is expensive, and is currently limited to relatively short distances and specific high-security contexts. For the vast majority of businesses, PQC is the relevant migration path.
Do UK SMEs need to start PQC migration now?
For SMEs that do not handle long-lived sensitive data or operate in regulated sectors, the immediate pressure is lower — but not absent. The NCSC recommends that all UK organisations begin with cryptographic discovery as a baseline exercise, regardless of size. SMEs operating as suppliers to larger enterprises or public sector bodies will face contractual and procurement pressure to demonstrate quantum-safe posture on an accelerating timeline. The lowest-cost moment to build crypto-agility into systems is during planned upgrades and new build — waiting until regulatory deadlines arrive will be substantially more expensive.