D3-BA Bootloader Authentication: Blocking Bootkits and Proving Secure Boot Works

Code that runs before the operating system loads can switch off every security control the operating system later starts, so the first piece of software a machine runs has to be checked before it runs. D3-BA Bootloader Authentication is the MITRE D3FEND countermeasure for that check: D3FEND defines it as "Cryptographically authenticating the bootloader software before system boot" and gives "Secure Boot" as its synonym. It sits in the Harden tactic as a child of Platform Hardening, and D3FEND models it as a technique that authenticates the Boot Loader artefact. This card explains what D3-BA blocks, the single ATT&CK technique D3FEND relates it to, how it is implemented on UEFI platforms, how to prove it is on and current, and how real bootkits have got past it. It is for endpoint, platform and detection engineers; the wider programme is in the Firmware and Boot Security Guide.

Key takeaways

• D3-BA is Secure Boot. Firmware verifies the signature of each boot component against allowed and revoked lists before passing control to it.
• D3FEND relates it to one ATT&CK technique. T1542.003 Bootkit, inferred because a bootkit may modify the Boot Loader that D3-BA authenticates.
• Signed is not the same as safe. A vulnerable boot manager that is still trusted can be loaded by an attacker, so the revocation list (dbx) is as important as the allow list.
• Verification has two parts. Confirm Secure Boot is on per device, and confirm the revocation and certificate updates are applied; measured boot and remote attestation give the stronger evidence.
• It needs privileged access to defeat. Bootkits need administrator or physical access first, so local admin control and credential hygiene sit alongside D3-BA.

D3-BA at a glance

The D3FEND entry has no "how it works" or considerations text (checked November 2026); the detail below comes from UEFI platform and vendor documentation.

How it works

On UEFI systems, firmware holds four signature stores in non-volatile memory, provisioned at manufacture and then locked so that changes need a correctly signed update or a physically present user in the firmware menus:

At power-on, firmware checks each image in the boot path (option ROMs, EFI applications, the operating system boot manager) against these stores and runs it only if its signature is trusted and not revoked. Microsoft's documentation states that firmware components must be signed with at least RSA-2048 and SHA-256. If the boot manager fails verification, firmware tries a backup copy and then falls back to manufacturer recovery.

D3-BA covers the step up to the operating system loader. On Windows, three further layers continue the chain: Trusted Boot (the loader verifies the kernel, which verifies boot drivers and startup files), Early Launch Anti-Malware (an anti-malware driver loads first and vets other boot drivers), and Measured Boot (firmware records each boot component in the TPM so a remote attestation service can judge device health). Linux distributions use a Microsoft-signed shim that then verifies GRUB and the kernel; see the Linux Secure Boot and Shim Guide.

ATT&CK techniques D3FEND relates to D3-BA

Relationship type: inferred only. D3FEND lists one ATT&CK relationship, derived from the shared Boot Loader artefact, and marks it inferred and experimental (checked November 2026).

Other Pre-OS Boot sub-techniques, such as T1542.001 System Firmware, act on firmware rather than the boot loader and are not in D3FEND's D3-BA mapping. See MITRE ATT&CK T1542 Pre-OS Boot for the technique family and M1046 Boot Integrity for the ATT&CK mitigation.

Where it is implemented

Bare-metal fleets that network boot need the same check on the PXE path; see the Bare-Metal Provisioning and PXE Boot Security Guide.

Implementation steps

1. Inventory boot state. For every endpoint, server and VM, record firmware mode (UEFI or legacy), Secure Boot state, TPM presence and the firmware version.
2. Convert legacy-mode systems. Plan disk partition conversion to GPT and UEFI mode before Secure Boot can be enabled; pilot on a small ring with a restore image.
3. Enable Secure Boot and lock firmware. Turn it on, set a firmware administrator password and disable boot from unapproved media.
4. Keep the trust lists current. Apply dbx revocation updates and certificate updates from the operating system vendor. Microsoft states that Secure Boot certificates issued in 2011 begin expiring in June 2026; see Secure Boot Certificate Expiry 2026.
5. Remove trust you do not need. Where a device boots only Windows, Microsoft's BlackLotus guidance notes that removing the third-party UEFI CA from Secure Boot blocks that bootkit, while stating that this does not eliminate the underlying vulnerability. Test first: some option ROMs and Linux loaders depend on it.
6. Add measured boot and attestation. Use the TPM log with a device health or attestation service so a compliance decision rests on evidence the operating system cannot forge.
7. Plan rollback. Keep recovery media and BitLocker or disk encryption recovery keys escrowed before any db, dbx or certificate change, because a bad update can stop a device booting or trigger recovery mode. See the BitLocker guide.

How to verify it works

• Per-device state: on Windows, System Information shows BIOS Mode "UEFI" and Secure Boot State "On", and the PowerShell cmdlet Confirm-SecureBootUEFI returns True. On Linux, mokutil reports the Secure Boot state. Collect these through endpoint management rather than by hand.
• Trust list currency: confirm the dbx and certificate update status reported by the operating system vendor's tooling across the fleet.
• Attestation results: where measured boot is in use, compare devices reporting healthy boot against the inventory; a device that cannot attest is a finding.
• Negative test in a lab: attempt to boot unsigned media on a test device and confirm firmware refuses it.

Detection signals around the boot path

Microsoft's BlackLotus investigation guidance lists signals that are weak alone but useful together: recently modified or locked boot loader files on the EFI System Partition (for example bootmgfw.efi or grubx64.efi), an unexpected staging directory on that partition, the HVCI "Enabled" registry value set to 0, the anti-malware service stopping (System log event ID 7023), and boot components that appear between measured boot logs from successive reboots. The Firmware and Bootkit Compromise Playbook covers response.

Limits, bypasses and failure patterns

• Trusted but vulnerable loaders: BlackLotus used CVE-2022-21894 to bypass Secure Boot on patched-looking systems, then placed its own files on the EFI System Partition. Signature checks passed because the abused component was still trusted, which is why revocation matters.
• Secure Boot left off or in setup mode: devices delivered with it disabled, or switched off to install a driver, never get turned back on without a compliance check.
• Stale trust lists: dbx and certificate updates are deferred because they carry boot risk, leaving revoked loaders usable.
• Firmware not covered: D3-BA verifies what firmware loads, not the firmware itself; firmware implants need firmware verification and update controls.
• Local admin everywhere: bootkit installation needs privileged access; broad local administrator rights make that step easy.
• No recovery plan: a bad dbx update without escrowed recovery keys turns a security change into an outage.

Framework mapping

Related countermeasures

• Siblings under Platform Hardening: TPM Boot Integrity (D3-TBI) measures the boot chain into the TPM, and Driver Load Integrity Checking (D3-DLIC) verifies drivers after the loader hands over.
• Monitoring: Firmware Verification (D3-FV) sits under Platform Monitoring and covers the firmware D3-BA trusts.
• Detection: D3-SICA System Init Config Analysis watches startup configuration that persistence often changes.

For how D3FEND is organised, see the MITRE D3FEND Guide.

Practitioner checklist

• Inventory firmware mode, Secure Boot state and TPM presence for every device and VM.
• Move legacy-mode systems to UEFI and enable Secure Boot with a firmware password.
• Track and apply dbx revocation and Secure Boot certificate updates, including the 2026 certificate transition.
• Remove unneeded third-party UEFI trust after testing.
• Enable measured boot and use attestation results in device compliance.
• Escrow disk encryption recovery keys and keep recovery media before trust-list changes.
• Restrict local administrator rights to reduce the access bootkits need.
• Collect EFI System Partition, boot log and anti-malware service signals for detection.

Standards and references

• MITRE D3FEND: Bootloader Authentication (D3-BA)
• UEFI Forum: UEFI Platform Initialization (PI) Specification 1.7A
• MITRE ATT&CK: T1542.003 Bootkit
• MITRE ATT&CK: M1046 Boot Integrity
• NIST: SP 800-53 Rev 5, Security and Privacy Controls
• Microsoft Learn: Secure Boot
• Microsoft Learn: Secure the Windows boot process
• Microsoft Security: Guidance for investigating attacks using CVE-2022-21894, the BlackLotus campaign

Related NHI Mgmt Group resources: Firmware and Boot Security Guide · Linux Secure Boot and Shim Guide · Secure Boot Certificate Expiry 2026 · MITRE ATT&CK T1542 Pre-OS Boot · MITRE D3FEND Guide