D3-FV Firmware Verification: Hash Baselines, Attestation and Proving Firmware Is Untouched

Firmware runs before the operating system and below every endpoint agent, so a tampered or outdated image is invisible to most security tooling unless something checks it on purpose. MITRE D3FEND names that check Firmware Verification (D3-FV) and defines it as "Cryptographically verifying firmware integrity." It sits under the Detect tactic as a child of Platform Monitoring (D3-PM) and has two children of its own: System Firmware Verification (D3-SFV) for BIOS and UEFI, and Peripheral Firmware Verification (D3-PFV) for devices such as disks, network cards and controllers. This card covers the parent technique: how hash-based verification works, which ATT&CK techniques D3FEND relates it to, how to build and run a baseline programme across both firmware classes, and how to prove it works. Platform specifics live in the two child pages. It is written for detection engineers, endpoint and infrastructure teams, and builds on the Firmware and Boot Security Guide.

Key takeaways

• Verification is comparison. D3FEND describes computing cryptographic hashes of system and peripheral firmware and comparing them with precomputed values for the identified firmware; everything else in the programme exists to make that comparison trustworthy.
• A mismatch has two meanings. D3FEND says a mismatch may mean tampering or an update to a non-current release, so the same check finds implants and configuration drift.
• The baseline is the hard part. D3FEND's considerations are hash computation and storage of precomputed hashes; without a maintained, protected reference set the check proves nothing.
• Do not trust the host to vouch for itself. A compromised machine can lie about its own firmware, so the strongest designs read measurements from a TPM or another root of trust and judge them on a separate server.
• D3FEND relates it to Pre-OS Boot. The D3FEND page lists inferred relations to System Firmware (T1542.001), Component Firmware (T1542.002) and ROMMONkit (T1542.004).

D3-FV at a glance

How it works

D3FEND's description is short: cryptographic hash values are computed for system and peripheral firmware and compared against precomputed hash values for the identified firmware. A mismatch "may indicate that the firmware may have been tampered with or updated with a non-current release indicating a misconfiguration for the system." A working programme has four parts.

• Identify: know which firmware is present. Each device model, component and firmware version needs its own reference, so the check starts from an inventory down to component level.
• Reference: build the precomputed hash set. Sources are the vendor's published release hashes or signed release packages, a hash taken from a known good reference unit, or a golden measurement recorded at provisioning. The D3-PFV entry in D3FEND adds that trust baselines need to be generated for specific devices and that changes to trusted configurations must be managed across the enterprise.
• Measure: read the installed image and hash it. The reading can be taken by software on the host, by the platform during boot into a TPM, or offline by reading the flash chip directly.
• Compare and respond: compare with the reference and act on mismatches. The D3-SFV entry notes that a failed check typically invokes predefined responses, which may disable some devices or operations.

Who reads the firmware matters

Software running on a compromised host can be fed false data. Microsoft's description of Measured Boot makes the point directly: rootkits hide their presence, so "you can't trust the client to tell you whether it's healthy." With Measured Boot the UEFI firmware stores hashes of the firmware, bootloader and boot drivers in the TPM; the TPM signs the log with a key supplied by an attestation server, and the server decides whether the device is healthy and can grant full or quarantine network access. Microsoft notes this requires UEFI 2.3.1 and a TPM, and that the attestation client and server come from other tools. The same principle applies on any platform: the measurement should come from a root of trust and be judged somewhere the attacker does not control. NIST SP 800-193, which D3FEND cites, frames platform firmware resiliency as protect, detect and recover; D3-FV is the detect part.

ATT&CK techniques D3FEND relates to D3-FV

Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-FV. Its page shows relations inferred through the Firmware artefact and labels them "inferred, experimental" (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.

The D3FEND page shows the Pre-OS Boot rows under both Persistence and Stealth. The T1495 and T1014 rows come from artefact relations in the D3FEND ontology file. Attacker-side detail is in MITRE ATT&CK T1542 Pre-OS Boot, MITRE ATT&CK T1495 Firmware Corruption and MITRE ATT&CK T1014 Rootkit.

Where it is implemented

Tools and features are listed by class and, where named, alphabetically. Naming is not a recommendation.

For BIOS and UEFI specifics see D3-SFV System Firmware Verification; for disks, NICs and other components see D3-PFV Peripheral Firmware Verification. Server management controllers need their own treatment, covered in Server BMC Security.

Implementation steps

1. Inventory to component level. For each hardware model, list system firmware and every peripheral that carries updatable firmware, with current versions. A hardware and firmware bill of materials, as described in the Hardware and Firmware SBOM Guide, is the natural format.
2. Define the approved set. For each component, record which versions are approved and where each reference hash comes from: vendor release data, a reference unit, or provisioning-time measurement. Store the set in a protected, version-controlled location with change control.
3. Choose the reading method per class. Use TPM-based measurement and attestation where the platform supports it; use host tooling where it does not; reserve offline reads for investigations and reference units.
4. Run in report-only mode first. Collect readings for a full update cycle without enforcement. Expect many mismatches at first: most will be unapproved but genuine vendor versions, which is the misconfiguration finding D3FEND describes.
5. Tie it to change management. Each approved firmware update must add its new reference hash before rollout, otherwise every update looks like tampering.
6. Add responses in steps. Start with alerts and tickets; later move high-assurance groups to conditional access or network quarantine on attestation failure, as Measured Boot designs allow.
7. Plan rollback. Keep the previous approved image and its hash available, so a failed update can be reverted without the device falling out of compliance in a way nobody can explain.

How to verify it works

• Known-bad test: on a lab unit, install an older but genuine vendor firmware version that is not on the approved list, and confirm the mismatch is reported and routed. This tests the pipeline without making a malicious image.
• Attestation negative test: on a lab unit, change a measured boot setting (for example, turn off Secure Boot) and confirm the attestation server marks the device unhealthy.
• Coverage audit: compare the device inventory with devices reporting firmware readings in the last 30 days; unreported devices are unverified, not clean.
• Reference audit: sample the reference set and confirm each hash traces to a recorded source and approval.

Limits, bypasses and failure patterns

• Trusting a compromised reader: a host-based check on a machine with a firmware rootkit can return the expected hash. Use root of trust measurements and remote judgement where assurance matters.
• Baselines that lag updates: if reference hashes are added after rollout, analysts learn to ignore mismatches, and a real implant hides in the noise.
• Whole-image hashes that change for benign reasons: firmware regions such as variable stores change during normal operation; hashing the whole flash blindly gives constant mismatches. Measure the code regions and measurements the platform defines.
• Peripheral blind spots: many teams verify system firmware only. Components such as disks and network cards also run firmware, which is the gap T1542.002 targets.
• Verification without recovery: detecting a bad image is half the job. NIST SP 800-193 pairs detection with recovery; know how each model is reflashed from a trusted source, as covered in the Firmware and Bootkit Compromise Playbook.
• Running test tools in production: deep assessment frameworks are built for test systems, and CHIPSEC's documentation warns against deploying it on production end-user systems because its drivers expose hardware access.

Framework mapping

Related countermeasures

• Firmware Embedded Monitoring Code (D3-FEMC): a monitor inside the firmware that watches it at runtime; see D3-FEMC Firmware Embedded Monitoring Code.
• Firmware Behavior Analysis (D3-FBA): behaviour rather than bytes; see D3-FBA Firmware Behavior Analysis.
• Bootloader Authentication (D3-BA): prevents unsigned boot code from running in the first place; see D3-BA Bootloader Authentication.
• Platform Monitoring (D3-PM): the parent technique; the D3FEND overview is in the MITRE D3FEND Guide.

Practitioner checklist

• Inventory system and peripheral firmware per hardware model, with versions.
• Keep a protected, change-controlled reference hash set with a recorded source for every entry.
• Add the reference hash for each approved update before it rolls out.
• Prefer TPM-based measurement and remote attestation over host self-reporting.
• Run report-only for a full update cycle before enforcing responses.
• Treat every unexplained mismatch as a possible implant until investigated.
• Track devices with no recent reading as unverified.
• Keep deep assessment tools on test and reference systems.
• Document how each model is reflashed from a trusted image.

Standards and references

• MITRE D3FEND: Firmware Verification (D3-FV)
• NIST: SP 800-193 Platform Firmware Resiliency Guidelines
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-7)
• Microsoft Learn: Secure the Windows boot process (Measured Boot)
• fwupd: Host Security ID specification
• fwupd: fwupdmgr command reference
• CHIPSEC: Platform Security Assessment Framework

Related NHI Mgmt Group resources: Firmware and Boot Security Guide · D3-SFV System Firmware Verification · D3-PFV Peripheral Firmware Verification · Linux Secure Boot and Shim Guide · MITRE D3FEND Guide