IoT & OT Security
PQC for constrained devices — algorithm selection, firmware signing, protocol impacts, and SCADA migration.
Why IoT/OT Is Different
Internet of Things (IoT) and Operational Technology (OT) devices face unique post-quantum migration challenges that don't apply to servers or desktops. These devices operate under severe resource constraints — limited RAM, slow processors, narrow bandwidth — while having deployment lifetimes of 15–30 years.
Many IoT devices have 10–256 KB of RAM. PQC algorithms like ML-KEM-768 require ~6 KB of stack RAM just for one key exchange — a significant fraction of a Class 1 device’s total memory.
NB-IoT offers only 62.5 kbps uplink. A single ML-KEM-768 ciphertext (1,088 bytes) takes ~0.14 seconds to transmit — manageable alone, but a full PQC DTLS handshake could take several seconds.
SCADA systems in power grids run for 20–30 years. Devices deployed today will still be operational when cryptographically relevant quantum computers (CRQCs) arrive. This makes them prime HNDL targets.
Many OT devices are air-gapped, physically inaccessible, or lack OTA update capability. Crypto-agility must be designed in from the start — it cannot be retrofitted.
PQC operations consume significantly more energy than classical crypto. For battery-powered devices with multi-year targets, this overhead must be budgeted — favoring session resumption (PSK) over repeated PQC handshakes.
| Class | RAM | Flash | Examples |
|---|---|---|---|
| Class 0 | 2 KB | 25 KB | Sensor tags, RFID sensors, Asset trackers |
| Class 1 | 10 KB | 100 KB | Smart meters, Environmental sensors, Actuators |
| Class 2 | 50 KB | 250 KB | Industrial gateways, PLCs, Camera nodes |
| Class 3+ | 256 KB | 1024 KB | Edge gateways, RTUs, Vehicle ECUs |
NIST selected as the lightweight authenticated encryption standard (2023), specifically designed for constrained IoT environments. While Ascon addresses symmetric-key AEAD, PQC algorithms address the asymmetric-key challenge — both are needed for comprehensive IoT security.
Algorithm Selection for Constrained Devices
Not all PQC algorithms are suitable for constrained devices. The key trade-off is between security level, resource consumption, and output sizes. fits in ~3 KB of stack RAM, while needs ~180 KB — impossible for Class 0/1 devices.
FrodoKEM's conservative design (no ring/module structure) comes at a massive RAM cost, making it infeasible for any IoT deployment.
(FIPS 206, draft) produces the most compact PQC signature (~666 bytes average, 690 max) — ideal for bandwidth-constrained IoT. has the smallest verifier (0.5 KB RAM, 56-byte public key) but requires stateful key management.
Certificate Chain Bloat
A classical ECDSA P-256 certificate chain (root + intermediate + leaf) is roughly 3 KB. A PQC chain using balloons to ~22 KB — a 7x increase. For a Class 1 device with 10 KB of RAM, this chain alone exceeds total memory.
Replace per-cert PQC signatures with compact Merkle inclusion proofs (~300 bytes vs ~3 KB). Reduces chain overhead by up to 85%. See the Merkle Tree Certificates module.
Certificate compression (RFC 8879) saves 25–35%. Session resumption (PSK) eliminates certs on reconnection. Raw public keys (RFC 7250) remove signatures and metadata entirely.
Firmware Signing for IoT
Over-the-air (OTA) firmware updates are a critical attack surface for IoT devices. The signing algorithm must produce compact signatures (to minimize bandwidth), have fast verification (constrained CPUs), and resist quantum attacks for the device's entire operational lifetime.
is the leading choice for firmware signing: 56-byte public key, 2.5 KB signature, and the fastest PQC verifier on constrained MCUs (~4× faster than XMSS on Cortex-M4). Its stateful nature (monotonic counter in TPM) is acceptable for firmware signing servers that sign infrequently. The (RFC 9019) wraps the firmware image with metadata, conditions, and signatures for secure OTA delivery.
For deep dives on LMS/XMSS state management and secure boot chains, see the Stateful Hash Signatures and Code Signing modules.
Protocol Considerations
IoT devices communicate over constrained protocols with strict payload limits. PQC key exchanges and signatures must fit within these constraints — or fragment across multiple messages, adding latency and failure risk.
| Protocol | Transport | Max Payload | PQC Feasibility |
|---|---|---|---|
| CoAP + DTLS 1.3 | UDP | 1,024 B | Challenging |
| MQTT 5.0 + TLS 1.3 | TCP | 65,535 B | Good |
| LoRaWAN 1.1 | LoRa PHY | 222 B | Problematic |
| Matter / Thread | UDP/IPv6 | 1,280 B | Challenging |
| LwM2M + DTLS 1.2/1.3 | UDP | 1,024 B | Challenging |
| BLE Mesh | BLE | 384 B | Problematic |
| OPC UA | TCP | 65,535 B | Good |
A classical 1.3 handshake is ~5 KB. With PQC (ML-KEM-768 + ML-DSA-44), this grows to ~22 KB — requiring 15+ DTLS fragments over a 1,280-byte IPv6 minimum MTU. Each fragment is a potential point of failure on lossy wireless networks.
SCADA/ICS Security
and Industrial Control Systems (ICS) manage critical infrastructure — power grids, water treatment, manufacturing. These systems have the longest asset lifecycles (15–30 years) and the highest consequences of compromise.
Sensors, actuators, field instruments
PLCs, RTUs, IEDs
HMIs, SCADA servers, historians
Domain controllers, file servers, engineering workstations
Data diodes, jump servers, patch management, remote access
ERP, email servers, corporate network
Cloud services, remote access, VPN gateways
“Internet-facing layers (DMZ, enterprise boundary) must migrate to PQC first — they are the primary target. Air-gapped Level 0–1 devices may rely on gateway-mediated PQC protection.”
Hybrid Approaches on Constrained Hardware
Running both classical and PQC algorithms doubles the resource cost. For Class 2+ devices, native hybrid (e.g., X25519 + ML-KEM-768) is feasible. For Class 0/1 devices, a gateway-mediated approach is more practical.
Constrained devices use classical crypto (ECDSA/X25519) to communicate with a nearby gateway. The gateway terminates classical connections and re-encrypts with PQC for the IT/cloud side. This protects data in transit without modifying field devices.
Devices with 50+ KB RAM can run hybrid key exchanges natively. The KEM shared secret is derived from both classical and PQC components — security holds as long as both algorithms remain unbroken.
Secure elements (ARM TrustZone-M, Infineon OPTIGA TPM, Microchip ATECC608) can offload PQC operations from the main MCU, enabling PQC on devices that otherwise lack sufficient RAM or processing power. Industry leaders including Samsung and Thales are developing ML-KEM support for embedded secure elements, enabling quantum-safe security for smart cards and constrained IoT devices.
For details on hybrid key exchange and composite signatures, see the Hybrid Cryptography and Crypto Agility modules.
Related Resources
Compare algorithm resource footprints, simulate firmware signing, visualize DTLS handshake overhead, and plan SCADA migration.