Post-Quantum Cryptography in Embedded Systems: Securing IoT for 2026

Language Wrappers Make PQC Accessible

Cryptographic libraries reach more developers when they speak more languages. The Open Quantum Safe project ships language wrappers for liboqs so that Python, Go, Rust, Java, C++, and Node.js teams can adopt quantum-resistant primitives without touching the underlying C interface. That matters most for ARMv7 and ARMv8 devices, where the application layer is often written far above the cryptographic core.

Wrappers also unlock ecosystems. A Python wrapper plugs PQC into TensorFlow Federated experiments, a Go wrapper drops into Kubernetes operators, and a Rust wrapper lets teams ship memory-safe firmware updates on Cortex-M and Cortex-A boards.

Use Cases

• IoT applications: secure telemetry, device identity, and OTA updates with PQC-protected channels.
• Mobile apps: integrate quantum-resistant key exchange and signatures into ARM-based handsets and tablets.
• Web services: terminate PQC-enabled TLS at the edge of edge-computing deployments.
• Community contributions: language wrappers attract bug fixes and improvements from polyglot developer communities.
• Easier adoption: developers already fluent in a language adopt PQC faster, lowering the migration barrier.

liboqs: The C Library at the Core

At the center of OQS is liboqs — a permissively licensed C library implementing the leading quantum-safe key encapsulation mechanisms (KEMs) and digital signature schemes. liboqs is the reference implementation that downstream language wrappers depend on and that production teams audit before deployment.

liboqs builds and runs across Windows, macOS, and Linux on x86-64, ARMv7, and ARMv8. That matrix matches almost every embedded platform a modern product team is likely to encounter.

Bringing PQC to Resource-Constrained Devices

Most PQC research has focused on x86 and ARM Cortex-A class hardware. The next frontier is the much larger universe of microcontrollers, sensor nodes, and edge devices — the long tail of connected products.

What Counts as a Resource-Constrained Device?

Resource-constrained devices run on tight compute, memory, and energy budgets. They include:

• Microcontrollers powering sensors, remote controls, and simple appliances.
• Internet of Things devices such as smart-home controllers, wearables, and environmental sensors.
• Embedded systems inside medical devices, industrial machinery, and automotive electronics.
• Wearable devices like smartwatches and fitness trackers where size limits battery and compute.
• Sensor nodes in distributed monitoring networks that must run for months on a single charge.
• Low-power radios such as LoRa, Zigbee, and Bluetooth Low Energy modules.
• Edge computing devices that process telemetry locally to reduce backhaul cost and latency.

PQC on ARMv7 and ARMv8

ARM Cortex-M4 was selected as one of NIST's reference platforms for the PQC competition, which kicked off a generation of optimization work — most notably the PQM4 project. PQM4 ships hand-tuned ARMv7 implementations of the leading PQC candidates so that microcontrollers can run them without busting power or memory budgets.

ARMv8 — AArch64 — powers smartphones, tablets, edge servers, and increasingly autonomous-vehicle platforms. The NEON SIMD engine lets developers parallelize lattice operations, which is essential for the polynomial multiplications at the heart of Dilithium and Kyber. Algorithms like SABER, Kyber, and Newhope have all been optimized to run efficiently on the ARMv8 ISA.

Together, ARMv7 and ARMv8 are the bridge that makes quantum-resistant cryptography practical for IoT and consumer electronics.

What This Means for Product Teams in 2026

If you ship hardware into hospitals, utilities, or automotive supply chains, expect customers and regulators in the U.S., U.K., and EU to ask about PQC readiness during procurement. The CNSA 2.0 timeline from the U.S. National Security Agency, the EU's NIS2 Directive, and ENISA's PQC guidance all push for migration to start now — even if full deployment takes years.

At Agnotic Technologies we help embedded and IoT teams build a cryptographic inventory, pilot hybrid (classical + PQC) deployments, and ship PQC-enabled firmware updates without disrupting their delivery cadence.

Inside the Four NIST-Selected Algorithms

NIST published FIPS 203 (ML-KEM, based on CRYSTALS-KYBER), FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, based on SPHINCS+) in 2024. FIPS 206 for FALCON is on the way. Each algorithm has a specific role in the cryptographic stack.

ML-KEM (Kyber)

A lattice-based Key Encapsulation Mechanism with three parameter sets (ML-KEM-512, 768, 1024) corresponding to AES-128, 192, and 256 security levels. Public keys are 800-1,568 bytes and ciphertexts are 768-1,568 bytes — manageable for TLS handshakes and OTA updates on Cortex-M class hardware.

ML-DSA (Dilithium)

The default digital signature algorithm. Three parameter sets (ML-DSA-44, 65, 87) match the three security levels. Signatures range from 2,420 to 4,627 bytes — larger than ECDSA, which can stress constrained flash and over-the-air budgets but remains practical for most embedded use cases.

FALCON

Lattice-based signatures with the smallest signatures among the NIST winners (roughly 666-1,280 bytes). FALCON shines when signature size dominates the budget — for example, code signing for firmware images on flash-constrained devices. The trade-off is more complex floating-point operations during signing.

SLH-DSA (SPHINCS+)

A stateless hash-based signature scheme that provides a security backstop in case lattice-based assumptions are weakened in the future. Signatures are large (8-50 KB) but verification is cheap and the security relies only on the underlying hash function. Use SLH-DSA where signing is rare, signatures are stored elsewhere, and assurance matters more than space.

Hybrid Cryptography: The Default Migration Pattern

Pure PQC deployments rarely make sense before standards and implementations are battle-tested. The pragmatic alternative is hybrid cryptography — combining a classical primitive (X25519, P-256) with a PQC primitive (ML-KEM, Dilithium) so that an attacker has to break both to compromise the channel.

• Hybrid key exchange: TLS 1.3 supports hybrid named groups (e.g., X25519MLKEM768) that combine classical ECDH with ML-KEM. Major browsers and CDNs have already shipped support.
• Hybrid signatures: combine ECDSA or Ed25519 with ML-DSA so existing PKI infrastructure continues to work while adding quantum resistance.
• Hybrid certificates: dual-signature X.509 extensions allow a single certificate to carry both classical and PQC signatures.
• Hybrid key establishment in firmware updates: bootloaders can verify both classical and PQC signatures before flashing a new image.

Hybrid cryptography is what U.S. CNSA 2.0 explicitly recommends through 2030 and what the U.K. NCSC has endorsed for its phased migration timeline. Treat hybrid as the path, pure PQC as the destination.

Memory and Energy Benchmarks on Cortex-M4

Performance is the question every embedded engineer asks. Public benchmarks from the PQM4 project and academic literature suggest the following ranges on a Cortex-M4 running at 168 MHz with hand-tuned assembly:

• ML-KEM-768 key generation: ~700-900 thousand cycles (~4-5 ms).
• ML-KEM-768 encapsulation: ~900 thousand-1.1 million cycles (~5-7 ms).
• ML-KEM-768 decapsulation: ~900 thousand-1.1 million cycles (~5-7 ms).
• ML-DSA-65 signing: ~3-7 million cycles (~20-45 ms) due to rejection sampling.
• ML-DSA-65 verification: ~1-2 million cycles (~6-12 ms).
• RAM usage: 5-10 KB for ML-KEM, 10-25 KB for ML-DSA.
• Flash footprint: 10-25 KB depending on optimization flags and selected parameter sets.

On Cortex-M0+ and Cortex-M3, expect 3-5x slower performance and consider whether the workload can offload key establishment to a co-processor or secure element. Several silicon vendors now offer PQC-ready secure elements that handle ML-KEM and ML-DSA in hardware.

A 5-Phase Migration Playbook

Migrating embedded products to PQC is a multi-year programme. The phases below mirror what we recommend to clients shipping medical devices, industrial controllers, automotive ECUs, and IoT consumer hardware.

Phase 1 — Cryptographic Inventory

Catalogue every cryptographic dependency: TLS endpoints, code-signing pipelines, secure boot chains, license servers, OTA update systems, identity certificates, MQTT/CoAP brokers, and key-management hardware. Identify which dependencies protect data with a long lifetime and prioritise accordingly.

Phase 2 — Risk and Impact Assessment

For each cryptographic asset, score the risk of harvest-now-decrypt-later attacks, the cost of remediation, the available hardware resources, and the regulatory exposure. The output is a sequenced migration backlog.

Phase 3 — Pilot in Non-Critical Fleet

Roll hybrid cryptography to a small fleet of beta devices. Measure handshake latency, battery impact, OTA update success rate, and field failure rates. Validate that monitoring and rollback work as intended.

Phase 4 — Production Rollout

Gradually expand hybrid PQC across the fleet using cohort-based OTA. Maintain dual-mode support so older devices remain functional and new devices benefit immediately.

Phase 5 — Deprecate Classical

Once the entire fleet supports hybrid PQC and the wider ecosystem (CAs, partners, suppliers) has caught up, plan the cut-over to pure PQC. Expect this phase to land between 2028 and 2032 depending on industry.

Real-World Embedded Use Cases

Automotive ECUs and V2X

Connected vehicles generate signed messages billions of times per day. SAE and ETSI working groups are aligning on hybrid PQC profiles for Vehicle-to-Everything (V2X) communications. Automakers shipping platforms in 2026 are designing OTA pipelines that can deliver PQC firmware updates over the next decade without warranty-driven recalls.

Medical Devices and Implants

The FDA's 2023 Refuse-to-Accept policy for premarket submissions emphasizes cybersecurity. Devices with ten-to-twenty-year service lives — insulin pumps, pacemakers, CT scanners, ventilators — must demonstrate a migration plan to quantum-safe cryptography or risk regulatory delays. The U.K. MHRA and the EU MDR are aligning on similar expectations.

Industrial IoT and Smart Grid

Operational technology environments often run two-decade-plus replacement cycles. NERC CIP, IEC 62443, and the EU NIS2 Directive create overlapping cybersecurity expectations. PQC migration in this space typically pairs hybrid TLS with hardware security modules certified to FIPS 140-3 Level 3 or 4.

Consumer Wearables and Hearables

Wearables push tight power budgets. Strategies that work in production today include offloading PQC handshakes to companion phones, caching session keys for longer than legacy patterns recommended, and rotating to PQC only on charging cycles.

Comparing PQC Libraries

Beyond Open Quantum Safe's liboqs, several libraries now offer PQC primitives for embedded and server use. Each has distinct strengths.

• liboqs: the most comprehensive open-source PQC reference; broad algorithm coverage, language bindings, and OQS-OpenSSL provider.
• wolfSSL with PQC: production-grade TLS stack widely used in embedded systems; hybrid PQC support and FIPS 140-3 path.
• BoringSSL/OpenSSL 3.x: server-class support with growing PQC coverage, used by major CDNs and browser vendors.
• PQClean: clean reference implementations focused on portability rather than performance.
• Microsoft SymCrypt + msquic: enterprise stack adopting hybrid PQC across Windows and Azure services.
• Apple CryptoKit + iCloud Keychain: iMessage PQ3 protocol uses ML-KEM and demonstrates large-scale PQC deployment to a consumer fleet.

Common Pitfalls in Embedded PQC Adoption

• Skipping the cryptographic inventory. Without it, prioritisation is guesswork.
• Assuming RSA-3072 buys time. It does not — Shor's algorithm breaks both RSA and ECC at scale.
• Forgetting code signing. Bootloaders and OTA flows can be the longest-lived cryptographic dependency in your product.
• Treating PQC as a firmware-only problem. Cloud, CDN, mobile companion app, and CA infrastructure must all support PQC for the migration to succeed.
• Underestimating regression testing. PQC primitives change cipher sizes; assumptions about packet sizes and buffer lengths break in subtle ways.

Authoritative References

• Open Quantum Safe Project
• liboqs on GitHub
• PQM4 — PQC on Cortex-M4
• NSA CNSA 2.0 Suite
• ENISA PQC Guidance

Conclusion

Quantum-safe cryptography is moving from research papers into production firmware. With liboqs, language wrappers, and the broader Open Quantum Safe ecosystem, embedded teams can bring quantum resistance to high-performance servers and tiny microcontrollers alike. Building that foundation today is the surest way to keep tomorrow's connected products — and the patients, drivers, and grid operators who rely on them — secure.

FAQ