Post-quantum migration for IoT fleets.

Why IoT is the hardest case

Harvest now, decrypt later applies to any traffic recorded today and decrypted once a quantum computer able to break public-key cryptography exists. IoT adds three aggravating factors. Devices stay in the field for ten to fifteen years, so a device shipped today with RSA or elliptic-curve cryptography may still be running after the 2030 and 2035 milestones. Fleets count thousands to millions of units, often from several vendors and firmware generations. And many devices are constrained: little memory, little bandwidth, battery budgets, and update channels that were never designed to change cryptographic algorithms.

Mosca’s inequality frames the risk: if data must stay confidential for x years, migration takes y years, and such a quantum computer arrives in z years, the data is exposed whenever x + y > z. For a fleet of long-lived devices, y alone can take several years.

The dates are set. NIST’s draft transition plan (IR 8547) deprecates RSA and elliptic-curve algorithms at the 112-bit security level after 2030 and disallows quantum-vulnerable public-key algorithms after 2035. The EU coordinated roadmap asks Member States to start by the end of 2026 and to migrate high-risk use cases, including critical infrastructure, by the end of 2030.

Where the cryptography lives

In a connected device, public-key cryptography sits in several places, most of them outside the SIM:

• the TLS or DTLS stack that connects the device to its platform, with its key exchange and certificates;
• the secure-boot chain and the signatures that authenticate firmware updates;
• device identity certificates and the provisioning PKI behind them;
• VPN, MQTT, CoAP or vendor protocols with their own handshakes;
• keys and certificates stored in configuration files, sometimes shared across a whole product line.

Symmetric primitives such as AES, SHA-2 and SHA-3 are far less affected: Grover’s algorithm at best halves their effective security, and the usual answer is 256-bit keys. The urgent part is public-key cryptography, RSA, Diffie-Hellman, ECDH, ECDSA and EdDSA, which Shor’s algorithm breaks.

What the SIM can and cannot see

Operators control the SIM remotely across their whole fleet, so it is tempting to use it to inventory the cryptography of the device. It cannot do that. The SIM (UICC or eUICC) is a secure element, isolated by design. It talks to the device only through standardized interfaces: APDU commands (ISO/IEC 7816-4) and the SIM Toolkit (ETSI TS 102 223, 3GPP TS 31.111), which lets SIM applets request a few services from the device. It cannot read the application processor’s memory, the operating system or the firmware, and that is where the cryptography to inventory lives.

The SIM still matters to the migration. Network authentication (MILENAGE, TUAK) is symmetric, and TUAK already supports 256-bit keys. The exposed parts are public-key: the concealment of the subscriber identifier in 5G (SUCI, based on elliptic-curve ECIES) and the elliptic-curve PKI behind remote SIM provisioning. The GSMA’s Post-Quantum Telco Network Taskforce publishes guidance on these telecom use cases.

Inventory, from the outside in

The inventory starts where access is cheapest and least intrusive, then moves inward:

1. External observation. Network scans, exposed endpoints, TLS and DTLS handshakes, certificates presented by devices and back-end platforms. This already reveals negotiated algorithms, key sizes, certificate chains and their expiry dates.
2. Traffic captures from the fleet. They show the protocols actually used in the field, not the ones in the documentation.
3. Firmware images and configurations. Binaries are lifted to an intermediate representation, cryptographic libraries and calls are identified, and certificates and keys embedded in images or configuration files are extracted.

The result is a cryptographic bill of materials: for each asset, the algorithm, key size, library, location and the evidence behind the finding. CycloneDX has supported CBOM since version 1.6, so the inventory can be reused by the operator’s own tools and handed on to its customers.

Prioritizing against 2030

Not every finding has the same urgency. A useful ordering combines four factors:

• how long the protected data must stay confidential, since long-lived secrets are exposed to harvesting now;
• how long the device will remain in the field;
• how exposed it is: reachable from the internet, over the air, or only locally;
• whether it can receive cryptographic updates over the air at all.

Devices that cannot be updated must be identified first, because the only remedy may be replacement, and replacement cycles are long. Every finding carries one of four statuses, confirmed, refuted under a model, unknown or heuristic, and what is not proven stays unknown.

The same inventory also surfaces classical weaknesses that are often more urgent than the quantum threat: deprecated TLS versions, short keys, private keys shared across a product line, expired or self-signed certificates.

Constraints on constrained devices

Post-quantum keys and signatures are much larger than the ones they replace:

On constrained links such as NB-IoT, LoRaWAN or satellite, a handshake may no longer fit in a few packets, certificates take more flash, and update payloads grow. The usual responses:

• hybrid key exchange, classical and ML-KEM together, as already deployed in TLS by major browsers;
• symmetric cryptography kept, with 256-bit keys;
• firmware-signing keys migrated early, since they are long-lived trust anchors; hash-based signatures (SLH-DSA, or stateful LMS and XMSS under NIST SP 800-208) are the conservative choice there;
• crypto-agility: the ability to change algorithms over the air without replacing the device.

Where AI fits

Two different problems call for two different kinds of AI system.

Migration is an inventory and planning problem at scale: thousands of firmware images, configurations and captures to read, classify and prioritize. An agentic system that drives existing analysis tools, reads their output and writes the CBOM with its evidence is enough. The SecAgent pipeline provides the analysis steps, inputs, ingestion, analysis, CBOM, exposure and migration plan; it runs offline, and every finding can be replayed.

Finding flaws in protocols, classical or post-quantum, is an open-ended search. There, an evolutionary system in the style of AlphaEvolve explores candidate attack programs continuously and keeps what the evaluator confirms. That is the role of AgadesEvolve, described in the research note.

The next proof is a pilot on a real industrial fleet. Operators and integrators who want to run one can see the engagements or write to [email protected].

Sources

• NIST, FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA), August 2024.
• NIST, IR 8547, Transition to post-quantum cryptography standards, initial public draft, November 2024.
• NIST, SP 800-208, Recommendation for stateful hash-based signature schemes, 2020.
• NIS Cooperation Group, A coordinated implementation roadmap for the transition to post-quantum cryptography, June 2025.
• M. Mosca, Cybersecurity in an era with quantum computers: will we be ready?, IEEE Security & Privacy, 2018.
• ISO/IEC 7816-4 (APDU); ETSI TS 102 223 and 3GPP TS 31.111 (SIM Toolkit); 3GPP TS 33.501 (5G security, SUCI); 3GPP TS 35.231 (TUAK).
• GSMA Post-Quantum Telco Network Taskforce, guidelines for telecom use cases.
• OWASP CycloneDX, CBOM support since specification 1.6, 2024.