Malware in BIOS or UEFI firmware survives disk wipes and operating system reinstalls, and most endpoint tools never look at it. MITRE D3FEND names the countermeasure System Firmware Verification (D3-SFV) and defines it as "Cryptographically verifying installed system firmware integrity." It sits in the Detect tactic as a child of Firmware Verification (D3-FV), next to D3-PFV Peripheral Firmware Verification, and verifies the System Firmware artefact, which D3FEND describes as firmware on the main board that manages the initial boot process (BIOS or UEFI firmware). This card covers how D3-SFV works, the two ATT&CK techniques D3FEND relates to it, the platform features that implement it, how to prove it is running and where it stops. It is written for endpoint, infrastructure and detection engineers; the broader picture is in the Firmware and Boot Security Guide.
Key takeaways
- D3-SFV compares firmware against known-good values. D3FEND's model is simple: compute hashes of installed system firmware and compare them with precomputed values, then trigger a predefined response on mismatch.
- Verification has to come from outside the thing being verified. A compromised host cannot be trusted to report on its own firmware, so measurements anchored in a TPM or hardware root of trust and checked remotely are the reliable form.
- You need a reference list, and that is the hard part. Without vendor-published or internally captured known-good hashes per model and version, a measurement is just a number.
- The ATT&CK link is narrow and inferred. D3FEND relates D3-SFV to T1542.001 System Firmware and T1542.004 ROMMONkit through the System Firmware artefact.
- It detects; it does not prevent or recover. Pair it with signed updates, write protection and a tested recovery path, as NIST SP 800-193 does with protect, detect and recover.
D3-SFV at a glance
| Field | D3-SFV System Firmware Verification |
|---|---|
| D3FEND ID | D3-SFV |
| Tactic | Detect |
| Parent technique | Firmware Verification, D3-FV (under Platform Monitoring); sibling: Peripheral Firmware Verification, D3-PFV |
| Digital artefact | System Firmware (D3FEND: the technique "verifies" System Firmware; also known as BIOS or UEFI firmware) |
| D3FEND considerations | Requires system-provided security modules; secure hash values must be computed for the firmware |
| Typical implementation points | TPM-based measured boot with remote attestation, hardware roots of trust and boot verification in the platform, firmware integrity scanning tools, network device image verification |
| Response on failure | D3FEND: a predefined response, which may disable some devices or operations; in practice also quarantine from the network and reimaging or reflashing |
| D3FEND references | NIST SP 800-193 Platform Firmware Resiliency Guidelines; Eclypsium patent US20200074086A1 |
How it works
D3FEND's description has three parts: hashes are computed for the installed system firmware, compared with precomputed hashes to detect tampering, and a failed check invokes a predefined response. The parent technique, D3-FV, adds that a mismatch can also mean the firmware was updated with a non-current release, which is a configuration problem rather than an attack. Both outcomes are worth knowing.
NIST SP 800-193 (Final, May 2018), one of D3FEND's references, frames platform firmware resiliency as three goals: protecting against unauthorised changes, detecting unauthorised changes that occur, and recovering rapidly and securely. D3-SFV is the detection goal applied to the main board firmware.
Three ways the check is done
| Approach | How it verifies | Strength | Limitation |
|---|---|---|---|
| Measured boot with remote attestation | Firmware measurements are extended into the TPM (core firmware into PCR0) and a TPM-signed log is sent to an attestation service that compares it with expected values | Evidence is signed by hardware and evaluated off the host | Needs an attestation service and a maintained list of expected values per model and version |
| Hardware root of trust boot verification | A root of trust in the platform checks the firmware's signature before it runs and refuses or recovers on failure | Acts before the firmware executes | Set by the platform vendor; you mostly verify it is enabled and provisioned |
| Firmware read-back and comparison | A tool reads the SPI flash image or firmware volumes from a running system and compares hashes or modules with a known-good image | Can find added modules in images that still boot | Runs with high privilege on the host; a compromised host can interfere |
Microsoft describes the measured boot model for Windows: the UEFI firmware stores in the TPM a hash of the firmware, bootloader, boot drivers and everything loaded before the anti-malware app; at the end of startup a remote attestation client has the TPM sign that log with a key from a trusted attestation server, and the server decides whether the device is healthy and can, for example, limit it to a quarantine network. Microsoft is explicit that the PC cannot be trusted to self-report, and that Windows supplies the APIs while the attestation client and server come from separate tools. UEFI Secure Boot and Trusted Boot are related but different: they check signatures of the bootloader and later components, not the firmware itself. See D3-BA Bootloader Authentication for that layer.
On Linux, the fwupd project's Host Security ID (HSI) checks report platform firmware protections in levels, including BIOS Write Enable, BIOS Lock Enable, SMM BIOS Write Protect and an "Empty PCR" test at HSI-1, and a "PCR0 TPM Event Log Reconstruction" test at HSI-2, which checks that the event log replays to the value in PCR0. The fwupdmgr security command (fwupd 1.8.4 or later) prints the results with recommendations. The HSI documentation is marked as in active development, so confirm attribute names against the current page.
Network devices
D3FEND's second ATT&CK link, ROMMONkit, applies to network device firmware. ATT&CK's mitigations for T1542.004 include periodically checking system image integrity (M1047 Audit) and enabling secure boot so the device will not boot if signature validation fails (M1046 Boot Integrity). For routers and switches, D3-SFV in practice means comparing ROMMON and system image hashes with the vendor's published values and using the platform's image verification features. See the Network Device Management Plane Hardening Guide.
ATT&CK techniques and D3-SFV
Relationship type: inferred only. D3FEND relates these techniques to D3-SFV because both concern the System Firmware artefact; the D3FEND page labels the mappings "inferred, experimental" (checked November 2026). Mitigation IDs are from the ATT&CK technique pages. The last column is NHI Mgmt Group's assessment.
| ATT&CK ID | Technique (tactics) | ATT&CK mitigations listed | What D3-SFV adds (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1542.001 | Pre-OS Boot: System Firmware (Stealth, Persistence) | M1046 Boot Integrity, M1026 Privileged Account Management, M1051 Update Software | Direct: a modified firmware image or added UEFI module changes the measurement or read-back hash. ATT&CK's procedure examples include LoJax and the Hacking Team UEFI Rootkit |
| T1542.004 | Pre-OS Boot: ROMMONkit (Stealth, Persistence) | M1047 Audit, M1046 Boot Integrity, M1031 Network Intrusion Prevention | Direct where image hashes are checked against vendor values after every upgrade and reboot |
Related techniques that D3FEND does not map to D3-SFV but that share the boot chain include T1542.003 Bootkit and T1495 Firmware Corruption. See the T1542 Pre-OS Boot guide, T1495 Firmware Corruption and M1046 Boot Integrity.
Implementation steps
- Inventory firmware. Record model, firmware vendor and version for every server, endpoint and network device. Without this, no comparison is possible. See the Hardware and Firmware SBOM Guide.
- Check the platform baseline. Confirm a TPM 2.0 is present and enabled, firmware write protections are on, and the platform's boot verification is provisioned. Tools such as fwupd HSI give a quick read on Linux fleets.
- Collect known-good values. Use vendor-published hashes or signed images where available; otherwise capture measurements from a small set of freshly flashed, trusted machines per model and version.
- Turn on measured boot reporting. Feed TPM-signed boot logs to an attestation service or device health capability, starting in report-only mode.
- Pilot and tune. On a pilot ring, compare results with expected values, then run a firmware update and confirm the new expected values are loaded before the update reaches the fleet.
- Define responses. For example: unknown but vendor-signed version, raise a configuration ticket; unknown and unsigned or unexplained module, isolate and escalate under the Firmware and Bootkit Compromise Playbook.
- Plan rollback and recovery. Keep vendor recovery images and know which models support firmware recovery; a failed verification that blocks network access needs a manual override path for the service desk.
Choosing an approach
| Situation | Practical choice |
|---|---|
| Managed Windows fleet with TPM 2.0 | Measured boot with remote attestation through a device health or attestation service; act on the result in conditional access or network access control |
| Linux servers and workstations | fwupd HSI reporting plus TPM event log checks, collected centrally |
| High-value servers or forensic investigation | Add periodic firmware image read-back and comparison on isolated or test systems |
| Routers, switches and firewalls | Vendor image verification and hash checks after each upgrade, with change records |
Tools that read firmware directly need care. The CHIPSEC project, a platform security assessment framework for Windows, Linux and the UEFI shell, states that it "should only be used on test systems", because its kernel drivers give user-mode code direct hardware access and incorrect access can hang or crash the system.
How to verify it works
- Known-good test: a freshly flashed pilot device must pass; if it fails, the expected values are wrong.
- Known-change test: update firmware on a pilot device before loading the new expected value; the check must flag it. This proves the comparison is live, not cached.
- Log integrity test: confirm the attestation service rejects a boot log whose replay does not match the TPM PCR values.
- Coverage check: compare devices reporting firmware measurements against the asset inventory.
| Metric | What it shows |
|---|---|
| Share of devices sending verifiable firmware measurements | Coverage |
| Share of firmware versions in use with a known-good reference value | Whether results can be interpreted |
| Mismatches per month, split into update lag and unexplained | Signal quality and update hygiene |
| Days from vendor firmware release to expected values loaded | Whether updates create false alarms |
| Devices with firmware write protection or boot verification disabled | Platform baseline drift |
Limits, bypasses and failure patterns
- Self-reporting: trusting a host agent's own statement about firmware. Microsoft notes that rootkits can hide from the client; use hardware-signed evidence evaluated elsewhere.
- Missing reference values: measurements collected but never compared, because nobody maintains the expected list per model and version.
- Alarm fatigue after updates: firmware rollouts without matching updates to expected values produce fleet-wide mismatches that teach the SOC to ignore the alert.
- Scope gaps: system firmware verified while peripheral firmware, management controllers and network devices are not. Peripheral firmware is a separate D3FEND technique (D3-PFV).
- Detection without recovery: a confirmed mismatch with no tested reflash or replacement path leaves an infected machine in service.
- Privileged update tools left open: ATT&CK's detection guidance for T1542.001 includes firmware tools run by non-IT accounts; restrict who can run flash utilities (M1026).
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SI-7 Software, Firmware, and Information Integrity; SI-7(6) Cryptographic Protection; SI-7(9) Verify Boot Process; SI-7(10) Protection of Boot Firmware | Integrity verification of firmware with cryptographic mechanisms |
| NIST SP 800-193 | Detection guidelines for platform firmware | The resiliency model D3FEND cites |
| NIST CSF 2.0 | DE.CM-09; PR.PS-02 | Monitoring computing hardware and software; maintaining software (including firmware) by risk |
| ATT&CK mitigations | M1046 Boot Integrity; M1047 Audit; M1051 Update Software; M1026 Privileged Account Management | See M1047 Audit and M1051 Update Software |
Practitioner checklist
- Inventory firmware vendor and version for servers, endpoints and network devices.
- Confirm TPM 2.0, firmware write protection and platform boot verification are enabled.
- Maintain known-good firmware values per model and version, updated before each rollout.
- Collect TPM-signed measured boot evidence and evaluate it off the host.
- Test monthly with a known-good and a known-change pilot device.
- Define responses that separate update lag from unexplained changes.
- Verify network device images against vendor hashes after every upgrade.
- Keep firmware read-back tools on test or isolated systems only.
- Keep vendor recovery images and a tested reflash procedure.
Standards and references
- MITRE D3FEND: System Firmware Verification (D3-SFV)
- MITRE D3FEND: Firmware Verification (D3-FV)
- NIST: SP 800-193 Platform Firmware Resiliency Guidelines
- MITRE ATT&CK: T1542.001 Pre-OS Boot: System Firmware
- MITRE ATT&CK: T1542.004 Pre-OS Boot: ROMMONkit
- Microsoft Learn: Secure the Windows boot process
- fwupd: Host Security ID specification
- CHIPSEC: Platform Security Assessment Framework
Related NHI Mgmt Group resources: Firmware and Boot Security Guide · D3-PFV Peripheral Firmware Verification · Linux Secure Boot and Shim Guide · Firmware and Bootkit Compromise Playbook · MITRE D3FEND Guide