Post-Quantum Side-Channel Attacks on ML-KEM and ML-DSA in Sovereign Hardware

Post-quantum side-channel attacks on ML-KEM and ML-DSA target the physical implementation of these lattice-based algorithms, not the mathematical hardness of the underlying problems. When a cryptographic module computes a key encapsulation or a digital signature, it leaks information through power consumption, electromagnetic emanation, timing variation, and responses to deliberate fault injection. For sovereign organisations replacing classical cryptography to satisfy GDPR, NIS-2, DORA, or national security requirements, these physical leakage channels represent a concrete and underappreciated operational risk, particularly in hardware that has received PQC firmware updates without corresponding side-channel validation.

Why Lattice-Based Algorithms Introduce New Physical Leakage Surfaces

ML-KEM (FIPS 203) and ML-DSA (FIPS 204) rely on polynomial arithmetic over structured lattices, dominated by the number theoretic transform (NTT). The NTT is computationally efficient, but its regular data-dependent memory access patterns and butterfly operations create leakage profiles that differ structurally from RSA modular exponentiation or ECC scalar multiplication.

Classical HSM countermeasures, such as base blinding for RSA or scalar randomisation for ECC, do not map directly to NTT-based schemes. The high-dimensional coefficient vectors in ML-KEM and ML-DSA expose new intermediate values during polynomial multiplication and decapsulation that existing HSM test suites were not designed to detect.

As ENISA stated in its Post-Quantum Cryptography guidance: “The transition to post-quantum cryptography is not just a matter of replacing algorithms; it requires a holistic re-evaluation of the physical security properties of every device that touches a private key.” This applies directly to HSMs that have received vendor firmware updates activating ML-KEM or ML-DSA support without independent physical security re-evaluation.

Known Attack Vectors and Their Operational Relevance to Sovereign HSMs

Four categories of physical attack are documented against PQC implementations, each with direct relevance to HSMs deployed in government, finance, and healthcare environments.

Power Analysis and Electromagnetic Emanation

Simple and differential power analysis (SPA/DPA) against NTT computations can recover secret polynomial coefficients from ML-KEM decapsulation. Electromagnetic side-channel attacks extend this to scenarios where power probing is not physically feasible, including sealed rack-mounted HSMs where an attacker with physical proximity can use a near-field probe. Thales Luna HSMs and Entrust nShield devices that have received PQC firmware updates are exposed to this risk unless the firmware applies first-order masking across all NTT butterfly stages and the updated firmware has been re-evaluated by a CMVP accredited laboratory.

Timing Attacks

Non-constant-time branches in polynomial comparison or rejection sampling routines in ML-DSA signing can leak secret nonce information through measurable timing variation, even over a network interface. ANSSI has noted in its technical guidance: “Side-channel leakage in lattice-based schemes is structurally different from RSA or ECC leakage. The high-dimensional arithmetic introduces new leakage points that existing HSM test suites were simply not designed to detect.”

Fault Injection and Glitching

Voltage glitching and clock glitching can skip integrity checks in ML-DSA signing, causing a device to output a signature computed with a predictable or biased nonce, from which the signing key can be recovered algebraically. Research into Falcon (a related lattice signature scheme) has demonstrated that a single fault during Gaussian sampling can expose the entire private key. While ML-DSA uses uniform rather than Gaussian sampling, fault attacks targeting the rejection sampling loop remain a documented risk that carries directly into sovereign HSM operations.

Resource-Constrained OT and Edge Environments Require a Separate Hardening Strategy

Server-grade HSMs can absorb the overhead of masking, shuffling, and constant-time implementations because they have dedicated cryptographic accelerators and substantial RAM. Operational technology controllers and edge devices do not share this luxury.

Signing with ML-DSA-65 on a Cortex-M4 class processor requires approximately 68 KB of RAM, as documented by the pqm4 benchmarking project. Many deployed industrial controllers, building management systems, and substation automation devices do not have 68 KB of RAM available for a signing operation alongside their application stack. This creates a forced choice between security posture and operational continuity.

For OT environments where ML-DSA-65 cannot fit, SLH-DSA (FIPS 205) offers a stateless hash-based alternative with smaller RAM requirements in its SLH-DSA-SHA2-128s parameter set, though at the cost of larger signatures and slower signing. The choice between these options must be documented and justified in the organisation’s PQC migration plan, not left to individual system integrators.

FIPS 140-3 and CMVP Certification Gaps for PQC Side-Channel Resistance

NIST finalised ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) in August 2024. The NIST Cryptographic Module Validation Program (CMVP) is the primary mechanism through which HSMs and cryptographic modules earn validated status under FIPS 140-3. However, a significant gap exists between algorithm standardisation and physical security certification.

As of mid-2024, no HSM product has a CMVP certificate that explicitly covers ML-KEM or ML-DSA with documented side-channel resistance validation. Vendors including Thales and Entrust have announced PQC-capable firmware, but firmware updates that change the cryptographic boundary of an already-validated module require submission of a new validation request or a change notice, a process that can take 12 to 24 months under current CMVP laboratory queue lengths. Sovereign procurement teams that accept a vendor’s PQC firmware update as sufficient compliance evidence, without demanding the updated CMVP certificate or a transitional evaluation report from an accredited CAVP laboratory, are accepting unverified assurance.

Procurement Criteria and Countermeasures Sovereign Operators Must Require

Given the certification gap, sovereign organisations cannot rely solely on certification status. Procurement criteria must be technically specific and demand evidence rather than vendor self-attestation.

For masking, require that the vendor demonstrates first-order masking applied to all NTT butterfly operations and to the decapsulation path of ML-KEM, with TVLA (Test Vector Leakage Assessment) results using a minimum of one million traces available for review. For shuffling, require randomisation of the processing order of polynomial coefficients during signing to prevent electromagnetic templates from being built over multiple observations. For constant-time implementation, require a signed declaration that no secret-dependent branches or memory access patterns exist in the ML-DSA rejection sampling loop, backed by a code audit from an independent laboratory. For physical shielding, require that the module meets FIPS 140-3 Level 3 physical tamper evidence requirements as a minimum, and consider Level 4 for HSMs handling long-lived root keys in environments with physical access risk.

For OT and edge procurement, additionally require that the vendor has tested the implementation against voltage and clock glitching at operating voltage margins representative of industrial power supplies, and that the firmware includes active fault detection, such as redundant computation or signature verification before output, to mitigate glitch-induced key leakage.

Incorporating Side-Channel Testing into PQC Migration Assurance

The European Commission’s ECCC Horizon call HORIZON-CL3-2026-02-CS-ECCC specifically targets high-assurance cryptographic software with emphasis on formal verification and side-channel resistance for post-quantum implementations. This call signals the regulatory direction of travel: the European framework is moving toward requiring independently verified, formally reasoned implementations rather than trusting vendor attestation. Sovereign organisations that align their PQC migration assurance process with these emerging standards will be better positioned for future regulatory audits under NIS-2, DORA, and national equivalents.

Concretely, the migration assurance process should include three stages for every cryptographic module that receives a PQC firmware update. First, a pre-deployment side-channel audit conducted by an accredited laboratory using TVLA methodology against ML-KEM decapsulation and ML-DSA signing. Second, a fault injection stress test covering voltage glitching and clock glitching at the module boundary, with documented pass or fail criteria. Third, a post-deployment monitoring commitment from the vendor to notify the organisation within 30 days of any published vulnerability in the PQC implementation, along with a remediation timeline. These requirements should be written into the service contract, not accepted as informal assurances.

For organisations operating under Swiss FADP or EU GDPR with a requirement to demonstrate technical and organisational measures, side-channel audit reports and CMVP certificates constitute the kind of documented, auditable evidence that data protection authorities and financial supervisors increasingly expect. The combination of algorithm-level compliance through FIPS 203, 204, and 205 with implementation-level assurance through side-channel testing is the only credible posture for sovereign infrastructure that must remain protected not only today but across the operational lifetime of hardware that may remain in service for a decade or more.

FAQ

Does a current FIPS 140-3 certificate for an HSM guarantee that its ML-KEM or ML-DSA implementation resists side-channel attacks?

No. FIPS 140-3 at Security Levels 1 and 2 does not require side-channel resistance testing for the PQC algorithms themselves. A module can hold a valid certificate while remaining vulnerable to power analysis against its ML-KEM or ML-DSA routines. Side-channel resistance is mandated from Level 3 upward, and the specific evaluation criteria for lattice-based algorithms within CMVP are still being defined. Procurement teams must request TVLA evidence and third-party audit reports separately.

What makes single-trace attacks particularly dangerous for ML-KEM compared to attacks on RSA or ECC?

Classical countermeasures for RSA and ECC relied on averaging effects across many power traces. ML-KEM’s NTT-based polynomial arithmetic produces distinctive leakage patterns in individual operations, enabling an attacker to recover the secret key from a single power or electromagnetic measurement. This drastically reduces the physical access time and equipment sophistication required to mount a successful attack.

Can ML-DSA or ML-KEM be deployed safely on OT edge devices with limited RAM?

Only with careful parameter selection. ML-DSA-65 requires approximately 68 KB of RAM on Cortex-M4 class hardware, which many deployed industrial controllers cannot accommodate. SLH-DSA (FIPS 205) in its small-signature parameter set or ML-KEM-512 for key encapsulation are more feasible alternatives. Any bare-metal implementation must be tested for side-channel leakage and fault injection before operational deployment, with results documented in the asset’s security baseline.

How should a CISO assess whether a vendor’s PQC firmware update for an existing HSM is safe to deploy?

Request the vendor’s TVLA test results for ML-KEM decapsulation and ML-DSA signing, the updated CMVP validation certificate or transitional evaluation report number, and evidence of constant-time implementation covering rejection sampling routines. If the vendor cannot provide these, treat the firmware update as unvalidated and limit its use to non-critical key operations until independent evidence is obtained.

What does the ECCC Horizon HORIZON-CL3-2026-02-CS-ECCC call mean for sovereign procurement?

This European Commission funding call targets high-assurance cryptographic software with formal verification and side-channel resistance for post-quantum implementations. It signals that European regulatory expectations are moving toward requiring provable, independently audited PQC implementations. Sovereign organisations should align RFP criteria with these standards now and favour vendors whose PQC firmware is submitted to or eligible for ECCC-funded validation programmes, reducing the risk of having to replace non-compliant modules when formal requirements crystallise.