When the UK's top cyber watchdog speaks on quantum security, it pays to listen.

The UK's National Cyber Security Centre (NCSC) has released a timeline and set of recommendations for addressing the risks posed by quantum computing. While the guidance includes familiar steps, it also offers valuable technical insights and some governance practices worth attention. What makes this noteworthy is the authoritative voice behind these recommendations. The NCSC's guidance can serve as a useful reference point for shaping internal quantum security strategies.

Understanding the role of the National Cyber Security Centre (NCSC) is essential when examining the UK's approach to post-quantum cryptography. As the UK's leading authority on cyber security, the NCSC provides trusted guidance on encryption standards, key management, secure protocols, and emerging areas such as post-quantum cryptography. Its publications offer comprehensive recommendations on cryptographic algorithms (including AES, RSA, and ECC), key lengths, and widely used protocols such as TLS and VPN standards. Notably, the NCSC also advises on readiness for post-quantum cryptography.

To support the security of cryptographic products, the NCSC operates evaluation schemes such as Commercial Product Assurance (CPA) and Common Criteria (CC). These assessments are particularly relevant for technologies deployed in government systems and critical national infrastructure.

Although the NCSC is not a formal regulator and its guidance is not legally binding, its recommendations carry substantial influence—especially across the public sector. For government departments and organisations handling classified or sensitive information, adherence to NCSC standards is often mandated by policy or contractual obligations. In the private sector, following this guidance is considered best practice.

---

The following sections highlight several aspects of the publication that stood out to me. The full publication is available here.

---

Timeline

A central takeaway from the publication is the proposed timeline for transitioning to quantum-safe cryptography. The guidance calls for organisations to complete their planning by 2028, ensure that high-criticality systems are migrated by 2031, and finalise the transition across all remaining systems by 2035. The timeline is slightly different from the NIST (US counterpart of the NCSC) recommendation but generally remains the same.

This is an ambitious schedule, particularly given the scale and complexity of modern digital infrastructure. Meeting these milestones will require a coordinated effort across technical teams, leadership, and supply chains.

Different Approaches for Different Organisations

The NCSC acknowledges that organisations will follow different paths in adopting post-quantum cryptography, depending largely on their size and the complexity of their IT environments. While the idea that different organisations require different approaches may seem self-evident, the structured comparisons provided by the NCSC offer valuable reference points. These distinctions can help internal stakeholders better articulate their organisation's current position and prioritise quantum-safe initiatives within broader strategic planning.

Small and medium-sized enterprises (SMEs)—defined as entities with fewer than 250 employees, and mid-sized organisations as those with 250 to 500—typically rely on standard, off-the-shelf IT solutions such as mainstream browsers, operating systems, and mobile platforms. For these organisations, PQC migration is expected to be relatively seamless, occurring through routine software updates provided by vendors. However, when SMEs use custom or specialised applications, they will need to identify and implement PQC-compatible updates or replacements. In these cases, the same migration timelines outlined for larger organisations should be followed.

Larger organisations—those with more than 500 employees—often operate more complex environments, including bespoke software and internal tools. Given their greater technical capacity and broader system landscape, these organisations are expected to develop and implement tailored PQC migration strategies that align with their specific operational needs.

Remediation strategies

While this may seem clear to those experienced in cyber and IT risk management, it is reassuring to see that the NCSC explicitly acknowledges a range of valid approaches. When post-quantum compatibility cannot be achieved easily, the NCSC outlines several strategic options that organisations can consider as part of a broader architectural review. These include:

• Modernise the system: Use the opportunity to assess whether a move to cloud-based infrastructure or alternative architectures is appropriate.

• Retire the service: Plan for a controlled shutdown of systems that do not justify further investment, avoiding the need for migration.

• Run until end-of-life: Continue operating systems that are already scheduled for decommissioning within a defined timeframe.

• Tolerate the risk: In limited cases, accept the risk of continued operation without quantum-safe protections, with proper oversight.

It is critical that cyber security and IT teams recognise that inaction is not a viable strategy. Where a technical solution is not feasible, the issue should be escalated to business leadership for a formal risk decision. Risk acceptance—if chosen—must be documented and supported by clear business rationale.

Private PKI Update

PKI is widely recognised as one of the first areas in enterprise infrastructure requiring attention in the transition to post-quantum cryptography. It delivers cryptography services to other infrastructure elements and, on that merit, needs to be updated first to enable the rest to become quantum safe. However, updating private PKI environments presents a range of technical and operational challenges.

Many enterprise IT systems use privately managed Public Key Infrastructure to issue certificates for devices and, for example, user authentication. Migrating to a quantum-safe PKI involves establishing a new root of trust and issuing PQC certificates throughout the environment. While much of this can be managed remotely, certain endpoints may require physical access or specialised handling.

Several migration strategies are available. One common approach involves deploying a PQC-enabled PKI alongside the existing infrastructure. In highly controlled environments, a direct switchover may be possible. More often, a phased transition is needed, where both legacy and PQC systems operate in parallel. Another strategy introduces a PQC root that cross-signs the existing root, allowing backward compatibility during the migration period. Each option comes with its own security trade-offs and should be assessed in the context of the organisation's risk profile and operational constraints.

Operational Technology and Industrial IoT Considerations

As enterprise IT environments evolve to become quantum-secure, attention must also turn to operational technology (OT) systems. While the confidentiality of their data may be less critical, maintaining data integrity is essential. Faulty readings or compromised commands can trigger failures in industrial control systems (ICS), with significant operational consequences.

Historically, these devices migrated to an isolated part of the network called a DMZ (Demilitarised zone), where the firewall controlled all communication inside and outside this zone. However, there is an increasing prevalence of wirelessly connected fielded OT devices and sensors.

Industrial IoT (IIoT) devices introduce unique challenges for post-quantum migration. The challenges stem from the additional computational demand imposed by Post Quantum Crypotghyic algorithms and operational challengesimposed by the devices themselves. These devices, in many cases:

• Are resource-constrained, limiting cryptographic performance

• Cannot be upgraded due to hardware or software limitations

• Are deployed in remote or hard-to-access locations

• Are embedded within larger systems, making replacement difficult

• Were not originally designed with future cryptographic updates in mind

• Operate using proprietary or non-PQC-compatible communication protocols

Given these complexities, migration strategies must account for both technical constraints and the broader security architecture. Special consideration is required to mitigate risks posed by legacy or un-upgradeable IIoT infrastructure.

Especially challenging areas

Two areas where migration is expected to be particularly complex are the Web Public Key Infrastructure (WebPKI) and Industrial Control System (ICS) protocols.

WebPKI

WebPKI underpins the trust infrastructure of the internet. It relies on a distributed ecosystem that includes Certificate Authorities (CAs), trusted root stores, Certificate Transparency (CT) log providers, and Certificate Revocation List (CRL) services. These components work together to authenticate websites and secure digital communications. This is what enables HTTPS communication.

Adapting WebPKI to support post-quantum cryptography—particularly quantum-resistant digital signatures—is complex. Current standards do not yet fully support quantum-safe certificates, and maintaining backward compatibility with existing browsers and servers adds further difficulty. Because WebPKI is decentralised, coordinating changes across its many participants is challenging. Any misalignment can compromise trust or cause service disruptions.

Below is a summary of how each key component is affected by the shift to post-quantum cryptography, including anticipated changes and the challenges that come with them:

• Certificate Authorities (CAs):

  • Modern Certificate Authorities (CAs) operate using a hierarchical key structure designed to balance security and scalability. At the top of this hierarchy is the offline root key, which is kept in cold storage and used sparingly to sign intermediate certificates. Beneath it, online intermediate keys handle the day-to-day issuance of X.509 certificates, as well as the generation of Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) responses used to verify certificate status.

  • To protect these critical cryptographic operations, CAs rely on hardware security modules (HSMs). These tamper-resistant devices enforce strict controls over how private keys are stored and used, helping prevent unauthorised access, key leakage, and operational misuse. This layered trust model not only limits the exposure of the most sensitive keys but also supports the scalability required for large-scale public key infrastructure. Today, CAs use offline root and online intermediate keys to sign X.509 certificates, CRLs, and OCSP responses. These operations are protected by hardware security modules (HSMs).

  • With PQC, CAs will need to rotate to new signature schemes such as Dilithium or Falcon. Challenges include the much larger size of PQ signatures—often 10 to 40 times bigger than RSA or ECDSA—which strains issuance pipelines and HSM storage. And root-store owners like Mozilla and Google are tightening policies on key lifecycles and revocation in preparation for this shift.

• Trusted Root Stores:

  • Operating systems and browsers maintain carefully curated lists of trusted root certificates, which serve asthe foundation for validating TLS certificate chains. These root certificates belong to certificate authorities (CAs) that have been vetted according to strict security and operational criteria. The purpose of curation isto ensure that only reputable and audited CAs are trusted to issue certificates for websites and digital services. Without this vetting process, any CA could issue a certificate for any domain, making it significantly easier for attackers to impersonate trusted services or intercept encrypted communications. 

  • Distribution at scale is a major challenge. Many devices—especially IoT and embedded systems—rarely receive updates. Additionally, mobile platforms limit trust-store size, and hard-coded fingerprints in legacy apps must be updated manually.

• Certificate Transparency (CT) Logs:

  • Certificate Transparency (CT) logs serve as a public record of all issued TLS certificates, enabling browsers and other clients to verify that a certificate has been properly logged. Once a certificate is submitted to a CT log, the log returns a signed receipt—known as a Signed Certificate Timestamp (SCT)—as proof of inclusion. These SCTs are typically signed using classical digital signature algorithms such as ECDSA.

  • Browsers rely on SCTs to validate certificates but generally require at least two SCTs from independent logs to ensure redundancy and detect potential mis-issuance. In practice, browsers trust the SCTs themselves, rather than querying the logs in real time.

  • Replacing ECDSA with post-quantum signature algorithms like Dilithium significantly increases SCT size—from just 64 bytes to around 2.4 KB. This added overhead can slow TLS handshakes and, in some cases,exceed the network's Maximum Transmission Unit (MTU), leading to fragmentation or failure.

  • Further complicating the transition, the current CT standard allows each log to use only a single signature algorithm. This limitation creates a challenge during the migration period, as not all clients and infrastructure will support PQC at the same time. To maintain compatibility, new specifications are needed to support hybrid or multi-algorithm SCTs—enabling the use of both classical and quantum-safe signatures during the transition.

• Certificate Revocation List (CRL) Services:

  • Certificate Authorities (CAs) use a variety of mechanisms to manage certificate revocation, with Certificate Revocation Lists (CRLs) remaining a core requirement under many public root programs. CRLs are digitally signed lists that identify certificates no longer considered valid, typically due to compromise or administrative withdrawal. These lists are most often signed using RSA or ECDSA, though some ecosystems rely more heavily on dynamic alternatives like the Online Certificate Status Protocol (OCSP) or compressed solutions such as CRLite.

  • With the adoption of post-quantum cryptographic (PQC) algorithms, each CRL file is expected to grow significantly—adding around 2.4 KB per signature. At the same time, certificate lifespans are shortening to minimise exposure windows, which in turn increases the frequency of CRL updates and further expandsoverall data volume.

  • These changes present compatibility challenges for legacy systems, many of which include hard-coded limits on CRL file size or support only specific signature algorithms. Updating these systems may be difficult or infeasible, particularly in embedded or long-life environments.

The complexity of modern WebPKI, combined with the scale of its deployment, means that even incremental changes must be carefully coordinated.

ICS protocols

A second major concern lies in the protocols used within Industrial Control Systems (ICS), which are responsible for operating and monitoring critical infrastructure such as energy grids, water treatment facilities, and industrial manufacturing lines. Many of these systems still depend on legacy communication protocols that were never built with cryptographic security in mind.

Introducing quantum-safe algorithms into these environments is not as simple as updating software libraries. In many cases, the underlying protocol architecture lacks the mechanisms needed for secure key exchange, authentication, or certificate management. Addressing this gap often requires fundamental redesign—not just of the software, but also of the supporting hardware and operational procedures.

These challenges are compounded by the nature of ICS environments, where uptime is essential, system updates are infrequent, and hardware lifecycles can extend well beyond a decade. As a result, migrating to post-quantum cryptography in these settings demands a careful, long-term approach that balances security with operational continuity.

What is missing

There are several areas where the publication could be strengthened. It's also important to consider what has been left unaddressed.

1. Concrete, real-world performance metrics for post-quantum cryptographic (PQC) key-agreement and digital-signature schemes remain notably absent. The current documentation offers only general observations, leaving a gap where precise, actionable data would be most valuable.

2. The discussion around vendor dependencies could be more closely aligned with established Vendor Risk Management practices. For large organisations, the path to PQC adoption will likely depend on the preparedness and support of their external suppliers.