PQC Requirements and Guidance for Critical Infrastructure

What the guidance means for critical infrastructure

Post-quantum cryptography is relevant because a sufficiently capable quantum computer could threaten commonly used public-key cryptosystems, including key-establishment and digital-signature schemes whose security relies on integer factorization or discrete logarithms over finite fields and elliptic curves. PQC uses algorithms intended to remain secure against classical and quantum computers, although the cited material does not establish when a cryptographically relevant quantum computer will exist. The practical requirement for critical infrastructure is therefore risk-informed preparation rather than reliance on a predicted arrival date.12

The UK National Cyber Security Centre (NCSC) describes PQC migration as a mass technology change that will take years and specifically addresses large organizations, operators of critical national infrastructure systems—including industrial control systems—and organizations with bespoke information technology. Its guidance says that sector and business-specific risks will influence objectives and that, in many cases, organizations will need to meet regulatory requirements. It also frames PQC as part of wider cyber resilience, rather than as an isolated cryptographic upgrade.3

The guidance is not a single universal legal rule applicable in the same way to every operator. The cited sources include standards, technical reports, national guidance, and agency resources with different scopes and statuses. Organizations should therefore distinguish between applicable obligations imposed by their sector or jurisdiction, official guidance used to plan risk reduction, and technical standards used to specify or assess cryptographic mechanisms. The evidence supports a disciplined governance process, but it does not identify a single cross-jurisdictional PQC mandate for all critical-infrastructure operators.314

Relevant standards and official guidance

NIST published FIPS 203, the Module-Lattice-Based Key-Encapsulation Mechanism Standard, on 13 August 2024. The standard specifies ML-KEM and three parameter sets with different trade-offs between security strength and performance. The cited FIPS 203 passage states that all three parameter sets are approved to protect sensitive, nonclassified communication systems of the U.S. federal government. It also states that the security guarantees of a key-encapsulation mechanism hold only under specified conditions, including protection of randomness, the decapsulation key, and the shared secret key.14

NIST also published FIPS 204, the Module-Lattice-Based Digital Signature Standard, and FIPS 205, the Stateless Hash-Based Digital Signature Standard, both on 13 August 2024. FIPS 204 addresses ML-DSA; FIPS 205 addresses SLH-DSA. The cited passages emphasize that private keys and signing-related sensitive values must be protected, that approved random-bit-generation processes are required for relevant key-generation operations, and that implementations must be designed and built securely.561

The standards contain an important limitation for assurance and procurement: conformance to a standard does not ensure that a particular implementation is secure, and a conforming product does not guarantee security for the overall system in which it is used. FIPS 203 places responsibility on the implementer to build a secure key-establishment capability; FIPS 204 and FIPS 205 place responsibility on the responsible authority or implementer to ensure an acceptable level of overall security. Critical-infrastructure assurance should therefore evaluate the module, its integration, operational controls, key lifecycle, validation status where relevant, and the surrounding system.156

The NSA’s cited post-quantum resources state that it has announced selections for quantum-resistant algorithms and refer to CNSS Policy 15, released 4 March 2025. The same material says that NIST was conducting a rigorous selection process and that updated NSA guidance would follow completion of that process. Because the cited evidence contains both this resource description and later references to CNSS Policy 15, organizations should preserve the status and date of the guidance they rely on and verify which requirements apply to their environment rather than treating every agency resource as interchangeable.7

ETSI TR 103 966 V1.1.1, dated October 2024, is a technical report on deployment considerations for hybrid schemes. It is useful for understanding migration design issues, but the cited evidence does not describe it as a legal requirement. ENISA’s cited material identifies PQC and quantum mitigation as part of its cybersecurity work and places the subject alongside risk management, cybersecurity of critical sectors, product security, and certification. These materials support awareness and technical risk analysis; they do not, on the cited evidence, create a single mandatory implementation profile for every critical-infrastructure organization.48

How critical-infrastructure organizations should interpret the risk

The strongest immediate rationale for prioritization is not a claim that a cryptographically relevant quantum computer is imminent. The German Federal Office for Information Security (BSI) material says that an enormous effort would currently be needed to scale quantum computing to a cryptographically relevant level and estimates that short-term development leaps in that direction are rather unlikely. It nevertheless calls for immediate action where cryptographic information has long secrecy periods and high security requirements.2

That urgency is associated with the “store now, decrypt later” risk: an adversary may collect key-negotiation messages and encrypted data in advance and attempt decryption in the future with a quantum computer. This makes confidentiality decisions dependent on the expected secrecy lifetime of information, not only on the current threat environment. Critical infrastructure should consequently identify data whose confidentiality must persist across long operational, legal, safety, strategic, or public-service lifetimes.2

The NCSC recommends beginning with a clear understanding of the current estate. Its cited guidance calls for identifying key services and applications, recording the data held—including expected lifetime and value to an adversary—identifying how data is protected in transit and at rest, mapping the systems through which data is processed, and maintaining effective processes for managing software and hardware assets. This inventory is particularly important in older estates, where cryptographic services may have evolved in haphazard ways.3

For critical infrastructure, discovery should include information technology, operational technology, industrial control systems, communications systems, embedded devices, hardware roots of trust, certificates, key-management services, remote-access paths, supplier-managed services, and dependencies that cannot be upgraded quickly. The cited evidence specifically identifies long-lived hardware roots of trust and supplier and physical-infrastructure dependencies as items to address in an initial migration plan. The broader categories in this sentence are a way to apply that evidence to an estate; they should be validated against the organization’s actual architecture and sector obligations.3

Indicative NCSC milestones and governance expectations

The NCSC’s current guidance, published 20 March 2025, sets indicative target dates for UK industry, government, and regulators. It says the core timelines are relevant to all organizations, while recognizing that sectors differ in cryptographic maturity and that the weight of activities may vary. For operators of critical national infrastructure, the milestones are best understood as planning and investment signals rather than as evidence in this bundle of a universally enforceable statutory deadline.3

By 2028, the NCSC identifies defining migration goals, carrying out a full discovery exercise, and building an initial plan. The plan should identify the highest-priority and earliest migration activities, supplier and physical-infrastructure dependencies, required investment, and the need to migrate long-lived hardware roots of trust. Organizations are also expected to communicate their needs to suppliers.3

By 2031, the NCSC identifies completion of the highest-priority migration activities needed to protect the most critical assets, readiness of infrastructure to support a PQC future, and refinement of the plan into a clear route to full migration by 2035. By 2035, it identifies completion of migration to PQC, while taking the opportunity to improve broader cyber resilience. The guidance says preparatory work enables a principled, staged migration once robust PQC implementations in products become available, limiting disruption, reducing insecurity risk, and ultimately reducing total cost.3

Governance should connect these milestones to accountable risk owners, investment planning, supplier management, architecture decisions, and evidence retention. The cited NCSC material notes that PQC is ecosystem-wide, can span multiple leadership cycles, and may have significant total financial cost, including both preparation and implementation. A credible program should therefore survive changes in leadership and procurement cycles, maintain a current inventory, and record why assets were prioritized or deferred.3

Hybrid cryptography: useful transition technique, not an automatic requirement

ETSI explains that combining traditional and post-quantum algorithms in a hybrid scheme or protocol may mitigate vulnerabilities in a PQC implementation or provide backward compatibility during migration. Hybrid designs may reduce bandwidth, computation, or latency overheads by pairing a PQC algorithm with a traditional elliptic-curve algorithm. However, the same passage warns that hybrids increase protocol, implementation, and key-management complexity and must be designed carefully.14

Hybrid security and hybrid interoperability are different objectives. Hybrid interoperability helps systems communicate across populations of traditional, PQC-aware, and PQC-only clients. Hybrid security seeks protection if one component algorithm or implementation is compromised. A design that supports one objective may not provide the other, and achieving both can be difficult. Requirements may also differ between confidentiality and authentication, depending on the protocol and use case.14

ETSI further warns that inappropriate hybrid schemes can be less secure than a non-hybrid PQC design. Algorithm negotiation must be protected against downgrade attacks. Key reuse across hybrid keys can complicate compromise and revocation: if a component key is shared across multiple hybrid keys, revoking one may affect others. For long-lived sensitive information or long-lived roots of trust, the organization must explicitly determine whether hybrid security, interoperability, or both are required and document the security properties that remain if a component fails.14

Why PQC guidance should not be replaced by assumptions about QKD

The cited NSA material characterizes quantum key distribution (QKD) as only a partial solution. QKD generates keying material for encryption but does not by itself address all security requirements. The material says QKD is hardware-based, requires dedicated fiber or free-space transmitters, cannot be implemented as software or a network service, and is not easily integrated into existing network equipment. It also identifies limited flexibility for upgrades and security patches, increased infrastructure costs, and additional insider-threat risks where trusted relays are required.56

The NSA material also rejects the assumption that QKD security is automatically guaranteed by the laws of physics. It describes the achieved security as dependent on hardware and engineering design, with validation made difficult by the extremely low tolerance for cryptographic error. This does not mean QKD is irrelevant to every specialized architecture; it means that the cited evidence does not support treating QKD as a general substitute for a broad, software-deployable PQC migration program.56

Evidence that should support assurance decisions

A critical-infrastructure organization evaluating a PQC capability should ask more than whether a product names a NIST algorithm. Relevant evidence includes the applicable standard and version, the intended security function—key establishment, digital signatures, or both—the parameter set, randomness generation, protection and destruction of sensitive values, key-management behavior, protocol negotiation, downgrade resistance, interoperability constraints, and the security of integration into the surrounding system. These questions follow from the explicit qualifications and implementation requirements in FIPS 203, FIPS 204, FIPS 205, and ETSI’s hybrid guidance.156

Procurement and supplier discussions should also address upgrade paths, dependencies on physical infrastructure, long-lived hardware roots of trust, and the supplier’s ability to support a staged migration. The NCSC specifically recommends communicating organizational needs to suppliers. For regulated operators, retained evidence should show how cryptographic assets were discovered, how data lifetime and criticality influenced prioritization, which dependencies remain, what compensating or transitional controls exist, and how the organization will reach its target state.3

Conclusion

For critical infrastructure, PQC requirements and guidance are best understood as a combination of risk management, standards adoption, lifecycle governance, and ecosystem coordination. The cited official material supports early discovery and prioritization, especially for long-lived sensitive data and critical roots of trust; use of final NIST standards where applicable; careful evaluation of hybrid designs; and sustained supplier and investment planning. The NCSC milestones—2028, 2031, and 2035—provide a practical planning horizon, while the standards’ qualifications make clear that secure implementation and system-level assurance remain the organization’s responsibility.31562