Post-quantum cryptography for embedded and IoT products

Post-quantum cryptography is becoming one of the most concrete technologies for teams building embedded systems, Linux gateways and IoT devices that are expected to remain in the field for many years. In just a few months, the ecosystem has seen the first finalized NIST standards, the European transition roadmap, support in OpenSSL 3.5 and the first embedded announcements from vendors such as STMicroelectronics. PQC is no longer only a laboratory or conference topic: it is entering the real stack of connected products, updateable firmware, trust chains and long-term security infrastructure.

The important question is not only "what is post-quantum cryptography?". For an embedded team, the better question is: if my device has to live for 10, 15 or 20 years, what happens to TLS, secure boot, OTA, device certificates and signature verification when classical algorithms are no longer a sufficient long-term foundation?

In embedded products, the problem is not only communication encryption. It also involves the chain of trust: the bootloader that verifies a signed image, the firmware that validates an OTA package, the Linux gateway that opens TLS sessions to the backend, the production PKI, certificates and field maintenance processes. In the draft NIST IR 8547, NIST explicitly notes that if signature verification code cannot be updated after production, devices intended for long service lives should be designed to require quantum-resistant signatures.

What post-quantum cryptography is

Post-quantum cryptography, or PQC, is the family of algorithms designed to resist attacks performed with quantum computers while still running on classical hardware. In 2024, NIST published the first three main standards from its post-quantum initiative: FIPS 203 for ML-KEM, FIPS 204 for ML-DSA and FIPS 205 for SLH-DSA.

For embedded systems, the two names to remember immediately are ML-KEM and ML-DSA. ML-KEM, standardized in FIPS 203, is a key encapsulation mechanism used to establish a shared secret over a public channel. NIST defines three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024, with increasing security and decreasing performance. In practice, it is the natural candidate for key establishment in protocols such as TLS.

ML-DSA, standardized in FIPS 204, is the lattice-based digital signature family used to generate and verify signatures. It is the most natural contact point with secure boot, firmware signing, package signing, certificates and device identity. In the OpenSSL EVP_SIGNATURE-ML-DSA documentation, ML-DSA-44, ML-DSA-65 and ML-DSA-87 signatures have indicative sizes of roughly 2.5 KB to 4.5 KB. That detail may look small, but it matters a lot when the discussion moves to OTA manifests, signed headers and microcontrollers with limited flash.

NIST is still standardizing additional backup or alternative algorithms, but the official message is already clear: for most deployments, the first three standards are the starting point. Teams do not need to wait for the "perfect set"; they need to start preparing products and measuring the real impact.

Why PQC matters for embedded and IoT

In modern embedded systems, security does not end with a firewall, a TLS certificate or an RSA signature provisioned during manufacturing. A connected device can stay in the field for many years, receive OTA updates, change backend, be integrated into industrial plants or fall under long support cycles. The longer the product lifecycle, the riskier it becomes to design the trust chain on the assumption that classical algorithms will remain adequate for the entire life of the product.

The urgency is not only theoretical. In 2025, the European Commission published a coordinated roadmap for the transition to post-quantum cryptography. In the related communication, the EU says Member States should start the transition by the end of 2026 and that critical infrastructure should move to PQC as soon as possible, by the end of 2030.

This urgency is especially visible in network protocols. NIST expects migration to prioritize quantum-resistant key establishment, particularly to defend against "harvest now, decrypt later" scenarios in interactive protocols such as TLS and IKE. For teams designing Linux gateways, edge computers, custom routers or industrial concentrators, this is a very concrete signal: PQC first enters data channels and then, immediately after, the firmware trust chain.

The main advantage: protect the chain of trust before it becomes expensive to change

In a traditional embedded flow, many cryptographic decisions become frozen earlier than expected: certificate formats, manifest size, signing policies, build tools, bootloader structure, provisioning procedures, secure elements, backend PKI. While the product is still in the lab, change is possible. Once the device is deployed, every modification becomes more delicate and more expensive.

This is why PQC should not be seen as "new cryptography to swap in for ECC and RSA everywhere". It is better understood as a way to introduce crypto agility and protect the part that is hardest to fix later. The point is not to rewrite everything tomorrow. The point is to avoid designing a product today that will force a painful redesign of the boot chain, update policy and PKI in a few years, when constraints are already frozen in the field.

Practical PQC applications in embedded systems

In embedded engineering, PQC only becomes interesting when it leaves abstract explanations and enters four very concrete areas: TLS and networking, secure boot and firmware signing, OTA and package lifecycle, and device identity and PKI.

TLS and networking for Linux gateways and edge computers

This is the first place where the transition is already visible in real software. The OpenSSL 3.5 release notes mention support for ML-KEM, ML-DSA and SLH-DSA. The default TLS group list has also been changed to include and prefer hybrid PQC KEM groups, and the default key shares now offer X25519MLKEM768 and X25519.

For embedded Linux gateway teams, this means testing no longer has to start from old experimental forks. Part of the discussion has reached the mainstream of a foundational cryptographic library. OpenSSL also includes dedicated pages for EVP_PKEY-ML-KEM and EVP_PKEY-ML-DSA, which are useful for understanding key handling, parameters and formats.

Hybrid approaches are valuable because they show a practical transition path: keep a classical component and add post-quantum resistance. But they must be handled carefully. A hybrid solution is not automatically simpler; it increases the number of components, the testing complexity, the interoperability matrix and the possible error surface.

Secure boot and firmware signing

If there is one area where PQC speaks directly to embedded systems, it is secure boot. Secure boot relies on the ability to verify a trusted signature before executing code. For devices that will remain in the field for many years, the question shifts from "do we need PQC?" to "how risky is it to lock our boot chain onto signatures that may not be considered adequate in the future?".

ML-DSA is the natural candidate for this part of the trust chain. But it must be treated as an architectural topic, not only as an algorithm. Signatures of a few kilobytes can affect headers, manifests, image formats, partitions, recovery paths and validation processes. That is not a reason to stop; it is a reason to start designing and measuring carefully.

OTA, package signing and product lifecycle

In an OTA flow, PQC does not only change the signature algorithm. It can change artifact size, update metadata, rollback policy, version compatibility and the memory budget reserved for verification. In its 2025 announcement on PQC for embedded systems, STMicroelectronics explicitly connects its post-quantum assets to three clear embedded use cases: firmware update, secure boot and authentication mechanisms.

This confirms that the embedded entry point for PQC will not be networking alone. It will also be firmware lifecycle. For a connected product, OTA and secure boot are not separate modules: they are parts of the same trust chain.

Device identity, certificates and PKI

Another practical front is PKI. The Open Quantum Safe ecosystem documents tools for experimenting with post-quantum key exchange and authentication in TLS, along with integrations based on OpenSSL providers. For an embedded team, this is especially valuable in the lab and during prototyping: it exercises the painful part of migration, namely certificates, tooling and interoperability, before the final product rollout is decided.

PQC is not only a data center technology

One of the most common misunderstandings is that PQC mainly concerns servers, cloud platforms and large appliances. In reality, the embedded supply chain is moving with real intent. STMicroelectronics has announced post-quantum algorithms integrated into general-purpose MCUs, secure microcontrollers and automotive microcontrollers, as well as software libraries for STM32 developers.

The memory trade-offs are also real. In tests published by wolfSSL on embedded platforms, ML-KEM and ML-DSA show different stack and heap profiles. The data in Optimizing Post-Quantum Algorithm Memory Usage on Embedded Systems suggests that ML-KEM tends to have a more predictable profile, while ML-DSA can require more attention, especially for heap usage and configurations aimed at reducing stack pressure.

The practical message is clear: the KEM is often the first realistic PQC entry point on constrained hardware; signatures require more attention to latency, memory and artifact formats.

Typical architecture of an embedded PQC solution

A well-designed embedded PQC solution does not place a "magic algorithm" in one location. It separates the problem into blocks: session establishment, signatures, certificates, build toolchain, provisioning and memory budgeting. The table below summarizes the main areas to evaluate in a real product.

PQC and controlled integration in embedded Linux

For an embedded Linux gateway, the professional path is not "turn on PQC everywhere and see what happens". The right path is controlled integration in the build and release process. OpenSSL 3.5 makes it possible to start with real tests on the target; Open Quantum Safe tools are very useful in the lab for TLS and X.509 interoperability.

In production, however, development images, test images and production images should be clearly separated, with an explicit decision about which algorithms and groups are actually enabled. The same logic applies to firmware and boot chains: the point is not only "support ML-DSA", but to decide where keys and trust anchors live, how signing policy is versioned, how the backend PKI is migrated and how fallback or rollback can be managed without creating an impossible compatibility maze.

pqc_embedded_strategy:
  linux_gateway_dev:
    openssl_3_5_tested: true
    hybrid_tls_groups_evaluated: true
    oqs_lab_interop_used: true
    x509_pqc_test_chain_created: true

  firmware_and_boot:
    signature_verifier_path_mapped: true
    manifest_size_impact_checked: true
    trust_anchor_update_policy_defined: true
    rollback_compatibility_reviewed: true

  production_rollout:
    only_required_algorithms_enabled: true
    legacy_fallback_policy_defined: true
    stack_heap_flash_measured_on_target: true
    release_artifacts_versioned: true

When PQC can create value in an embedded product

PQC creates the most value when the product is connected, updateable, expected to live in the field for a long time and genuinely dependent on certificates, secure boot, OTA or secure protocols. The higher the cost of physical intervention or late boot-chain redesign, the more valuable early PQC planning becomes.

It is especially relevant for Linux gateways, edge appliances, industrial products installed at customer sites, devices with remote updates and product lines that must be supported for a long time. In these product classes, PQC is not just "extra security"; it is a way to reduce the risk of ending up with a chain of trust that is hard to migrate after the regulatory, technological and market context has already moved.

Where caution is still needed

PQC is not automatically the right choice for every product. On very small devices, extremely constrained MCUs, minimal images or aggressive real-time requirements, the memory, latency and design complexity impact can outweigh the immediate benefit. Benchmarks and vendor data show that feasibility exists, but they also show that signatures can have costs and variability that must be taken seriously.

Hybrid approaches also require caution. They can be useful as a transition bridge, but they increase complexity, cost and implementation risk. The goal is not to "put PQC everywhere"; the goal is to understand where it creates measurable value and where it is better to prepare the design, introduce crypto agility and wait for more mature support.

Classical, hybrid and post-quantum cryptography: practical differences

The right choice depends on the device role. Today a Linux gateway can often start from hybrid TLS testing; a boot chain or firmware signing flow may require a more cautious but deeper evaluation of signatures and lifecycle.

Technical checklist for evaluating PQC on embedded and IoT

Before introducing PQC into an embedded product, it is worth performing a real audit. The objective is not only to check whether a library supports ML-KEM or ML-DSA, but to understand whether the whole architecture can evolve without becoming fragile.

pqc_embedded_audit:
  lifecycle:
    expected_field_life_checked: true
    long_term_confidentiality_needs_checked: true
    non_updatable_signature_verifier_identified: true

  protocols:
    tls_or_vpn_usage_mapped: true
    device_authentication_paths_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:
    target_library_selected: true
    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
    backend_compatibility_checked: true
    release_and_support_workflow_documented: true

Suggested adoption plan

The best strategy is almost always gradual: inventory, proof of concept, measurement on the real target, controlled integration and only then rollout. This matches both the tone of NIST guidance and the uneven maturity of the ecosystem across embedded Linux, vendor libraries and very small microcontrollers.

flowchart TD
    A["Cryptographic inventory of the product"] --> B["TLS, VPN and secure channels"]
    A --> C["Secure boot and firmware signing"]
    A --> D["OTA, manifests and rollback"]
    A --> E["PKI, certificates and device identity"]

    B --> F["Evaluate ML-KEM or hybrid groups"]
    C --> G["Evaluate ML-DSA and signature formats"]
    D --> H["Measure artifact and memory impact"]
    E --> I["Verify provisioning and trust anchors"]

    F --> L["Benchmark on the real target"]
    G --> L
    H --> L
    I --> L

    L --> M["Controlled rollout with crypto agility"]

The diagram above is an operational summary of the healthiest path: map first, experiment second, measure third, deploy last. Not the other way around.

The business value of PQC in embedded products

For a company building connected devices, PQC can become a competitive advantage not because it is fashionable, but because it reduces the risk of redesigning the most sensitive parts of digital trust too late: boot chain, update path, PKI and secure protocols. NIST notes that full integration will take time, so teams that start earlier with audits and realistic measurements have more room for an orderly transition.

On the European side, the Cyber Resilience Act does not specifically require ML-KEM or ML-DSA, but it creates a product-security and lifecycle framework in which manufacturers must take long-term security seriously. In this context, the ability to update and evolve the product cryptographic architecture becomes far more relevant.

FAQ on PQC and embedded systems

Do we need to change everything immediately?

No. Official sources encourage teams to start the transition now, but not to replace every algorithm overnight. The priority is understanding where the risk is highest: TLS and channels with long-term confidentiality needs, code signing, secure boot, PKI and products with long field lifetimes.

Does ML-KEM replace ECDH?

Conceptually, it is the natural reference for new post-quantum key establishment, but in the real world the transition often passes through hybrid solutions and gradual compatibility. OpenSSL 3.5 already supports hybrid groups and key shares, but these mechanisms must be tested inside specific protocols and stacks instead of copied indiscriminately into every part of the architecture.

Does ML-DSA make sense for secure boot and firmware signing?

Yes, it is one of the most natural use cases. Firmware, OTA manifest and software package signatures are critical parts of the trust chain. However, the impact on signature size, verification time and image formats must be measured on real hardware.

Is PQC really feasible on MCUs?

Yes, but with concrete trade-offs. Embedded implementations are maturing, and some vendors are already bringing PQC support to microcontrollers and dedicated libraries. The right question is not whether it is possible in absolute terms, but whether it is sustainable on the specific target in terms of stack, heap, flash, latency and power.

Can I run real tests on embedded Linux today?

Yes. OpenSSL 3.5 includes support for ML-KEM, ML-DSA and SLH-DSA, while Open Quantum Safe remains very useful in the lab for prototyping, TLS interoperability and certificate testing. This makes embedded Linux gateways a natural starting point for serious, measurable PoCs.

Does the Cyber Resilience Act already require PQC?

No, it does not prescribe specific algorithms of this kind. But it does create a product security and lifecycle framework that makes updateable systems, maintainable digital trust and less rigid cryptographic choices much more important.

Useful technical references

• NIST - Post-Quantum Cryptography Project
• NIST - First 3 Finalized Post-Quantum Encryption Standards
• NIST FIPS 203 - ML-KEM
• NIST FIPS 204 - ML-DSA
• NIST FIPS 205 - SLH-DSA
• NIST IR 8547 - Transition to Post-Quantum Cryptography Standards
• European Commission - Roadmap for the transition to PQC
• OpenSSL 3.5 - Release notes
• OpenSSL - EVP_PKEY-ML-KEM
• OpenSSL - EVP_PKEY-ML-DSA
• OpenSSL - EVP_SIGNATURE-ML-DSA
• Open Quantum Safe - TLS
• Open Quantum Safe - X.509
• STMicroelectronics - PQC for embedded systems
• wolfSSL - Optimizing PQC memory usage on embedded systems

Conclusion

Post-quantum cryptography is no longer a topic to keep "for later". For teams building Linux gateways, updateable firmware, secure boot, OTA and long-lived products, it is already an architectural issue.

The right move is not to change everything impulsively. The right move is to understand where the risk is real, introduce crypto agility, test the available stacks, measure memory and latency on the target, and prepare the product chain of trust before it becomes too rigid to modify.

Handled with method, PQC is not a trend. It becomes part of the strategy that keeps an embedded product credible, updateable and defensible over time.