Electronics Guide

Shor's Algorithm and Public-Key Cryptography

The primary quantum threat to current cryptographic systems comes from Shor's algorithm, developed by mathematician Peter Shor in 1994. This quantum algorithm can efficiently solve the mathematical problems that underpin most widely used public-key cryptography, specifically integer factorization and the discrete logarithm problem.

RSA encryption relies on the difficulty of factoring large composite numbers into their prime factors. Classical computers require super-polynomial time to solve this problem for sufficiently large numbers, but a quantum computer running Shor's algorithm can accomplish this in polynomial time. Similarly, elliptic curve cryptography (ECC), which bases its security on the elliptic curve discrete logarithm problem, is equally vulnerable to quantum attack.

This means that RSA, ECC, Diffie-Hellman key exchange, and related algorithms will become insecure once sufficiently powerful quantum computers exist. For embedded systems with long deployment cycles, data encrypted today could be stored and decrypted in the future when quantum computers become available, a threat model known as "harvest now, decrypt later."

Grover's Algorithm and Symmetric Cryptography

Grover's algorithm provides a quadratic speedup for searching unstructured spaces, which in the worst case reduces the effective security level of symmetric cryptographic algorithms by half. A 256-bit AES key, for example, would provide roughly 128 bits of security against an idealized quantum adversary, although the enormous circuit depth and the difficulty of parallelizing Grover's algorithm make this an optimistic bound for any realistic attacker.

The mitigation for symmetric cryptography is relatively straightforward: doubling the key size preserves the original security margin. AES-256 is widely considered to remain secure against quantum attacks where 128-bit security is acceptable. For hash functions, collision resistance is affected less than preimage resistance, but moving from SHA-256 to SHA-384 or SHA-512 provides a comfortable margin for applications requiring higher assurance.

Timeline Considerations

While large-scale fault-tolerant quantum computers capable of breaking current cryptography do not yet exist, the timeline for their development is uncertain. Published estimates range from roughly 10 to 30 years, but the long certification cycles, deployment timelines, and operational lifespans of embedded systems mean that migration to quantum-resistant cryptography must begin now.

Regulatory timelines are more concrete than the technical ones and are what most engineering programs actually plan against. NIST IR 8547, first issued as a public draft in November 2024, sets out a transition schedule in which classical public-key algorithms at the 112-bit security level, such as RSA-2048 and ECC over P-256, are deprecated after 2030, and all quantum-vulnerable public-key cryptography is disallowed in NIST-conformant systems after 2035. The National Security Agency's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) is stricter still for national security systems, requiring exclusive use of post-quantum algorithms for software and firmware signing by 2030 and for most other functions by 2033.

Critical infrastructure, automotive systems, industrial control systems, and medical devices designed today may still be in operation when cryptographically relevant quantum computers become available. A power meter, an implantable device, or a rail signaling controller certified in 2027 may well outlive the 2035 disallowance date. The transition to post-quantum cryptography requires careful planning, testing, and phased deployment that can take many years to complete.

Standardization Process

The National Institute of Standards and Technology (NIST) initiated a post-quantum cryptography standardization process in 2016, evaluating candidate algorithms through multiple rounds of public scrutiny and cryptanalysis. In August 2024, after an eight-year effort, NIST published its first finalized post-quantum standards as FIPS 203, FIPS 204, and FIPS 205, providing a foundation for widespread adoption.

The standardization process considered not only cryptographic security but also performance characteristics, implementation complexity, and suitability for various deployment scenarios including resource-constrained embedded systems. It also demonstrated the value of open cryptanalysis: several candidates that reached late rounds were broken during the competition, including the isogeny-based SIKE, which fell to a classical attack in 2022. That history is the main argument for algorithm diversity and for designing systems that can change algorithms later.

NIST classifies parameter sets by security category, defined by comparison with the effort required to attack a symmetric primitive. Category 1 is comparable to a key search on AES-128, category 3 to AES-192, and category 5 to AES-256; categories 2 and 4 are pegged to collision search on SHA-256 and SHA-384. Vendor documentation uses these category numbers heavily, so mapping them to the familiar AES levels is a useful habit when comparing parameter sets.

ML-KEM (FIPS 203, from Kyber)

ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism derived from the CRYSTALS-Kyber algorithm and standardized as FIPS 203, is the primary standard for key encapsulation mechanisms (KEMs). It is based on the Module Learning With Errors (MLWE) problem, a variant of lattice-based cryptography that offers strong security guarantees and efficient implementation.

Key characteristics of ML-KEM include relatively compact key and ciphertext sizes compared to other post-quantum alternatives, fast key generation and encapsulation operations, and straightforward constant-time implementation. The algorithm is well-suited for embedded systems, with implementations requiring modest memory and computational resources.

ML-KEM is available in three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, at NIST security categories 1, 3, and 5 respectively. Their sizes scale roughly linearly with the module rank. ML-KEM-512 uses an 800-byte encapsulation key and a 768-byte ciphertext; ML-KEM-768 uses 1,184 and 1,088 bytes; ML-KEM-1024 uses 1,568 and 1,568 bytes. Decapsulation keys are 1,632, 2,400, and 3,168 bytes. For most embedded applications, ML-KEM-768 provides an appropriate balance of security and performance, and it is the parameter set chosen for the hybrid groups now deployed in TLS.

Two implementation details matter in practice. ML-KEM uses implicit rejection: a decapsulation that fails integrity re-encryption returns a pseudorandom shared secret derived from the ciphertext and a stored rejection value rather than an error, so applications must not treat "success" as proof of a valid ciphertext. ML-KEM is also an IND-CCA2 KEM rather than a general-purpose encryption scheme, so it establishes a 256-bit shared secret that is then fed to a key-derivation function and used with a symmetric cipher such as AES-256-GCM.

ML-DSA (FIPS 204, from Dilithium)

ML-DSA, the Module-Lattice-Based Digital Signature Algorithm derived from CRYSTALS-Dilithium and standardized as FIPS 204, is the primary standard for digital signatures. Like ML-KEM, it relies on lattice-based cryptography, specifically the Module Learning With Errors problem combined with the Short Integer Solution problem.

ML-DSA signatures are larger than classical ECDSA signatures but remain practical for most applications. The algorithm offers fast signing and verification operations, making it suitable for embedded systems that require digital signature functionality for firmware updates, secure boot, or authenticated communications.

Three parameter sets are specified: ML-DSA-44, ML-DSA-65, and ML-DSA-87, mapping to NIST security categories 2, 3, and 5. Their signatures are 2,420, 3,309, and 4,627 bytes, with public keys of 1,312, 1,952, and 2,592 bytes. The middle variant, ML-DSA-65, is recommended for most applications requiring strong security without excessive signature sizes; CNSA 2.0 mandates ML-DSA-87 for national security systems.

ML-DSA signing uses Fiat-Shamir with aborts: the signer samples a masking vector, computes a candidate signature, and rejects it if any coefficient falls outside a safe range, repeating until a candidate passes. The number of iterations is data-dependent, so signing time is variable, and a naive implementation can leak information through that variation. FIPS 204 specifies a hedged mode that mixes fresh randomness with a deterministic derivation, which is the sensible default for embedded signers because it neither depends entirely on the quality of the device's entropy source nor exposes a purely deterministic signer to fault attacks that solve for the private key by signing the same message twice.

SLH-DSA (FIPS 205, from SPHINCS+)

SLH-DSA, the Stateless Hash-Based Digital Signature Algorithm derived from SPHINCS+ and standardized as FIPS 205, provides a hash-based signature scheme that serves as a conservative alternative to lattice-based signatures. Its security relies solely on the properties of cryptographic hash functions, which are well-understood and have been extensively analyzed.

FIPS 205 defines twelve parameter sets, spanning three security categories, two hash families (SHA-2 and SHAKE), and two optimization targets denoted s for small signatures and f for fast signing. The trade-off between them is stark. SLH-DSA-SHA2-128s produces a 7,856-byte signature, while SLH-DSA-SHA2-256f produces 49,856 bytes; the s variants sign an order of magnitude more slowly than the f variants in exchange for roughly half the signature size. Public keys, by contrast, are tiny: 32, 48, or 64 bytes.

The costs are therefore signature size and signing time, not key storage or verification. Signing invokes the underlying hash function hundreds of thousands of times, so on a microcontroller without hash acceleration a single SLH-DSA signature can take seconds. Verification is far cheaper, which suits the asymmetry of firmware signing: signing happens once, in a build system or an HSM, while verification happens on every boot of every device.

SLH-DSA is particularly valuable for root-of-trust applications, certificate authorities, and firmware signing where the conservative security posture outweighs the size overhead. Because its security rests only on the properties of its hash function, it is the natural hedge against a future cryptanalytic advance against structured lattices.

FN-DSA (FIPS 206, from FALCON)

NIST selected a fourth algorithm, FALCON, in 2022 and is standardizing it as FN-DSA in FIPS 206. As of 2026 that standard remains in draft. FN-DSA is built on NTRU lattices over the class of problems known as short integer solution over NTRU, and it produces markedly smaller signatures than ML-DSA: roughly 666 bytes at the category 1 parameter set and roughly 1,280 bytes at category 5, against 2,420 and 4,627 bytes for the corresponding ML-DSA sets.

Those compact signatures are attractive for bandwidth-constrained embedded links, but FN-DSA carries a serious implementation caveat that explains its slower standardization. Signing requires Gaussian sampling over a lattice using floating-point arithmetic, and a constant-time, side-channel-resistant implementation of that sampler is difficult on hardware whose floating-point unit has data-dependent timing, or absent entirely on the many Cortex-M0 and Cortex-M3 class parts. Verification does not need the sampler and is comparatively simple. A common pattern is therefore to verify FN-DSA signatures on the device while signing on a well-characterized host or security module.

Memory Requirements

Post-quantum cryptographic algorithms generally require more memory than their classical counterparts. Public keys, private keys, ciphertexts, and signatures are all larger, and the algorithms themselves often require substantial working memory for intermediate computations.

For ML-KEM-768, encapsulation keys are 1,184 bytes and ciphertexts are 1,088 bytes, compared to 32 to 64 bytes for ECC equivalents. ML-DSA-65 signatures are 3,309 bytes, roughly fifty times the 64-byte ECDSA signature over P-256. These increased sizes affect storage requirements, transmission bandwidth, and RAM usage during cryptographic operations.

Working memory is often the harder constraint. Published pqm4 measurements for ML-KEM-768 on a Cortex-M4 show speed-optimized implementations consuming roughly five to seven kilobytes of stack per operation, while stack-minimized variants of the same algorithm fit in under three kilobytes at a cost in speed; portable reference code can exceed ten kilobytes. On a part with 20 KB of SRAM, the difference between those implementations decides whether the algorithm fits at all. ML-DSA needs more still, because rejection sampling holds several polynomial vectors live at once.

Embedded systems with limited RAM must therefore treat stack budgeting as a design input rather than an afterthought. Default RTOS task stacks of one or two kilobytes will overflow, so the cryptographic work usually runs on a dedicated task with a measured high-water mark and a stack guard region. Flash storage for keys and certificates also grows: a certificate chain that occupied a few hundred bytes with ECDSA can reach several kilobytes with ML-DSA, which matters on parts where the entire firmware image budget is measured in hundreds of kilobytes.

Computational Performance

While post-quantum algorithms are generally more computationally intensive than classical alternatives, the performance impact varies significantly by algorithm and operation. ML-KEM and ML-DSA are designed to be efficient and perform well even on resource-constrained microcontrollers.

On a typical Arm Cortex-M4 microcontroller, an optimized ML-KEM-768 key generation, encapsulation, or decapsulation costs on the order of a million clock cycles, which is a few milliseconds at 100 to 200 MHz and comfortably faster than RSA-2048 key generation or private-key operations on the same part. ML-DSA verification is similarly practical. ML-DSA signing time is variable because of rejection sampling, so systems should budget against a worst-case iteration count rather than an average.

SLH-DSA sits at the opposite end. Its verification cost is modest, but signing is dominated by hundreds of thousands of hash compressions and can take seconds on a microcontroller without a hash accelerator, which effectively rules out on-device SLH-DSA signing for interactive workloads.

The specific performance characteristics depend heavily on implementation optimization. Leveraging hardware acceleration for arithmetic operations, carefully optimizing memory access patterns, and using platform-specific instructions can significantly improve performance. On Cortex-M4, the DSP multiply-accumulate instructions accelerate the Number Theoretic Transform substantially over portable C, which is why the optimized pqm4 implementations outperform reference code by a wide margin. Energy per operation usually tracks cycle count closely, so for battery-powered and energy-harvesting devices the number of handshakes per day, not the latency of any single one, is the figure that determines feasibility.

Side-Channel Resistance

Embedded systems are often deployed in environments where attackers may have physical access, making resistance to side-channel attacks essential. Post-quantum algorithms introduce new attack surfaces that require careful mitigation.

Timing attacks exploit variations in execution time that depend on secret data. Constant-time implementations that avoid data-dependent branches and memory accesses are essential. The lattice-based algorithms in ML-KEM and ML-DSA include operations that must be carefully implemented to avoid timing leaks.

The KyberSlash vulnerabilities disclosed in late 2023 and early 2024 illustrate how subtle these leaks are. Several widely used reference implementations divided a secret-dependent value by the modulus during ciphertext compression. On processors whose division instruction takes a variable number of cycles, or that lack a hardware divider entirely and fall back to a software routine, that single operation leaked enough timing information to recover the private key over repeated decapsulations. The algorithm was not at fault; a routine arithmetic idiom was. A related result the same year showed a compiler introducing a secret-dependent branch into source code that was constant-time as written, which is why constant-time properties must be verified on the compiled binary for the actual target and toolchain, not assumed from the C.

Power analysis attacks measure the power consumption of a device during cryptographic operations to extract secret information. Countermeasures include masking, shuffling operations, and adding random delays. The polynomial arithmetic in lattice-based cryptography requires specific countermeasures different from those used for classical algorithms, and masking is markedly more expensive here than for AES: splitting the secret polynomial into shares must be carried out through both the arithmetic operations of the NTT and the Boolean operations of the hashing and sampling steps, and the conversions between arithmetic and Boolean masking dominate the overhead. First-order masked ML-KEM implementations commonly cost several times the unmasked version.

Electromagnetic emanation attacks and fault injection attacks also pose threats. Fault attacks are especially relevant to signatures, where injecting a fault during ML-DSA signing, or persuading a deterministic signer to sign the same message twice under different fault conditions, can expose the private key. Comprehensive side-channel protection requires a layered approach combining algorithmic, implementation, and hardware countermeasures, and it is the main reason many products place post-quantum operations inside a certified secure element rather than in application firmware.

Random Number Generation

Post-quantum algorithms have stringent requirements for random number generation. Poor-quality randomness can catastrophically compromise security, making the implementation of robust random number generators critical.

Hardware random number generators (HRNGs) provide entropy from physical sources, but their output must be properly conditioned and health-tested. NIST SP 800-90B governs the assessment of entropy sources and requires continuous health tests, including repetition-count and adaptive-proportion tests that detect a stuck or degraded noise source at runtime. Deterministic random bit generators (DRBGs) specified in SP 800-90A, such as HMAC-DRBG and CTR-DRBG, expand limited entropy into larger quantities of pseudorandom output.

ML-KEM and ML-DSA key generation each consume a small, fixed amount of true randomness, which has a useful storage consequence. Because FIPS 203 derives an entire ML-KEM key pair deterministically from a 64-byte seed, a constrained device may store that seed rather than the 2,400-byte ML-KEM-768 decapsulation key and regenerate the key on demand, trading a modest amount of computation for a large reduction in protected non-volatile storage. The same seed must then be guarded exactly as the private key would be.

For resource-constrained embedded systems, accumulating sufficient entropy can be challenging. The classic failure is a device that generates its identity key on first boot, before its ring-oscillator entropy source has accumulated enough samples, producing keys that repeat across a production run. Careful design must ensure that random number generators are properly seeded before any key generation occurs, that health-test failures block cryptographic operations rather than being logged and ignored, and that entropy is maintained across power cycles when necessary.

liboqs

The Open Quantum Safe (OQS) project provides liboqs, an open-source library implementing a variety of post-quantum algorithms including the NIST-standardized algorithms. While primarily targeting desktop and server environments, liboqs can be adapted for embedded use with appropriate optimizations.

The library provides a consistent API across different algorithms, simplifying the development of crypto-agile applications that can switch between algorithms as standards evolve or vulnerabilities are discovered. The project itself cautions that liboqs is intended for prototyping and evaluation rather than production deployment, and that it does not carry the side-channel hardening or validation a fielded product requires. It is well suited to interoperability testing and to measuring the size and latency budget a design must absorb, after which production code typically moves to a vendor library or a validated module.

Cryptographic module validation is a practical gate for regulated products. NIST's Cryptographic Algorithm Validation Program covers ML-KEM, ML-DSA, and SLH-DSA, and modules seeking FIPS 140-3 validation must exercise those algorithms against the program's test vectors. Teams working toward validation should confirm the certification status of a vendor's post-quantum implementation early, because it constrains the choice of library far more than performance does.

PQClean and pqm4

Several implementations target embedded systems specifically. PQClean provides clean, portable reference implementations suitable as a starting point for embedded ports, with each scheme isolated and consistently structured. The pqm4 project builds on PQClean to provide implementations optimized and benchmarked for Arm Cortex-M4 microcontrollers, demonstrating practical performance on resource-constrained devices.

Vendors of secure microcontrollers and security ICs are increasingly providing post-quantum algorithm support in their firmware libraries and hardware accelerators. These implementations often include side-channel countermeasures and certification for security standards.

TLS and Protocol Integration

Post-quantum algorithms are being integrated into security protocols like TLS. Hybrid key exchange mechanisms combine classical and post-quantum algorithms to provide security against both classical and quantum adversaries during the transition period; the X25519MLKEM768 group, for example, is now widely deployed in TLS 1.3 and is enabled by default in major browsers and content delivery networks. It concatenates an X25519 share with an ML-KEM-768 share, so a compromise of either primitive alone does not compromise the session.

The size consequence is immediate: a hybrid key share grows the TLS ClientHello from a few hundred bytes to well over a kilobyte, which pushes it past a single TCP segment on typical paths. Middleboxes that mishandle a multi-packet ClientHello were a real source of connection failures during early deployment, and embedded stacks with fixed handshake buffers must be sized accordingly.

For embedded systems using TLS for secure communications, libraries such as wolfSSL and Mbed TLS have added post-quantum support. The increased handshake sizes and computational requirements may require protocol-level optimizations such as session resumption to minimize overhead. Constrained networks feel this most acutely: an IEEE 802.15.4 physical-layer frame carries at most 127 bytes, so a single 3,309-byte ML-DSA-65 signature spans dozens of 6LoWPAN fragments, and a DTLS handshake carrying a full post-quantum certificate chain can require hundreds. Where a single lost fragment forces retransmission of the whole message, that is a reliability problem as much as a bandwidth one. Mitigations include raw public keys instead of certificates, certificate compression, suppressing intermediate certificates that the peer already holds, and pre-shared key modes that avoid the public-key exchange entirely on subsequent connections.

Arithmetic Accelerators

The core operations in lattice-based cryptography involve polynomial arithmetic, particularly the Number Theoretic Transform (NTT) used for efficient polynomial multiplication. The NTT is the finite-field analogue of the fast Fourier transform: it converts multiplication of degree-255 polynomials from a quadratic operation into a pointwise product flanked by two transforms. ML-KEM and ML-DSA both fix their parameters, a 256-coefficient ring with a prime modulus of 3,329 and 8,380,417 respectively, so that the transform is efficient, which is precisely why hardware accelerators for NTT computation can improve performance and reduce energy consumption so substantially.

Below dedicated accelerators sit cheaper options. Modern Cortex-M4 and Cortex-M33 cores provide DSP multiply-accumulate instructions that process the butterfly operations efficiently, and application-class cores add SIMD units. Modular reduction is the inner-loop cost, and implementations rely on Montgomery and Barrett reduction, or on Plantard arithmetic on 32-bit parts, to avoid an actual division instruction. Dedicated cryptographic coprocessors that expose NTT and sampling primitives are emerging in security-focused parts, and RISC-V vendors have proposed custom instruction extensions for the same purpose. The accelerator microarchitectures themselves, including number-theoretic transform datapaths and sampler blocks, are treated in Hardware Acceleration for Post-Quantum Cryptography.

Hash Function Acceleration

Post-quantum algorithms make extensive use of hash functions, particularly SHA-3 (Keccak) and its SHAKE variants. Hardware acceleration for these functions, available in some security-focused microcontrollers, provides significant performance benefits.

The SHAKE extendable-output functions are particularly important for ML-KEM and ML-DSA, where they are used for key generation, sampling, and other operations. Efficient SHAKE implementation or acceleration directly impacts overall algorithm performance, and for hash-based SLH-DSA the cost of hashing dominates almost entirely.

Secure Elements and HSMs

Hardware Security Modules (HSMs) and secure elements provide isolated environments for cryptographic operations with built-in side-channel protections. These devices are increasingly adding support for post-quantum algorithms.

For embedded systems requiring high security assurance, offloading post-quantum cryptography to dedicated secure hardware provides both performance benefits and security advantages. The secure element handles key storage, random number generation, and cryptographic operations in a protected environment.

Cryptographic Agility

Cryptographic agility, the ability to change cryptographic algorithms without significant redesign, is essential for long-lived embedded systems. Systems should be designed to allow algorithm updates through firmware updates or configuration changes.

This requires abstracting cryptographic operations behind well-defined interfaces, allocating sufficient resources for larger algorithm requirements, and establishing secure update mechanisms. Protocol negotiation mechanisms should allow endpoints to select mutually supported algorithms.

In embedded practice, agility is limited less by software architecture than by decisions frozen in silicon and in wire formats. Concretely, this means avoiding fixed-width fields sized for a 64-byte ECDSA signature and using length-prefixed or tagged encodings instead; provisioning more than one key slot in one-time-programmable memory so a second root key can be activated later; reserving flash and RAM headroom for larger credentials before the board is built; and identifying keys and signatures by an algorithm identifier rather than by position. A product whose message format cannot express a 3,309-byte signature is not agile no matter how cleanly its cryptographic layer is abstracted.

Agility also has a limit worth stating plainly. A boot ROM verifier and the immutable root key it trusts cannot be changed after tape-out, so the first stage of a secure boot chain must be conservative from the outset. Designs commonly resolve this by keeping the ROM verifier simple and hash-based, and by giving the second stage, which is updatable, responsibility for the algorithms most likely to change.

Hybrid Approaches

During the transition period, hybrid cryptographic schemes that combine classical and post-quantum algorithms provide defense-in-depth. If either the classical or post-quantum algorithm is broken, the combined scheme remains secure.

For key encapsulation, hybrid schemes combine the shared secrets from both classical and post-quantum KEMs through a key-derivation function. The combiner must be constructed so that the result is secure as long as either input is, which in practice means feeding both shared secrets, together with the transcript or the ciphertexts, into a single KDF invocation rather than exclusive-ORing them. For signatures, hybrid schemes may use dual signatures, where both are transmitted and both must verify, or composite constructions that bind the pair into one algorithm identifier so that no verifier can be tricked into accepting only the classical half.

The cost is real and should be counted: a hybrid handshake performs two key exchanges and transmits two key shares, and a dual-signed image carries two signatures. On a constrained radio link that overhead can exceed the post-quantum algorithm's own. Opinion is divided on how long hybrids should persist. They are the prudent default while post-quantum implementations are young, but every hybrid deployment also doubles the code that must be maintained and eventually retired, and NIST's own guidance permits pure post-quantum use of the standardized algorithms.

Phased Deployment

Migration to post-quantum cryptography should follow a phased approach. Initial phases focus on inventory and assessment, identifying all cryptographic assets and their quantum vulnerability. Subsequent phases involve implementing cryptographic agility, testing post-quantum algorithms, and gradually deploying hybrid and pure post-quantum solutions.

For embedded systems, the update mechanisms themselves must be secured with quantum-resistant cryptography. Secure boot chains, firmware signing, and update authentication should transition early to prevent attackers from compromising update mechanisms and blocking future migrations.

Secure Boot and Firmware Updates

Secure boot implementations should transition to post-quantum signature verification to ensure that only authorized firmware can execute. Root keys stored in immutable memory should use post-quantum algorithms, potentially with hybrid schemes for additional assurance. Hash-based signatures such as SLH-DSA, or their stateful counterparts LMS and XMSS standardized in NIST SP 800-208, are often favored for this role because their security rests only on hash functions. CNSA 2.0 goes further and requires LMS or XMSS specifically for software and firmware signing, reflecting the same conservatism.

Stateful schemes carry an operational hazard that the stateless ones do not. LMS and XMSS consume a one-time key with every signature, and signing twice with the same one-time key can expose the private key outright. SP 800-208 therefore constrains where the state may live and how it must be updated, and in practice this means keeping the signing key and its counter inside a hardware security module that will not roll back, never restoring the signing key from a backup, and never running two signing instances from one key. The device that verifies the signature is unaffected by any of this; the burden falls entirely on the build and release infrastructure.

The verification side favors hash-based schemes for a different reason. A boot ROM is fixed at tape-out and cannot be patched, so whatever verifier it contains must remain trustworthy for the life of the product. A verifier that needs only a hash function is small, easy to audit, and has no dependence on a lattice assumption that might be revised. The cost is signature size: an SLH-DSA-128s signature adds nearly 8 kilobytes to every image, and a stateful LMS signature is comparable, which must be budgeted in flash alongside the image itself.

Firmware update mechanisms must accommodate larger signatures and potentially longer verification times. Update image sizes may increase due to larger signatures, affecting storage and transmission requirements, and devices that verify a signature before every boot rather than only at install time will see the verification cost on every reset.

Device Authentication

Device identity and authentication mechanisms using public-key cryptography require migration to post-quantum alternatives. Certificate chains will be larger, and the verification process may require more memory and time. A conventional three-certificate chain built on ECDSA occupies well under a kilobyte; the same chain with ML-DSA-65 keys and signatures runs to roughly fifteen kilobytes, which must be stored on the device, transmitted on every unresumed connection, and held in RAM during parsing.

Device identity is also long-lived by construction. An initial device identifier provisioned at manufacture may be expected to remain valid for the life of the product, which places it squarely inside the migration window. Manufacturers shipping devices today face a choice between provisioning post-quantum identity keys now, at a cost in storage and provisioning time, and provisioning classical keys with a credible field path to replacing them later.

For constrained IoT devices, lightweight alternatives to full certificate-based authentication are often preferable: raw public keys, which omit the certificate wrapper entirely; certificate formats with compact encodings rather than verbose ones; and symmetric or pre-shared key authentication for device-to-gateway links, which is already quantum-resistant when the keys are long enough and can confine public-key operations to the gateway's uplink.

Secure Communications

TLS connections using post-quantum key exchange will have larger handshake messages. Network protocols may need adjustment to accommodate increased packet sizes, and connection establishment may take longer.

Session resumption and connection persistence become more important to amortize the increased handshake overhead. Pre-shared key modes with post-quantum key establishment can reduce per-connection overhead.

Long-Term Data Protection

Data that must remain confidential for extended periods should be protected with post-quantum encryption now, even if the threat from quantum computers is years away. The harvest-now-decrypt-later threat model makes immediate action necessary for sensitive data.

Key management systems should plan for algorithm transitions, ensuring that encrypted data can be re-encrypted with new algorithms as needed while maintaining access throughout the transition.

Functional Testing

Post-quantum implementations require thorough functional testing using known-answer tests (KATs) provided by algorithm specifications and reference implementations. Interoperability testing with other implementations ensures correct protocol behavior.

Edge cases and error conditions must be carefully tested. Invalid inputs, truncated messages, and malformed keys should be handled gracefully without revealing sensitive information through error messages or timing differences.

Performance Benchmarking

Comprehensive performance benchmarking on target hardware is essential for understanding the impact of post-quantum cryptography on system performance. Measurements should include operation latency, throughput, memory usage, and energy consumption.

Performance testing should cover representative use cases, including cold-start scenarios, sustained operation, and peak-load conditions. The results inform capacity planning and help identify optimization opportunities.

Security Evaluation

Side-channel analysis should be performed on implementations before deployment. This includes timing analysis, power analysis, and electromagnetic analysis to identify information leakage. Specialized equipment and expertise are required for comprehensive side-channel evaluation.

Fault injection testing verifies that implementations behave safely under abnormal conditions. Voltage glitching, clock manipulation, and laser fault injection can reveal vulnerabilities in security-critical code paths.

Additional Standardization

NIST and other standards bodies continue to evaluate additional post-quantum algorithms. Schemes founded on different mathematical assumptions provide diversity and backup options if lattice-based schemes prove vulnerable. In March 2025 NIST selected the code-based HQC algorithm as a backup key-encapsulation mechanism to ML-KEM, with a draft standard to follow and finalization targeted for 2027. HQC is not a drop-in replacement in constrained designs, because code-based key encapsulation carries substantially larger keys and ciphertexts than ML-KEM; it is best understood as insurance against a future break of structured lattices rather than a default choice. NIST also continues to run an on-ramp competition for additional signature schemes.

Code-based cryptography, isogeny-based cryptography, and multivariate cryptography offer alternative foundations, though each has its own history: several multivariate candidates were broken during the NIST rounds, and the isogeny-based SIKE was broken outright in 2022. That record argues for treating any single assumption as provisional. While current standards center on lattice-based and hash-based schemes, the cryptographic landscape may evolve as research continues, which is precisely the case for building cryptographic agility into products now.

Hardware Evolution

Semiconductor vendors are developing dedicated hardware acceleration for post-quantum algorithms, and secure elements and secure microcontrollers advertising ML-KEM and ML-DSA support have begun to reach the market. As this support becomes standard, the implementation burden shifts from writing hardened cryptographic code to selecting and integrating a validated part.

These devices typically combine an Arm Cortex-M or comparable core with accelerators for the Number Theoretic Transform and for SHA-3, protected key storage, a certified entropy source, and side-channel countermeasures evaluated against a recognized protection profile. For a design team, the practical questions are which parameter sets a part supports, whether its post-quantum implementation is covered by the part's security certification or only by the vendor's claims, and whether firmware can be updated to add algorithms later.

Protocol Standards

Standard protocols like TLS, IPsec, SSH, and others are being updated to support post-quantum algorithms. These updates will propagate to embedded protocol stacks, enabling transparent post-quantum security for networked embedded systems.

Industry-specific protocols in automotive, industrial, and medical domains are also beginning to address quantum resistance, often with extended timelines reflecting the long certification and deployment cycles in these sectors.