Last reviewed: June 2026. This article reflects NCSC guidance published March 2025 and the finalised NIST FIPS 203, 204, and 205 standards. Given the pace of regulatory change, readers in CNI, financial services, and healthcare sectors should verify current NCSC guidance directly.
Why 2026 Is the Inflection Point for Enterprise Cryptography
For several years, post-quantum cryptography sat comfortably on the “emerging threats” slide of annual security reviews — important, but not urgent. That positioning is no longer tenable. Two converging events have moved PQC from strategic consideration to operational obligation: the finalisation of NIST’s cryptographic standards and the publication of NCSC’s explicit migration timeline. Together, they establish 2026 as the year enterprises must begin executing, not merely planning.
NIST finalises PQC standards: what FIPS 203, 204, and 205 mean in practice
In August 2024, the US National Institute of Standards and Technology (NIST) published three finalised post-quantum cryptography standards, removing the uncertainty that had caused many enterprises to defer procurement decisions:
- FIPS 203 standardises ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation.
- FIPS 204 standardises ML-DSA (formerly CRYSTALS-Dilithium) for digital signatures.
- FIPS 205 standardises SLH-DSA (formerly SPHINCS+) as a stateless hash-based signature scheme.
These are not draft guidelines or provisional recommendations — they are published standards against which vendors, procurement frameworks, and regulators will increasingly evaluate compliance. For UK enterprises that procure technology under government frameworks or supply into regulated sectors, FIPS alignment has direct commercial relevance. The full specifications are available from the NIST Post-Quantum Cryptography project at csrc.nist.gov.
The NCSC migration timeline: 2028, 2031, and 2035 milestones explained
The National Cyber Security Centre published its PQC migration timeline in March 2025, establishing three headline milestones that UK organisations — particularly those in critical national infrastructure and regulated sectors — should treat as planning anchors:
- 2028: Organisations should have completed their cryptographic discovery and assessment, identified high-priority systems, and begun migration of the most sensitive and exposed workloads.
- 2031: Migration of all high-value and legacy systems should be substantially complete. Hybrid schemes may still be in use, but pure classical cryptography should no longer protect high-sensitivity data.
- 2035: Full migration to quantum-safe cryptography across all systems. Classical asymmetric algorithms (RSA, ECC, Diffie-Hellman) should be retired entirely from enterprise environments.
The NCSC is careful to frame these dates as risk-based planning targets rather than guaranteed deadlines tied to a known quantum computing capability date — a nuance that matters when communicating with boards and regulators alike. The full timeline and supporting rationale appear in the NCSC guidance on timelines for migration to post-quantum cryptography.
Why waiting is no longer a defensible position for UK enterprises
The argument for delay — “quantum computers capable of breaking RSA don’t exist yet” — misunderstands the threat model. Adversaries do not need a cryptographically relevant quantum computer (CRQC) today to benefit from quantum-vulnerable encryption today. They need it only at the point of decryption, which may be years or decades away. Data exfiltrated now will be decrypted later.
Beyond the technical threat, the regulatory position is hardening. Board-level reporting on quantum risk is increasingly expected by the FCA, and supply chain contractual requirements are beginning to reference quantum-safe standards. The cost and complexity of migration also scale with delay — the longer cryptographic debt accumulates, the more expensive remediation becomes.
Understanding the Threat: Harvest Now, Decrypt Later
The harvest now, decrypt later (HNDL) threat is the primary reason PQC migration has urgency today, before any CRQC exists. Nation-state adversaries and sophisticated criminal groups are known to intercept and store encrypted traffic at scale, with the expectation of decrypting it once quantum capability matures. This is not a theoretical concern: intelligence assessments from GCHQ and allied agencies have consistently identified long-term data exfiltration as an active threat vector.
What adversaries are already doing with encrypted enterprise data
Persistent interception of encrypted traffic — targeting government communications, financial transactions, intellectual property, and health records — is well-documented in threat intelligence reporting. The value of this stored data varies: communications that will be stale within months are lower risk, but M&A negotiations, clinical trial data, long-term infrastructure designs, and state-level secrets retain value over multi-decade timescales. Any data encrypted today with RSA or ECC and held by an adversary is potentially at risk once a CRQC becomes operational.
Which algorithms are vulnerable: RSA, ECC, Diffie-Hellman
The algorithms at risk are those whose security relies on mathematical problems that quantum computers can solve efficiently using Shor’s algorithm:
- RSA (integer factorisation) — used widely for encryption, key exchange, and digital signatures in TLS, email, and PKI.
- Elliptic Curve Cryptography (ECC) (discrete logarithm on elliptic curves) — underpins ECDSA, ECDH, and much of modern TLS and code signing.
- Diffie-Hellman key exchange (classic discrete logarithm) — used in older TLS cipher suites and some VPN configurations.
All asymmetric cryptography based on these problems is, in principle, vulnerable to a sufficiently powerful quantum computer. Key size increases do not resolve this — a 4096-bit RSA key is not meaningfully safer than a 2048-bit key against Shor’s algorithm at quantum scale.
Which algorithms remain relatively safe: symmetric cryptography and hash functions
Symmetric encryption, including AES-256, is affected differently. Grover’s algorithm can theoretically halve the effective key length of a symmetric cipher — reducing AES-256 to an effective 128-bit security level against a quantum adversary. At 128 bits of post-quantum security, AES-256 remains computationally infeasible to brute-force and is currently considered adequate. Organisations already using AES-128 may wish to migrate to AES-256 as a precaution, but symmetric algorithms are not the priority.
Similarly, well-designed hash functions (SHA-256 and above) retain adequate security in a post-quantum context, again with the caveat that larger output sizes are preferable. The acute migration challenge is in asymmetric cryptography.
The NIST PQC Standards: What Enterprises Need to Deploy
Understanding what to deploy — and where — is more immediately useful to enterprise security architects than understanding how lattice mathematics resists quantum attacks. The following summarises each standard from a deployment-decision perspective.
ML-KEM (FIPS 203): replacing key exchange mechanisms
ML-KEM is a key encapsulation mechanism (KEM) derived from the CRYSTALS-Kyber algorithm. It replaces classical Diffie-Hellman and ECDH in scenarios where two parties need to establish a shared secret — primarily TLS handshakes, VPNs, and secure messaging protocols.
The performance characteristics are favourable relative to other post-quantum candidates. ML-KEM-768 (the recommended security level for most enterprise use cases) produces a public key of approximately 1,184 bytes, compared to 256 bytes for an ECDH P-256 key. This size increase has measurable but manageable implications for TLS handshake latency — a consideration addressed in Phase 3 below. ML-KEM is the algorithm most enterprises will encounter first, as it is already being integrated into TLS 1.3 implementations by major vendors.
ML-DSA (FIPS 204): the new standard for digital signatures and authentication
ML-DSA, derived from CRYSTALS-Dilithium, is the primary post-quantum digital signature algorithm. It applies wherever enterprises currently use ECDSA or RSA-PSS for signing: code signing, certificate issuance, document signing, authentication tokens, and software supply chain verification.
ML-DSA signatures are larger than their classical equivalents — an ML-DSA-65 signature is approximately 3,309 bytes versus roughly 72 bytes for ECDSA P-256. For high-throughput signing operations or bandwidth-constrained environments, this matters. Enterprises should benchmark signing performance in their specific environments during the testing phase rather than relying solely on published benchmarks, which vary significantly by hardware platform.
SLH-DSA (FIPS 205): the stateless hash-based backup signature scheme
SLH-DSA (derived from SPHINCS+) is a stateless hash-based signature scheme. Its security assumptions are more conservative than ML-DSA — it relies only on the security of hash functions rather than lattice problems — making it a valuable diversity mechanism. NIST recommends it as a secondary option rather than a primary deployment target, partly because its signature sizes are substantially larger than ML-DSA.
The practical enterprise use case for SLH-DSA is in high-assurance, low-throughput contexts where conservative security assumptions justify the performance trade-off: root CA certificates, firmware signing for critical infrastructure, and long-lived regulatory documents. It should not be treated as a drop-in replacement for ML-DSA across general enterprise signing.
Hybrid schemes: running classical and post-quantum algorithms in parallel
A hybrid cryptographic scheme combines a classical algorithm with a post-quantum algorithm, requiring an attacker to break both simultaneously. For example, a hybrid TLS handshake might use X25519 (classical ECDH) combined with ML-KEM-768, so that security is maintained even if either algorithm is compromised.
Hybrid schemes are the NCSC’s recommended approach for the current transition period for two reasons. First, they preserve classical security in the event of an undiscovered flaw in the newer PQC algorithms — a non-trivial concern given that ML-KEM and ML-DSA have had significantly less real-world exposure than RSA or ECC. Second, they maintain interoperability with systems that do not yet support PQC. The practical implication: enterprises should plan their migration path through hybrid schemes rather than attempting a direct cut-over to pure PQC, which introduces unnecessary risk on both sides.
Phase 1 — Cryptographic Inventory and Risk Assessment
No migration can be prioritised or budgeted without knowing what exists. Cryptographic discovery is consistently underestimated in scope and complexity — and it is where most enterprise PQC programmes stall. The NCSC’s own guidance identifies this as the foundational phase, and the advice is sound: you cannot protect what you cannot see.
Building a cryptographic bill of materials (CBOM) across your estate
A cryptographic bill of materials (CBOM) is a structured inventory of every cryptographic asset in an organisation’s environment: algorithms in use, key lengths, certificate lifetimes, protocol versions, and the systems and applications that depend on them. Think of it as a software bill of materials (SBOM) extended to cover cryptographic primitives and configurations.
Discovery typically involves several overlapping techniques:
- TLS inspection and protocol scanning — tools that enumerate cipher suites and certificate details across internal and external-facing services.
- PKI and certificate lifecycle audits — exporting and analysing certificate inventories from certificate authorities, Active Directory, and cloud-hosted PKI services.
- Code and dependency scanning — identifying cryptographic library usage within application code and third-party dependencies.
- Network traffic analysis — passive inspection to detect non-standard or legacy protocols not captured by configuration audits.
- Hardware and firmware interrogation — particularly for OT/IoT and embedded systems where cryptographic configuration is not surfaced by standard IT tooling.
The output of this process feeds directly into risk prioritisation and forms the baseline against which migration progress is measured. Cryptographic agility — the ability to update algorithms and keys without architectural change — should be recorded for each system, as it directly determines migration complexity.
Prioritising assets by data sensitivity and exposure window
Not all cryptographic assets carry equal risk. Prioritisation should account for two dimensions:
- Data sensitivity: How valuable is the data protected by this cryptographic control, and how long does it need to remain confidential? Customer PII under UK GDPR, commercially sensitive M&A data, and classified infrastructure designs all have long confidentiality windows and therefore high HNDL risk.
- Exposure window: How long has this data been or will it remain accessible to potential interception? Publicly accessible TLS endpoints are higher priority than internal service-to-service communications on air-gapped networks.
Data classification frameworks already in use within most enterprises (often maintained for UK GDPR compliance) provide a natural starting point for this prioritisation exercise. The output should be a tiered risk register — not a flat list — that maps cryptographic assets to business risk.
On-premises, cloud, and hybrid environments: what differs in discovery
Cloud-hosted workloads present different discovery challenges to on-premises infrastructure. In AWS, Azure, and GCP, cryptographic configuration is distributed across managed services — TLS termination in load balancers, key management in KMS or Key Vault, certificates in ACM or equivalent — rather than centralised in an on-premises PKI. API-driven discovery is possible but requires access to cloud management planes and, in larger estates, programmatic enumeration across multiple accounts and regions.
Hybrid environments often have the most complex discovery challenge: legacy on-premises systems communicating with cloud services over VPNs, using a mixture of classical TLS cipher suites and IPsec configurations. Shadow IT — applications and integrations provisioned without central IT oversight — consistently causes discovery scope to be underestimated. Conservative planning should assume the initial CBOM will be materially incomplete and budget for iterative refinement.
Phase 2 — Migration Strategy Selection and Prioritisation
With a CBOM and risk register in place, enterprises can develop a migration roadmap that is specific, sequenced, and costed. This is the stage where many programmes lose momentum — the gap between assessment and execution is where competing priorities, budget cycles, and vendor readiness create friction.
Defining migration goals aligned to NCSC 2028 and 2031 milestones
Working backwards from the NCSC’s timeline, the 2028 milestone requires completed discovery and active migration of high-priority systems. For most enterprises beginning their CBOM work in 2026, this leaves approximately 24 months to complete inventory, prioritise, procure or configure quantum-safe controls, and begin rollout. That is achievable for TLS and PKI modernisation; it is tight for legacy hardware and embedded systems.
A practical approach is to define three migration tiers aligned to the NCSC milestones: systems that must be migrated by 2028 (highest sensitivity, highest HNDL exposure), systems targeted for the 2031 window (operational systems with longer lead times), and residual systems and legacy environments targeted for 2035. Each tier should have an accountable owner, a defined scope, and an agreed budget envelope.
Quick wins: updating TLS configurations and certificate authorities
TLS configuration modernisation is the most accessible early action for most enterprises. Moving to TLS 1.3 across all services — retiring TLS 1.2 where still present — removes several classical cipher suites from the estate and establishes the baseline for hybrid PQC integration. Modern TLS 1.3 implementations from major vendors (OpenSSL 3.x, BoringSSL, and cloud provider-managed TLS) are beginning to support hybrid key exchange with ML-KEM.
Certificate authority modernisation — migrating to ML-DSA-capable CA infrastructure and beginning the issuance of hybrid certificates — is a parallel track. Certificate lifecycle management processes should be updated to account for the larger certificate sizes and any changes to validity periods recommended under post-quantum PKI best practice. Both workstreams are relatively well-supported by vendor tooling in 2026 and should be prioritised for the 2028 milestone.
Long-lead items: firmware, HSMs, embedded systems, and OT/IoT
Hardware security modules (HSMs) present one of the most significant long-lead challenges in PQC migration. Many HSMs currently deployed in enterprise PKI, payment processing, and key management environments do not support PQC algorithms in firmware and cannot be upgraded — they require physical replacement. HSM replacement cycles are long: procurement, certification testing, integration, and parallel operation periods routinely extend to 18–36 months even in well-resourced programmes.
Operational technology (OT) and IoT devices present similar constraints, often compounded by the absence of remote update capability, vendor support for legacy hardware, and safety certification requirements that constrain what changes can be made to embedded firmware. Enterprises with significant OT estates — energy, manufacturing, transport — should treat this workstream as an independent programme with dedicated resource and a realistic timeline that may extend to the 2031 milestone even with early starts.
Budgeting for PQC migration: key cost drivers enterprises overlook
PQC migration budgets that focus solely on software licensing and professional services consistently underestimate total cost. The categories most frequently missed in initial estimates include:
- HSM replacement and re-certification costs — hardware acquisition, installation, and the operational cost of running parallel environments during transition.
- Staff retraining — security engineers, developers, and operations teams need working knowledge of PQC algorithms, hybrid schemes, and updated PKI processes. Training investment is material in larger enterprises.
- Vendor SLA renegotiation — many existing technology contracts do not address PQC readiness. Legal and procurement effort to assess and update vendor SLAs is frequently underbudgeted.
- Supply chain assessment costs — third-party risk programmes need to extend to cryptographic posture, which may require supplier questionnaires, audits, or contractual addenda.
- Performance mitigation — larger key sizes and signature sizes can require additional compute capacity or network optimisation to maintain service levels.
- Interoperability testing — testing hybrid and PQC configurations across a complex enterprise ecosystem is time-intensive and often requires dedicated test environments.
Building a realistic migration roadmap requires honest accounting across all these categories, not just the algorithm selection and deployment work.
Phase 3 — Implementation, Testing, and Validation
The implementation phase is where theoretical migration plans meet operational reality. Performance, interoperability, and governance considerations that were easy to defer in planning become immediate constraints in production.
Deploying hybrid TLS and hybrid certificates in production
Hybrid TLS deployment — combining X25519 with ML-KEM-768 in TLS 1.3 key exchange — is the most mature production deployment path available in 2026. IETF drafts for hybrid key exchange in TLS 1.3 have been adopted by several major implementations, and cloud providers are enabling hybrid cipher suites on managed TLS endpoints. Enterprises should verify specific version support with their TLS library and load balancer vendors before planning rollout timescales.
Hybrid certificates — X.509 certificates containing both a classical and a post-quantum signature — are less mature from a standards perspective, with ongoing IETF and CA/Browser Forum work on encoding approaches. Enterprises relying on publicly trusted certificates should monitor vendor and CA announcements carefully. Internal PKI deployments have more flexibility to adopt hybrid certificate formats ahead of public trust store support.
Performance benchmarking: larger key sizes and latency implications
Academic research and vendor benchmarks document meaningful but manageable performance impacts from PQC algorithms. As noted in research published in MDPI by Campbell (2025), larger parameter sizes in post-quantum algorithms create measurable overhead in handshake latency and bandwidth consumption, particularly in high-throughput or latency-sensitive environments.
To provide a concrete reference point: ML-KEM-768 public keys are approximately 1,184 bytes versus 32 bytes for X25519, and the combined ciphertext adds a further 1,088 bytes per handshake. For most enterprise web applications, this overhead is absorbed within normal TLS handshake variability. For APIs handling thousands of short-lived connections per second, for real-time communications systems, or for satellite or low-bandwidth links, the impact warrants specific performance testing before production deployment.
Enterprises should establish performance baselines before migration and define acceptable latency thresholds for each workload tier. This prevents post-deployment surprises and provides evidence for FIPS compliance documentation.
Interoperability testing across enterprise ecosystems and supply chains
Interoperability is the most underestimated implementation challenge in enterprise PQC programmes. A hybrid TLS configuration that works correctly between two updated endpoints may fail silently with legacy clients or intermediary devices — load balancers, web application firewalls, DLP appliances — that inspect or terminate TLS. Each network device in the path needs to be assessed for PQC compatibility.
Supply chain cryptography risk extends this challenge outward: partners, suppliers, and SaaS vendors that form part of enterprise data flows may not support hybrid or PQC cipher suites. Prioritising interoperability testing across the highest-value third-party integrations — particularly those involving sensitive data exchange — is a necessary step before broad rollout. A phased geographic or business-unit rollout allows interoperability issues to be identified and resolved at manageable scale.
Staff training and internal cryptography governance
Technical migration without governance change creates fragile security posture. Cryptographic governance — policies, standards, and processes that govern algorithm selection, key management, certificate lifecycle, and algorithm deprecation — needs to be updated to reflect the post-quantum context and to embed cryptographic agility as a standing design requirement.
Developer training is particularly important: the choices made during application development — which cryptographic library to use, how to handle key material, whether to implement certificate pinning — have long tails. Enterprises that invest in updating secure coding standards and training developers to work with PQC libraries reduce the likelihood of generating new cryptographic debt during the migration period itself.
Compliance and Regulatory Obligations for UK Enterprises
The regulatory landscape for PQC migration in the UK is developing rapidly. While no single piece of primary legislation mandates PQC adoption by a specific date, the cumulative effect of NCSC guidance, sector-specific regulatory expectations, and cross-border frameworks creates a substantive compliance obligation for most large enterprises.
NCSC guidance obligations vs. recommendations: what is mandatory for CNI sectors
The NCSC’s PQC guidance is formally advisory for most organisations, but its practical weight varies by sector. For operators of critical national infrastructure (CNI) — energy, water, transport, finance, healthcare, telecommunications — NCSC guidance is effectively mandatory, either through sector-specific regulation or through the CNI assurance frameworks that reference NCSC standards. The NCSC guidance on preparing your organisation for post-quantum cryptography explicitly addresses board-level accountability for this transition.
CNI operators that fail to demonstrate progress against the 2028 milestone risk adverse findings in regulatory assurance reviews and, in the event of a quantum-enabled breach, potential regulatory sanction for inadequate risk management.
Alignment with UK GDPR and data protection considerations
UK GDPR’s security obligation (Article 5(1)(f) and Article 32) requires organisations to implement appropriate technical measures to protect personal data against foreseeable risks. The Information Commissioner’s Office has not yet issued specific PQC guidance, but the harvest now, decrypt later threat is increasingly considered a foreseeable risk for organisations holding sensitive personal data at scale. PQC migration can therefore be framed as a UK GDPR security obligation for data processors and controllers holding long-lived sensitive personal data.
Risk registers maintained for UK GDPR purposes should include quantum risk as a documented item, with migration progress tracked as a mitigating control. This provides a defensible record in the event of a future regulatory inquiry.
Financial services: FCA and PRA expectations on quantum risk
The Financial Conduct Authority and Prudential Regulation Authority have both signalled attention to quantum risk as part of broader operational resilience frameworks. FCA supervisory expectations require firms to identify and manage material technology risks, and quantum risk — including HNDL exposure for long-term financial data — is increasingly expected to appear in technology risk assessments and board-level reporting.
The Bank of England’s Financial Policy Committee has flagged quantum computing as a systemic risk consideration for the financial sector. Regulated firms that cannot demonstrate awareness of and planning for quantum risk face increasing scrutiny in SREP (Supervisory Review and Evaluation Process) discussions and operational resilience self-assessments.
NIS2 and cross-border implications for UK enterprises operating in the EU
The EU’s NIS2 Directive, which came into force for EU member states in October 2024, establishes cybersecurity requirements for essential and important entities that include supply chain security and cryptographic risk management. UK enterprises that operate in EU markets, supply EU-regulated entities, or process data subject to EU jurisdiction may face NIS2 obligations through their EU subsidiaries or contractual relationships.
ENISA (the EU Agency for Cybersecurity) has published PQC guidance aligned with NIST standards, and NIS2 enforcement in major EU markets is expected to reference this guidance. UK enterprises with EU operations should assess NIS2 applicability to their structures and ensure their PQC migration roadmaps are compatible with both NCSC and NIS2 timelines.
Common Mistakes Enterprises Make During PQC Migration
The following patterns emerge repeatedly in enterprise security programmes that have begun PQC planning. They are worth naming explicitly because they are easy to fall into under organisational and budget pressure.
Underestimating discovery scope: shadow IT and forgotten legacy systems
The most common cause of failed or delayed PQC programmes is an incomplete cryptographic inventory. Shadow IT — applications, integrations, and cloud subscriptions provisioned outside central IT governance — consistently expands the true cryptographic estate beyond what initial scans identify. Legacy systems that pre-date modern IT asset management processes (mainframes, bespoke applications, decommissioned-but-still-connected systems) are regularly missed in the first CBOM pass.
A practical mitigation: treat the first CBOM as a version-one document with a defined review cycle, not a definitive inventory. Build discovery into ongoing security operations — continuous certificate scanning, regular dependency audits, and cloud configuration reviews — rather than treating it as a one-time project deliverable.
Treating PQC migration as a one-time project rather than continuous crypto-agility
The algorithms standardised today may not be the algorithms in use in 2035. The history of cryptography includes algorithms that were considered secure and were later found to be vulnerable. ML-KEM and ML-DSA have undergone rigorous review, but they have not had the decades of real-world adversarial exposure that RSA and ECC accumulated. Cryptographic agility — designing systems so that algorithms can be changed without architectural re-engineering — is the sustainable response to this uncertainty.
Enterprises that hard-code algorithm choices into applications and infrastructure during migration, rather than using configurable cryptographic abstractions, create new technical debt at the same time as they are paying off old technical debt. Cryptographic agility should be a non-functional requirement for any system being migrated or newly built during this period.
Skipping hybrid transition and moving directly to pure PQC prematurely
The appeal of moving directly to pure PQC — cutting over completely to ML-KEM and ML-DSA without hybrid schemes — is understandable from a programme simplicity perspective. In practice, it introduces two risks simultaneously: the residual uncertainty around newly standardised algorithms, and interoperability failures with systems that do not yet support PQC. The NCSC’s recommendation to use hybrid schemes during the transition period exists for good reason. Enterprises that skip this stage in the interest of speed may face costly rollback or parallel re-deployment if interoperability or algorithm concerns materialise.
Your PQC Migration Checklist for 2026
The following checklist consolidates the key actions from the phases above into a prioritised sequence for enterprise security and IT teams:
- Initiate cryptographic discovery: Begin building your CBOM across on-premises, cloud, and hybrid environments. Use TLS scanning, PKI audits, code scanning, and network analysis in combination.
- Classify and risk-rank your cryptographic assets: Apply your data classification framework to produce a tiered risk register, focusing first on long-lived sensitive data with high HNDL exposure.
- Assign NCSC milestone ownership: Map your risk register tiers to the 2028, 2031, and 2035 NCSC milestones and assign accountable owners with budget authority.
- Modernise TLS to version 1.3: Retire TLS 1.2 and legacy cipher suites. Enable hybrid ML-KEM key exchange where your TLS library supports it. This is your most accessible quick win.
- Audit your PKI and begin certificate lifecycle management updates: Identify CA infrastructure that will require upgrade or replacement to support ML-DSA certificate issuance. Update certificate lifecycle processes.
- Assess HSM and hardware readiness: Identify HSMs and embedded systems that require physical replacement. Begin procurement and replacement planning — lead times are long.
- Conduct vendor and supply chain assessment: Survey critical technology vendors and supply chain partners on their PQC roadmaps. Update vendor SLAs and procurement standards to reference FIPS 203, 204, and 205 compliance.
- Implement hybrid schemes before pure PQC: Follow NCSC guidance and deploy hybrid cryptographic schemes as your migration posture, not pure PQC configurations that may create interoperability or stability risk.
- Benchmark and test performance: Establish latency and throughput baselines before migration. Measure the impact of larger key and signature sizes in your specific environment.
- Update cryptographic governance and policies: Revise cryptographic standards, secure coding guidelines, and key management policies to reflect PQC algorithms and embed cryptographic agility as a design requirement.