Post-quantum cryptography is no longer just a research topic. It is starting to affect the way embedded teams design TLS, secure boot, OTA, firmware signing, device identity and long-term product maintenance.
NIST has finalized the first post-quantum standards. OpenSSL 3.5 now includes ML-KEM, ML-DSA and SLH-DSA support. The European roadmap points toward a coordinated transition, and embedded vendors are already moving PQC into MCU and firmware workflows.
For connected products that may stay in the field for 10, 15 or 20 years, this is not abstract security theater. It is architecture.
Why embedded teams should care
Embedded products freeze cryptographic choices earlier than many teams expect:
- bootloader verification logic
- firmware image and manifest formats
- OTA package signatures
- device certificates
- production PKI
- secure elements and trust anchors
- TLS or VPN libraries in Linux gateways
- update and rollback policies
Once the device is deployed, changing those choices becomes expensive. Sometimes it becomes almost impossible without a carefully designed migration path.
That is the real value of post-quantum planning: not replacing RSA and ECC everywhere overnight, but introducing crypto agility before the product becomes too rigid.
ML-KEM and ML-DSA in plain terms
The two names embedded teams should recognize first are:
- ML-KEM: a key encapsulation mechanism for establishing shared secrets, especially relevant to TLS and similar protocols.
- ML-DSA: a digital signature scheme, relevant to secure boot, firmware signing, package signing, certificates and device identity.
For Linux gateways, ML-KEM is often the first practical entry point because TLS stacks can be tested and upgraded more easily than immutable boot chains.
For firmware and boot flows, ML-DSA is very relevant but needs more careful engineering. Signature sizes, verification time, image layout and manifest formats all matter.
Where PQC enters an embedded architecture
| Area | What changes | Why it matters |
|---|---|---|
| TLS and networking | Hybrid groups, new key establishment, library updates | Gateways and edge devices can start testing now |
| Secure boot | Signature verification may need post-quantum readiness | Boot chains are hard to change after deployment |
| OTA | Manifests, package signing and rollback policies may need new formats | Update reliability and security are part of the same trust chain |
| PKI | Certificates, provisioning and trust anchors need migration planning | Device identity is a long-term product dependency |
| Memory budget | Stack, heap, flash and latency must be measured | Papers and release notes are not a substitute for target testing |
A practical adoption path
Do not turn on PQC everywhere and hope for the best. A healthier path looks like this:
- Inventory every cryptographic dependency in the product.
- Map TLS, VPN, secure boot, OTA, package signing, certificates and PKI.
- Identify code paths that cannot be updated after manufacturing.
- Run a Linux gateway pilot with OpenSSL 3.5 or lab tools such as Open Quantum Safe.
- Measure ML-KEM and ML-DSA impact on real hardware.
- Review image formats, manifests, rollback and recovery paths.
- Define a policy for trust anchor rotation and crypto agility.
- Move only the justified parts into production.
Example checklist
pqc_embedded_audit:
lifecycle:
expected_field_life_checked: true
non_updatable_signature_verifier_identified: true
protocols:
tls_or_vpn_usage_mapped: true
certificates_and_pki_inventory_done: true
firmware_chain:
secure_boot_flow_reviewed: true
ota_manifest_and_signature_format_reviewed: true
rollback_and_recovery_paths_verified: true
implementation:
hybrid_transition_need_evaluated: true
stack_heap_flash_measured_on_real_target: true
latency_variance_measured: true
operations:
trust_anchor_rotation_plan_available: true
crypto_agility_requirements_defined: true
release_and_support_workflow_documented: true
When PQC makes sense
PQC planning is most useful when the product is:
- connected
- updateable
- deployed for a long time
- dependent on secure boot, OTA, certificates or secure networking
- expensive to access physically
- subject to compliance or long support windows
That makes Linux gateways, edge appliances, industrial IoT devices and remotely maintained firmware platforms natural candidates for early evaluation.
Where to be careful
PQC is not automatically the right move for every MCU or every firmware build.
Very constrained devices may have strict limits around stack, heap, flash, latency or power. Hybrid approaches can help with migration, but they also add complexity and testing cost. The goal is not to put post-quantum algorithms everywhere. The goal is to know where they reduce real product risk.
Final takeaway
Post-quantum cryptography is becoming part of embedded product architecture. The smartest move today is not panic migration; it is inventory, measurement and crypto agility.
Teams that understand their boot chain, OTA process, PKI and field lifecycle now will have a much easier transition later.
Canonical source: Post-quantum cryptography for embedded and IoT: secure boot, TLS and OTA
Silicon LogiX helps teams review embedded Linux, secure boot, firmware signing, OTA and security architecture for connected products.
