Post-Quantum Cryptography Migration Guide (2026)

Why 2026 Is the Defining Year for PQC Migration

For most organisations, the threat from quantum computing has long felt theoretical — a problem for the next decade, not this quarter. That calculation has changed. In 2026, post-quantum cryptography has crossed from research into regulatory obligation, and the organisations that treat migration as a future project are already falling behind.

Three forces are converging simultaneously: finalised international algorithm standards that are ready to deploy, binding regulatory deadlines that are now in effect or imminent, and an adversarial threat that does not require a quantum computer to exist today to cause harm now.

The ‘harvest now, decrypt later’ threat explained

The most urgent risk is not a future breach — it is a breach that has already occurred. State-level adversaries and sophisticated criminal groups have been intercepting and storing encrypted network traffic for years, in anticipation of the moment a cryptographically relevant quantum computer (CRQC) becomes available to decrypt it. This strategy, widely referred to as harvest now, decrypt later (HNDL), means that long-lived secrets — classified government communications, patient health records, intellectual property, financial transaction histories — are already compromised in storage, even though current encryption has not been broken.

Any data encrypted today with RSA-2048, ECDH, or similar classical asymmetric schemes, and that must remain confidential for five years or more, should be considered at risk. For sectors such as defence, healthcare, financial services, and critical national infrastructure (CNI), that threshold covers almost everything.

Why cryptographically relevant quantum computers (CRQCs) reset every deadline

A CRQC — a quantum computer powerful and stable enough to run Shor’s algorithm against RSA and elliptic-curve cryptography at meaningful key sizes — does not yet exist. However, the uncertainty around its arrival is precisely what makes planning difficult. Estimates from leading research institutions and national intelligence agencies vary considerably: some assessments place a CRQC within ten to fifteen years; others suggest it could arrive sooner as error-correction techniques improve. The US National Security Agency and GCHQ-affiliated NCSC both explicitly decline to specify a single “Q-Day” year, and organisations planning migration timelines should treat any confident single-year prediction with scepticism.

What matters for planning is that the combination of HNDL risk and uncertain Q-Day means the deadline for protecting sensitive data is already passed for some data classes. Cryptographic agility — the ability to swap cryptographic algorithms across an estate without rebuilding systems from scratch — is therefore not a nice-to-have feature; it is a prerequisite for operating securely across the transition window.

Key regulatory triggers already in force in 2026

Several mandates with direct PQC implications are already active in 2026. The US Office of Management and Budget Memorandum M-23-02 directed federal agencies to begin inventorying cryptographic assets. NSM-10 established requirements for National Security Systems (NSS) to transition away from classical public-key cryptography. The EU’s NIS2 Directive, which came into force for member states in late 2024, includes cryptographic risk management within its scope, and the Digital Operational Resilience Act (DORA) is now binding on financial entities operating in the EU. In the UK, the NCSC published its formal migration timelines document in March 2025, establishing a three-stage roadmap with the first milestone in 2028. Organisations in regulated sectors who have not yet begun their migration programmes are not simply behind schedule — they are, in many cases, out of compliance with current guidance.

Understanding the PQC Standards Landscape

Migration cannot begin in earnest without knowing which algorithms to migrate to. After eight years of open global evaluation, NIST finalised its first three post-quantum cryptography standards in August 2024, providing the stable technical foundation that migration programmes require.

NIST FIPS 203, 204, and 205: the finalised algorithms

Three Federal Information Processing Standards now define the baseline for quantum-resistant cryptography globally:

• FIPS 203 — ML-KEM (CRYSTALS-Kyber): A key encapsulation mechanism based on lattice-based cryptography (specifically the Module Learning With Errors problem). ML-KEM is intended to replace classical key exchange mechanisms such as ECDH and RSA key encapsulation. It is the primary algorithm recommended for protecting data in transit.
• FIPS 204 — ML-DSA (CRYSTALS-Dilithium): A lattice-based digital signature algorithm, designed to replace RSA and ECDSA signatures. It is applicable to authentication, code signing, and certificate issuance.
• FIPS 205 — SLH-DSA (SPHINCS+): A stateless hash-based signature scheme, offering a security basis that is mathematically independent of lattice assumptions. It is recommended as a conservative alternative or complement to ML-DSA where diversity of cryptographic assumptions is a priority.

NIST has also published a fourth standard, FIPS 206 (FN-DSA / FALCON), finalised in August 2024 alongside the others. Organisations should base deployment decisions on these FIPS-validated specifications. Algorithms that were withdrawn from the NIST process or remain in supplementary evaluation rounds should not be deployed in production systems as primary mechanisms.

It is equally important not to conflate post-quantum cryptography with quantum key distribution (QKD). QKD is a physics-based key exchange technique that uses quantum mechanical properties to detect eavesdropping; it is not a drop-in replacement for public-key infrastructure and is not part of the NIST PQC standardisation. The NCSC’s guidance explicitly cautions against relying on QKD as a primary mitigation strategy.

NCSC guidance and the UK three-stage migration timeline

The UK’s National Cyber Security Centre published its Timelines for migration to post-quantum cryptography document in March 2025. It establishes a three-stage roadmap anchored at 2028, 2031, and 2035, and is the de-facto compliance framework for UK organisations, particularly those operating as part of critical national infrastructure. The NCSC aligns its algorithm recommendations closely with NIST’s finalised standards and explicitly endorses ML-KEM, ML-DSA, and SLH-DSA for new deployments.

EU coordinated roadmap and ENISA recommended algorithms

The European Union Agency for Cybersecurity (ENISA) published its Post-Quantum Cryptography: Current state and quantum mitigation report as part of a coordinated EU approach to PQC. ENISA’s recommended algorithm set aligns substantially with NIST’s finalised standards, reflecting the global convergence around lattice-based and hash-based schemes. EU member states are expected to align national guidance with ENISA recommendations, and the NIS2 Directive provides a binding compliance lever for essential and important entities to act on that guidance.

BSI and ANSSI: the strictest hybrid requirements in Europe

Germany’s Federal Office for Information Security (BSI) and France’s national cybersecurity agency (ANSSI) have both published detailed PQC migration guidance that goes further than NIST and NCSC in one specific respect: both agencies explicitly require hybrid cryptography as a transitional measure — meaning organisations must run classical and post-quantum algorithms in parallel rather than switching directly to standalone PQC. BSI’s technical guideline TR-02102 series has been updated to reflect this requirement. The rationale is that NIST’s algorithms, while rigorously evaluated, have not yet accumulated the decades of real-world scrutiny that RSA and elliptic-curve cryptography have. Running both in combination maintains protection if an unexpected weakness is discovered in either. Organisations with operations in Germany or France, or that operate under German or French regulatory jurisdiction, should treat hybrid deployment as mandatory rather than optional.

Phase 1 — Foundation: Crypto Discovery and Inventory

Every credible migration guidance document — from the NCSC to IETF to commercial security vendors — places cryptographic discovery first. This is not a formality. Organisations that skip or rush this phase consistently find themselves migrating incomplete estates, missing embedded cryptography in third-party components, or prioritising the wrong systems. Before any algorithm can be replaced, you must know precisely what cryptography your organisation uses and where.

How to build a Cryptographic Bill of Materials (CBOM)

A Cryptographic Bill of Materials (CBOM) is a structured inventory of every cryptographic primitive in use across an organisation’s technology estate: algorithms, key lengths, certificate types, protocol versions, libraries, and their dependencies. The concept is analogous to a Software Bill of Materials (SBOM) and is increasingly expected by regulators and auditors as evidence of cryptographic governance maturity.

A complete CBOM should capture, at minimum:

• All X.509 certificates, their issuing CA, validity period, algorithm (RSA, ECDSA), and key size
• TLS configurations across web servers, APIs, load balancers, and VPN endpoints
• SSH keys and their algorithm types (RSA, Ed25519, ECDSA) across infrastructure
• Code signing certificates and keys used in software build pipelines
• Symmetric encryption in use for data at rest (noting that AES-256 is considered quantum-resistant; AES-128 is less so and warrants review)
• Cryptographic libraries embedded in applications and firmware (OpenSSL version, BouncyCastle, etc.)
• Hardware security modules (HSMs) and their supported algorithm sets
• PKI infrastructure components: root CAs, intermediate CAs, certificate authorities

Tools and methods for automated crypto asset discovery

Manual inventorying at enterprise scale is impractical. A growing category of specialised tools supports automated cryptographic asset discovery, including network-level TLS scanning tools (such as testssl.sh or commercial equivalents), static and dynamic application analysis tools capable of identifying cryptographic library calls, PKI management platforms with discovery agents, and emerging CBOM-specific tooling from vendors such as Keyfactor and IBM (via its CBOM specification contributions to the CycloneDX standard). The IETF has published guidance on cryptographic agility and discovery as part of its ongoing PQC migration workstream. Your tool selection should be driven by your estate’s composition: a predominantly cloud-native organisation has different discovery challenges from one with significant legacy on-premises infrastructure or operational technology (OT) environments.

Prioritising assets: critical systems vs. lower-risk environments

Not all cryptographic assets carry equal risk. Prioritisation should consider two axes: the sensitivity of the data protected and the longevity of the data. A long-lived secret encrypted today that must remain confidential for ten or more years is immediately high priority due to HNDL risk, regardless of how remote a CRQC appears. Systems supporting CNI, national security, financial transaction integrity, or long-retention personal data should be moved to the top of the queue. Internal development test environments or short-lived session tokens can be addressed in later phases.

Common discovery pitfalls and how to avoid them

Several patterns consistently emerge as failure modes during cryptographic inventory exercises:

• Shadow cryptography: Development teams embedding cryptographic libraries directly in application code, bypassing centralised PKI governance. Requires application-layer scanning, not just network scanning.
• Firmware and embedded systems: Industrial control systems, IoT devices, and medical equipment often use hardcoded cryptographic implementations that are invisible to network scanners. Vendor engagement is essential here.
• Third-party and SaaS dependencies: Cryptography implemented by a vendor on your behalf is still your risk. Contractual obligations to disclose cryptographic capabilities should be part of supplier due diligence.
• Certificate sprawl: Organisations with unmanaged certificate estates frequently discover thousands of certificates they were not aware of, including expired or misconfigured ones that create immediate vulnerabilities independent of quantum risk.

Phase 2 — Plan and Validate: Choosing Your Migration Strategy

Once you have a reliable CBOM, the next phase is strategic: deciding how to migrate, not just what to migrate to. Two complementary architectural principles should guide every decision in this phase: hybrid cryptography and crypto-agile design.

Hybrid cryptography: running classical and post-quantum in parallel

Hybrid cryptography combines a classical algorithm (such as ECDH) with a post-quantum algorithm (such as ML-KEM) in a single key exchange or signature scheme, such that the combined scheme is secure if either algorithm remains unbroken. The security guarantee is therefore additive: an attacker who discovers a flaw in ML-KEM gains nothing if ECDH remains sound, and vice versa.

In practice, composite certificates — X.509 certificates carrying both a classical and a post-quantum key and signature — are the implementation vehicle for hybrid cryptography in PKI. Standardisation work through the IETF and the Internet Architecture Board is maturing rapidly, and several major CA vendors have already issued hybrid test certificates. For organisations subject to BSI or ANSSI jurisdiction, hybrid deployment is a regulatory requirement, not merely a best practice. For others, it is the recommended transitional posture until post-quantum algorithms have accumulated sufficient operational history.

Crypto-agile architecture: designing for algorithm replacement

Crypto-agility refers to designing systems so that the cryptographic algorithm in use can be replaced without requiring architectural changes to the system itself. This means abstracting cryptography into dedicated libraries or services, avoiding hardcoded algorithm identifiers or key sizes in application logic, and building certificate and key management workflows that support multiple algorithm types concurrently. A crypto-agile architecture treats algorithm replacement as a configuration or deployment event rather than a development project. Given that post-quantum standards will evolve — NIST continues to evaluate additional algorithms for use cases not fully covered by the initial standards — building for agility is not merely a transitional measure but a permanent operational requirement.

Vendor and supply-chain dependencies to map before migrating

Supply chain cryptography is one of the most underestimated risk areas in PQC migration. An organisation’s own systems may be migrated successfully, but if a third-party vendor’s API, HSM firmware, or cloud provider’s TLS stack does not yet support post-quantum algorithms, migration is incomplete. Before finalising a migration plan, organisations should:

• Issue PQC readiness questionnaires to all critical technology vendors
• Review SLAs and contractual terms for cryptographic standard compliance
• Assess HSM and hardware token vendor roadmaps — many current-generation HSMs do not yet support ML-KEM or ML-DSA natively, and firmware upgrade paths vary significantly
• Engage cloud providers on their PQC TLS rollout timelines (AWS, Google Cloud, and Microsoft Azure have all published preliminary timelines, but coverage varies by service)

Risk-based prioritisation framework

With a complete CBOM and a vendor dependency map, prioritisation becomes structured rather than intuitive. A workable framework scores each cryptographic asset across three dimensions: data sensitivity (confidentiality, integrity, or authenticity requirement), data longevity (how long the protected data must remain secure), and system migration complexity (how difficult it is to update the cryptography in that system). High scores on all three dimensions — a long-lived sensitive data store protected by software that is easy to update — should be migrated first. Low scores on all three — a short-lived internal session token protected by a complex embedded system — can be deferred to a later phase.

Phase 3 — Build: Implementing Quantum-Safe Cryptography

Implementation is where planning meets reality. This phase covers the specific technical domains where most of the migration work is concentrated, along with the validation practices that ensure new implementations are correct and interoperable.

Updating PKI infrastructure and certificate lifecycle management

PKI modernisation is typically the most complex and highest-impact workstream in a PQC migration. Root CAs and intermediate CAs must be capable of issuing and signing certificates using ML-DSA or SLH-DSA. Certificate lifecycle management platforms must be updated to handle composite certificates and post-quantum key types. Organisations running private PKI have more control over this process; those relying on public CAs are dependent on the CA’s own migration timeline, which should be a key factor in CA selection going forward.

Certificate validity periods are also a relevant consideration: the industry move towards shorter-lived certificates (driven by proposals from the CA/Browser Forum to reduce maximum validity to 90 days) is actually beneficial for PQC migration, since it reduces the window during which a certificate using a pre-quantum algorithm remains in circulation after migration has begun.

Migrating TLS, VPNs, and secure messaging protocols

TLS 1.3 is the baseline for secure transport, and its extensible design accommodates post-quantum key exchange through the supported_groups extension, which can be populated with ML-KEM-based key encapsulation groups (such as X25519Kyber768). Major browsers and TLS libraries are already publishing support timelines. For VPNs, IKEv2 (the key exchange protocol underlying IPsec VPNs) has IETF drafts specifying how ML-KEM should be integrated into the key exchange, and several commercial VPN vendors have published post-quantum VPN implementations. The IETF’s guidance document on migration to post-quantum cryptography, published in July 2025, provides authoritative protocol-level guidance for TLS, IKEv2, and SSH migration.

Secure messaging protocols vary significantly in their PQC readiness. Signal has deployed a post-quantum ratchet extension (PQXDH) as of 2023. Enterprise messaging and collaboration platforms are at varying stages, and their PQC roadmaps should be assessed as part of the supply-chain review.

Code signing and software supply chain protections

Code signing is a critical but often overlooked migration target. Software signed with ECDSA or RSA keys today will eventually be verifiable by an adversary with a CRQC, enabling post-hoc validation of tampered software if the original signatures are retained. Migrating code signing to ML-DSA or SLH-DSA should be included in the Phase 3 workstream, and build pipelines should be updated to use FIPS-validated modules for all cryptographic operations. The Sigstore project and similar transparency log frameworks will need corresponding updates, and organisations using third-party software vendors should request their code-signing migration timelines.

Testing and validating post-quantum implementations

Interoperability testing is essential before production deployment. Post-quantum algorithms have different performance characteristics from their classical counterparts: ML-KEM and ML-DSA have larger key and signature sizes than RSA equivalents, which can affect protocol handshake performance, certificate chain sizes, and bandwidth in constrained environments. Testing should include:

• Functional validation against NIST’s published Known Answer Tests (KATs) for FIPS 203, 204, and 205
• Interoperability testing with counterpart systems (client–server, server–server) to verify that hybrid configurations negotiate correctly
• Performance benchmarking under representative load, particularly for high-throughput TLS termination and HSM-based signing
• Regression testing to confirm that migrated systems do not break backward compatibility with legacy clients during the hybrid transition period

The NCSC Three-Stage UK Roadmap: 2028, 2031, 2035 Milestones

The NCSC’s March 2025 timelines document establishes the clearest framework available for UK organisations. It is structured around three milestone years, each with specific expectations for different categories of organisation. What follows is a summary of those milestones; the full document should be consulted for sector-specific obligations and nuance.

What organisations must complete by 2028

By 2028, the NCSC expects all UK organisations — and places particular emphasis on CNI operators, government departments, and their supply chains — to have:

• Completed a comprehensive cryptographic inventory (CBOM) across their entire technology estate
• Identified all high-priority cryptographic assets requiring migration (applying sensitivity and longevity criteria)
• Developed a detailed, costed PQC migration plan with executive sponsorship
• Begun migration of the highest-priority systems, including those protecting long-lived sensitive data
• Engaged their critical suppliers on PQC readiness and incorporated PQC requirements into procurement processes

The 2028 milestone is less than two years away. For large enterprises with complex estates, consulting firm and academic estimates consistently put a full-estate PQC migration at three to seven years. Starting in 2026 is not early — for some organisations, it is already tight.

Obligations and targets for 2031

By 2031, the NCSC expects significant portions of an organisation’s cryptographic estate to have completed migration to quantum-resistant algorithms. Specifically:

• All high-priority and medium-priority systems should be running on NIST-finalised post-quantum algorithms, in hybrid configuration where required
• PKI infrastructure should be issuing post-quantum or composite certificates as the default
• Legacy cryptographic systems that cannot be migrated should have documented risk acceptance and compensating controls in place
• Supplier chain migration should be substantially complete for critical dependencies

Full migration to quantum-resistant cryptography by 2035

The 2035 milestone represents the NCSC’s target for complete migration: all systems across an organisation’s estate should be running quantum-resistant cryptography, with no reliance on algorithms vulnerable to a CRQC. This includes systems with long upgrade cycles — operational technology, embedded systems, and legacy infrastructure that may require hardware replacement rather than software updates. The 2035 deadline is deliberately set to provide lead time for these categories, but it should not be read as permission to begin planning for them only after 2031.

How UK deadlines compare with US CNSA 2.0 and EU obligations

The US NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) sets timelines for National Security Systems that are broadly similar to, but in some areas more aggressive than, the NCSC roadmap. CNSA 2.0 targeted NSS software and firmware for PQC adoption beginning in 2025, with networking equipment and other hardware to follow. Full NSS migration is targeted by 2033 for most system types.

EU obligations are less prescriptive in their specific dates but are becoming more binding through NIS2 and DORA compliance requirements, with sector-specific regulators expected to provide increasingly detailed guidance through 2026 and 2027. The ENISA roadmap and the EU’s coordinated approach aim for broad quantum-safe transition across critical sectors by the early 2030s, broadly consistent with UK and US timelines.

For UK organisations with US operations or that handle NSS-adjacent data, CNSA 2.0 compliance may impose earlier effective deadlines than the NCSC roadmap. Cross-jurisdictional compliance mapping should be part of every multinational organisation’s PQC governance programme.

Regulatory and Compliance Pressures Organisations Cannot Ignore

One of the most significant gaps in the current PQC guidance landscape is a cross-jurisdictional synthesis: most published roadmaps address a single regulatory context. For the many UK organisations operating across multiple jurisdictions, assembling a coherent compliance picture requires drawing from several sources simultaneously.

UK: NCSC guidance and CNI sector-specific obligations

In the UK, the NCSC’s PQC migration timelines constitute the primary framework, but they sit alongside sector-specific obligations. Operators of essential services under the Network and Information Systems (NIS) Regulations are expected to address cryptographic risk as part of their security risk management obligations. The Financial Conduct Authority (FCA) and Prudential Regulation Authority (PRA) have signalled increasing attention to operational resilience frameworks that encompass cryptographic risk, particularly following DORA alignment activity. Organisations holding classified government data operate under additional obligations set by the Cabinet Office and the National Technical Authority.

US: OMB M-23-02 and NSM-10 federal mandates

US federal agencies are operating under two primary mandates. OMB Memorandum M-23-02, issued in December 2022, directed agencies to develop cryptographic inventories and migration plans aligned with NIST standards. National Security Memorandum 10 (NSM-10), signed in May 2022, established the policy framework for NSS migration and directed CISA, NSA, and NIST to produce coordinated guidance. For UK organisations with US federal contracts or that operate systems touching US government data, these mandates may create contractual or compliance obligations that mirror or exceed NCSC requirements. The compliance deadline 2026 context is directly relevant here: US agencies were expected to have inventories substantially complete by 2023–2024, placing their supply chains under immediate scrutiny.

EU: NIS2, DORA, and the proposed binding PQC obligation

The NIS2 Directive, in force since October 2024, requires essential and important entities across the EU to implement appropriate cryptographic policies as part of their information security risk management measures. Cryptographic practices — including the use of up-to-date encryption standards — are explicitly within scope. DORA, which became directly applicable to EU financial entities from January 2025, includes ICT risk management requirements that encompass cryptographic resilience and digital operational continuity. As of 2026, the European Commission is consulting on whether to introduce a more explicit binding PQC obligation as part of the EU’s broader cybersecurity legislative framework. Organisations subject to both NIS2 and DORA should treat their PQC migration programme as a direct compliance requirement, not merely a best-practice recommendation.

Financial services and healthcare: sector-specific timelines

Financial services organisations face some of the most acute PQC pressure, given the combination of long data retention requirements, transaction integrity obligations, and the DORA framework for EU operations. Payment card industry standards bodies are beginning to address PQC requirements in forthcoming revisions to PCI DSS. Healthcare organisations holding long-lived patient data are particularly exposed to HNDL risk: medical records have effective lifespans of decades, well within any reasonable Q-Day estimate range. The NHS and UK health sector regulators have not yet published explicit PQC migration deadlines, but the NCSC timelines apply to health sector CNI operators, and information governance obligations under UK GDPR reinforce the case for early action.

Building Your PQC Migration Team and Governance Structure

Technical migration without organisational governance is one of the most reliable paths to a failed programme. PQC migration is a multi-year, cross-functional programme that requires executive sponsorship, defined accountability, and board-level visibility — not a project assigned to an already-stretched security team.

Roles and responsibilities: CISO, CTO, procurement, legal

Effective PQC programme governance requires clearly defined ownership across functions:

• CISO: Programme ownership and quantum risk management accountability. The CISO should own the CBOM, the migration roadmap, and the reporting cadence to the board. They are accountable for ensuring that cryptographic risk is treated with the same rigour as other enterprise security risks.
• CTO / Engineering leadership: Responsible for implementing crypto-agile architecture standards, overseeing technical migration workstreams, and managing the cryptographic library and tooling estate.
• Procurement and vendor management: Responsible for embedding PQC readiness requirements in supplier questionnaires, contract terms, and technology procurement decisions. Every new technology acquisition made today should include a PQC-readiness question as standard.
• Legal and compliance: Responsible for mapping cross-jurisdictional regulatory obligations (NCSC, DORA, NIS2, OMB M-23-02) and ensuring that the programme’s milestones align with compliance deadlines.
• Risk function: Responsible for maintaining a quantum risk register and for integrating PQC risk into the enterprise risk framework.

Board-level reporting: how to communicate quantum risk

Board reporting on quantum risk is an area where many organisations struggle. The technical complexity of the subject and the uncertainty around Q-Day timelines make it easy for boards to defer engagement. The most effective approach is to frame quantum risk in terms the board already understands: regulatory compliance risk (specific named obligations and deadlines), reputational risk (the HNDL threat to data already in circulation), and programme delivery risk (the consequence of starting too late given multi-year migration lead times).

Boards should be presented with a clear migration programme status — phases completed, phases in progress, estimated completion dates, and budget consumed versus allocated — on at least a quarterly basis. The NCSC roadmap milestones (2028, 2031, 2035) provide ready-made programme markers that make reporting tractable. Organisations that have achieved ISO 27001 certification or that report under DORA or NIS2 can integrate PQC programme status into existing governance reporting structures.

Budget and resource planning for a multi-year programme

Budgeting for a multi-year programme in a rapidly evolving technical landscape is genuinely difficult. However, a few principles are well-established. Cryptographic discovery and inventory (Phase 1) is relatively low-cost and should be funded immediately — it is the foundation for every subsequent decision. PKI modernisation and the migration of internet-facing systems (Phase 3 priority one) typically represents the largest expenditure. Hardware replacement for legacy embedded systems and OT equipment can represent the longest lead-time cost and should be flagged in capital planning cycles now. Organisations that have deferred PKI refresh or certificate lifecycle management investment on the grounds of future PQC migration have compounded their costs; a modern, automated certificate management platform is a prerequisite for PQC migration, not a consequence of it.

Common Mistakes and Risks to Avoid During PQC Migration

With enough published guidance now available, the failure modes in PQC migration are increasingly well-documented. The following represent the most consistently cited and consequential mistakes — drawn from NCSC, IETF, and specialist security practitioner guidance.

Skipping the inventory phase and migrating blind

The most common and costly mistake is beginning migration before completing a cryptographic inventory. Organisations that migrate their visible, well-documented systems while leaving shadow cryptography, third-party dependencies, or embedded firmware untouched have not reduced their quantum risk — they have made it harder to assess. Regulators conducting audits or assessments will look for evidence of a CBOM as a baseline competency indicator. There is no shortcut to this phase.

Deploying non-NIST-approved or pre-standard algorithms

During the years-long NIST evaluation process, a number of vendors and researchers promoted candidate algorithms as production-ready. Some of those candidates were subsequently broken — most notably, SIKE (Super