Eight Steps for Post-Quantum Cryptography Adoption in Embedded Systems

Embedded products with multi-decade lifecycles demand early cryptographic planning. This eight-step adoption path outlines how teams can integrate post-quantum standards into secure boot, TLS, and OTA updates.

Connected embedded products often remain in the field for 10, 15, or even 20 years, locking in cryptographic choices at design time. NIST's finalized post-quantum standards, including ML-KEM and ML-DSA, necessitate a structured transition for these long-lifecycle devices. OpenSSL 3.5 now supports these algorithms, indicating a shift from research to practical implementation for secure boot, TLS, and over-the-air (OTA) updates.

The challenge for embedded teams is not merely adopting new algorithms, but integrating crypto agility into architectures that are notoriously difficult to update post-deployment. The following eight-step path details a framework for this transition, focusing on strategic integration rather than an immediate, wholesale replacement of existing cryptographic primitives.

Long-term Cryptographic Commitments

Embedded products inherently commit to cryptographic choices earlier than other software systems. This includes bootloader verification logic, firmware image formats, OTA package signatures, device certificates, and production Public Key Infrastructure (PKI). Once a device is deployed, altering these foundational elements becomes expensive, often requiring a carefully designed migration strategy. The core value of post-quantum planning lies in introducing crypto agility before a product's architecture becomes too rigid, rather than attempting to replace all RSA and ECC instances overnight.

NIST-Standardized Algorithms

Two primary post-quantum algorithms are critical for embedded teams to recognize: ML-KEM and ML-DSA. ML-KEM (Module-Lattice-based Key Encapsulation Mechanism) is designed for establishing shared secrets, making it particularly relevant for TLS and similar protocols. ML-DSA (Module-Lattice-based Digital Signature Algorithm) is a digital signature scheme, crucial for secure boot, firmware signing, package signing, and device identity. For Linux gateways, ML-KEM often serves as the initial entry point due to the relative ease of testing and upgrading TLS stacks compared to immutable boot chains. ML-DSA, while highly relevant for firmware and boot flows, demands more meticulous engineering considerations, including signature sizes, verification times, and image layout.

Architectural Integration Points

Post-quantum cryptography impacts several key areas within an embedded architecture. For TLS and networking, the changes involve hybrid groups, new key establishment mechanisms, and library updates, allowing gateways and edge devices to begin testing immediately. Secure boot requires post-quantum readiness for signature verification, a critical component that is difficult to modify after deployment. OTA updates will necessitate new formats for manifests, package signing, and rollback policies to maintain update reliability and security. PKI, including certificates, provisioning, and trust anchors, requires a migration plan as device identity represents a long-term product dependency. Finally, memory budget considerations—stack, heap, flash, and latency—must be measured on target hardware; theoretical papers are not a substitute for real-world testing.

Eight-Step Adoption Playbook

A structured approach is essential for integrating post-quantum cryptography. The recommended eight-step path avoids a broad, untested deployment:

1. Inventory every cryptographic dependency in the product. This includes all algorithms, key sizes, and protocols used across the entire system.
2. Map TLS, VPN, secure boot, OTA, package signing, certificates, and PKI. Understand where each cryptographic primitive is used and its criticality.
3. Identify code paths that cannot be updated after manufacturing. These are the most critical areas for early PQC integration.
4. Run a Linux gateway pilot with OpenSSL 3.5 or lab tools such as Open Quantum Safe. This allows for early experimentation and performance measurement in a more flexible environment.
5. Measure ML-KEM and ML-DSA impact on real hardware. This step quantifies performance, memory, and power consumption.
6. Review image formats, manifests, rollback, and recovery paths. Ensure these critical components can accommodate new signature schemes and key sizes.
7. Define a policy for trust anchor rotation and crypto agility. Establish how cryptographic primitives can be updated or replaced over the product's lifespan.
8. Move only the justified parts into production. Prioritize PQC integration based on threat models and long-term security requirements.

WHAT WE'D CHANGE

The outlined eight-step path provides a logical sequence for PQC adoption, but several areas warrant deeper consideration for practical implementation. The fifth step,

Pull quote: “”