Post-quantum cryptography for embedded and IoT: secure boot, TLS and OTA

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

A practical adoption path

Do not turn on PQC everywhere and hope for the best. A healthier path looks like this:

1. Inventory every cryptographic dependency in the product.


2. Map TLS, VPN, secure boot, OTA, package signing, certificates and PKI.


3. Identify code paths that cannot be updated after manufacturing.


4. Run a Linux gateway pilot with OpenSSL 3.5 or lab tools such as Open Quantum Safe.


5. Measure ML-KEM and ML-DSA impact on real hardware.


6. Review image formats, manifests, rollback and recovery paths.


7. Define a policy for trust anchor rotation and crypto agility.


8. 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.