Why do embedded systems make PQC migration harder?

Why embedded systems slow down PQC migration

embedded systems are often the hardest place to land a post-quantum transition because the crypto is not always a clean software module you can swap out. When algorithms are fixed in firmware, tied to silicon, or constrained by tight memory and update limits, the real problem becomes asset lifecycle planning, not just cryptography selection.

Where the migration pain comes from

In an embedded environment, cryptography may be embedded in ROM, compiled into appliance firmware, or dependent on a vendor stack that cannot be readily patched in the field. That means the usual migration playbook, update libraries, rotate keys, and reissue certificates, may not be enough if the device cannot accept new code, cannot handle larger PQC artifacts, or cannot survive the performance cost of stronger algorithms.

Long replacement cycles make this worse. Many embedded assets are deployed to do one job for years, sometimes across factories, buildings, vehicles, medical environments, or industrial control estates. If the device has no practical reflash path, PQC readiness depends on whether the asset can be retired, replaced, or isolated before the old cryptography becomes a liability. Post-Quantum Readiness for Identity and PKI is useful here because it frames PQC as an inventory and crypto-agility problem, not just an algorithm choice.

Size and timing constraints also matter. Some embedded devices have little spare RAM, limited CPU headroom, and narrow communication budgets, so larger keys, signatures, or handshake flows can create latency, failure, or interoperability issues. That is why migration often has to be sequenced around product refreshes, maintenance windows, and vendor support commitments rather than treated as a simple configuration change.

Why replacement is sometimes the only realistic control

For some devices, the only viable option is replacement because the cryptographic implementation is inseparable from the hardware lifecycle. If secure boot, signing verification, or protocol support is hard-coded, then the question is not how to patch the device, but whether the device can be transitioned out before the current cryptographic assumptions age out. Machine Identity, PKI and Certificate Lifecycle Guide is a strong companion when certificate or key handling is part of that lifecycle decision.

This is why embedded PQC work usually needs a portfolio view. Teams should separate devices that can be upgraded in place from devices that require vendor firmware, and from devices that must be replaced entirely. The technical answer changes depending on whether the cryptography is a library, a protocol implementation, a certificate workflow, or a hardware trust anchor.

That distinction also changes procurement. New embedded purchases should be evaluated for cryptographic agility, firmware update support, and vendor roadmaps for PQC-capable implementations. If those capabilities are missing, the organisation inherits a future replacement cost whether or not today’s device is still functioning correctly.

Practitioner Guidance

What to prioritise: Build a cryptographic inventory for embedded assets and classify each device by updateability, vendor support horizon, and dependency on fixed firmware or hardware trust. That tells you which systems can be patched, which need vendor intervention, and which should move to replacement planning.

What to verify: Confirm whether the device supports field firmware updates, algorithm replacement, certificate reissuance, and acceptable performance with larger PQC parameters. If any of those are missing, treat the migration as a hardware refresh problem rather than a crypto configuration task.

Decision rule: If the embedded system cannot accept a trustworthy software update path, assume cryptographic migration will be slower than the wider enterprise and compensate with earlier retirement, segmentation, or compensating controls.

Practitioner takeaway: The hardest embedded PQC cases are not blocked by mathematics, they are blocked by lifecycle reality, so the winning move is to map crypto changes to asset refresh timing before the old design becomes unpatchable.

Related resources from NHI Mgmt Group

• Why do AI systems make NHI risk harder to control?
• Why do agentic AI systems make NHI risk harder to manage?
• Why do AI systems make least privilege harder to enforce?
• Why do MCP systems make identity governance harder for NHI teams?