Quantum Risk for Government: What Public Sector Security Teams Must Do Now

A procurement officer writing a TLS certificate requirement today for a system with a planned go-live in 2028 is making a cryptographic decision that will still be live when the most widely cited expert estimates for a cryptographically relevant quantum computer begin to arrive. That system, if it uses RSA or ECDSA for key exchange, will need to be migrated or replaced at cost. The procurement decision is not a future problem. It is happening now, in every department that issues an ICT framework call-off.

Public sector organisations face authoritative government guidance on PQC migration timelines, not aspirational targets. The UK's National Cyber Security Centre has set 2031 as the milestone for completing early, highest-priority PQC migration activities, and 2035 as the milestone for full migration of all systems. The US equivalent framework, through NSM-10 and OMB M-23-02, mirrors the urgency. NIST's IR 8547 deprecation schedule removes RSA and ECDSA from new systems entirely from 2030. These are not recommendations from an academic body. They are government security obligations backed by the same agencies that set classification policy.

Most public sector security teams understand the regulatory context in broad terms. Fewer have mapped it to the specific procurement and accreditation workflows where the work actually gets done. This article provides that mapping, and it is direct about the timeline problem: working back from 2031 with a realistic implementation lead time of three to five years means the cryptographic inventory work should already be underway. For some departments, it is not.

The regulatory mandate is not a recommendation

UK: NCSC PQC migration timeline

NCSC published its PQC migration guidance in October 2023, with updates in 2024, setting two milestones within the UK Government Security Classification framework. The 2031 milestone is for completion of early, highest-priority PQC migration activities. The 2035 milestone is for full migration of all systems. The classification levels determine the sequencing: the higher the classification, the earlier the migration requirement. This is the same logic applied to any security control with a tiered compliance structure.

NCSC's guidance does not treat these as desirable targets for technically sophisticated departments. The language positions them as baseline requirements within the Government Security Classification (GSC) policy framework, which applies to all departments processing OFFICIAL, OFFICIAL-SENSITIVE, SECRET, and TOP SECRET information. Most UK government departments operate primarily in the OFFICIAL and OFFICIAL-SENSITIVE tiers. It should be noted that NCSC's published guidance does not explicitly map the 2031 milestone to a specific GSC classification tier; the inference that it applies to OFFICIAL-SENSITIVE and above is a reasonable operational interpretation, not a stated mapping. The 2031 milestone therefore applies in practice to the systems that form the bulk of central government's digital infrastructure.

For the detailed interpretation of NCSC's full migration guidance, including the specific algorithm recommendations and hybrid transition approach, see the NCSC PQC migration guidance for UK organisations.

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

National Security Memorandum 10 (NSM-10, May 2022) directed all US federal agencies to inventory their National Security Systems cryptographic dependencies and begin migration to quantum-resistant algorithms. It set the policy framework for CNSA 2.0 adoption within national security systems, establishing the US government's formal position that migration is a strategic priority rather than a technical upgrade cycle.

OMB Memorandum M-23-02 (18 November 2022) extended the directive to all Federal Civilian Executive Branch agencies, not just national security systems. Agencies were required to develop quantum-resistant cryptography transition plans. The distinction matters for UK security teams: NSM-10 applies to national security systems specifically; OMB M-23-02 broadens the scope across all civilian federal operations. These are US federal instruments. They do not bind UK government organisations. What they do provide is corroboration: two governments, working independently, arrived at substantially the same 2031-2035 migration window. For UK security teams making the case internally for migration investment, that convergence is an argument worth using.

NIST IR 8547: what it means for government procurement

The transition timeline standard

NIST IR 8547, published as an Initial Public Draft in November 2024, provides the formal deprecation schedule for the algorithms that underpin most government cryptographic infrastructure. RSA, DSA, ECDH, and ECDSA are deprecated for use in new systems after 2030 and disallowed entirely after 2035. AES-128 key wrapping and SHA-256 are retained under review. The schedule is unambiguous about direction.

The alignment between NIST IR 8547 and NCSC's 2031/2035 milestones is not coincidental. Both reflect a similar assessment of CRQC feasibility probability distributions and of the lead times required for large-scale cryptographic migration in complex, multi-supplier environments. The structural convergence gives UK procurement officers an internationally authoritative standards basis for writing PQC readiness into supplier evaluation criteria. For the detailed timeline and its implications, see the NIST IR 8547 transition timeline analysis.

Procurement implications

Government ICT procurement through Crown Commercial Service framework agreements, G-Cloud, and DOS already requires suppliers to demonstrate compliance with information security standards. NIST IR 8547's deprecation schedule is the authoritative basis for including PQC readiness as a supplier evaluation criterion from current procurement cycles. A system procured on a five-year contract today will be live through 2030 and potentially beyond, inside the deprecation window.

The practical language for tender specifications: ML-KEM (FIPS 203) support as a roadmap commitment for TLS and key management components; ML-DSA (FIPS 204) roadmap for code signing and authentication tokens; hybrid key exchange capability for TLS 1.3 in transitional deployments. CCS has not yet published formal PQC procurement guidance as of May 2026, but the NIST IR 8547 deprecation schedule provides the standards-body authority to include these requirements as best-practice security criteria regardless.

Government Security Classifications and migration sequencing

Classification-driven prioritisation

The UK GSC framework defines four tiers: OFFICIAL, OFFICIAL-SENSITIVE, SECRET, and TOP SECRET. Her Majesty's Government Communications Centre and NCSC publish cryptographic standards per classification level. For most departmental security teams, the relevant migration scope is OFFICIAL-SENSITIVE: the classification tier used for data whose compromise would cause harm but not directly threaten national security.

OFFICIAL-SENSITIVE encompasses a substantial portion of government operational data. HR records, legal case files, policy communications, procurement strategies, and ministerial correspondence all routinely fall within this tier. Under the Public Records Act 1958, OFFICIAL-SENSITIVE records can have 20-year or longer retention requirements. Apply Mosca's inequality to that retention window: 20 years of data sensitivity lifetime, added to a three-to-five year migration lead time, exceeds GRI 2024's estimated 14 to 34 percent probability window for a CRQC by 2034. For that category of data, migration is already overdue on any conservative risk calculation.

GovAssure and cryptographic controls

GovAssure, the Cabinet Office's government assurance scheme launched in 2023, requires departments to demonstrate capability across NCSC's Cyber Assessment Framework (CAF). Cryptographic controls map to CAF Objective B (Protecting Against Cyber Attack), specifically B2 (Identity and Access Control) and B4 (Data Security). Current CAF assessments focus on the adequacy of classical cryptographic controls. As PQC migration guidance matures, CAF assessment cycles are expected to incorporate quantum readiness as a component of B4 compliance evidence.

Departments building their GovAssure evidence packs in 2026 and 2027 should document their PQC migration planning as forward-looking B4 evidence. An active cryptographic inventory programme and a defined migration sequencing plan are documentable commitments that will strengthen CAF submissions, even before migration is complete.

EU context: NIS 2 Article 21(2)(h) for public sector operators

What Article 21(2)(h) requires

NIS 2 Directive (EU 2022/2555) Article 21(2)(h) requires essential and important entities to implement "the use of cryptography and, where appropriate, encryption" as part of their cybersecurity risk management. Central governments in EU member states are designated essential entities under Annex I, placing them in the highest tier of NIS 2 obligation. The transposition deadline for member state implementation was October 2024.

The regulation is not algorithm-specific. "Cryptography" in Article 21(2)(h) does not mandate ML-KEM by name. ENISA guidance for NIS 2 implementation positions PQC migration as a component of Article 21 compliance for long-lived systems, characterising post-quantum algorithms as part of "state-of-the-art" cryptography. That characterisation creates a dynamic compliance standard: as FIPS 203 establishes ML-KEM as the published standard, its adoption becomes the state-of-the-art baseline. For the detailed NIS 2 quantum risk gap analysis, see NIS 2 and quantum security: the compliance gap analysis.

UK public sector and NIS 2: the jurisdiction boundary

NIS 2 is EU law. It does not apply to UK organisations unless they operate as essential entities within EU member states. The UK departed the EU on 31 January 2020. UK public sector organisations are governed by the UK Network and Information Systems (NIS) Regulations 2018 (SI 2018/506) and NCSC CAF requirements. NIS 2 does not create UK obligations, and security teams should not cite it as doing so.

The practical exception: UK public sector bodies that provide digital infrastructure or cross-border digital services within EU member states may be in NIS 2 scope in that specific capacity. This is a case-by-case legal question, not a general rule. Any UK department with EU-facing digital services should obtain specific legal advice on NIS 2 applicability before treating it as a compliance obligation.

Cabinet Office cryptographic policy and departmental obligations

The policy framework

Cabinet Office owns cross-government cryptographic policy through the National Cyber Security Strategy and NCSC tasking. Departmental information security policies must align to NCSC-endorsed standards. GCHQ and NCSC publish guidance on approved cryptographic products and configurations for government networks, with specific guidance per classification tier. Procurement of cryptographic products outside NCSC-endorsed schemes for classified processing requires central coordination.

For procurement teams, the practical implication is that any system procured for OFFICIAL-SENSITIVE processing that includes cryptographic components should be selected against NCSC product guidance, not simply against a generic ISO 27001 security requirement. FIPS 203-compliant libraries and algorithm-agile hardware will appear on NCSC-endorsed product lists as the migration timeline advances.

Cross-departmental migration coordination

GDS (Government Digital Service) and the Central Digital and Data Office own the Government Digital and Data Service Standard. Point 9 of the Service Standard ("Create a secure service which protects users' privacy") provides the policy hook for PQC migration in public-facing digital services. Teams building or renewing services under the standard should incorporate ML-KEM compatibility into their cryptographic design decisions now.

The structural constraint for large departments is not technical. ML-KEM libraries are available in OpenSSL 3.5, Bouncy Castle, and other production TLS implementations. The constraint is that most departments have never conducted a formal cryptographic asset inventory. They do not know what is running RSA-2048, where, on what hardware, with what update cycle, and with what supplier dependencies. The NCSC CBOM (Cryptographic Bill of Materials) methodology is the starting tool: a structured inventory of all cryptographic dependencies, modelled on the Software Bill of Materials concept that is now required in many procurement processes. The cryptographic asset register build guide provides a step-by-step approach to constructing that inventory for government departments.

First actions for government security teams

Immediate term (now to 2027)

Three actions can be initiated without waiting for departmental approval of a full migration programme. First, cryptographic inventory: enumerate all systems using RSA, ECDH, ECDSA, DSA, and DH. Prioritise by data classification and sensitivity lifetime. A spreadsheet-based CBOM for the 20 highest-value systems gives an immediate risk picture. Second, identify PQC-ready products already in the estate. OpenSSL 3.5 and later supports ML-KEM hybrid key exchange. Thales payShield and Entrust nShield HSMs have published PQC roadmaps. Third, begin supplier engagement: request PQC migration roadmaps from current ICT suppliers under framework agreements. Suppliers who cannot provide a roadmap are a procurement risk in the 2027-2031 window. Algorithm agility is the baseline procurement criterion; the crypto agility implementation guide provides the specification language for tender documents.

The PQC migration decision tree provides a structured self-assessment for sequencing the cryptographic inventory, including classification-tier weighting and supplier dependency mapping.

Medium term (2027-2031)

The medium-term programme has three components. Migrate highest-classification systems to hybrid key exchange, combining X25519 with ML-KEM to maintain classical security during the transition period while adding quantum resistance. Update signature infrastructure from ECDSA to ML-DSA (FIPS 204) for document signing, code signing, and authentication tokens. Align GovAssure CAF evidence documentation with migration progress, building a verifiable record that can be submitted in future assessment cycles.

Hardware replacement cycles are the binding constraint. Smart card-based authentication, HSMs, and VPN appliances implemented in 2020-2022 hardware generations may not support PQC algorithm updates via firmware. Decisions about hardware replacement within this window must be made in current procurement cycles, not deferred to 2028. The PQC migration timeline: 2025 to 2027 maps the specific procurement and deployment milestones against the 2031 deadline.

The honest timeline challenge

No government security team should plan as though 2031 is a comfortable deadline. A realistic implementation timeline for a large department, accounting for procurement approval cycles, supplier negotiations, legacy system constraints, and accreditation requirements, runs to three to five years from first inventory completion to full deployment on high-priority systems. Working back from 2031 means cryptographic inventory work should be starting in 2026 at the latest. For some departments, it is behind that point.

The constraint is not technical. ML-KEM is a published standard with production library implementations. The constraint is that migration requires knowing what needs to be migrated, and most government cryptographic infrastructure has never been formally inventoried. That inventory is where the work starts, and it is within every department's capacity to begin it without waiting for central guidance to mature further.

QSECDEF's PQC readiness checklist for CISOs provides a starting framework for structuring the inventory and migration planning process within government security teams.