Post-quantum cryptography, or PQC, uses new public-key algorithms designed to resist future quantum attacks while still running on conventional processors and microcontrollers.
The current problem for hardware teams is product lifetime. A connected device released today may stay in service for 10–15 years, long enough to outlive the RSA and elliptic-curve cryptography it currently depends on. The risk is that attackers can collect encrypted data now and decrypt it later once sufficiently capable quantum hardware exists.
For connected devices, PQC matters across:
- Secure boot and firmware signing.
- OTA updates.
- TLS and DTLS connections.
- Provisioning certificates.
- Device identity.
- Model and data protection.
NIST (National Institute of Standards and Technology) has already standardized the first major PQC algorithms:
| Algorithm | Purpose | Typical device use |
| ML-KEM | Key establishment | Secure cloud or gateway sessions. |
| ML-DSA | Digital signatures | Firmware, model updates, and device identity. |
| SLH-DSA | Hash-based signatures | Alternative digital-signature use cases. |
Default credentials, open debug ports and unpatched stacks remain the more common IoT device security risks, and PQC fixes none of them. What it protects is still wider than the cloud link: provisioning certificates, TLS or DTLS sessions, sensor streams, model updates, service channels and the firmware itself.
The main hardware challenge is size. PQC keys, signatures, and handshakes are much larger than the elliptic-curve values many embedded systems use today.
What PQC Changes Inside a Connected Device
PQC affects more than the encryption library. It can change the boot chain, memory budget, certificate handling, OTA architecture, secure storage, and even radio behavior.
On Linux-based edge devices, the transition may mainly involve choosing and integrating a compatible cryptographic library. Small microcontrollers are more difficult because they often have limited RAM, flash, bandwidth, and power.
The main engineering constraints are:
| Design area | What changes with PQC | What hardware teams should check |
| Flash and storage | Larger certificates, keys, signatures, and verification code increase storage needs. | Leave margin in bootloader, firmware, and certificate storage before the PCB is frozen. |
| RAM | Key establishment and signature operations need more working memory. | Measure peak RAM alongside RTOS tasks, sensor buffers, and AI workloads. |
| Bootloader | Secure boot may depend on a signature scheme fixed early in development. | Make sure the boot chain can support future signature schemes and updated trust anchors. |
| OTA updates | Larger signatures and certificates increase update metadata and image size. | Size update partitions with enough room for future firmware and cryptographic overhead. |
| Radio bandwidth | PQC handshakes can require much larger messages than current elliptic-curve schemes. | Test fragmentation, retransmission, and reconnect behavior on the real production link. |
| Power consumption | Longer handshakes and more radio traffic can increase energy use. | Measure energy per connection on battery-powered devices rather than relying on desktop benchmarks. |
| Key storage | Strong algorithms still fail if private keys can be extracted. | Protect keys in a secure element, HSM, or other trusted storage where appropriate. |
| Rollback protection | Devices must not fall back to vulnerable firmware or cryptographic configurations. | Tie secure boot and OTA logic to version control and authenticated rollback protection. |
A Simple Path to PQC-Ready Hardware
Current cryptography → identify dependencies → protect update paths → make crypto replaceable → migrate to PQC when required
The transition to post-quantum cryptography does not need to happen all at once. First, identify where the product relies on public-key cryptography today, such as secure boot, firmware signing, certificates, and TLS connections.
Then make sure firmware and, where relevant, AI model updates are authenticated so the device only accepts trusted changes. The next step is crypto agility: design the bootloader, trust anchors, and certificate handling so cryptographic methods can be updated later.
If enough RAM, flash, and update capacity are reserved from the start, moving to PQC can become a software migration instead of a hardware redesign.
Plan the PQC Migration Around Regulation Deadlines
Most teams do not need to replace every existing algorithm immediately. The practical goal is to make new products capable of moving to PQC without a board redesign.
A useful migration plan is:
- Build a crypto inventory. Map every place where keys, certificates, or signatures appear, including secure boot, OTA, TLS or DTLS, debug access, factory tools, apps, and backend systems.
- Prioritize long-lived data. Health records, biometric data, credentials, voice, video, and proprietary model weights deserve earlier attention because they may remain valuable for years.
- Design for crypto agility. Algorithms, trust anchors, and certificate formats should be replaceable through authenticated updates.
- Reserve hardware margin. Leave enough flash, RAM, and update-partition space for larger certificates, signatures, and handshake buffers.
- Use hybrid key exchange during transition. Where supported, combine a classical scheme such as ECDH with ML-KEM rather than moving directly to PQC-only communication.
- Test on production-like hardware. Measure handshake time, packet fragmentation, reconnect behavior, memory use, and energy consumption on the actual radio and firmware stack.
- Plan key and certificate rotation. Manufacturing, replacement devices, returns, and field updates all need a controlled way to update cryptographic identities.
| The timeline makes this relevant now:In the United States, NIST’s transition plan phases out quantum-vulnerable public-key cryptography through 2035, with some RSA and ECDSA uses deprecated after 2030 and federal high-risk systems moving earlier. The European Union’s coordinated roadmap calls for all Member States to begin transitioning to PQC by the end of 2026, with high-risk use cases and critical infrastructure moving no later than the end of 2030. |
For products expected to remain in service into the 2030s, those dates fall inside a normal product lifetime. The objective is to make sure the device can adopt them later through firmware and infrastructure updates rather than a hardware respin.
AJProTech helps connected-device and edge-AI teams review secure boot, key storage, OTA architecture, memory requirements, radio constraints, and crypto agility before production decisions are locked.
FAQ
Do devices shipping today need PQC?
Usually not as the only cryptography they use. But long-life connected products should have an updateable cryptographic architecture, certificate rotation, and enough hardware margin to support PQC later.
EU Cyber Resilience Act adds a compliance reason: its security-by-design and update obligations make crypto agility a cybersecurity requirement that a market surveillance authority can ask about.
Can a microcontroller run ML-KEM?
Yes, many 32-bit microcontrollers can. The practical limits are usually RAM, flash, energy per handshake, and radio packet size rather than whether the algorithm can execute at all.
Is AES-256 vulnerable to quantum computers?
AES-256 is much less affected than RSA or elliptic-curve cryptography. The main PQC migration effort focuses on public-key operations such as key exchange, signatures, and certificates.
What is hybrid key exchange?
Hybrid key exchange combines a classical scheme such as ECDH with a post-quantum scheme such as ML-KEM. The resulting session key depends on both, reducing migration risk while PQC support is still developing.
When should my team start planning for PQC?
During architecture planning for any connected product expected to remain in service into the 2030s. The earlier crypto agility, secure storage, and memory headroom are designed in, the easier migration becomes later.
AJProTech helps connected-device and edge-AI teams build PQC-ready security architecture before production decisions are locked. Talk to our team about your product architecture before the next hardware revision.