Post-Quantum Crypto Is Coming to BLE Devices — Here's What Your Firmware Needs Before the Deadline
Your ECDSA secure boot signature is 64 bytes. Its post-quantum replacement is 2,420 bytes. That’s not a tuning problem you solve with a compiler flag.
For years “quantum-safe” sat in the same bucket as flying cars: real someday, irrelevant this quarter. That bucket just got a date on it. NIST finalized its post-quantum standards in 2024, and the NSA’s migration timeline now names specific years.
The math isn’t the hard part; mature libraries already implement it. The hard part is that post-quantum keys and signatures are 10 to 100 times bigger than the ECC ones you’re using now, and BLE devices are the most memory-starved, payload-limited place you could try to fit them.
If you build firmware for constrained SoCs, you’re the hard case. Let’s go through what actually changes and what you can do about it now.
What Actually Got Standardized (and When)
NIST published three final standards in August 2024:
- FIPS 203 (ML-KEM, formerly Kyber**):** key encapsulation, meaning establishing a shared secret. This is your ECDH/X25519 replacement.
- FIPS 204 (ML-DSA, formerly Dilithium**):** lattice-based digital signatures. Your ECDSA/RSA replacement for things like secure boot and firmware signing.
- FIPS 205 (SLH-DSA, formerly SPHINCS+): stateless hash-based signatures. Slower and bulkier, but built on conservative assumptions, so it’s the belt-and-suspenders choice for long-lived signing.
On timelines: the NSA’s CNSA 2.0 guidance lays out staged adoption across the 2020s and into the 2030s, with software/firmware signing expected earlier than general-purpose traffic. Don’t take my dates from memory. Before you scope a roadmap, pull the current CNSA 2.0 table from nsa.gov and the migration guidance from NIST’s NCCoE project, because the milestones have shifted before and your compliance owner will want the source, not a blog paraphrase.
One thing that isn’t waiting for any deadline: harvest now, decrypt later. An attacker can record your encrypted BLE session traffic today and decrypt it once a quantum computer exists. Anything with a long confidentiality lifetime (device identity, provisioning secrets, telemetry that’s still sensitive in 10 years) is already exposed if the key exchange is classical. That’s why key exchange is the urgent surface, not signatures.
Why Are BLE Devices the Hard Case for PQC?
Because the numbers don’t fit. Look at what you’re being asked to swap in:
Algorithm | Public Key | Signature/Ciphertext | Purpose
------------------|------------|----------------------|------------------
ECC P-256 | 64 B | 64 B (sig) | Classical baseline
X25519 | 32 B | 32 B (shared) | Classical KEX
ML-KEM-512 | 800 B | 768 B (ciphertext) | PQC key exchange
ML-DSA-44 | 1312 B | 2420 B (sig) | PQC signatures
SLH-DSA-128s | 32 B | 7856 B (sig) | PQC sig (hash-based)Byte counts are from the FIPS 203/204/205 parameter tables. Confirm against the spec for the exact parameter set you pick, they vary by security level.
Three places this collides with reality on a constrained SoC.
Flash and RAM. A 2,420-byte signature has to live somewhere during verification, plus the algorithm’s working buffers and a deeper call stack than ECC ever needed. On a part with tens of kilobytes of RAM, lattice keygen and verification stack usage is something you measure, not assume.
BLE payload limits. This is the one people underestimate. A legacy advertising PDU gives you 31 bytes total, and after headers and your own framing you’re often working with far less. Hubble’s satellite-backed BLE devices work within roughly a 13-byte arbitrary payload per packet. An 800-byte ML-KEM public key against a 13-byte window means fragmenting one key across dozens of packets, with all the reassembly, ordering, and retry logic that implies. That’s a protocol design problem, not a config change. If your device only ever verifies signatures on-device and never transmits large key material over the air, you dodge most of this. If it participates in key exchange over a constrained link, plan for fragmentation from day one. Hubble’s advertising packet format docs spell out exactly how much room you’re working with.
Compute and energy. Lattice operations are generally fast, often competitive with or faster than ECC for verification, but hash-based schemes like SLH-DSA are heavy, and every cycle is battery on a coin-cell device. Benchmark before you commit.
BLE constrained payload: [~13 bytes]
ML-KEM-512 public key: [========== 800 bytes ==========]
--> requires fragmentation / multi-packet transferThe Two Firmware Surfaces That Change
Your PQC embedded firmware work splits into two surfaces with different constraints and different urgency. Treat them separately.
+------------------+ +----------------------+
| SECURE BOOT | | SESSION / KEX |
| verify only | | encaps + decaps |
| ML-DSA / SLH-DSA | | ML-KEM (hybrid) |
+------------------+ +----------------------+
low urgency HIGH urgency
(deadline-driven) (harvest-now-decrypt-later)BLE Secure Boot PQC: Signature Verification
Secure boot has one convenient property: the cost is asymmetric. Your device verifies signatures, it doesn’t sign them. Signing happens in your build pipeline on a real machine with real memory. The on-device cost is verification, and the storage cost is the public key plus the signature you ship in the image header.
That reframes the tradeoff between ML-DSA and SLH-DSA:
- ML-DSA-44: 1,312-byte public key, 2,420-byte signature, fast verification. Reasonable default for firmware verification if you can spare the signature space in your image layout.
- SLH-DSA-128s: tiny 32-byte public key, but a 7,856-byte signature and slower verification. You take that trade when you want the conservative security of a hash-based construction and you can absorb a big signature blob per image.
For most BLE devices doing signed OTA, ML-DSA is the pragmatic pick. Reserve SLH-DSA for cases where the security argument justifies the bulk.
Key Exchange: The Urgent One
Session establishment is where harvest-now-decrypt-later bites. ML-KEM handles the encapsulation, and the standards bodies explicitly endorse a hybrid approach for the interim: run X25519 and ML-KEM together, combine both shared secrets, so you’re safe if either one holds. You get classical assurance today plus quantum resistance, at the cost of shipping both sets of key material.
On silicon: a modern part like Nordic’s nRF54L15 pairs a Cortex-M33 with an integrated crypto accelerator and a flash/RAM envelope sized for this class of work, the kind of platform that can realistically host PQC alongside a BLE stack. I’m not going to quote nRF54L15 cryptography cycle counts I can’t source, and neither should any whitepaper you read. Get the numbers from your own board. Nordic, NXP, and ST all publish platform-specific PQC guidance, useful, but treat it as vendor-tuned. The architecture decisions here should stay portable across silicon so a BOM change doesn’t force a crypto rewrite.
What To Do Before the Deadline
Nobody’s asking you to rip out ECC this sprint. The goal right now is optionality: get your firmware to a state where swapping algorithms is a change, not a rebuild.
Make your crypto swappable first. If your code calls ECDSA and X25519 directly in a dozen places, that’s your real problem. Abstract algorithm choice behind an interface, sign/verify, encaps/decaps, so the call sites don’t know or care what’s underneath. This is the single highest-leverage move because it’s useful even if the timeline slips. Open-source libraries like liboqs, PQClean, and mbedTLS’s PQC support give you drop-in implementations to sit behind that interface.
Inventory where asymmetric crypto lives. Walk your firmware and list every place it appears: secure boot, provisioning, OTA update verification, session establishment, attestation. Each one migrates on its own schedule. You can’t plan what you haven’t mapped.
Benchmark on real silicon. Datasheet math lies. Pick your target part, build a small harness, and fill in this table for the parameter sets you’re considering:
Metric | Classical (ECC) | PQC (ML-KEM) | Delta
------------------|-----------------|--------------|------
Flash | | |
RAM (stack peak) | | |
Cycles / op | | |Stack high-water mark is the one that ambushes people. Measure it, don’t estimate it.
Commit to hybrid for the interim. X25519 + ML-KEM for key exchange buys you quantum resistance without betting everything on a young algorithm. It’s the endorsed path, so it’s also the easy sell to a compliance reviewer.
Plan payload fragmentation early. If large key material has to cross a constrained BLE link, design the reassembly, sequencing, and retry logic as a first-class part of your protocol. Bolting it on after you’ve discovered an 800-byte key won’t fit is the painful way to learn this.
Prioritize key exchange over signatures. Harvest-now-decrypt-later means your key exchange is exposed the moment traffic goes out. Secure boot only matters against an adversary who already has a quantum computer to forge with, so it’s deadline-driven rather than a concern for today. Fix the leak before you fix the lock.
Refactor for Crypto-Agility This Quarter
Quantum-safe IoT security won’t arrive as one heroic migration weekend. It arrives as a series of small, boring decisions: an interface here, an inventory there, a benchmark on the actual board.
The engineers who come out ahead aren’t the ones who migrate first. They’re the ones whose firmware can swap an algorithm without a rewrite, so that when the compliance date lands or the RFP demands ML-KEM, it’s a configuration change instead of a rebuild. If you’re starting from the Hubble Device SDK, that abstraction layer is a good place to draw the line. Refactor for crypto-agility this quarter, and everything else gets easier from there.
Hubble Network connects BLE devices directly to satellites, so crypto-agile firmware stays reachable no matter where it ships. See how it works →