Post-Quantum Security for Robots and Drones: Firmware Signing, Fleet Links and Migration

Post-quantum security for robots and drones means replacing the RSA and elliptic-curve cryptography in boot chains, OTA updates and fleet links with algorithms that survive a large quantum computer. The device-side priority is signatures: a robot shipped today may still be running in 2040, and if its boot ROM trusts only ECDSA, a future quantum attacker can sign firmware it will accept. NIST finalised ML-KEM, ML-DSA and SLH-DSA on 13 August 2024, and its October 2026 transition plan deprecates RSA and ECC after 2030 and disallows them after 2035.

A warehouse AMR commissioned in 2027 can plausibly still be moving totes in 2042. The industrial arm beside it has a longer life still: the International Federation of Robotics models the installed base on a 12-year service life and notes a pilot study that put the real figure closer to 15 years. Every one of those machines carries a public key somewhere it cannot easily be changed: a hash fused into the microcontroller, a certificate in a secure element, a key compiled into a bootloader. The algorithm behind that key decides who can push firmware to the machine for its whole working life.

That is the shape of the quantum problem for robotics. The data angle matters too, since telemetry and video recorded today can be decrypted later, but the hard engineering sits in the boot chain and the update pipeline, where decisions made at the factory are frozen for a decade or more.

The take: treat post-quantum migration in robots as a firmware-signing project first and a link-encryption project second. Put a quantum-resistant verifier (LMS, XMSS or ML-DSA) in every new bootloader now, reserve flash and RAM for signatures of 1.5 to 5 kB, keep a second root key from a different algorithm family, and move fleet links to hybrid ML-KEM key exchange as your middleware supports it. Hardware designed in 2026 that only verifies ECDSA will still be in service after NIST disallows ECDSA in 2035.

Companion reading: robot cybersecurity, robot middleware and DDS, and robot fleet management. For the cryptography itself, see Post-Quantum Cryptography Explained on the Pwnsy blog.

Table of contents

1. Key takeaways
2. Why robots are a harvest-now, forge-later case
3. What a quantum computer breaks
4. Signatures are the device risk
5. The standards map
6. Key and signature sizes on real hardware
7. LMS and XMSS for firmware, and the state problem
8. Secure boot, hybrid signatures and crypto-agility
9. Silicon and library support
10. ROS 2, DDS-Security and fleet links
11. MAVLink, PX4 and ArduPilot
12. Quantum sensing for navigation without GPS
13. Migration checklist for a robotics team
14. Frequently asked questions
15. Sources

Why robots are a harvest-now, forge-later case

Two separate quantum threats apply to a robot, and they run on different clocks.

The first is harvest now, decrypt later. An adversary records encrypted traffic today and stores it until a cryptanalytically relevant quantum computer (CRQC) can recover the session keys. NIST IR 8547 names this threat as "one of the main reasons why the transition to post-quantum cryptography is urgent". For robots, the recorded traffic is telemetry, maps of the sites they work in, camera feeds, teleoperation sessions and command-and-control links for drones. A delivery drone's video of a customer's yard or a security robot's patrol footage may still be sensitive in 10 years.

The second is forge later. Signatures are not exposed to harvesting: IR 8547 states plainly that "signatures are not vulnerable to HNDL attacks". The risk arrives on the day a CRQC exists. From then on, anyone who can run Shor's algorithm against a vendor's ECDSA or RSA public key can recover the private key and sign anything: firmware, OTA manifests, mission files, certificates. Every device still trusting that key will accept the forgery.

Robots are exposed to the second threat for three reasons.

Long service lives. The IFR's 12-year modelling assumption, with evidence nearer 15 years, is a floor for industrial arms. AMRs, inspection robots, drones and agricultural machines are capital equipment too, and their controllers and secure elements stay in service as long as the machine does. Michele Mosca's rule, which NIST IR 8547 restates, applies directly: if X is how long a system must stay secure and Y is how long migration takes, you are already late when X + Y exceeds the time Z until a CRQC exists. A robot shipped in 2027 with a 15-year life has X = 15 before you count migration time at all.

Keys burned into hardware. Secure boot anchors trust in something immutable: a root public key hash in one-time-programmable fuses, a key inside a secure element or TPM, or a verifier in mask ROM. That immutability is the security property, and it is also why the algorithm cannot be swapped later. IR 8547 makes the point for code signing directly: where "it is not feasible to update the code that performs the signature verification after the devices have been manufactured", devices that may outlive the arrival of a CRQC should be designed to require quantum-resistant signatures from the start.

Fleet-scale update channels. One OTA signing key can reach every robot a company has shipped. A forged update is a fleet-wide compromise, and for machines that move, it is a physical safety event.

The Harvest Window planner on Pwnsy orders this work for you. It gives data a harvest window based on how long it must stay secret, and gives code-signing keys (release, firmware, container and package signing) a start-by year instead, because their risk is forgery after the break.

What a quantum computer breaks

Shor's algorithm breaks the hard problems behind RSA, finite-field Diffie-Hellman and elliptic-curve cryptography. That covers almost every public-key operation in a robot: ECDSA and Ed25519 firmware signatures, RSA or ECDSA device certificates, TLS and DTLS handshakes using ECDHE, and the DDS-Security handshake in ROS 2.

Symmetric cryptography fares far better. NIST IR 8547 states that all NIST-approved symmetric primitives with at least 128 bits of classical security are believed to meet Category 1, the lowest of NIST's five post-quantum security categories. AES-128 and AES-256, SHA-256, HMAC and the AES-GCM used for DDS data protection stay usable. NIST will disallow its few 112-bit symmetric options in 2030.

Component in a robot	Typical algorithm today	Quantum status	Threat type
Boot ROM and bootloader signature check	ECDSA P-256, Ed25519, RSA-2048	Broken by Shor	Forgery once a CRQC exists
OTA update manifest signing	ECDSA, RSA	Broken by Shor	Forgery, fleet-wide
Device identity certificate	ECDSA P-256	Broken by Shor	Impersonation
TLS, DTLS, DDS-Security key exchange	ECDHE P-256, DHE-2048	Broken by Shor	Harvest now, decrypt later
Bulk data encryption	AES-128-GCM, AES-256-GCM	Category 1 or better	Low
Message authentication	HMAC-SHA-256, truncated SHA-256	Holds	Low
Firmware image hash	SHA-256	Holds	Low

Signatures are the device risk

For a robot vendor, the asymmetry is simple. A key-exchange algorithm can be replaced by a software update to both ends of a link. A signature verifier in ROM, or a root key fused into silicon, can only be replaced by replacing the board.

That makes the bootloader the first decision. If a device's first-stage verifier can check a post-quantum signature, every later stage can be migrated over the air: the vendor signs a new second-stage bootloader with the post-quantum key, and that stage can carry newer algorithms. If the immutable verifier only understands ECDSA, the device's trust chain ends at an algorithm with a disallow date of 2035.

There is also a timing trap. Authentication systems, IR 8547 notes, stay secure as long as the algorithm is unbroken at the moment the signature is checked. A device can keep verifying ECDSA safely right up until a CRQC appears, and then it needs to stop at once. A fleet cannot stop at once. The only workable path is to ship devices that already trust a quantum-resistant key, and to keep the classical key as a second factor until it is retired.

The standards map

Standard	Algorithm	Use	Status (November 2026)
FIPS 203	ML-KEM-512, 768, 1024	Key establishment	Final, 13 August 2024
FIPS 204	ML-DSA-44, 65, 87	Signatures, general purpose	Final, 13 August 2024
FIPS 205	SLH-DSA (12 parameter sets)	Signatures, conservative backup	Final, 13 August 2024
SP 800-208	LMS, HSS, XMSS, XMSS^MT	Stateful signatures for firmware and software	Final, October 2020
FIPS 206	FN-DSA (from Falcon)	Compact signatures	In development
HQC-KEM	HQC	Alternative key establishment	Selected; FIPS in development
NIST IR 8547	Transition plan	RSA, ECC deprecated after 2030, disallowed after 2035	Final, 27 October 2026

NIST's announcement in August 2024 told implementers there was "no need to wait for future standards". ML-DSA, derived from CRYSTALS-Dilithium, is the general-purpose signature. SLH-DSA, derived from SPHINCS+, rests only on hash functions and is the backup in case lattice assumptions weaken. IR 8547 lists the security categories: ML-DSA-44 at Category 2, ML-DSA-65 at 3 and ML-DSA-87 at 5; SLH-DSA at 1, 3 and 5 by parameter size; LMS and XMSS at Category 3 with 192-bit hash outputs and Category 5 with 256-bit outputs.

The final IR 8547 simplified the draft's schedule. Every quantum-vulnerable signature family (ECDSA, EdDSA, RSA) and key-establishment scheme (finite-field DH, ECDH, RSA) is "deprecated after 2030" and "disallowed after 2035". Deprecated means a data owner may still use the algorithm after weighing the risk; disallowed means it is no longer allowed for the stated purpose. US federal agencies face earlier dates: under Executive Order 14412 and OMB Memorandum M-26-15, high-value and high-impact systems must adopt post-quantum key establishment by 31 December 2030 and post-quantum signatures by 31 December 2031. The report sets these deadlines against the 10 to 20 years earlier cryptographic transitions took.

US national security systems follow the NSA's CNSA 2.0 suite, which sets its own milestones for software and firmware signing. Robotics suppliers to defence customers should read the current NSA advisory directly for those dates.

Key and signature sizes on real hardware

The table below takes every figure from the specifications themselves. ECDSA and Ed25519 are shown for comparison.

Scheme	Specification	Public key (bytes)	Signature (bytes)	Signatures per key
ECDSA P-256	FIPS 186-5	64 (raw x, y)	64 (raw r, s)	Unlimited
Ed25519	RFC 8032	32	64	Unlimited
ML-DSA-44	FIPS 204	1,312	2,420	Unlimited
ML-DSA-65	FIPS 204	1,952	3,309	Unlimited
ML-DSA-87	FIPS 204	2,592	4,627	Unlimited
SLH-DSA-128s	FIPS 205	32	7,856	Up to 2^64
SLH-DSA-128f	FIPS 205	32	17,088	Up to 2^64
SLH-DSA-192s	FIPS 205	48	16,224	Up to 2^64
SLH-DSA-256s	FIPS 205	64	29,792	Up to 2^64
SLH-DSA-256f	FIPS 205	64	49,856	Up to 2^64
LMS SHA256 M32 H10, LM-OTS W8	RFC 8554, SP 800-208	56	1,452	1,024
LMS SHA256 M32 H20, LM-OTS W8	RFC 8554, SP 800-208	56	1,772	1,048,576
XMSS-SHA2_10_256	RFC 8391, SP 800-208	68	2,500	1,024
XMSS-SHA2_20_256	RFC 8391, SP 800-208	68	2,820	1,048,576
Falcon-512 (basis of FN-DSA)	Falcon specification	897	666	Unlimited

Notes on the figures. The SHA2 and SHAKE variants of each SLH-DSA set have identical sizes. The LMS signature is 4 bytes of leaf index, a 1,124-byte LM-OTS signature, a 4-byte type code and h authentication-path nodes of 32 bytes each; an HSS wrapper adds 4 bytes, and each extra HSS level adds another LMS signature and public key. The XMSS figures come straight from RFC 8391's parameter table. FIPS 205 caps each SLH-DSA key at 2^64 signatures, which it notes would take over 58 years at 10 billion signatures a second. ML-DSA private keys are 2,560 to 4,896 bytes, but FIPS 204 allows storing only the 32-byte seed and regenerating the rest, which suits a secure element with little storage.

Three practical consequences follow.

Flash. A firmware image header that reserved 64 bytes for an Ed25519 signature now needs 2.4 kB for ML-DSA-44, 4.6 kB for ML-DSA-87 or 1.5 kB for LMS H10. If the bootloader also stores the public key in flash, add 1.3 to 2.6 kB for ML-DSA. LMS and XMSS public keys stay at 56 and 68 bytes, which matters when the root key lives in fuses or a small OTP area.

Bandwidth. For a full image, a 5 kB signature is noise. It matters for small signed messages: mission uploads, signed telemetry, certificate chains sent over a 57.6 kbps telemetry radio, or a DDS handshake that carries a certificate chain per participant. A chain of three ML-DSA-65 certificates carries roughly 15.8 kB of keys and signatures alone (3 x 1,952 plus 3 x 3,309 bytes) before any other certificate fields.

Compute and boot time. Verification is fast enough for microcontrollers. The pqm4 project, which benchmarks post-quantum schemes on a Cortex-M4 board (Nucleo-L4R5ZI), measures:

Scheme (pqm4 implementation)	Verify cycles	Verify stack (bytes)	At 100 MHz
ML-DSA-44 (m4f)	1,421,623	8,912	about 14 ms
ML-DSA-44 (m4fstack)	3,242,333	2,712	about 32 ms
ML-DSA-65 (m4f)	2,415,944	9,888	about 24 ms
ML-DSA-87 (m4f)	4,193,104	12,060	about 42 ms
SLH-DSA-SHA2-128s (clean)	7,471,794	1,968	about 75 ms
SLH-DSA-SHA2-128f (clean)	21,923,628	2,664	about 219 ms

The millisecond column is simple arithmetic from the cycle counts. Hashing the firmware image itself usually costs more than the signature check on a multi-megabyte image, and a hardware SHA-256 accelerator helps both. Signing is the expensive side (ML-DSA-44 signing averages 3.9 million cycles in the m4f build, and SLH-DSA-128s signing takes 7.7 billion), but signing happens on a build server or HSM. A robot that only verifies does not pay it.

LMS and XMSS for firmware, and the state problem

Stateful hash-based signatures are the most conservative option available. Their security rests only on the hash function, and NIST approved them in SP 800-208 in October 2020, four years before ML-DSA. SP 800-208 describes exactly the robotics case as the intended use: an implementation needed soon, with a long lifetime, where changing the signature scheme after deployment would be impractical. Its example is "the authentication of firmware updates for constrained devices", some of which "will be in use for decades".

The catch is state. An LMS or XMSS private key is a large set of one-time signature keys. If the signer ever uses the same one-time key on two different messages, an attacker holding both signatures can forge signatures on arbitrary messages. RFC 8391 says an implementation "MUST NOT output the signature before the private key is updated". SP 800-208 goes further and requires key generation and signing inside hardware cryptographic modules that do not let the secret key be exported, even in encrypted form, with FIPS 140-3 Level 3 or higher physical security.

The failure modes are mundane, which is why they are dangerous:

• Backups and snapshots. Restoring a signing server or VM from yesterday's snapshot rolls the counter back, and the next build reuses one-time keys.
• Parallel CI runners. Two build agents sharing one key file can sign two images with the same leaf.
• Crash between sign and persist. If the signature leaves the module before the incremented counter is durably stored, a crash can replay the index.
• Running out. An LMS H10 key signs 1,024 messages. A team signing 4 product lines weekly uses 208 signatures a year and exhausts it in under 5 years. Size the tree, or use HSS with multiple levels, for the product's whole life plus a margin.

Verification has no state, so the robot side is simple: the bootloader only needs the 56-byte LMS public key and a SHA-256 implementation. That is why LMS verification fits in fixed hardware: Microchip's MEC175xB controllers, for example, implement it in immutable logic. Verifier bugs still happen. Mbed TLS fixed CVE-2025-49600, in which an attacker who could make a hash accelerator fail could get an invalid LMS signature accepted, and CVE-2025-49601, a buffer over-read in LMS public key import.

Rule of thumb: use LMS or XMSS when a small team signs a small number of releases from one well-controlled HSM, and the verifier must be tiny. Use ML-DSA when many parties sign, signing volume is open-ended, or you cannot guarantee a single source of truth for the counter.

Secure boot, hybrid signatures and crypto-agility

A bootloader built today should be able to survive two algorithm transitions: classical to post-quantum now, and a possible move between post-quantum families later if one is weakened. Five design choices make that possible.

1. Put an algorithm identifier in the image header. Every signature block should carry a type code and a length, the way LMS signatures already carry their own type codes. A verifier that parses the type can refuse unknown algorithms cleanly and accept new ones after a second-stage update.

2. Provision more than one root key, from different families. ArduPilot's secure bootloader already holds up to 10 public keys. A robot can carry one ECDSA or Ed25519 root, one LMS or ML-DSA root, and a spare. The spare is your recovery path if a key leaks or an algorithm falls. LMS and XMSS public keys are 56 and 68 bytes, so a hash-based root is cheap to add even where fuse space is tight.

3. Use dual signatures during the transition. NIST IR 8547 describes hybrid or composite signatures as two or more signatures over the same message, all of which must verify, and says existing NIST guidance accommodates them provided at least one component is NIST-approved. For firmware, sign each image with both Ed25519 and ML-DSA (or LMS) and require both. An attacker then has to break both families. Retire the classical half once your fleet and your regulators no longer need it.

4. Keep anti-rollback independent of the algorithm. A monotonic version counter in OTP or a secure element blocks downgrade to a vulnerable but validly signed image. After you rotate to post-quantum keys, raise the floor so images signed only with the old key are refused.

5. Budget memory up front. Reserve at least 5 kB in the image header for signatures, 3 kB of flash for each ML-DSA public key you might store, and 10 to 12 kB of stack or a dedicated buffer if you use the speed-optimised ML-DSA verifier. These numbers are small on an application processor and decisive on a 256 kB microcontroller.

The same structure applies above the bootloader. OTA frameworks such as TUF and Uptane separate root, targets, snapshot and timestamp roles, and each role can migrate to a post-quantum signature independently. Start with the root and targets keys, which protect the longest-lived trust.

Silicon and library support

Support is real but uneven. The table lists only what the vendor or project documents directly.

Product	Post-quantum support (as documented)	Notes
Infineon OPTIGA TPM SLB 9672	Firmware update protected by XMSS signatures	Infineon calls it the first TPM with a PQC-protected firmware update; recovery per NIST SP 800-193
Microchip MEC175xB embedded controllers	ML-DSA, LMS verification and ML-KEM in immutable hardware; secure boot configurable for CNSA 1.0, CNSA 2.0 or hybrid verification	Announced 15 May 2025; Cortex-M4F at 96 MHz, 480 KB SRAM; early-adopter programme at launch
wolfBoot (wolfSSL)	LMS/HSS and XMSS/XMSS^MT since v2.0.0; ML-DSA since v2.3.0; hybrid PQC plus ECC/RSA authentication since v2.3.0	v2.10.0 adds an ML-DSA-87 signed-boot configuration for NXP i.MX RT700
Mbed TLS	LMS added in 3.3.0 (14 December 2022); verification production-ready, signing for testing only; single parameter set LMS_SHA256_M32_H10	The changelog names firmware image verification as the intended use
liboqs (Open Quantum Safe)	ML-KEM (tier 1), ML-DSA, LMS, XMSS (tier 2), SLH-DSA and Falcon (tier 3)	The project says it does not recommend relying on it in production or to protect sensitive data
PQClean	Reference C for Kyber, Dilithium, Falcon, SPHINCS+, HQC, Classic McEliece	Archived and read-only since 4 August 2026; do not start new work on it

Two cautions apply when reading vendor material. First, "supports ML-DSA" can mean signing, verification or key generation; a boot ROM may verify only. Second, algorithm validation (NIST CAVP) and module validation (CMVP) are different things, and IR 8547 notes NIST is revising CMVP processes to speed up validation of post-quantum modules. Ask suppliers which they hold.

For Linux-class robot computers (Jetson, x86, i.MX 8 and similar), the post-quantum path runs through the operating system's TLS stack and the bootloader chain. Check what your SoC's ROM verifies before assuming a Linux-level fix covers secure boot. The edge AI compute guide covers those platforms.

ROS 2, DDS-Security and fleet links

ROS 2 security runs on the OMG DDS-Security specification. Version 1.2, published by the OMG in February 2026, defines the builtin plugins' algorithms:

• Signatures: RSASSA-PSS and RSASSA-PKCS1-v1_5 with 2048-bit RSA, and ECDSA on P-256 and P-384.
• Key establishment: Diffie-Hellman on the 2048-bit MODP group, and ECDHE on P-256 (the required default).
• Data protection: AES-128-GCM and AES-256-GCM, with AES-256-GCM as the default required mask.

There is no post-quantum algorithm in the 1.2 builtin set. The SROS 2 tooling follows the specification: its keystore code generates P-256 keys (with a comment that DDS-Security calls for prime256v1) and issues certificates valid for 3,650 days. A keystore created today therefore produces 10-year certificates on an algorithm NIST disallows in 2035.

What this means in practice:

• Harvest exposure is real for ROS 2 traffic leaving a site. The DDS-Security handshake derives session keys from ECDHE or DHE. Anyone recording encrypted DDS traffic, for example over a site-to-site link or a cloud relay, can in principle recover it after a CRQC exists. The AES-GCM payload protection is fine; the key exchange is the weak point.
• Wrap external links now. Fleet telemetry, remote teleoperation and cloud bridges usually leave the robot over TLS, a VPN or a vendor relay. Those layers can move to hybrid ML-KEM key exchange well before DDS-Security does. Prioritise links that carry video, maps or customer data with a long secrecy requirement.
• Keep the local DDS domain segmented. Traffic that never leaves a segmented control network is harder to harvest. The robot cybersecurity guide covers the segmentation and SROS 2 enforcement basics.
• Plan certificate rotation. Shorten certificate lifetimes from the 10-year default so a future switch to post-quantum identities is a routine rotation.

The middleware and DDS guide explains how DDS vendors implement these plugins; ask yours for its post-quantum roadmap, since vendor plugins can add algorithms beyond the builtin set.

MAVLink, PX4 and ArduPilot

MAVLink 2 message signing is symmetric. Each signed packet carries 13 extra bytes: an 8-bit link ID, a 48-bit timestamp in 10-microsecond units since 1 January 2015, and a 48-bit signature that is the first 48 bits of a SHA-256 hash over a 32-byte secret key and the packet. Both ends hold the same key. Shor's algorithm does not apply, and a 256-bit secret key keeps a large margin against quantum key search. The quantum migration leaves MAVLink signing largely as it is.

Its real limits are classical ones, and they are worth fixing while you are in the code:

• It is off by default. PX4 documents that with no key on the SD card, signing is disabled and all messages are accepted unsigned. ArduPilot enables it through Mission Planner's MAVLink Signing setup.
• It provides authentication only. Signing does not encrypt payloads; telemetry and video still need their own encrypted transport, and that transport's key exchange is where the harvest risk sits.
• Key handling is manual. The key is shared using the SETUP_SIGNING message over a secure link such as USB, which the MAVLink documentation says should never be broadcast. PX4 stores it as a 40-byte file on the SD card. Physical access to the card is access to the key.

Firmware signing on drones is a different story. ArduPilot's optional secure bootloader holds up to 10 public keys and checks a 72-byte signature block (an 8-byte version plus a 64-byte Monocypher EdDSA signature) before it boots the vehicle firmware. That is an elliptic-curve signature, so it falls into the forge-later category. For drones with Remote ID tamper-resistance requirements or long-lived enterprise fleets, it is the component to watch for a hash-based or ML-DSA option. See the drone navigation guide for how the flight stack fits together.

Quantum sensing for navigation without GPS

Quantum technology also offers robots something useful: navigation that does not depend on GNSS, which can be jammed or spoofed. Three classes of sensor matter, and each has a verified field trial.

Trial	Sensor	Platform	Result reported
Boeing and AOSense, 2024	Quantum IMU using atom interferometry (three single-axis sensors)	Beechcraft 1900D, flight from St. Louis	Aircraft navigated without GPS for 4 hours; Boeing says such IMUs could cut end-of-flight error from tens of kilometres to tens of metres
Q-CTRL Ironstone Opal, paper April 2025	Quantum magnetometers matched against magnetic anomaly maps	Aircraft at up to 19,000 ft and a ground vehicle	Up to 46x lower positioning error than a velocity-aided strategic-grade INS; best final accuracy 22 m, 0.006% of flight distance; at least 11x across airborne trials
Royal Navy, October 2025	Infleqtion Tiqker quantum optical atomic clock	XV Excalibur uncrewed submarine	Operated through multiple dives; the Navy called it a first step, with no accuracy figures published

Quantum IMUs measure acceleration and rotation with clouds of cold atoms, whose behaviour does not drift the way MEMS or fibre-optic gyros do. Boeing's flight also carried SandboxAQ's AQNav, a magnetic navigation system that bounds IMU drift. The IMU guide explains why drift is the limiting factor for any dead-reckoning robot.

Quantum magnetometers sense the Earth's crustal magnetic field precisely enough to match it against survey maps, which works like terrain matching without a camera. Q-CTRL's preprint says its system is sized for fixed-wing drones as well as an airliner's avionics bay; the company's own release rounds the best airborne result to about 50x.

Atomic clocks keep time when GNSS timing is lost, which matters for dead reckoning, radio synchronisation and underwater vehicles that cannot see satellites at all.

These systems are at the trial stage, and the reported figures come from the developers. For a small AMR or a consumer drone, size, power and cost still rule them out. For long-range fixed-wing UAVs, submarines and defence robots, they are the most credible answer to GNSS denial, which is why military drone and underwater robot programmes fund them.

Migration checklist for a robotics team

Work through this in order. The first five items cost little and decide what the next decade looks like.

1. Inventory every key. List each place your products use public-key cryptography: boot ROM and fuse keys, bootloader keys, OTA and manifest signing, device certificates, TLS and VPN endpoints, DDS-Security keystores, cloud APIs, and signing keys held by contract manufacturers. Record algorithm, key size, where the key lives and whether it can be updated in the field.
2. Record each product's service life. Note when the last unit ships and how long customers keep it. Feed both into the Harvest Window planner to get a start-by year for each signing key.
3. Check what your silicon's ROM can verify. For each MCU, SoC, secure element and TPM on your boards, find out whether the immutable verifier supports LMS, XMSS or ML-DSA. If it does not, the bootloader stage above it must carry the post-quantum check.
4. Ship a post-quantum root key in every new design. Provision at least one LMS, XMSS or ML-DSA root alongside the classical key, plus a spare. This is the one step that cannot be done after the device leaves the factory.
5. Reserve memory and bandwidth. At least 5 kB for signatures in the image header, 3 kB per stored ML-DSA public key, and stack for the verifier. Check OTA packet sizes and certificate chain sizes on your slowest link.
6. Choose a signing model. LMS or XMSS from one HSM with strict counter handling, or ML-DSA if many parties sign. Put signing keys in an HSM either way and test restore procedures for state rollback before you need them.
7. Turn on dual signatures. Sign releases with both the classical and the post-quantum key and make the bootloader require both. Measure boot-time impact on real hardware.
8. Move external links to hybrid key exchange. Telemetry, video, teleoperation and cloud bridges first, ordered by how long their data stays sensitive.
9. Shorten certificate lifetimes. Replace 10-year device and DDS certificates with lifetimes that let you rotate to post-quantum identities as your middleware supports them.
10. Turn on what is already quantum-safe. Enable MAVLink 2 signing, AES-256-GCM in DDS-Security, and HMAC-SHA-256 for any internal message authentication. These need no new algorithms.
11. Write it into procurement. Ask suppliers of secure elements, TPMs, flight controllers, DDS implementations and cloud fleet platforms for dated post-quantum roadmaps, and for whether they hold CAVP or CMVP validation.
12. Set the retirement dates. Plan to stop accepting classical-only signatures for new firmware before 2030 and to remove classical-only trust from the fleet before 2035, matching NIST's deprecation and disallow dates.

Frequently asked questions

Do robots need post-quantum cryptography if no quantum computer can break RSA yet? Yes, because robots outlive the decision. A device shipped in 2027 with a 15-year life is in service until 2042. If its boot chain trusts only ECDSA or RSA, a quantum computer built at any point in that window can be used to forge firmware it accepts. NIST deprecates those algorithms after 2030 and disallows them after 2035.

What is harvest now, decrypt later, and does it affect firmware signatures? It is the practice of recording encrypted traffic today to decrypt once a quantum computer exists. It affects data such as telemetry, video and maps whose key exchange used ECDH or RSA. NIST IR 8547 states that signatures are not vulnerable to it; their risk is forgery after a quantum computer exists.

Which post-quantum signature should I use for robot firmware? LMS or XMSS (NIST SP 800-208) if one team signs a limited number of releases from a well-controlled HSM and you want the smallest verifier. ML-DSA (FIPS 204) if signing volume is open-ended or several parties sign. Many teams combine one of these with their existing Ed25519 or ECDSA signature as a dual signature during the transition.

How large are post-quantum signatures compared with ECDSA? ECDSA P-256 and Ed25519 signatures are 64 bytes. ML-DSA-44 signatures are 2,420 bytes, ML-DSA-87 4,627 bytes, LMS with a height-10 tree 1,452 bytes, XMSS-SHA2_10_256 2,500 bytes, and the smallest SLH-DSA set 7,856 bytes. Falcon-512, the basis of the coming FN-DSA standard, is 666 bytes.

Is ROS 2 security quantum-safe? Not yet. SROS 2 uses DDS-Security, whose version 1.2 builtin plugins use RSA-2048 or ECDSA for signatures and DHE-2048 or ECDHE P-256 for key exchange, all of which Shor's algorithm breaks. The AES-GCM data protection is fine. Protect external links with hybrid post-quantum TLS or VPNs in the meantime.

Is MAVLink signing broken by quantum computers? No. MAVLink 2 signing uses a 32-byte shared secret and SHA-256, which are symmetric primitives that keep a large margin against quantum attack. Its weaknesses are classical: it is off by default, it does not encrypt, and the key must be provisioned and stored securely. Drone firmware signing, such as ArduPilot's EdDSA secure boot, does need a post-quantum plan.

What are stateful hash-based signatures and why are they risky? LMS and XMSS build a key from many one-time signature keys. They are compact and their security depends only on the hash function, but reusing a one-time key lets an attacker forge signatures. Snapshots, backups, parallel build agents and crashes can all cause reuse, so NIST requires signing inside a non-exportable hardware module.

Can quantum sensors replace GPS on a drone today? Not on small drones. Quantum IMUs, magnetometers and clocks have flown and sailed in trials, including Boeing's 4-hour GPS-free flight in 2024 and Q-CTRL's magnetic navigation results of up to 46x better than a strategic-grade INS, but they remain trial systems sized for aircraft, larger UAVs and submarines.

Sources

Primary sources first: the standards, specifications, project code and documentation, and the developers' own trial reports. Secondary reporting follows.

Primary

1. NIST releases first 3 finalized post-quantum encryption standards - the 13 August 2024 announcement of FIPS 203, 204 and 205.
2. NIST IR 8547, Transition to Post-Quantum Cryptography Standards - the final October 2026 report with the 2030 and 2035 dates, the code-signing guidance and the hybrid signature text (record page).
3. FIPS 203, ML-KEM - key and ciphertext sizes.
4. FIPS 204, ML-DSA - Table 2 key and signature sizes and the 32-byte seed option.
5. FIPS 205, SLH-DSA - Table 2 parameter sets and the 2^64 signature limit.
6. NIST SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes - intended applications, state management and the hardware module requirement.
7. RFC 8554, Leighton-Micali Hash-Based Signatures - LMS and LM-OTS formats and sizes.
8. RFC 8391, XMSS: eXtended Merkle Signature Scheme - XMSS formats, the parameter table and the state-update rule.
9. RFC 8032, Edwards-Curve Digital Signature Algorithm - Ed25519 key and signature sizes.
10. FIPS 186-5, Digital Signature Standard - ECDSA on P-256.
11. Falcon specification - Falcon-512 and Falcon-1024 key and signature lengths.
12. OMG DDS Security specification - version 1.2 (February 2026) builtin signature, key-establishment and AES-GCM algorithms.
13. sros2 - keystore code generating P-256 keys and 3,650-day certificates.
14. MAVLink message signing - packet format, SHA-256 signature and key sharing.
15. PX4 MAVLink message signing - default-off behaviour and key storage.
16. ArduPilot MAVLink2 signing - setup in Mission Planner.
17. ArduPilot secure boot signing tools - up to 10 bootloader public keys and Monocypher key generation.
18. wolfBoot - release notes for LMS, XMSS, ML-DSA and hybrid authentication.
19. Mbed TLS ChangeLog - LMS support in 3.3.0 and its scope.
20. liboqs - supported algorithms, support tiers and the production-use warning.
21. PQClean - archive notice.
22. pqm4 benchmarks - Cortex-M4 cycle counts and stack usage.
23. Infineon OPTIGA TPM SLB 9672 product brief - XMSS-protected firmware update.
24. Microchip brings hardware quantum resistance to embedded controllers - MEC175xB algorithms and configuration.
25. IFR World Robotics 2017, Industrial Robots, Chapter 1 - the 12-year service-life assumption and the 15-year pilot study.
26. Boeing: Beyond GPS, quantum navigation flight test - the AOSense quantum IMU flight.
27. Quantum-assured magnetic navigation achieves positioning accuracy better than a strategic-grade INS - Q-CTRL's preprint with the airborne and ground results.
28. Q-CTRL press release on GPS-denied navigation - the company's summary of the trials.
29. Royal Navy: quantum navigation trials on XV Excalibur - the Tiqker clock trial.

Further reading

30. Harvest Window planner - orders post-quantum migration by data lifetime, with start-by years for signing keys.
31. Post-Quantum Cryptography Explained - background on Shor's algorithm and the NIST standards.
32. Post-quantum cryptography and Hash-based cryptography - overviews of the algorithm families.
33. Open Quantum Safe - the project behind liboqs and its protocol integrations.
34. Boeing's quantum-based navigation system takes flight - reporting on the 2024 flight test.
35. Royal Navy tests quantum tech on drone sub Excalibur - reporting on the Tiqker trial.
36. Royal Navy tests quantum optical atomic clock on underwater vessel - further coverage of the same trial.
37. Infineon launches world's first TPM with a PQC-protected firmware update mechanism - launch coverage of the SLB 9672.
38. Microchip brings hardware quantum resistance to embedded controllers - trade coverage of the MEC175xB.