Firmware runs below the operating system, so malware that modifies it is invisible to tools that run on top, and a device's behaviour can be the only evidence left. MITRE D3FEND names this countermeasure Firmware Behavior Analysis (D3-FBA), synonym Firmware Timing Analysis, and defines it as "Analyzing the behavior of embedded code in firmware and looking for anomalous behavior and suspicious activity." It sits under the Detect tactic as a child of Platform Monitoring (D3-PM). This card is deliberately short: D3-FBA is mostly a research-grade technique, built into devices by manufacturers rather than switched on by defenders. It explains how the technique works according to D3FEND and its references, which ATT&CK techniques D3FEND relates to it, where you can realistically use it, and what to rely on instead where you cannot. It is for security architects, OT and embedded security teams and detection engineers responsible for servers and network devices.
Key takeaways
- Behaviour, not hashes. D3-FBA judges firmware by measured behaviour, for example how long a checksum computation takes or how many low-level hardware events occur, rather than by comparing an image with a known hash.
- Built in, not bolted on. D3FEND's considerations say the firmware code needs to be modified to include the monitoring function and that devices must be profiled for timing, so this is a manufacturer or integrator capability.
- Pre-OS boot is the target. D3FEND 1.6.0 infers relations to System Firmware (T1542.001), Component Firmware (T1542.002) and ROMMONkit (T1542.004).
- Not a hardware root of trust. D3FEND states the technique is not expected to be one hundred percent correct and may need tuning; treat it as a complement to measured and verified boot.
- Most teams act through procurement. The practical step is to ask suppliers what firmware integrity detection their devices provide and how its alerts reach you.
D3-FBA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FBA (d3f:FirmwareBehaviorAnalysis) |
| Tactic | Detect |
| Parent technique | Platform Monitoring (D3-PM) |
| Synonym | Firmware Timing Analysis |
| Digital artefact | Firmware (D3FEND relation: analyzes Firmware) |
| Applies to | Mutable firmware and immutable read-only memory (ROM), according to D3FEND |
| D3FEND references | ConFirm (New York University, hardware performance counters); VIPER (Carnegie Mellon CyLab, software-only attestation of peripheral firmware) |
| Effort | High; requires firmware modification and per-device profiling |
How it works
D3FEND's article describes a challenge and response design. The original firmware image is modified by injecting a monitoring component, which provides a software root of trust inside the device. A verifier sends a challenge that includes a nonce, so responses cannot be replayed. The firmware computes a checksum over all of its memory, including the nonce, and returns it. The verifier checks both the result and the time the computation took: modified firmware either produces the wrong checksum or needs extra time to fake the right one, and the timing is measured specifically for the installed device.
The two references listed by D3FEND show the range of the idea. The summaries below go no further than the abstracts D3FEND reproduces.
- ConFirm: the abstract describes a low-cost technique to detect malicious firmware modifications in embedded control systems by counting low-level hardware events during firmware execution, using hardware performance counters. The authors note that software-level techniques cannot detect malicious firmware behaviour because software relies on the firmware.
- VIPER: the abstract proposes software-only attestation protocols to verify the integrity of peripherals' firmware in x86 systems, motivated by research showing malware can infect peripheral firmware through vulnerabilities in the firmware or its update tools.
D3FEND also notes that firmware in deployed network devices is typically not analysed and monitored, which is why the technique targets devices in the field rather than images in a lab.
ATT&CK techniques D3FEND relates to D3-FBA
Relationship type: inferred only. D3FEND 1.6.0 lists no direct ATT&CK mapping for D3-FBA; the rows below are inferred because each ATT&CK technique acts on Firmware, the artefact D3-FBA analyses (checked November 2026). IDs verified against ATT&CK v20.
| ATT&CK ID | Technique | Tactics (v20) | What behavioural analysis can show |
|---|---|---|---|
| T1542.001 | System Firmware | Stealth, Persistence | Altered BIOS or UEFI code that changes timing or event counts during measured routines |
| T1542.002 | Component Firmware | Stealth, Persistence | Modified firmware on disks, network cards or other peripherals, the VIPER use case |
| T1542.004 | ROMMONkit | Stealth, Persistence | Modified ROM monitor images on network devices, the class D3FEND says is rarely monitored |
Firmware Corruption (T1495) and Rootkit (T1014) are closely related outcomes, but D3FEND does not list them as relations of D3-FBA; see MITRE ATT&CK T1495 Firmware Corruption and MITRE ATT&CK T1014 Rootkit. The parent technique is covered in MITRE ATT&CK T1542 Pre-OS Boot.
Where it is implemented
| Approach | Who provides it | What the defender does |
|---|---|---|
| Timing-based software attestation (D3FEND's described method) | Device manufacturer or integrator, who injects the monitoring code and profiles timing | Ask whether the device supports it, run the verifier, collect and alert on failures |
| Hardware event counting (ConFirm style) | Embedded and control system designers with access to performance counters | Specify it for high-assurance embedded or OT devices in design and procurement |
| Embedded monitoring code | Covered as its own D3FEND technique, D3-FEMC Firmware Embedded Monitoring Code | Deploy where the device vendor offers it |
| Image and measurement checks (complementary, not D3-FBA) | Platform features such as measured boot and firmware verification tooling | See D3-FV Firmware Verification, D3-SFV System Firmware Verification and D3-PFV Peripheral Firmware Verification |
NIST SP 800-193, Platform Firmware Resiliency Guidelines (final, May 2018), frames the wider goal as protection, detection and recovery for platform firmware, and is written both for manufacturers and for administrators and buyers using it to inform procurement. D3-FBA is one way to deliver the detection part.
Implementation steps
- Inventory firmware-bearing devices. Servers, network devices, storage controllers and OT controllers, with their firmware versions and suppliers. The Hardware and Firmware SBOM Guide covers the record.
- Ask suppliers the question. For each class, ask what runtime firmware integrity detection exists, whether it is behavioural or image based, and how results are exported (syslog, SNMP, management controller API).
- Start with verification you can run. Where behaviour analysis is not available, put firmware verification and measured boot in place first; they are cheaper and deterministic.
- Pilot behavioural checks where offered. Profile each device model in a lab, record normal timing or event ranges, then run on a small set of production devices and track false positives.
- Route alerts and plan response. A failed check means the device cannot be trusted. The Firmware and Bootkit Compromise Playbook covers isolation, reflashing from trusted media and hardware replacement.
How to verify it works
- Lab tamper test: on a test unit, install a deliberately modified but harmless firmware build from the supplier's test programme and confirm the check fails and alerts.
- Replay test: confirm the verifier rejects a recorded old response, which shows the nonce is enforced.
- Drift review: after each legitimate firmware update, confirm the timing profile was updated and no false alerts follow.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Device classes with a known firmware integrity detection method | Rising each quarter | Shows where you are blind below the OS |
| Lab tamper tests detected | 100% | Proves the check works on your models |
| False alerts after firmware updates | Close to zero | Shows profiling is maintained |
Limits and bypasses
- Tuning and false results: D3FEND says the technique is not expected to be one hundred percent correct, as a hardware root of trust would be, and may require tuning.
- Device sensitivity: timing depends on the device, so each model and sometimes each firmware version needs its own profile.
- Trust in the injected monitor: the check relies on monitoring code inside the firmware it is checking; if an attacker controls the update path, that code can be targeted too. Protect firmware update channels and signing keys.
- Coverage: few commodity devices expose this capability, so most estates will rely on image verification and procurement requirements.
Where identity fits
Firmware update paths are authenticated by machine credentials: code signing keys and management controller accounts. Those are non-human identities whose compromise lets an attacker install firmware that passes signature checks, which is exactly the case behavioural analysis is meant to catch. Inventory and rotate management controller credentials as you would any privileged service account.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 Software, Firmware, and Information Integrity | Detecting unauthorised changes to firmware |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Routing integrity results into monitoring |
| NIST SP 800-193 | Detection principle | Detecting unauthorised firmware change as part of resiliency |
| NIST CSF 2.0 | DE.CM-09 | Monitoring computing hardware and software for adverse events |
| MITRE D3FEND | D3-PM, D3-FBA | Parent and technique |
Practitioner checklist
- Inventory firmware-bearing devices with versions and suppliers.
- Ask each supplier what runtime firmware integrity detection their devices provide.
- Deploy firmware verification and measured boot where behavioural analysis is unavailable.
- Profile device models in a lab before enabling behavioural checks in production.
- Route failed checks to the SOC with a firmware compromise playbook.
- Protect firmware signing keys and management controller credentials.
- Re-profile after every legitimate firmware update.
Standards and references
- MITRE D3FEND: Firmware Behavior Analysis (D3-FBA)
- NIST: SP 800-193 Platform Firmware Resiliency Guidelines
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-7)
- Wang, Konstantinou, Maniatakos, Karri: ConFirm, Detecting Firmware Modifications in Embedded Systems using Hardware Performance Counters
- Li, McCune, Perrig: VIPER, Verifying the Integrity of PERipherals' Firmware
- MITRE ATT&CK: T1542 Pre-OS Boot
Related NHI Mgmt Group resources: Firmware and Boot Security Guide · D3-FV Firmware Verification · MITRE ATT&CK T1542 Pre-OS Boot · MITRE D3FEND Guide