UK NCSC Guidance

What the UK NCSC guidance is—and is not

The source covered by this article is the UK National Cyber Security Centre’s current document Timelines for Migration to Post-Quantum Cryptography, published on 20 March 2025. It describes the transition to post-quantum cryptography (PQC) as a mass technology change that will take a number of years. The NCSC says it is providing both early-stage migration guidance and indicative timelines that UK industry, government, and regulators can follow.1

The document is primarily directed at technical decision-makers and risk owners in large organisations, operators of critical national infrastructure systems—including industrial control systems—and companies with bespoke IT. At the same time, the NCSC states that its core timelines are relevant to all organisations. That combination matters: the guidance has broad planning relevance, but the scale, sequencing, and effort required will depend on an organisation’s current cryptographic maturity and technology estate.1

The guidance also recognises that different sectors will have different current states of cryptographic maturity. The weight assigned to activities across the migration periods may therefore vary, although the NCSC says that focusing on the headline dates is important for investment decisions and broader cyber-security planning.1

The NCSC’s migration milestones

The cited NCSC evidence identifies the activities expected by 2028. Organisations should use these activities to establish a fact base and decision process before attempting broad technology replacement. The sequence begins with governance and discovery, then moves to planning. It is not simply an instruction to deploy a particular algorithm immediately.1

• Define migration goals. This means establishing what the organisation is trying to protect, which business and security outcomes matter, and what “migration” means for its own environment.
• Carry out a full discovery exercise. The NCSC describes this as assessing the estate to understand which services and infrastructure depend on cryptography and therefore need to be upgraded to PQC.
• Build an initial plan for migration. The discovery results should inform sequencing, dependencies, investment decisions, and risk ownership rather than remaining as an inventory exercise.

The practical implication is that an organisation cannot responsibly estimate its migration effort from the number of servers or applications alone. It needs to understand where cryptography is used, which services and infrastructure depend on it, and which components may require upgrade or replacement. The evidence does not provide a universal inventory methodology or prescribe a single product, algorithm, or architecture; those choices require context-specific assessment.1

What the guidance means for enterprise planning

A credible response should make cryptography visible as an enterprise dependency. Discovery should cover services and infrastructure rather than focusing only on applications that explicitly advertise encryption. In practice, the planning question is not merely whether an organisation uses public-key cryptography, but where cryptographic mechanisms affect confidentiality, integrity, authentication, certificates, key establishment, remote access, device communications, and long-lived data. The cited NCSC passage directly supports the need to assess services and infrastructure that depend on cryptography; the additional categories should be treated as areas for an organisation to examine, not as a prescribed NCSC checklist.1

Risk owners should connect discovery to business priorities. Systems protecting information that must remain confidential for a long period may have different urgency from systems where integrity or authentication is the dominant concern. The evidence supports a differentiated, risk-based programme because the NCSC says sectoral maturity differs and that the weight of activities may vary. It does not, however, supply a universal classification threshold or a fixed deadline for each data type.1

The programme should also account for standards maturity and implementation assurance. NIST’s final FIPS 203, FIPS 204, and FIPS 205 standards were published on 13 August 2024, but their qualifications emphasise that conformance does not ensure that a particular implementation is secure, and that the wider system still requires responsible security decisions. This is relevant to procurement and architecture: selecting a standardised mechanism is not equivalent to proving that a deployed product, module, protocol, or system is secure. claim-8234

Critical infrastructure, ICS, and industrial IoT considerations

The NCSC’s intended audience includes operators of critical national infrastructure and industrial control systems, and the cited evidence highlights why these environments need dedicated planning. For ICS networks, conventional enterprise IT considerations still apply, including the protection of remote logins over the internet and the separation of operational technology and IT zones by a DMZ firewall. Remote access channels therefore need to become quantum-secure as part of the migration.1

Operational technology also changes the risk analysis. For wireless fielded OT devices and sensors, confidentiality may not always require strong cryptographic protection, while integrity may be critical because faulty sensor readings or commands can lead to ICS failures. This means that a migration assessment should not rank systems only by confidentiality. Authentication and message integrity can be decisive in safety- or availability-sensitive environments.1

Industrial IoT devices create additional constraints. The evidence identifies devices that may be resource-constrained, difficult to service, embedded in larger products, non-replaceable by design, dependent on proprietary protocols, or based on protocols that are not yet PQC-compatible. Internet-connected devices can also provide an entry point into control networks and onward into the ICS enterprise IT zone through the DMZ. These characteristics make asset discovery, vendor engagement, maintenance planning, and compensating controls important parts of the migration programme.1

Physical infrastructure changes require significant planning and should, as far as possible, coincide with other infrastructure maintenance and improvement. The NCSC evidence further states that continuing OT/IT convergence means conventional IT upgrades that support PQC should become a core part of business planning in the relevant sectors.1

Hybrid cryptography during transition

Hybrid schemes or protocols combine post-quantum and traditional algorithms. ETSI’s final TR 103 966 V1.1.1, published in October 2024, explains that hybrid deployment can mitigate potential vulnerabilities in PQC implementations or provide backward compatibility during migration. It may also reduce bandwidth, computation, and latency overheads by pairing a post-quantum algorithm with a traditional elliptic-curve algorithm.2

Those benefits come with material costs. Hybrid designs increase protocol, implementation, and key-management complexity. The component algorithms may have different functionality and security properties, so the security analysis must consider what guarantees remain if one component is broken. An inappropriate hybrid may be less secure than a properly designed non-hybrid PQC deployment. Hybrid negotiation must also be protected against downgrade attacks, and the requirements can differ between confidentiality and authentication.2

The evidence cautions against deploying post-quantum algorithms that have not undergone standardisation or received sufficient analysis, even in a hybrid construction. ETSI also describes a future point at which confidence in PQC algorithms and implementations may make hybrids unnecessary; moving to purely post-quantum algorithms could then avoid hybrid overhead and the continued use of traditional components known to be vulnerable to quantum adversaries.2

Accordingly, hybrid deployment should be a documented migration choice, not an assumed safe default. The design record should state whether the objective is hybrid security, interoperability, or both; how negotiation is protected; how keys and certificates are managed; and how the organisation will retire the traditional component when appropriate. The cited evidence does not prescribe one universal hybrid pattern.2

Standards, implementations, and crypto-agility

NIST FIPS 203 specifies a module-lattice-based key-encapsulation mechanism and states that its three parameter sets offer different trade-offs between security strength and performance. It also warns that the security guarantees of a KEM hold only under specified conditions, including protection of sensitive values such as randomness, the decapsulation key, and the shared secret.5

FIPS 204 and FIPS 205 similarly stress that digital-signature security depends on protecting private keys and that conformance does not guarantee the security of a particular implementation or the overall system. FIPS 204 additionally identifies secure key management, identity binding, and proof of possession as important considerations for digital signatures.34

These qualifications reinforce a central NCSC migration lesson: the programme must address architecture and operations, not just algorithm names. Procurement and assurance should examine implementation security, key protection, certificate and identity processes, update paths, performance, interoperability, and operational support. The evidence does not establish that any particular vendor product is approved or that any single certification proves end-to-end system security.34

Crypto-agility is a practical way to preserve options while standards, protocols, products, and organisational requirements evolve. The German Federal Office for Information Security recommends making cryptographic mechanisms sufficiently flexible in new and existing applications so that organisations can react to developments, implement future recommendations and standards, and replace algorithms that no longer provide the desired security level. This is supporting international guidance, not a UK NCSC mandate in the cited evidence.6

A practical operating model for organisations

The NCSC milestones can be translated into an operating model without turning them into a rigid implementation prescription. First, assign executive ownership and risk ownership for the migration goals. Second, establish the scope of the estate, including outsourced services, bespoke systems, operational technology, embedded devices, certificates, protocols, and long-lived information. Third, record cryptographic dependencies and the consequences of failure across confidentiality, integrity, authentication, availability, safety, and regulatory or contractual exposure. The NCSC evidence directly supports goal-setting and full discovery; the remaining design choices should be tailored to the organisation.1

1. Set migration goals and define decision rights. Record which business outcomes and risk tolerances govern prioritisation.
2. Perform full discovery across services and infrastructure, including dependencies that are hidden behind products, suppliers, devices, and protocols.
3. Prioritise systems by exposure, data lifetime, integrity and authentication needs, criticality, upgrade difficulty, and dependency on third parties. The NCSC evidence supports differentiated sectoral emphasis but does not prescribe a universal scoring model.
4. Build an initial plan with work packages for architecture, procurement, testing, replacement, maintenance windows, supplier engagement, and incident response.
5. Evaluate hybrid options only where their security objective, interoperability need, downgrade protection, and additional complexity are understood.
6. Validate implementations and the wider system rather than relying solely on conformance claims. Protect keys, randomness, certificates, and other sensitive cryptographic values. claim-9
7. Review the plan as standards, protocols, products, and organisational dependencies evolve. Crypto-agility can help preserve the ability to change mechanisms, but it does not remove the need for sound security analysis.

For critical infrastructure and ICS operators, the operating model should include physical maintenance cycles and the relationship between OT and IT upgrades. For industrial IoT, it should explicitly track devices that cannot be upgraded, are difficult to service, use proprietary protocols, or sit on internet-connected paths into control networks. These constraints may determine sequencing and compensating measures more strongly than the cryptographic algorithm choice itself. claim-51

Scope, limitations, and interpretation

This article is limited to the cited source set. The central UK source is current and published on 20 March 2025, but the cited passage does not provide a complete list of every NCSC milestone beyond the 2028 activities quoted here. It also does not state that all organisations must deploy a named algorithm, adopt a particular hybrid construction, or finish migration by a universal date. claim-11

The other evidence passages provide context from NIST, NSA, ETSI, ENISA, the German BSI, and the Canadian Centre for Cyber Security. Their documents have different jurisdictions, purposes, and statuses. NIST FIPS 203, 204, and 205 are final standards published on 13 August 2024; ETSI TR 103 966 V1.1.1 is final and dated October 2024; the NCSC document is current and dated 20 March 2025. These sources should not be treated as interchangeable UK legal or regulatory instruments.152

In particular, the evidence does not establish a legal obligation for a specific UK organisation, an applicable sector regulator’s rule, a complete UK procurement requirement, or a guaranteed date for cryptographically relevant quantum computing. It supports preparation, discovery, risk management, standards-aware design, and staged migration planning. Organisations requiring a binding interpretation must assess the instruments that apply to their jurisdiction, sector, contracts, and systems. claim-1152

Conclusion

The UK NCSC guidance frames PQC migration as a multi-year enterprise transformation. Its immediate message is practical: define migration goals, discover cryptographic dependencies across services and infrastructure, and build an initial plan by 2028, while adapting emphasis to sectoral maturity and system constraints. Large organisations, critical infrastructure operators, ICS environments, and bespoke-IT companies should treat the milestones as a basis for investment and risk planning. Hybrid cryptography may assist transition, but it requires careful security analysis, downgrade protection, and key-management discipline. Finally, standard conformance is not a substitute for secure implementation or whole-system assurance, and the NCSC dates should not be misrepresented as universal legal deadlines. claim-1 claim-31234