TL;DR
Physical systems often remain in service across long technology cycles. During that time, the cryptography built into a device may need to change even when the hardware itself is still operational.
This creates a particular challenge for post-quantum cryptography (PQC) migration. Cryptographic functions may be tied to firmware, hardware security components, device certificates, communication protocols, or vendor-controlled systems that cannot be changed as easily as conventional software.
For organizations operating long-lived equipment, PQC planning therefore needs to consider the remaining life of the system, its ability to receive cryptographic updates, and what happens when migration cannot be completed through a software update alone.
When Hardware and Cryptography Have Different Lifecycles
A device purchased today could still be operating as organizations transition away from quantum-vulnerable public-key cryptography.
NIST's PQC migration work explicitly covers the use of vulnerable public-key algorithms across hardware, software, and services. It also addresses areas such as device identity certificates and code signatures, where cryptography is part of how systems establish trust rather than simply how they encrypt network traffic.
For physical systems, these cryptographic functions can be difficult to change. They may depend on firmware, bootloaders, hardware security components, device certificates, or protocols selected when the equipment was designed.
The hardware may therefore remain perfectly functional while its cryptographic environment needs to change.
Why Long-Lived Devices Can Be Harder to Migrate
PQC migration becomes more complicated when cryptography is closely tied to physical equipment.
Some devices have limited processing or memory resources. Others cannot easily receive firmware updates. Cryptographic functionality may also depend on components or software controlled by equipment manufacturers and other suppliers.
Operational technology (OT) is a clear example. CISA notes that industrial control systems and other OT environments can depend directly or indirectly on public-key cryptography for encryption, digital signatures, identity, and access control. CISA recommends that OT owners, operators, and vendors account for the transition to quantum-resistant technologies as part of their security planning.
These constraints change the migration decision.
The difficulty and time required to modify the system will also affect how companies assess [password risk] and prioritize PQC migration.
The Long-Lived Device Problem Across Industries
Long hardware lifecycles appear across many sectors, but the operational consequences are different.
| Industry | Where the issue can appear | PQC consideration |
|---|---|---|
| Healthcare | Medical devices, imaging systems, connected clinical equipment | Equipment may depend on manufacturer-controlled firmware, certificates, or software components |
| Critical infrastructure | Industrial controllers, sensors, field devices, and OT gateways | Operational availability, hardware constraints, physical access, and OT/IT dependencies can affect migration |
| Financial Services | HSMs, payment infrastructure, ATMs, security appliances | PQC changes may affect specialized cryptographic hardware and interconnected payment or trust infrastructure |
| Government | Communications systems, identity infrastructure, specialized equipment | Long procurement and technology-refresh cycles can leave older systems operating during the PQC transition |
The critical-infrastructure case is particularly well documented. CISA has issued dedicated guidance on quantum risks to OT, while recent NCSC migration work identifies systems dependent on long-lived hardware as candidates that may require earlier planning because they take longer to migrate.
Financial infrastructure presents a different challenge. In Project Leap, the BIS Innovation Hub and participating central banks tested PQC in payment systems. The work required changes across multiple system components and identified interoperability and performance considerations rather than treating PQC as a simple algorithm replacement.
The specific constraints therefore depend on the system. The common issue is whether the equipment and its surrounding infrastructure can continue to adapt as cryptographic requirements change.
What Happens When the Device Cannot Simply Be Upgraded?
Some systems will support new cryptography through firmware, software, or configuration changes. Others may require changes elsewhere in the architecture or eventual hardware replacement.
The remaining operational life of the system becomes important here.
Equipment approaching retirement may be handled differently from infrastructure expected to operate for many more years. Systems that cannot be modified also require organizations to understand what cryptographic function is exposed and what surrounding controls are available.
NCSC's recent PQC migration work recommends prioritizing systems partly according to how long they will take to migrate, specifically citing dependencies on long-lived hardware. It also emphasizes engaging suppliers early because an organization's ability to migrate may depend on supplier readiness.
This makes vendor support part of the migration question. Organizations need to know whether suppliers intend to support PQC, whether existing equipment can be updated, and whether replacement will ultimately be required.
Digital Signatures Matter Too
Long-lived equipment also demonstrates why PQC migration cannot focus only on encrypted communications.
Devices can use public-key cryptography to authenticate software, verify code or firmware, establish device identity, and validate communications. NIST's PQC migration project specifically includes device identity certificates and code signatures within its work on quantum-resistant digital trust.
A device may therefore continue to perform its primary function while becoming increasingly difficult to maintain securely if its trust mechanisms cannot evolve.
Consider software updates. Replacing the encryption protecting a connection addresses one part of the problem. If the device cannot support the signature mechanism required to authenticate future firmware, another cryptographic dependency remains.
For long-lived systems, encryption, authentication, device identity, and software integrity all need to be considered when assessing whether the equipment can remain supportable through the PQC transition.
PQC Changes Future Hardware Requirements
The issue is not limited to legacy equipment.
Hardware being designed or purchased today may remain operational well into the PQC transition. Organizations can therefore use procurement and product design to reduce future migration constraints.
Requirements can address whether firmware and cryptographic libraries can be updated, whether trust stores and certificates can change, which cryptographic functions are fixed in hardware, and how long the supplier will provide security and cryptographic updates.
This is where crypto-agility becomes particularly relevant.
Instead of assuming that one migration to PQC will permanently solve the problem, systems can be designed so that cryptographic mechanisms can change as standards and security requirements evolve.
NIST's work on crypto-agility treats this capability across software, hardware, firmware, protocols, and infrastructure. Its PQC program also continues to develop additional algorithms alongside the standards already available today.
Incorporate the equipment life cycle into the PQC planning
PQC transfers are often discussed in terms of standard transfer times, but long-life equipment has another time dimension: how long the equipment itself is expected to last.
In addition to understanding which systems [quantum-vulnerability cryptography technology] is present, companies also need to know which systems are difficult to modify, how long they are expected to remain in use, and which updates must be relied upon by the device manufacturer or other suppliers.
Different systems may therefore require different handling methods. Some can be migrated through general software updates; others may require restructuring, early equipment replacement, or other control measures to keep existing equipment operating safely until the end of its lifecycle.
For equipment with a long expected service life, the ability to change cryptography can therefore become part of the lifecycle requirement itself.
Sources
National Institute of Standards and Technology (NIST), National Cybersecurity Center of Excellence. Migration to Post-Quantum Cryptography.
https://www.nccoe.nist.gov/applied-cryptography/migration-to-pqc
Cybersecurity and Infrastructure Security Agency (CISA). Post-Quantum Considerations for Operational Technology.
https://www.cisa.gov/resources-tools/resources/post-quantum-considerations-operational-technology
UK National Cyber Security Centre (NCSC). Post-Quantum Cryptography Migration Workshop Report. 2026.
https://www.ncsc.gov.uk/blogs/post-quantum-cryptography-pqc-migration-workshop-report
Bank for International Settlements (BIS) Innovation Hub. Project Leap Phase 2: Quantum-Proofing Payment Systems. 2025.
https://www.bis.org/publications/project-leap-phase-2-quantum-proofing-payment-systems
National Institute of Standards and Technology (NIST). Considerations for Achieving Crypto-Agility. 2025.
https://csrc.nist.gov/pubs/cswp/39/upd1/considerations-for-achieving-crypto-agility/final