Fault Injection and Glitching Attacks: Defence Guide

A device that verifies firmware, checks a PIN or protects a key can be made to skip that check if an attacker with physical access disturbs its power, clock or electromagnetic environment at the right moment. Fault injection, often called glitching, turns a correct implementation into a faulty one, and it defeats secure boot, debug locks and cryptography that are sound on paper. This guide explains the attack class at concept level, where it matters, how to detect it and, mainly, how product security teams design and evaluate devices to resist it. It is written for hardware, firmware and product security engineers, and for buyers who need to judge vendor claims about secure elements and microcontrollers. It deliberately contains no attack procedures or parameters. Passive leakage attacks are covered separately in the Side-Channel Attacks Guide.

Key takeaways

Faults break assumptions, not algorithms. Code that is logically correct can still be bypassed if a single branch, comparison or memory read can be corrupted.
Physical access is the usual precondition. Most fault injection needs the device in hand, so it matters most where the attacker owns or captures the hardware: payment cards, wallets, IoT, automotive, consoles and phones.
Software interfaces can create the same risk remotely. Where software can change voltage or clock settings, as in Plundervolt (CVE-2019-11157), fault injection does not need a lab.
Defend in layers. Combine hardware sensors and shields with fault-aware firmware (redundant checks, fail-by-default logic, flow integrity) and a response that wipes or locks secrets.
Evaluation is the only real evidence. Ask for independent evaluation results at a stated attack potential or certification level, not a "glitch-resistant" marketing claim.

How the attack works

MITRE CAPEC-624 Hardware Fault Injection describes an adversary using disruptive signals or events, or changing the device's physical environment, to cause faulty behaviour: electromagnetic pulses, laser pulses, clock glitches, temperature extremes and more. Performed in a controlled way during cryptographic operations, the resulting errors can reveal secret key information. CAPEC-625 applies the same idea to mobile devices and notes that the attack can be non-destructive, leaving no sign that keys were compromised.

At concept level, an induced fault has one of a few effects, and defences are designed around these effects rather than the injection method:

Fault effect	What goes wrong	Security consequence	Relevant weakness
Instruction skip	A CPU instruction does not execute or executes wrongly	A conditional branch in a signature, PIN or debug-lock check is bypassed	CWE-1332 Improper Handling of Faults that Lead to Instruction Skips
Data corruption	A register, bus or memory value changes	A flag reads as "verified", a counter fails to increment, a length check is wrong	CWE-1247 Improper Protection Against Voltage and Clock Glitches
Faulty cryptographic output	An intermediate value in a cipher or signature is wrong	Comparing correct and faulty outputs can leak key material (fault analysis)	CWE-1319 Improper Protection against Electromagnetic Fault Injection
State machine confusion	The device enters an unexpected state during boot or lifecycle changes	Debug or test modes become reachable	CWE-1319 notes bypass of secure JTAG and Secure Boot

The common injection families, again at concept level only:

Voltage glitching: brief disturbances of the supply voltage outside the specified range.
Clock glitching: irregular clock edges that give logic too little time to settle.
Electromagnetic fault injection (EMFI): a local transient magnetic pulse that induces faults in part of the chip, usually without opening the package.
Optical or laser fault injection: light focused on the die, typically after removing packaging, giving precise targeting at higher cost.
Environmental stress: temperature or other conditions outside the operating range.
Software-induced faults: software driving the hardware out of its safe envelope, for example through voltage and frequency scaling interfaces or memory disturbance (Rowhammer), covered by CWE-1256 Improper Restriction of Software Interfaces to Hardware Features.

Where it shows up

Product type	Asset at risk	Typical attacker	Why it matters
Smart cards, SIMs, payment and ID chips	Keys, PIN counters, credentials	Well-resourced labs, fraud groups	Long-standing target; certification schemes test for it
Hardware wallets and security keys	Seed phrases, private keys, FIDO credentials	Owner of a stolen or lost device	A single device can hold high value
Microcontrollers in IoT and industrial devices	Firmware, device identity keys, debug locks	Competitors, cloners, researchers	Firmware extraction enables cloning and fleet-wide attacks
Automotive ECUs	Immobiliser and feature-unlock logic, secure boot	Thieves, tuners	Physical access is easy for the owner
Consoles, phones and media devices	Boot chain, DRM keys	Hobbyist and commercial modders	Breaking one model's boot ROM can be unpatchable
PCs and servers with trusted execution	Enclave secrets	Privileged local software	Software-reachable voltage controls (Plundervolt)

Threat modelling question: does the attacker plausibly hold the device, and is one device's compromise worth a lab effort? A per-device unique key with no fleet-wide secret greatly reduces the payoff. See the MITRE EMB3D Embedded Device Threat Model Guide.

Impact

Secure boot bypass: unsigned firmware runs, and with it any further compromise. Where the bypass is in mask ROM, it cannot be fixed in shipped devices.
Key extraction: device identity keys, cryptographic keys or wallet seeds are recovered, allowing cloning, impersonation or theft. A device identity key is a non-human credential; once extracted it can impersonate the device to cloud services. See the IoT Device Identity with TPM and DICE Guide.
Debug re-enablement: locked debug ports are reopened, exposing firmware and memory.
Counter and limit bypass: PIN retry counters, anti-rollback counters or licence limits are defeated.
Fleet exposure: if all devices share a secret, one extraction can compromise the whole fleet.

Detection

Fault injection happens on the bench, so detection is mostly on the device itself, with some signals visible at fleet level:

On-chip sensors: voltage, clock, light, temperature and glitch detectors that trigger an alarm. CWE-1247 recommends glitch sensors at the SoC or platform level, and CWE-1319 recommends monitoring voltage and current for abnormal variations.
Integrity checks and canaries: redundant computations, error detection codes and canary values that disagree when a fault occurs.
Response: on detection, reset, increment a persistent attack counter and, past a threshold, wipe secrets or permanently lock. CWE-1332 advises identifying which secrets to wipe when faulting is detected.
Fleet telemetry: report attack counter values, unexpected resets and brown-out events with device attestation, and flag devices whose counts jump.
Back-end anomalies: the same device identity used from two places, or cloned serial numbers, can indicate extracted keys.

Detector speed matters. CWE-1332 notes that a detector that responds too slowly may act after the instruction pointer has already moved past the critical check.

Prevention and hardening

Hardware and silicon

Choose evaluated parts: secure elements and microcontrollers evaluated against physical attacks, for example PSA Certified Level 3, which protects the PSA Root of Trust against physical attackers including sophisticated side-channel and perturbation attacks, or Common Criteria evaluations of smart cards using the SOG-IS "Application of Attack Potential to Smartcards" methodology (version 3.2.1, February 2024). See the PSA Certified and SESIP Guide and the Common Criteria Evaluation Guide.
Circuit-level protection: CWE-1247 lists tunable replica circuits and special flip-flops such as Razor flip-flops, plus glitch sensors.
Shields and error codes: active shields and error detection or correction on memories and buses (CWE-1319).
Lock software control of physical parameters: restrict voltage, clock and power management registers to the most privileged software, and lock them before untrusted code runs (CWE-1256).
Fail safe outside the envelope: design for safe failure when supply voltage goes out of range (CWE-1332).

Firmware and software

Redundant checks: perform security-critical decisions twice, ideally in different ways, and compare (redundancy in space or time, with majority voting where possible).
Fail-by-default logic: handle every case explicitly and default to "deny" rather than falling through to success (CWE-1319).
Hardened booleans: represent "verified" with multi-bit values that a single bit flip cannot produce, rather than 0 and 1.
Program flow integrity: run-time checks that critical code points were reached in order and not skipped.
Random delays: make the timing of critical operations unpredictable so faults are hard to place.
Cryptographic countermeasures: verify signatures after generating them, check results before releasing output, and use libraries with documented fault countermeasures.
Limit the prize: unique per-device keys, no fleet-wide secrets in device firmware, and server-side checks that do not trust the device alone.

Rolling out in a product programme

Threat model: decide whether physical attackers are in scope for each product and asset, and record the attack potential you need to resist.
Select silicon: require evaluation evidence at that level from the supplier; check the evaluated configuration matches how you use the part.
Design review: review boot, debug unlock, key handling and update code for single points of failure. CWE-1247 warns that some protections only shift the target, so review the whole path.
Test: commission an accredited or independent lab to perform fault injection testing on prototypes. Running test labs yourself requires trained staff, authorised hardware and safety procedures; treat it as a specialist service.
Fix and retest: fix in firmware where possible; where a weakness is in ROM or silicon, record it, change the part in the next revision and limit what a compromised device can reach.
Operate: collect attack counter telemetry and handle vulnerability reports through your PSIRT. See the PSIRT Guide.

Decision guidance: a consumer IoT product holding only per-device credentials may accept basic attack potential plus fault-aware firmware. A wallet, payment device or root of trust that protects high-value or fleet-wide secrets needs a secure element evaluated at high attack potential. Where cost forbids a secure element, reduce what a compromised device can do instead.

Lessons from incidents

Most fault injection results are published as research or evaluation findings rather than breaches. One case with an official advisory illustrates the software-reachable variant: Intel advisory INTEL-SA-00289 (10 December 2019, revised 20 March 2020) covers CVE-2019-11157, an improper conditions check in voltage settings on several Intel Core and Xeon processor generations that could allow a privileged local user to escalate privileges or disclose information, rated CVSS 3.1 7.9. Mitigation was a BIOS update and an SGX TCB recovery. MITRE lists it under CWE-1256 as an example of software being able to change physical operating conditions. The lesson for product teams is that any software path to voltage or clock control is part of the fault injection attack surface and must be locked before untrusted code runs.

Common failure patterns

A single check guards everything: secure boot or debug unlock depends on one comparison and one branch, so one skipped instruction is enough.
Boolean success flags: "verified" stored as 1 and "failed" as 0, so a single corrupted bit or a skipped store turns failure into success.
Fall-through to success: error handling that ends in the success path when an unexpected value appears, the opposite of the fail-by-default coding CWE-1319 recommends.
Shared fleet secrets: one key or firmware decryption secret in every device, so a single extraction compromises the whole product line.
Trusting a datasheet claim: selecting a microcontroller for "glitch detection" without evaluation evidence, or using it in a configuration (clock source, sensor enablement) that differs from the evaluated one.
Software-reachable power controls: voltage and frequency interfaces left writable by less privileged software, as in CWE-1256.

Framework mapping

Area	MITRE reference	NIST SP 800-53 Rev. 5	Product security scheme
Attack pattern	CAPEC-624, CAPEC-625	SA-8 Security and Privacy Engineering Principles	PSA Certified Level 3, Common Criteria AVA_VAN
Glitch and EM protection	CWE-1247, CWE-1319	SC-51 Hardware-based Protection	SOG-IS attack potential for smartcards
Instruction skip handling	CWE-1332	SI-7 Software, Firmware, and Information Integrity	SESIP or PSA evaluation
Software control of hardware features	CWE-1256	SI-6 Security and Privacy Function Verification	Vendor advisories and TCB recovery
Component authenticity	CAPEC-624	SR-11 Component Authenticity	Supplier evaluation evidence

Practitioner checklist

Record in each product's threat model whether physical attackers are in scope and at what attack potential.
Require independent evaluation evidence for secure elements and microcontrollers that hold critical secrets.
Remove fleet-wide secrets from devices and use unique per-device keys.
Implement redundant, fail-by-default checks and hardened flags in boot, debug unlock and key handling code.
Lock voltage, clock and power management interfaces before untrusted code runs.
Enable on-chip sensors, persistent attack counters and a wipe or lock response.
Commission fault injection testing from a specialist lab before release and after major revisions.
Collect attack counter telemetry and route findings through your PSIRT.

Fault Injection and Glitching Attacks Guide: Designing Devices That Fail Safely