Quantum-safe by design: why embedded security can’t wait for Q-Day

The device you ship this year will outlive its own security. Not because anyone cut a corner, but because a quantum computer will eventually crack the cryptography protecting it. For embedded devices, that’s a real problem. A product with a fifteen-year life and a signing key burned into read-only memory can’t be re-keyed later. The vulnerability doesn’t appear on Q-Day (the point a quantum computer can break today’s encryption); you’re designing it in right now.

What quantum breaks, and what it doesn’t

This isn’t a break-everything event.

A large enough quantum computer running Shor’s algorithm will break the public-key cryptography that almost everything leans on: RSA and elliptic-curve (ECC) key exchange and signatures. But it leaves strong symmetric cryptography alone. AES-256, the workhorse cipher behind most encryption, and modern hashes stay safe for the foreseeable future. The hunt is narrower than it sounds: you’re looking for RSA and ECC, not AES.

But here’s the catch: AES only works once both ends share a secret key, and that key is almost always set up at the start of a session using RSA or ECC — the very schemes quantum breaks. So an attacker doesn’t have to beat AES itself. They record your encrypted traffic today and sit on it. Once quantum can crack that RSA or ECC key setup, they pull the AES key straight out of the recording and read everything the session carried, years after the fact. The security world calls this ‘harvest now, decrypt later’, and it’s why the clock is already running even though the machine to do the cracking doesn’t exist yet.

How does quantum affect embedded devices?

Embedded devices carry the quantum transition harder than almost everything else in software, with many medical, industrial, and other quality-critical products remaining in service for ten, fifteen, or even twenty years. While much of the quantum conversation is about servers and browsers, where you can roll out new cryptography over a lunch break, a significant proportion of embedded devices can’t be updated in the field, and run on microcontrollers with kilobytes of RAM, tight compute budgets and, often, with no modern hardware security. All of this works against a clean transition to quantum-readiness. And it collides with where regulation is heading: the Cyber Resilience Act expects even small, connected devices to ship secure and stay updatable across their supported life, which is exactly what a lot of embedded hardware was never built to do.

There’s a simple test for whether this is your problem: Mosca’s inequality. Add together how long your data or device must remain secure and how long your migration will take. If that total is longer than the time until a capable quantum computer arrives, you’re already behind.

When will quantum computing bypass my security?

Nobody can give you a firm date, and the estimates genuinely vary. But expert surveys mostly land somewhere in the 2030s, and governments have set their migration deadlines around 2030 to be safe. For a long-life embedded product, you can almost skip the guesswork: if what you ship today will still be in service in the 2030s, its secure lifetime already enters the risk window.

What this means for quality-critical sectors

The stakes are even higher for regulated, quality-critical products — medical devices, industrial control, aerospace, and defence — where lifespans run longest of all. An infusion pump or an avionics unit can be in service for thirty years. Two things push the stakes higher still:

1. A forged firmware update here doesn’t cost you data; it costs you safety. A compromised medical device, a manipulated industrial process, a safety function you can no longer trust. Authentication stops being an IT problem and becomes a safety one.
2. You already carry a duty to manage security risk through IEC 62304 and EU MDR in medical devices, IEC 62443 in industrial systems, and the incoming Cyber Resilience Act across the board. As state-of-the-art cryptography shifts towards post-quantum, that duty quietly grows to include quantum-readiness, whether or not a standard says the word yet.

So, the question isn’t only ‘will my product still be secure in a decade?’ It’s ‘can I still show it’s safe and compliant?’

Boot ROM is forever

Device authentication is where this gets most dangerous. Ship a device today with an ECDSA-only verification key in the boot ROM, and it’s perfectly safe. But it’s guaranteed to become unsafe during its service life, and you’ll never be able to fix it, because that key lives in read-only memory that can’t be changed.

The update mechanism is the worst place for this to go wrong, because it reaches every device at once. Forge a single firmware-signing key, and you can push malicious firmware to everything that key ever protected, turning one compromised key into a compromised fleet, and a compromised fleet into either a botnet or a product recall.

There’s a closing window, too. A device with updatable firmware can still be saved, but only by one final, classically signed update that installs quantum-safe verification. And it has to reach the device before classical signatures can be forged. Any device that misses that update (and with patchy update rates, there are always some) stays stuck on breakable cryptography for good. The sooner you start, the more of your devices make it through.

Which post-quantum standards are already finalised?

Formal guidance is already here. In 2024, NIST finalised its first post-quantum standards, ML-KEM (FIPS 203) for key exchange, and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures. FN-DSA, with smaller signatures suited to constrained devices, is expected to follow. For firmware and boot signing specifically, LMS and XMSS are already mature and standardised (NIST SP 800-208), and they’re a strong fit because their security rests on plain, well-understood hashing rather than newer maths.

The engineering around them isn’t finished, though. Side-channel hardening on constrained hardware is still maturing, and standards keep moving. The primitives are ready to build on; the craft of fitting them to real devices is where the work now sits.

The policy signal is explicit, too. In June 2026 the US issued an executive order, Securing the Nation Against Advanced Cryptographic Attacks, setting federal deadlines to move to the NIST standards: end of 2030 for key establishment, end of 2031 for signatures, with federal contractors pulled in on the same timeline. The EU is heading to the same place by a different road, through the Cyber Resilience Act’s demand for state-of-the-art cryptography. You don’t need a US federal contract to read the direction. Across both blocs, this has moved from ‘if’ to ‘when’.

Is post-quantum cryptography too slow for embedded devices?

Contrary to a common assumption, post-quantum cryptography is not too slow for small devices. On most modern microcontrollers, speed isn’t your problem. Size is. Post-quantum keys and signatures are measured in kilobytes, not the tens of bytes you’re used to, and that leans hard on small-SRAM parts, constrained radio links and certificate chains that were never sized for it. Fitting these schemes into a tight memory and bandwidth budget without weakening them is a real embedded engineering problem. It’s not simply a matter of dropping in a library.

The silicon industry has seen this coming and is responding. Chip vendors have started building post-quantum acceleration into new parts. STMicroelectronics’ ST54M, with its PQC hardware accelerator, is one early example. It shows where the market expects new designs to go, and it opens a hardware path that wasn’t there a couple of years ago.

Five steps to start your post-quantum migration

None of this means panic, or rewriting every product this quarter. It means a plan, and enough runway to run it. Five things:

1. Inventory your cryptography. You can’t migrate what you haven’t mapped. Find every place your products use public-key cryptography: secure boot, firmware updates, comms, device identity, and data at rest.
2. Prioritise by risk. Rank each product by how long it has to stay secure and how sensitive its data is, then work down from the top.
3. Fix authentication first. Start with secure boot and firmware signing. They’re the choices you can’t walk back later.
4. Go hybrid through the transition. Combine classical and post-quantum schemes to keep today’s proven security while you add tomorrow’s. A weakness later found in either one still leaves you covered.
5. Design for crypto-agility. Build products so the algorithm can be swapped in the field, turning the next change from a hardware respin or an unpatchable mistake into a configuration decision.

And where a device in the field simply doesn’t have headroom for post-quantum cryptography, the honest answer is often to move it to a more capable platform. Either way, better to know now than in 2032.

The decision you need to make

The quantum question for embedded isn’t ‘when does the computer arrive?’ It’s ‘what am I baking into this product today, and can I change it later?’

For anything long-lived, and anything in boot ROM, the answer is often no. That’s what makes this a decision for your current design cycle. And it’s the kind of long-view, quality-critical judgement good embedded software teams excel at.

A sensible first step

None of this needs a full migration programme to begin with. The first step is simply knowing where you stand: a crypto inventory and a per-product risk view that show how exposed each product really is, and how much time it has. That’s the kind of Bluefruit do alongside teams building for quality-critical and regulated markets. If it would help to talk yours through, we’d be glad to.