PQC for Defence

What PQC for defence means

PQC refers to cryptography based on mathematical problems that future large-scale, fault-tolerant quantum computers are not expected to solve efficiently. The principal mitigation identified in the cited guidance is migration to PQC. For defence organisations, the scope includes the cryptographic mechanisms used to create and validate digital signatures, establish keys, authenticate users and machines, protect communications, sign software and firmware, and secure data in applications and services. It also includes the infrastructure that delivers those functions: protocols, cryptographic libraries, hardware, PKI, devices, cloud services and enterprise software.132

The practical boundary is therefore wider than classified or mission systems alone. Web applications, databases, communications tools, cloud services and enterprise applications may all require changes to cryptographic implementations, protocols and libraries. Those changes can affect key sizes, algorithm performance, interfaces, code, testing and user experience. Defence teams should treat PQC as a portfolio of dependencies and operational changes rather than as a procurement of one replacement product.32

Why PQC matters to defence

Future quantum computers are expected to threaten the hard mathematical problems on which today’s asymmetric public-key cryptography relies. The risk is especially material where information must remain confidential for a long time, or where trust in signatures, identities, updates, commands and machine-to-machine communication is mission-critical. The cited NIST transition material says migration planning should prioritise quantum-resistant key-establishment schemes to address “harvest now, decrypt later” attacks, particularly in interactive protocols such as TLS and IKE.32

Defence risk is not limited to disclosure. In OT and industrial control environments, the integrity of sensor data and commands may be more important than confidentiality: faulty readings or unauthorised commands can contribute to control-system failure. Remote logins into ICS IT zones, wireless field devices, sensors and internet-connected industrial IoT can therefore become important migration paths. A system that encrypts data but cannot reliably authenticate a command, update or device may remain operationally exposed.1

Evidence base and scope limitations

This article draws on four cited primary-authority documents: the CISA, NSA and NIST Joint Quantum-Readiness Fact Sheet, published 17 August 2023 and marked final; NIST CSWP 39 Update 1, marked final, published 19 December 2025 and updated 29 June 2026; NIST IR 8547 IPD, an initial public draft published 12 November 2024; and the UK National Cyber Security Centre’s current guidance on migration timelines, published 20 March 2025. Their statuses and dates matter. In particular, the NIST IR 8547 material is an initial public draft, and the cited fact sheet notes that final implementation specifics for draft algorithms were incomplete.413

The evidence supports planning, prioritisation, architecture and assurance principles. It does not establish a defence-specific deadline, prescribe a particular vendor, or prove that any named product is PQC-ready. Organisations should apply applicable national, mission, regulatory and classification requirements separately and confirm current standards and implementation guidance before deployment.32

A practical defence migration workflow

A defensible sequence begins with a project management team that represents security, architecture, IT, OT, procurement, engineering, operations, risk and relevant mission owners. The team should define scope, decision rights, dependencies, funding, acceptance criteria and escalation paths. The joint agency guidance recommends creating a quantum-readiness roadmap while standards are still developing, rather than waiting for every downstream product implementation to be available.31

1. Establish governance and a roadmap covering IT, OT, custom-built systems, commercial products, cloud services and supply-chain dependencies.
2. Perform cryptographic discovery and create an inventory of algorithms, protocols, certificates, keys, libraries, devices, applications, data and owners.
3. Assess impact by mission consequence, exposure, confidentiality lifetime, integrity requirements, system criticality, replaceability and technical feasibility.
4. Prioritise high-impact systems, ICSs and information with long-term confidentiality or secrecy needs; include remote access and externally exposed datasets.
5. Engage suppliers and cloud providers to obtain roadmaps, upgrade paths, expected costs, supported configurations and testing responsibilities.
6. Design migration patterns that preserve interoperability and continuity, including staged PKI changes and, where justified, controlled hybrid approaches.
7. Test implementations and configurations in representative environments, verify that systems do not silently fall back to traditional cryptography, and conduct independent assurance.
8. Measure adoption, remediate exceptions, and define evidence-based conditions for reducing or retiring support for legacy algorithms.

The inventory is foundational. It should provide visibility into how cryptography is used across IT and OT, including network protocols, end-user systems, servers, applications and associated libraries. It should also identify the criticality of protected data and correlate outside access to datasets. This enables risk assessment, prioritisation and later measurement of migration progress.3

Architecture considerations for defence environments

Defence architectures commonly combine enterprise IT, mission applications, cloud services, remote access, OT zones and devices with different lifecycles. Existing enterprise controls remain relevant in ICS contexts, but OT adds constraints: physical infrastructure changes require planning, upgrades should align where possible with maintenance, and devices may be resource-constrained, difficult to service, embedded in larger products, non-upgradeable, proprietary or dependent on protocols that are not yet PQC-compatible.1

PKI migration deserves explicit design. An enterprise PKI may require a new PQC root of trust and new certificates for machines and, in some cases, users. A parallel PQC PKI can run beside the traditional PKI during a staged transition; in tightly controlled environments, a one-step move may be possible. More commonly, protocols such as TLS and IKE must support negotiation of the appropriate certificates while both environments operate. Some devices may require physical interaction, so certificate and trust-anchor planning must include field logistics.32

Crypto agility is the capability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations. It is an architectural and operational property: centralised cryptographic interfaces, explicit algorithm configuration, manageable certificate lifecycles, upgradeable components, tested rollback controls and documented dependencies can reduce the cost and disruption of future changes. Crypto agility does not remove the need for secure design, assurance or prioritisation.32

Interoperability, hybrid modes and transition risk

Backward compatibility and interoperability are crucial during transition. Applications and services may need refactoring, updated libraries, protocol changes, performance testing and interface changes. Defence teams should test interactions across enclaves, coalition or partner connections, legacy systems, remote access paths, cloud services and field devices rather than assuming that algorithm support means end-to-end protection.2

Hybrid key-establishment techniques and dual signatures may allow organisations to retain a legacy component while adding a PQC component. The cited NIST draft says existing standards and guidelines can accommodate such use when at least one component digital-signature algorithm is NIST-approved, while also leaving application owners to weigh cost, performance, engineering complexity and independent security review. Hybrid solutions can provide transition flexibility, but they add implementation and architectural complexity, which can increase security risk and cost. They are generally expected to be temporary where used, leading to a later transition to tools using only PQC algorithms.2

Suppliers, cloud and operational technology

Supplier engagement is a core control. For commercial off-the-shelf products, the roadmap should record when and how each vendor expects to deliver updates or upgrades, how PQC will be enabled, and the expected migration cost. For cloud-hosted products, organisations should ask providers about their quantum-readiness roadmap and later clarify configuration changes, application updates and supported protocols. Vendors are encouraged to plan and test integration, but the cited guidance cautions that draft algorithm implementation specifics were incomplete.3

Custom-built and older systems may require the most effort. Where quantum-vulnerable cryptography is found, the owner should identify the risk to dependent data or functions and either migrate the technology or develop security upgrades that mitigate continued use. For OT and industrial IoT, the plan should account for remote authentication, wireless connections, proprietary protocols, difficult servicing, embedded components, limited resources and network paths from internet-connected devices into control environments.3

Testing, assurance and useful measures

Migration testing must validate both availability and security. A system may continue operating while using an unintended legacy fallback, so teams should verify the cryptographic suites and certificates actually negotiated in production-like conditions. The NCSC evidence specifically recommends checking that standardised PQC cipher suites, when available for TLS, are being used rather than silently falling back to traditional cryptography. Assurance should cover implementation correctness, configuration, interoperability, performance, resilience, independent review and operational procedures.2

Useful measures should be derived from the inventory and tied to mission risk. Examples include the proportion of applications, clients, protocols, certificates, devices or high-impact systems using approved PQC; the number and criticality of unresolved quantum-vulnerable dependencies; the proportion of suppliers with documented roadmaps; the number of verified legacy fallbacks; and the age or status of approved exceptions. Metrics should support decisions about remediation and the point at which traditional-algorithm support can be reduced, rather than functioning as a purely numerical score.2

Recommended first actions for enterprise security teams

• Name an accountable programme owner and create a cross-functional IT/OT and procurement team.
• Freeze neither innovation nor operations: begin discovery and roadmap work while preserving safe, supported current controls.
• Identify long-lived secrets, high-impact missions, ICSs, remote access, signing and update mechanisms, PKI roots and externally reachable datasets.
• Require cryptographic dependencies and upgrade commitments in architecture reviews, procurement, supplier management and system refresh plans.
• Pilot inventory, PKI, protocol and application changes in representative environments before broad deployment.
• Record uncertainty explicitly: draft-standard dependencies, unsupported devices, untested protocols, vendor assumptions, performance limits and residual legacy exposure.
• Use maintenance windows and planned infrastructure replacement to address physical and difficult-to-upgrade components where possible.
• Review metrics regularly with mission owners and make risk-based decisions about exceptions, hybrid use and legacy retirement.

Conclusion

PQC for defence is a long-horizon resilience and modernisation programme. The most useful starting point is not selecting an algorithm in isolation, but establishing ownership, inventorying cryptographic dependencies, prioritising mission and long-secrecy risk, engaging suppliers, and designing systems that can change without losing security or continuity. IT, OT, PKI, applications, devices and cloud services require different migration treatments. Rigorous testing, explicit treatment of uncertainty, controlled use of hybrid techniques and measurable adoption are essential to demonstrate that systems are becoming quantum-ready in practice.3