Crypto Agility for Long-Lifecycle Devices: How to Prepare Embedded Products for the PQC Transition

An embedded device shipped today may still be running in 2035. Its firmware will have been updated several times, but its hardware security architecture was fixed at tape-out. If that architecture relies on RSA-2048 or ECC for key exchange and firmware signing, the cryptographic assumptions baked into it are almost certainly not going to hold for the full intended service life. This is not a distant theoretical concern. NIST finalized the first three post-quantum cryptography standards in August 2024. The NSA's Commercial National Security Algorithm Suite 2.0 sets a 2030 deadline for transitioning software and firmware signing to quantum-resistant algorithms. And adversaries are already collecting encrypted traffic today to decrypt once capable quantum hardware becomes available — a strategy broadly described as harvest-now, decrypt-later.

For product engineers working on industrial IoT devices, automotive ECUs, medical equipment, or energy grid controllers, the PQC transition is an architectural decision that needs to enter product design now. The core capability required is crypto agility: the ability to change cryptographic algorithms, key lengths, and protocols across a device fleet without requiring hardware replacement.

Why Long-Lifecycle Devices Are Especially Exposed

Most networked infrastructure products are designed with 10- to 20-year operational lifespans. Industrial PLCs, substation controllers, automotive gateway ECUs, and building management systems are not replaced on the cadence of consumer electronics. The cryptographic primitives embedded in their secure boot chains, TLS stacks, and firmware signing pipelines were designed for a classical computing threat model that assumed factoring large integers or solving the elliptic curve discrete logarithm problem would remain computationally infeasible.

Shor's algorithm, running on a sufficiently large quantum computer, breaks both RSA and ECC in polynomial time. The open question is not whether this is possible but when it becomes practical at scale. Estimates vary, but ranges commonly cited by national security agencies and standards bodies put cryptographically relevant quantum computers between five and fifteen years away. A device deployed in 2025 with a 12-year lifecycle sits squarely in the risk window.

The harvest-now, decrypt-later attack pattern makes the timeline more urgent than it first appears. An adversary who captures TLS-encrypted firmware update traffic, OTA commands, or key provisioning exchanges today does not need to decrypt them immediately. If the data retains value in 2031 or 2033, the adversary simply waits for capable hardware. For devices handling sensitive configuration, authentication credentials, or safety-critical command channels, this is a concrete risk that cannot be deferred to a future hardware generation.

What the NIST PQC Standards Actually Specify

In August 2024, NIST published three finalized PQC standards under FIPS 203, FIPS 204, and FIPS 205. These are the first formally approved quantum-resistant algorithms intended for broad deployment across civilian infrastructure, including embedded systems.

The table below summarizes what each standard provides and its primary use case in an embedded context:

ML-KEM is designed as a near-drop-in replacement for ECDH in TLS handshakes. ML-DSA replaces RSA and ECDSA for signature operations and is the most versatile choice for general embedded security tasks. SLH-DSA uses conservative hash-based mathematics with well-understood security assumptions, making it well suited for use cases where the signed data must remain verifiably authentic for decades — root certificates, safety-critical configuration records, and long-term audit logs.

In March 2025, NIST selected HQC as an additional code-based KEM to standardize alongside ML-KEM, adding further redundancy to the PQC algorithm landscape. Product teams planning multi-year platform roadmaps should track the HQC draft standardization process as a potential complement to ML-KEM deployments.

The performance tradeoff is real and relevant for constrained hardware. PQC algorithms carry larger key and signature sizes than their classical equivalents. An ML-KEM-768 public key is 1184 bytes, compared to 64 bytes for an ECC P-256 key. An ML-DSA-65 signature is approximately 3309 bytes, versus roughly 64 bytes for an ECDSA signature. On a 32-bit Cortex-M4 with 256 kB of RAM, the computational overhead of ML-KEM or ML-DSA is manageable, but it is not free. On a Cortex-M0+ with 32 kB of RAM, PQC signature verification during secure boot becomes a significant budget item that must be accounted for at architecture stage.

What Crypto Agility Means in Practice for Embedded Firmware

Crypto agility is defined by NIST's Cybersecurity White Paper CSWP 39 as "the capabilities needed to replace and adapt cryptographic algorithms, parameters, processes, and technologies without introducing unacceptable security risks and without disrupting normal operation." For an embedded product team, this translates to a concrete set of firmware and hardware design decisions.

The key architectural elements of a crypto-agile embedded system are:

• A modular cryptographic abstraction layer that isolates algorithm-specific code from the application. The application calls a generic interface (sign, verify, encrypt, decrypt, key_exchange) without direct dependency on RSA, ECC, or any PQC algorithm. Swapping the underlying algorithm means updating the module behind the interface, not refactoring application code.
• An updateable firmware path that can deliver new cryptographic libraries to deployed devices. Immutable mask-ROM secure boot logic that cannot be patched without hardware replacement is the primary architectural anti-pattern for crypto agility. The secure boot chain should include a field-updateable stage that allows the signature verification algorithm to be replaced via a signed OTA process.
• Hardware-isolated key storage in a secure element or HSM that is physically separable from the main application processor. If the secure element can be replaced or its firmware updated independently, the cryptographic root of trust can be migrated to PQC without redesigning the main board.
• A cryptographic inventory — a documented map of every algorithm, key, certificate, and cryptographic dependency in the device software stack. This is the prerequisite for any migration. Without it, PQC remediation becomes a reverse-engineering exercise rather than a planned upgrade.

The last point is consistently underestimated in product development programs. Many embedded platforms accumulate cryptographic dependencies across the bootloader, RTOS networking stack, device management agent, cloud connectivity library, and application code, each potentially using different libraries with different algorithm configurations. NIST's CSWP 39 explicitly identifies cryptographic inventory as the first step in any crypto agility program. OEM supplier requirements in both automotive and medical sectors are increasingly mandating cryptographic bills of materials as a delivery artifact.

Hybrid Cryptography as a Migration Bridge

The practical migration path for most long-lifecycle embedded products is not a hard cutover from classical to PQC algorithms. It is a hybrid approach that combines classical and post-quantum algorithms in parallel, so that the system remains secure against classical attackers while also providing protection against future quantum attacks.

In a hybrid TLS handshake, for example, the session key is derived from both an ECDH exchange and an ML-KEM exchange. An attacker who breaks one of the two mechanisms still cannot recover the session key without breaking both. This approach preserves backward compatibility with infrastructure that does not yet support PQC while adding quantum resistance for traffic that is at risk of harvest-now, decrypt-later interception.

Several protocol-level specifications for hybrid PQC are already published or in progress. IETF has active work on hybrid key exchange for TLS 1.3, SSH, and IKEv2. The Google Chrome browser shipped ML-KEM support as part of hybrid TLS in late 2024. For embedded devices communicating over TLS — OTA update channels, cloud telemetry, management interfaces — the hybrid approach is the most practical near-term migration step and does not require hardware changes if the device has sufficient compute and memory headroom.

For firmware signing, the transition is more constrained. A secure boot chain that relies on hardware-verified signature validation using an asymmetric algorithm baked into ROM cannot be migrated in the field if the ROM is immutable. This is the hardest case in long-lifecycle PQC migration, and the one that requires the most foresight at initial product design. The emerging approach is to combine a dedicated security controller or secure element — external to the main SoC — that handles signature verification and can be firmware-updated independently. When the main SoC's ROM supports only ECC or RSA, the external security controller can take over the PQC signature chain, with the ROM-level check validating only that the security controller itself has not been tampered with.

Industry-Specific Migration Patterns

The migration path varies by sector, and the constraints are different enough that sector-specific patterns have emerged.

In automotive, the long development cycle and strict functional safety requirements mean that PQC migration is effectively a platform-level decision rather than a firmware patch. OTA-capable ECUs in modern vehicles can receive cryptographic updates over the vehicle's backend infrastructure, but any change to the security architecture must pass through change impact analysis under ISO 26262 and ISO/SAE 21434. The practical implication is that PQC readiness needs to be designed into the next-generation platform now, even if deployment is three to four years away. Vehicles currently in production with fixed hardware security architectures will likely reach the end of their service life before quantum computing becomes a direct threat to their key lengths, but vehicles being designed for 2027–2030 production start have a different calculation.

In industrial IoT and operational technology, the dominant challenge is the installed base. Brownfield deployments of PLCs, remote terminal units, and field devices often run on hardware from 2010 to 2015 with no OTA mechanism and no secure element. For these devices, the migration strategy is typically gateway termination: a field gateway or aggregation point handles PQC key exchange with the backend infrastructure, while the legacy device communicates over a legacy-encrypted local link to the gateway. This does not fully solve the problem — the local link remains classically encrypted — but it removes the device's cryptographic exposure from internet-reachable threat surfaces.

Medical devices face a distinct regulatory dimension. The FDA's updated cybersecurity guidance, effective for new device submissions since 2023, requires manufacturers to demonstrate a plan for post-market cryptographic updates. The PQC4MED project, funded by the German Federal Ministry of Education and Research, has specifically examined how crypto agility can be embedded into regulated medical device architectures through updatable secure elements and modular firmware structures, given that device recertification after a cryptographic change is a real regulatory cost.

Engineering teams building hardware-software products from concept to mass production — including those working across industrial, automotive, and medical domains — are increasingly asked by customers to assess PQC readiness as part of platform feasibility studies. The question is no longer whether to plan for PQC but how early in the design process to lock in the architectural decisions that make migration feasible.

Where Product Teams Most Commonly Get This Wrong

Several failure patterns repeat across embedded product development programs that have underinvested in crypto agility:

• Hardcoded algorithm identifiers in protocol implementations, making it impossible to negotiate a different cipher suite without refactoring the communication stack.
• Secure boot chains that verify firmware signatures using a key burned into OTP fuses, with no provision for rotating or replacing the verification algorithm.
• No documented cryptographic inventory at the time of first submission to regulatory authorities, forcing a rebuild of the security analysis when PQC requirements appear in supplier audits.
• Memory and compute budgets that leave no headroom for PQC algorithm overhead, because the original architecture assumed ECC key sizes and signature verification times.
• Assuming that symmetric keys are safe and ignoring that key exchange, which is typically asymmetric, is the primary exposure vector for harvest-now, decrypt-later attacks.

The most actionable mitigation for teams currently in design is to add crypto agility to the threat model and architecture review as a first-class requirement, alongside functional safety and classical cybersecurity requirements. The cost of building in the abstraction layer, updateable secure boot stage, and cryptographic inventory at design time is a fraction of the cost of retrofitting these capabilities after the platform is in production.

Quick Overview

Crypto agility is the design capability that allows embedded products to replace cryptographic algorithms and key material without hardware redesign. For long-lifecycle embedded devices, it is the core architectural requirement for surviving the transition to post-quantum cryptography — a transition now anchored by finalized NIST standards and regulatory timelines.

Key Applications

Industrial IoT devices and operational technology controllers, automotive ECUs with OTA update capability, medical devices subject to FDA cybersecurity guidance, energy grid equipment with decade-long field deployments, gateway and connectivity modules managing cryptographic sessions between legacy fieldbus devices and cloud backends.

Benefits

Devices with modular cryptographic abstraction layers can migrate to ML-KEM, ML-DSA, or future NIST PQC algorithms via firmware update rather than hardware replacement. Hybrid classical-plus-PQC key exchange provides immediate harvest-now, decrypt-later protection while maintaining backward compatibility. Cryptographic inventories produced during development reduce remediation cost when algorithm requirements change in supplier audits or regulatory submissions.

Challenges

PQC algorithms carry significantly larger key and signature sizes than ECC equivalents, requiring memory and compute headroom that constrained MCUs may not have. Immutable ROM-based secure boot chains cannot be migrated in the field without external secure element workarounds. Cryptographic inventory creation in legacy platforms requires reverse-engineering work that many product teams have not budgeted. Regulatory change impact analysis for cryptographic updates adds cost and cycle time in automotive and medical domains.

Outlook

NIST FIPS 203/204/205 are in force as of August 2024. NSA CNSA 2.0 timelines call for exclusive use of PQC in firmware and software signing by 2030, and for traditional network equipment by 2030 as well. HQC standardization will add a code-based KEM option alongside ML-KEM. The industry expectation is that hybrid PQC deployment in TLS and OTA infrastructure will become standard practice for new embedded platform designs by 2026 to 2027, with full PQC transition in critical infrastructure extending into the early 2030s.

Related Terms

ML-KEM, ML-DSA, SLH-DSA, CRYSTALS-Kyber, CRYSTALS-Dilithium, SPHINCS+, FIPS 203, FIPS 204, FIPS 205, NIST PQC, harvest-now decrypt-later, secure boot, HSM, secure element, OTA firmware update, TLS 1.3, hybrid cryptography, CNSA 2.0, cryptographic inventory, IETF PQC, HQC, lattice-based cryptography