Embedded Post-Quantum Security Starts Now

Think quantum computing is the next decade’s threat? Think again. If your hardware ships this year, it’s already a today problem.

It’s easy to dismiss Post-Quantum Cryptography (PQC) as a problem for the 2030s. After all, RSA and ECC are not broken today, and cryptographically relevant quantum computers are still generally expected around the 2030 to 2035 horizon.

But the standards are no longer hypothetical. NIST has already finalized ML-KEM for key establishment, ML-DSA for digital signatures and SLH-DSA for stateless hash-based signatures.

NIST expects that the two digital signature standards (ML-DSA and SLH-DSA) and key-encapsulation mechanism standard (ML-KEM) will provide the foundation for most deployments of post-quantum cryptography. They can and should be put into use now.

Source: NIST Post-Quantum Cryptography Project

Why Embedded Systems Cannot Wait

For embedded systems, that NIST statement changes the nature of the discussion. A smart meter, industrial gateway or automotive ECU deployed today may still be active well into the post-quantum era. The “harvest now, decrypt later” model is also already considered a realistic threat by cybersecurity agencies: encrypted traffic can be intercepted and stored today, then decrypted later once the required quantum capability exists.

Transitioning to PQC does not usually mean rewriting the business application. For systems already using TLS or SSH, much of the migration happens inside the cryptographic stack and protocol configuration. The harder questions are elsewhere: where asymmetric cryptography is used, whether the boot chain can evolve, whether the hardware has enough memory headroom, and whether the communication stack can tolerate larger keys, certificates and signatures.

The Three Domains of Embedded PQC

Securing an embedded device against quantum threats means looking at where cryptography actually lives in your system. In almost every architecture, it splits into three buckets:

1. Network Sessions (TLS/SSH)

This is where session keys are negotiated and data in transit is encrypted. If your devices use HTTPS, or MQTTS secured over TLS 1.3, the hard work is mostly done. PQC is already appearing in maintained SSH and TLS stacks, especially through hybrid key exchange. On platforms where both endpoints support it, deployment is often a configuration and validation exercise rather than an application rewrite.

2. Signing and Certificates

This covers firmware image validation, device identity (X.509 certificates), and cloud authentication. Post-quantum signing algorithms are standardized and available in libraries. However, their integration into certificates, firmware update formats and constrained verification paths still requires careful design, especially on smaller platforms.

3. Secure Boot and the Root of Trust

This is the trickiest domain. The immutable primary bootloader (Boot ROM) has its public key or hash burned directly into the silicon. If that silicon only understands RSA or ECDSA, it cannot magically verify a post-quantum signature. The pragmatic mitigation is to introduce PQC or hybrid verification in a secondary, updatable bootloader or in the update manifest. This improves the chain above the first boot stage, but it does not make the immutable Boot ROM itself post-quantum.

The Golden Rule: Hybrid Cryptography

Migrating to PQC does not mean replacing Elliptic Curve Cryptography (ECC) with ML-KEM or ML-DSA overnight. Instead, the industry standard is hybrid cryptography: combining a trusted classical algorithm with a newer post-quantum algorithm.

By binding both together, your system remains protected if classical ECC is broken by a future quantum computer, and it also remains protected if the newly standardized PQC algorithms suffer an unexpected mathematical vulnerability.

For product architects, there is a strict operational distinction between how we handle hybrid key exchanges and hybrid signatures.

Hybrid Key Exchange

Used in TLS 1.3 or SSH, both peers establish two independent shared secrets. The two secrets are mixed through the protocol key schedule so that the final session keys remain secure as long as at least one of the two key exchange mechanisms remains secure.

Conceptually, the key schedule looks like this:

classic_secret = ECDH(private_key, peer_public_key)
pq_ciphertext,pq_secret_client = ML-KEM.encapsulate(peer_pq_public_key)
pq_secret_server = ML-KEM.decapsulate(pq_ciphertext)

final_secret = KDF(classic_secret || pq_secret)
session_keys = HKDF(final_secret,transcript_context)

Implementation Warning !

Never invent the wire format or the transcript binding yourself. Standard protocols already define these hybrid groups. Current TLS 1.3 hybrid deployments commonly use groups such as X25519MLKEM768, pairing X25519 with ML-KEM-768.

Downgrade Warning !

A fallback mechanism like “try PQC, and if it fails, use ECC” is not hybrid cryptography. That is simply a negotiation protocol vulnerable to downgrade attacks.

Hybrid Signatures

For firmware updates and device certificates, the signer produces both a classical and a post-quantum signature over the payload. The embedded verifier must strictly enforce an “AND” logic rule:

classic_sig = ECDSA_sign(classic_private_key, hash(message))

pq_sig = ML-DSA_sign(pq_private_key, message)

valid = ECDSA_verify(classic_public_key, message, classic_sig)
     && ML-DSA_verify(pq_public_key, message, pq_sig)

If your verifier accepts either one or the other, your system is only as secure as its weakest link. Forcing both guarantees an attacker must break both math families to forge an image.

Embedded Engineering Watchouts

While the math is solid, the physical realities of microcontroller architectures introduce three distinct hurdles:

Memory Bloat (RAM & Flash): PQC keys and signatures are significantly larger than their ECC counterparts. ML-KEM and ML-DSA will demand significantly more peak stack, heap, and packet buffer space during handshakes.
Network Fragmentation: Because public keys and signatures are larger, a cryptographic exchange can easily exceed a standard network MTU. A handshake that used to fit into a single packet might now fragment across multiple packets, exposing your stack to transport reassembly bugs.
Compute Burden: PQC algorithms are computationally intensive. Do not count on hardware acceleration engines in existing microcontrollers; your CPU will be doing the heavy lifting in software. An operation that used to complete in microseconds or a few milliseconds can turn into a visible latency and power-consumption event.

The Practical Embedded PQC Checklist

When auditing your next production design, use this checklist to ensure your post-quantum strategy doesn’t create accidental vulnerabilities:

Topic	Practical Implementation Choice
Key Exchange	Prefer hybrid ECDH + ML-KEM, mixed through a KDF.
Signatures	Prefer classical signature + ML-DSA, with both required for verification.
Protocol Negotiation	Authenticate the selected algorithms to prevent downgrade attacks.
TLS / SSH	Use existing hybrid modes from maintained libraries (e.g., OpenSSH’s `mlkem768x25519-sha256` or `sntrup761x25519-sha512`). Do not design a custom handshake.
Secure Boot	In new products, prefer CPU/MCU where the immutable root of trust can verify PQC signatures. In existing products, introduce hybrid verification in later, updatable boot stages or update manifests.
Memory	Measure peak stack, heap, and packet buffers during handshake and signature verification.
Transport	Check fragmentation and reassembly. Larger keys can turn formerly small exchanges into multi-packet network sequences.
Lifecycle	Keep crypto providers replaceable. Hybrid today should not become another hard-coded algorithm trap tomorrow.

How To Start Deploying

In a majority of cases, introducing embedded PQC doesn’t have to be difficult. You probably won’t have to touch a single line of the business application with these guidelines:

For SSH: Leverage existing production mechanisms. Modern OS and enterprise distributions (like RHEL or Debian/Ubuntu updates) as well as embedded frameworks (Yocto and the like) support hybrid post-quantum key exchange natively in OpenSSH via algorithms like mlkem768x25519-sha256.
For TLS: Enforce TLS 1.3 and offload the heavy lifting. Run a TLS terminator, reverse proxy, or API gateway at your cloud edge that supports hybrid groups like X25519MLKEM768. Your firmware application layer stays identical, while the underlying transport layer gains quantum immunity.
For Proprietary Protocols: Make sure the stack is isolated from the rest of the application as it should be. Copy the architectural structure, not the wire format. Combine classical ECDH with ML-KEM, bind both public values directly into the session transcript, and use HKDF to derive the final operational keys.

The practical rule is conceptually simple: combine secrets for key exchange, require both signatures for authentication, and never implement the protocol glue casually. The cryptographic primitives (FIPS 203 and FIPS 204) are standardized and heavily reviewed. The remaining danger is usually in the system integration: downgrade negotiation, buffer sizing, transport fragmentation and root-of-trust boundaries.

Need a Second Look?

Post-quantum deployment is no longer only a cryptography topic. In embedded systems, the hard parts are often memory sizing, boot architecture, update flows, transport constraints and long-term maintainability.

Embedded Expertise helps industrial teams assess these constraints before they become fixed in hardware. We can help you review your current architecture, and ensure your firmware is ready for the field.

Enjoyed this article?
Embedded Notes is an occasional, curated selection of similar content, delivered to you by email. No strings attached, no marketing noise.