MITRE D3FEND Platform Hardening Implementation Guide: Sequencing Boot, Firmware, Storage and Configuration Controls

Hardening a host is usually run as a dozen separate projects, Secure Boot here, BitLocker there, patching somewhere else, and nobody can say whether the platform as a whole resists tampering. MITRE D3FEND groups these controls under Platform Hardening (D3-PH), a technique in the Harden tactic that covers firmware, boot logic, hardware security devices such as the TPM, kernel components, storage and physical construction. This guide treats D3-PH as one programme: what each child technique contributes, how to sequence them so each layer protects the next, how to prove they are working, and where they fail. It is written for endpoint, infrastructure and security architecture teams. Each child technique has its own deep page on this site; this page does not repeat them. For the tactic itself see the D3FEND Harden Tactic guide.

Key takeaways

• D3-PH is a family, not a single control. The D3FEND ontology places ten direct child techniques under it. Below Radiation Hardening sit Electromagnetic Radiation Hardening (with RF Shielding beneath it) and an unnumbered Particle Radiation Hardening entry.
• The children form a chain of trust. Boot integrity protects the kernel, the kernel enforces driver and configuration rules, and encryption protects data when the chain is bypassed by taking the disk away.
• Sequence matters. Measured boot and Secure Boot should be in place before you bind disk encryption keys to them, or recovery events will follow every firmware update.
• D3FEND's ATT&CK links are inferred. The D3FEND site lists a long set of related offensive techniques for D3-PH and labels them inferred and experimental: use them as test ideas, not as proof of coverage.
• Evidence is attestation and inventory, not policy documents. A hardened platform is one that can report its boot measurements, encryption state, update level and configuration owner on demand.

What D3FEND means by Platform Hardening

D3FEND defines Platform Hardening as hardening components of a platform with the intention of making them more difficult to exploit, and lists four component types: BIOS and UEFI subsystems, hardware security devices such as Trusted Platform Modules, boot process logic or code, and kernel software components. Its synonyms are System Hardening and Endpoint Hardening. The technique enables the Harden tactic and has no external references of its own; the detail lives in the children.

In practice D3-PH answers one question: if an attacker gains code execution, physical access or a supply chain foothold, how hard is it for them to persist below or beside the operating system, read data at rest, or change how the platform behaves? That is broader than the configuration baselines in the D3-ACH Application Configuration Hardening page, which deal with applications rather than the platform beneath them. For firmware-level threat modelling of embedded devices, see the MITRE EMB3D Embedded Device Threat Model Guide.

The child techniques

The table lists every technique under D3-PH in the D3FEND ontology, with D3FEND's own one-line purpose and the layer it protects. Each name links to the full page on this site.

The ontology also holds Particle Radiation Hardening, a child of D3-RH covering total ionising dose and single-event effects, which has no D3FEND ID. It matters for space, aviation and nuclear environments and rarely for enterprise estates.

How to choose and combine the children

Most organisations do not need all twelve. A useful way to decide is to group them by the threat each group answers.

Combinations that work

• Secure Boot plus measured boot: D3-BA stops unsigned boot code; D3-TBI records what actually ran so a verifier can detect a signed but unexpected component. Either alone leaves a gap.
• Measured boot plus disk encryption: binding the disk encryption key to TPM measurements means a modified boot chain cannot release the key. This is the strongest pairing in the family for laptops.
• Driver integrity plus update: D3-DLIC blocks unsigned drivers but signed, vulnerable drivers still load. Pair it with a vulnerable driver blocklist and D3-SU for driver and firmware updates.
• Configuration permissions plus update tooling: D3-SCP limits who can change the platform; the identities used by patching and management tools then become the most privileged accounts on every host.

Small and large organisations

• Small organisations: buy devices with Secure Boot and TPM 2.0 enabled from the factory, turn on full disk encryption through your device management tool, enforce automatic updates, and remove local admin rights. That covers D3-BA, D3-DENCR, D3-SU and D3-SCP with little engineering.
• Large and regulated organisations: add remote attestation for D3-TBI, a driver blocklist and code integrity policy for D3-DLIC, file-level encryption for sensitive shares, and firmware update tracking as part of D3-SU.
• OT and embedded operators: D3-HBWP and D3-PEH often matter more than disk encryption, because field devices are reachable by hand and are rarely patched. See the MITRE EMB3D Embedded Device Threat Model Guide.

Implementation sequence

The order below is an NHI Mgmt Group recommendation. It follows the protection, detection and recovery principles in NIST SP 800-193 Platform Firmware Resiliency Guidelines, and builds each layer on the one below.

1. Inventory platform capability. For every device class record firmware vendor and version, UEFI or legacy BIOS mode, Secure Boot state, TPM presence and version, and encryption state. Devices that cannot do UEFI Secure Boot or TPM 2.0 go on a replacement list.
2. Fix change control first (D3-SCP, D3-SU). Remove standing local admin, restrict who can change firmware settings (set firmware setup passwords and manage them as secrets), and get firmware and drivers into your update process. Without this, later controls can be switched off.
3. Turn on Secure Boot (D3-BA). Enable it in pilot rings by hardware model. Check that boot media, recovery tools and any third-party drivers are signed. Track certificate changes: the Secure Boot Certificate Expiry 2026 guide covers the current Microsoft certificate rollover.
4. Add measured boot and attestation (D3-TBI). Collect TPM measurements and evaluate them with a health attestation or remote attestation service. Start in report-only mode and build known-good baselines per model and firmware version.
5. Enforce driver integrity (D3-DLIC). Run kernel code integrity and the vulnerable driver blocklist in audit mode, review blocked loads, then enforce.
6. Encrypt storage (D3-DENCR, D3-FE). Bind keys to the TPM, escrow recovery keys centrally, and test recovery before wide rollout. Add file encryption for data that must stay protected after it leaves the device.
7. Add physical controls where the threat model needs them (D3-HBWP, D3-PEH, D3-RH family). Tamper-evident seals, locked ports and enclosures, write-protect jumpers on field devices, and shielding for high-assurance sites.

Testing and rollback

• Pilot by hardware model, not by department: boot failures cluster by firmware version.
• Suspend before you update: when disk encryption is bound to boot measurements, firmware and bootloader updates change the measurements. Use the encryption product's suspend or reseal step before planned updates, or expect recovery prompts.
• Keep a rollback path per layer: Secure Boot can be disabled in firmware setup, code integrity policies can return to audit mode, and recovery keys must be retrievable by the service desk out of hours.

Where identity fits

Platform hardening depends on a small set of very powerful non-human identities: the device management service that pushes encryption and code integrity policy, the patching and firmware update tooling, the attestation service, and the code-signing keys that make Secure Boot and driver signing meaningful. If any of these is compromised, the attacker can switch controls off fleet-wide or sign their own boot code. Treat signing keys and management service credentials as tier-zero secrets, keep firmware setup passwords and disk recovery keys in a managed vault with access logging, and review which accounts can change device policy. See the Secrets Management Guide.

ATT&CK behaviours D3FEND relates to Platform Hardening

D3FEND links defensive and offensive techniques through the digital artefacts both act on. For D3-PH the site lists related techniques across Persistence, Privilege Escalation, Execution, Credential Access, Initial Access, Collection, Exfiltration, Command and Control and Impact, and labels every mapping inferred and experimental. Most arrive through the children: storage-related techniques through encryption, boot-related through D3-BA and D3-TBI. The table is a selection for testing, using ATT&CK v20 IDs. D3FEND's current list still includes some IDs that ATT&CK v20 has revoked, such as the old command history logging sub-technique; those are left out here.

The child column is our reading of the shared artefacts, not a D3FEND statement. See the MITRE D3FEND Guide for how the inferred mappings are built.

Detection and measurement

Useful signals for the family: attestation failures or unexpected PCR values from a device that previously attested cleanly; Secure Boot reported off on a device that had it on; blocked driver loads, especially on servers; encryption suspended for longer than a planned maintenance window; firmware setting changes outside change windows; and recovery key retrievals, which can indicate either a support case or an attacker with physical access.

Metrics we suggest at NHI Mgmt Group (targets are examples, not standards):

1. Boot chain coverage: percentage of devices with Secure Boot on and measured boot attesting healthy.
2. Encryption coverage: percentage of laptops and removable media encrypted with escrowed recovery keys (example target 100 percent for laptops).
3. Firmware currency: percentage of devices on the latest vendor firmware for their model, and median age of the oldest firmware.
4. Driver enforcement ratio: percentage of hosts with kernel code integrity in enforce rather than audit mode.
5. Configuration ownership: percentage of hosts with no standing local administrator accounts outside the managed break-glass account.
6. Attestation drift: count of devices whose measurements left baseline in the period, and median time to resolve.

Framework mapping

Common failure patterns

• Secure Boot on, nobody checking. Without measured boot and attestation, a device that has Secure Boot switched off by an attacker or a technician looks identical in reporting.
• Encryption without tested recovery. Keys are escrowed but the recovery process has never been run at scale, so a firmware update causes an outage and pressure to weaken the control.
• Signed but vulnerable drivers. Driver signature enforcement is treated as complete when known vulnerable signed drivers can still load.
• Firmware outside patching. Operating system updates are tracked to the day, while firmware sits years behind.
• Management plane as the weak link. Hardening policies are pushed by a management service whose admin accounts lack MFA or whose signing and service credentials are poorly protected.
• Physical controls skipped where they matter. Field devices and kiosks get enterprise baselines but no enclosure, port or write-protect controls.

Practitioner checklist

• Map every D3-PH child to an owner, a tool and a coverage figure.
• Replace or isolate devices that cannot run UEFI Secure Boot and TPM 2.0.
• Remove standing local admin and protect firmware setup with managed passwords.
• Enable Secure Boot and measured boot in hardware-model rings, with attestation reporting.
• Enforce kernel code integrity with a vulnerable driver blocklist after an audit period.
• Bind disk encryption to the TPM, escrow recovery keys and rehearse recovery.
• Bring firmware, drivers and bootloaders into the update process and track currency.
• Protect signing keys and management service credentials as tier-zero secrets.
• Apply enclosure, port and write-protect controls to physically exposed devices.

Standards and references

• MITRE D3FEND: Platform Hardening
• MITRE D3FEND: TPM Boot Integrity
• MITRE D3FEND: Bootloader Authentication
• NIST: SP 800-193 Platform Firmware Resiliency Guidelines
• NIST: SP 800-147 BIOS Protection Guidelines
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Pre-OS Boot

Related NHI Mgmt Group resources: MITRE D3FEND Guide · D3FEND Harden Tactic · MITRE EMB3D Embedded Device Threat Model Guide · Secure Boot Certificate Expiry 2026 · Secrets Management Guide