PQC for Aerospace

What PQC for aerospace means

PQC is cryptography based on mathematical problems that future large-scale, fault-tolerant quantum computers are not expected to solve efficiently. The motivation is that such computers would efficiently solve the hard mathematical problems on which today’s asymmetric public-key cryptography relies. Migration to PQC is identified as the primary mitigation for that risk.1

For aerospace, “PQC” should be understood as a systems and supply-chain transition. The relevant technology surface includes network protocols and security technologies, software cryptographic libraries, cryptographic hardware, PKI and other infrastructure components, and IT applications and services. Applications may need changes for encryption, digital signatures, and key exchange, including adjustments for key sizes, algorithm performance, protocols, libraries, code, testing, and user interfaces.2

The scope extends beyond conventional enterprise IT. Aerospace environments may contain operational technology, remote-access channels, fielded devices, sensors, embedded components, proprietary protocols, cloud-connected systems, and equipment that is difficult or impossible to update. Integrity can be more important than confidentiality for some sensor and control faulty readings or commands can contribute to control-system failures.1

Why aerospace organizations should prepare now

Aerospace assets and information often have long operational, support, or confidentiality horizons. The joint CISA, NSA, and NIST guidance recommends proactive preparation and a deliberate quantum-readiness roadmap while standards and implementations continue to develop. It specifically calls for discovery of current reliance on quantum-vulnerable cryptography and prioritization based on the risk to data or functions.31

The “harvest now, decrypt later” concern makes timing relevant even before a cryptographically relevant quantum computer exists: information intercepted today may be retained for later decryption. NIST’s initial public draft says application-specific updates are expected to prioritize quantum-resistant key-establishment schemes, particularly in interactive protocols such as TLS and IKE, while recognizing that different applications have different risks, security needs, and adoption challenges.2

Aerospace organizations should therefore assess both present exposure and future migration difficulty. A system with long-lived secrets, important signing keys, remote access, high operational impact, or limited upgradeability may merit earlier action than a system with short-lived data and a straightforward replacement path. This is a prioritization principle, not a claim that every aerospace component must migrate simultaneously.3

A practical aerospace migration workflow

A useful workflow begins with governance. Establish a cross-functional project team with authority spanning information technology, operational technology, engineering, product or mission owners, procurement, supplier management, safety and assurance, and security operations. The team should define scope, decision rights, dependencies, acceptance criteria, exception handling, and a roadmap for systems and suppliers. The joint guidance identifies a project management team as the starting point for planning and scoping migration.3

1. Discover cryptography across aircraft or spacecraft systems, ground systems, enterprise IT, OT, software, firmware, protocols, hardware, PKI, applications, libraries, cloud services, and supplier products.
2. Record the asset, algorithm or mechanism, use case, data or function protected, key and certificate relationships, owner, lifecycle, upgrade path, connectivity, supplier, and operational criticality.
3. Assess the consequence of compromise or loss of confidentiality, integrity, authentication, or availability, giving attention to high-impact systems, ICS, and long-term confidentiality needs.
4. Select a transition pattern for each system: direct migration where feasible, staged coexistence where necessary, or a documented compensating upgrade when immediate migration is not practical.
5. Implement and validate changes in representative environments before operational deployment, including interoperability, performance, certificate handling, signing, update, recovery, and fallback tests.
6. Track adoption, exceptions, supplier commitments, unresolved dependencies, and readiness to retire traditional algorithms.

The inventory is the foundation of this workflow. The joint guidance says it should provide visibility into how cryptography is used in IT and OT systems and should identify quantum-vulnerable algorithms in network protocols, end-user systems and servers, applications, and associated libraries. It also connects inventory to data criticality, outside access, zero-trust planning, and analysis of information that could be targeted now and decrypted later.3

For aerospace, discovery should follow trust relationships rather than organizational boundaries. For example, a signed software or firmware update may depend on a signing system, certificate authority, validation library, boot or update process, supplier workflow, and fielded device. A remote maintenance channel may depend on identity systems, certificates, TLS or IKE negotiation, gateways, network segmentation, and devices with different update capabilities. Mapping these chains prevents a narrow application-by-application view from missing a critical dependency.23

Aerospace systems and functions to prioritize

Prioritization should be based on impact, exposure, data lifetime, and migration difficulty. The joint guidance explicitly gives priority to high-impact systems, industrial control systems, and systems with long-term confidentiality or secrecy needs. For custom-built technologies, especially older systems, migration may require the greatest effort; organizations should identify the risk to dependent data or functions and either migrate or develop security upgrades that mitigate continued use.3

Digital signatures deserve particular attention because they support software and firmware updates as well as certificates and other trust mechanisms. A compromised or quantum-vulnerable signing path can affect the ability to establish what software, firmware, or identity material should be trusted. Key establishment also warrants early analysis where communications have confidentiality requirements over long periods.32

OT and embedded equipment require a different operational lens. Devices may be resource-constrained, non-upgradeable, difficult to service, embedded in larger products, designed without replacement in mind, or dependent on proprietary or not-yet-compatible protocols. Internet-connected industrial devices can also provide an entry point into control networks and onward into enterprise IT through a demilitarized-zone boundary.1

Aerospace PKI migration should be treated as a trust-infrastructure program. A large enterprise PKI migration may require a new PQC root of trust and new certificates for network entities. Possible models include a parallel PQC PKI, a controlled one-step transition, or—more commonly—a staged period in which traditional and PQC PKIs operate together through protocols that can negotiate the certificates to use. Some devices may require physical interaction.1

Interoperability, hybrid operation, and crypto agility

Backward compatibility and interoperability are essential during transition. Applications and services may need refactoring and extensive testing, while protocols and libraries must accommodate changed key sizes and performance. A migration that changes cryptography without verifying interoperability can disrupt communications or leave systems using an unintended legacy path.2

Hybrid key-establishment techniques or dual signatures may be considered where applications need a transition mechanism. NIST’s initial public draft notes that hybrid solutions can help accommodate PQC while legacy algorithms remain required, but they increase implementation and architectural complexity, which can increase security risks and costs. They are typically expected to be temporary and followed by a transition to tools using only PQC algorithms.2

Crypto agility provides the broader engineering objective: the capability to replace and adapt algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. For aerospace, this means making cryptographic choices discoverable, configurable under controlled governance, testable, and replaceable without redesigning an entire platform or mission system.4

Standards maturity and supplier management

Aerospace migration depends on products, services, protocols, and suppliers. Organizations should ask commercial off-the-shelf and custom-product vendors how they are addressing quantum readiness, when updates or upgrades will support PQC, how those changes will be enabled, and what migration costs are expected. For cloud-hosted products, the same discussion should occur with cloud service providers. The roadmap should capture vendor timing and dependencies rather than assume that a product will become ready automatically.3

The cited NIST transition material is an initial public draft dated November 2024, and the joint fact sheet says final implementation specifics for the algorithms discussed in draft standards were incomplete at the time of its guidance. The NCSC material likewise describes standards as a building block for protocols, products, and services and says further guidance on patterns and configurations will evolve as technical standards mature. Procurement and architecture decisions should preserve room for such updates.231

Supplier contracts and assurance activities should address supported algorithms and protocol configurations, update and certificate lifecycles, signing and validation, vulnerability response, interoperability testing, fallback behavior, end-of-support dates, and evidence of implementation. These are implementation and governance considerations derived from the cited migration guidance; they should be adapted to the organization’s contractual, safety, regulatory, and mission context. [claim-15321

Testing, assurance, and useful measures

Testing must confirm behavior, not only configuration intent. The NCSC advises checking that standardized PQC cipher suites are actually being used and that systems are not falling back to traditional cryptography. It also calls for a rigorous assurance process to determine whether migration and the broader cybersecurity uplift meet core goals.1

• Inventory coverage: proportion of in-scope systems, devices, applications, protocols, certificates, libraries, and suppliers with an identified cryptographic use.
• Risk coverage: proportion of high-impact, OT, long-term-confidentiality, signing, and remote-access dependencies assessed and assigned a migration priority.
• Adoption: number or percentage of software clients and systems using intended PQC mechanisms, with explicit identification of those that are not.
• Interoperability: tested combinations across aircraft or spacecraft components, ground systems, gateways, suppliers, cloud services, and legacy peers.
• Fallback and exception status: observed traditional-cryptography fallback, approved exceptions, compensating controls, owners, expiry dates, and remediation plans.
• Lifecycle readiness: systems with tested update, certificate, key, recovery, rollback, and eventual traditional-algorithm retirement procedures.

Metrics should support decisions rather than create a misleading percentage. A high adoption rate can conceal an unassessed signing authority, an unupgradeable field device, or a supplier dependency that controls a critical trust path. Report counts and percentages alongside impact, residual risk, evidence quality, and planned remediation. The cited guidance specifically identifies the value of quantifying clients using PQC and identifying those that are not so that remedial action and retirement timing can be judged.1

Practical next steps for an aerospace security team

In the first planning cycle, establish the accountable team and agree the mission, enterprise, platform, ground, OT, supplier, and cloud boundaries. Start cryptographic discovery before attempting broad replacement. Use the results to identify long-lived confidentiality, high-impact functions, signing and update chains, remote access, PKI, and devices that cannot be readily upgraded. claim-073

Next, build a dependency-aware roadmap. Pair cryptographic changes with scheduled infrastructure maintenance and broader IT/OT modernization where possible; the NCSC notes that physical-infrastructure changes need significant planning and should, where possible, coincide with maintenance and improvements. For each system, document the target state, interim state, test evidence, supplier dependency, operational constraints, and decision date.3

Finally, run controlled pilots and assurance exercises across representative trust paths, including certificates, signing, remote access, network protocols, applications, embedded devices, and supplier interfaces. Capture fallback findings and performance or interoperability constraints, update the inventory, and use measured evidence to sequence wider deployment. Do not declare readiness solely because a product advertises PQC support; verify the implemented configuration and operational behavior.1

Conclusion

PQC for aerospace is a long-horizon resilience and modernization effort spanning mission systems, aircraft or spacecraft components, ground infrastructure, enterprise IT, OT, PKI, software and firmware trust, protocols, suppliers, and cloud services. The strongest starting point is a cross-functional cryptographic inventory tied to impact, data lifetime, exposure, upgradeability, and trust dependencies. Organizations should prepare before every implementation detail is settled, preserve interoperability and crypto agility, treat hybrid mechanisms as controlled transitional options, test actual protocol behavior, and measure progress with evidence. claim-04314