Firmware and Boot Security Guide: UEFI, Secure Boot and TPM

Code that runs before the operating system decides what the operating system can trust, and malware that lives there survives disk wipes, reinstalls and most endpoint security tools. UEFI firmware, option ROMs, boot loaders and server management controllers are routine targets, and 2026 adds a deadline: the Microsoft 2011 Secure Boot certificates that most PCs and servers trust are expiring. This guide covers the boot chain, UEFI Secure Boot and its key databases, measured boot and TPM attestation, bootkits in ATT&CK, the BlackLotus revocations and certificate rotation, BMC exposure, DMA and physical attacks, and firmware updates. It is written for endpoint, server and infrastructure engineers and for architects who set and measure the baseline.

Key takeaways

• Secure Boot only blocks what its databases say to block. A vulnerable but validly signed boot manager stays trusted until it is revoked in dbx or by version number, which is how BlackLotus defeated fully patched machines.
• The 2011 certificates are expiring now. Microsoft gives 24 June 2026 for the KEK CA 2011, 27 June 2026 for the UEFI CA 2011 and 19 October 2026 for the Windows Production PCA 2011 (as of October 2026). Devices without the 2023 certificates keep booting but stop receiving boot-level security updates.
• Measured boot detects, it does not prevent. TPM measurements only help when a remote verifier checks them and something acts on the result, such as conditional access or quarantine.
• The BMC is a second computer with its own credentials. iLO, iDRAC and IPMI run while the server is off, can disable Secure Boot and TPM, and are often left on default or shared accounts.
• Firmware updates are a supply chain. Use signed channels, inventory versions and plan for recovery, because a failed or malicious flash can leave hardware unbootable.

The boot chain and where trust starts

Each stage verifies or measures the next. If one stage is compromised, everything after it inherits the compromise, including security tools that load later.

The core root of trust for measurement (CRTM) is the first code that measures anything, so it must be immutable or verified by the hardware root of trust. ATT&CK mitigation M1046 Boot Integrity recommends moving the root of trust into hardware, citing Intel Boot Guard, to stop tampering with SPI flash. Because Boot Guard and AMD PSB trust vendor keys fused into the processor, leaked signing keys cannot be revoked by customers: see the MSI signing keys leak, where firmware and Boot Guard private keys were exposed after a ransomware breach.

UEFI Secure Boot: keys, databases and modes

Secure Boot checks the signature of every UEFI executable (boot loaders, drivers, option ROMs) against variables held in firmware. NSA's UEFI Secure Boot Customization report describes the hierarchy:

• Standard or custom mode: standard mode uses Microsoft and OEM keys, and NSA says Secure Boot "is best left enabled in standard mode" for most organisations. Custom mode lets the owner prune or replace PK, KEK, db and dbx, which NSA limits to expertly administered infrastructure because a mistake can block firmware updates, GPUs or recovery media. Audit mode logs failures without blocking, useful when testing a custom key set.
• Disable CSM: the Compatibility Support Module boots legacy code without signature checks. NSA: "Disable CSM to prevent legacy fallback mode from bypassing Secure Boot protections."
• Verify, do not assume: Confirm-SecureBootUEFI returns True on Windows; on Linux, dmesg | grep -i "secure boot" shows the state and fwupdmgr security reports the attribute org.fwupd.hsi.Uefi.SecureBoot. NSA cites racadm get BIOS.SysSecurity.SecureBoot for Dell servers.
• Linux revocation: distributions boot through a Microsoft-signed shim that verifies GRUB and the kernel against distribution keys. SBAT (Secure Boot Advanced Targeting) revokes a vulnerable generation of shim or GRUB without filling dbx with hashes, so keep shim packages current.
• Lock the setup screen: set a firmware supervisor password, unique per device or held in a vault, so local users cannot disable Secure Boot or change boot order. See the Privileged Access Management Guide.

Measured boot, TPM and physical attacks

Secure Boot blocks unsigned code; measured boot records what actually ran. Firmware hashes each component into TPM PCRs before executing it and keeps a TCG event log. Microsoft explains why the verdict must be remote: rootkits can hide from local reporting, so "you can't trust the client to tell you whether it's healthy." A verifier requests a TPM-signed quote of the PCRs, replays the event log against it and grants full access, a quarantine network or nothing.

• PCRs that matter: PCR 0 holds core firmware measurements, and per NSA "PCR 7 captures integrity measurement events that summarize the PK, KEK, DB, and DBX." BitLocker with Secure Boot seals to PCR 7 and PCR 11, which is why db or dbx changes can trigger BitLocker recovery.
• Attestation keys: the endorsement key proves a genuine TPM; an attestation identity key (AIK) signs quotes without exposing it. Verifiers include Intune device health attestation and Keylime on Linux. See the Device Trust and Posture Guide.
• Dynamic root of trust: Intel Trusted Execution Technology (TXT) and AMD's equivalent re-establish a measured state after firmware has run. Windows System Guard Secure Launch uses it, and Secured-core PCs combine it with Secure Boot, TPM 2.0, Kernel DMA Protection and virtualisation-based security; Microsoft notes they distrust the third-party UEFI CA by default.
• Evil maid and pre-boot authentication: an attacker with brief unattended access changes settings or boot files, and TPM-only encryption unlocks for any normal boot. Use TPM plus PIN for travellers, executives and administrators. Hibernation instead of sleep also limits cold boot attacks on memory that keeps its contents briefly after power loss.
• Drive-by DMA: Thunderbolt, USB4 and CFexpress devices can read memory directly. Windows Kernel DMA Protection uses the IOMMU to block devices without DMA remapping until a user signs in; it needs VT-d or AMD-Vi enabled in firmware, appears as "Kernel DMA Protection" in msinfo32 and is set by the policy "Enumeration policy for external devices incompatible with Kernel DMA Protection" (DmaGuard CSP). It only protects after the OS loads, so firmware pre-boot DMA protection (org.fwupd.hsi.PrebootDma) still matters.

Bootkits and firmware implants in ATT&CK

ATT&CK v20 places T1542 Pre-OS Boot under Stealth (TA0005) and Persistence (TA0003). Every ID below was checked on attack.mitre.org in October 2026.

The mitigations repeat across these techniques: M1046 Boot Integrity, M1026 Privileged Account Management (firmware writes need administrator or physical access) and M1051 Update Software, "Patch the BIOS and EFI as necessary". Detection strategy DET0099 looks for writes to firmware regions or EFI partitions that do not match vendor updates. D3FEND's counterpart is Firmware Verification (D3-FV), with Peripheral (D3-PFV) and System Firmware Verification (D3-SFV). Post-boot persistence is covered in the Persistence Techniques Guide.

BlackLotus and the Secure Boot certificate rotation

NSA's June 2023 guidance explains that BlackLotus exploits "Baton Drop", CVE-2022-21894, through old Windows boot managers that were vulnerable but still signed and absent from dbx, and warns that "currently published patches could provide a false sense of security". Microsoft's response to the follow-on bypass, CVE-2023-24932 (KB5025885), moves Windows to boot managers signed by the Windows UEFI CA 2023 and then revokes the 2011 signing certificate, at the same time as the 2011 certificates expire.

Devices without the new certificates keep starting but "will no longer be able to receive new security protections for the early boot process". As of the 30 September 2026 revision of KB5025885, the steps use the AvailableUpdates REG_DWORD under HKLM\SYSTEM\CurrentControlSet\Control\Secureboot, followed by the \Microsoft\Windows\PI\Secure-Boot-Update scheduled task:

1. 0x5944: add Windows UEFI CA 2023 to db and install the 2023-signed boot manager; confirm UEFICA2023Status reads "Updated" and look for events 1036 and 1799.
2. 0x80: add Windows Production PCA 2011 to dbx (event 1037). This cannot be reverted while Secure Boot stays on, and reformatting the disk does not undo it.
3. 0x200 (optional): raise the Secure Version Number to block rollback to older boot managers (event 1042).

Microsoft's enforcement phase, which revokes PCA 2011 automatically with no opt-out, "will not begin before January 2026" and had no announced date at the time of writing. Before revoking, refresh installation, recovery and PXE media, escrow BitLocker recovery keys and test one device per model, because Microsoft warns some firmware fails to apply db or dbx updates. KEK updates must be signed by the OEM's PK, so older models may need manufacturer firmware first. On Linux-only fleets, confirm the distribution shim is signed by the UEFI CA 2023 and that firmware trusts it.

Server firmware, BMCs and out-of-band management

Baseboard management controllers (HPE iLO, Dell iDRAC, Lenovo XClarity Controller, generic IPMI) are separate computers on the motherboard. The June 2023 NSA and CISA information sheet notes that BMCs keep running when the server is off and could be used to disable TPM and UEFI Secure Boot, manipulate storage and spread implants. Its three action areas are credentials and configuration, integrity monitoring and updates, and network separation. NIST SP 800-147B extends the BIOS protection guidelines to servers.

• Isolate the network: a dedicated management VLAN reachable only from administrative jump hosts, never from user networks or the internet. Block IPMI over LAN (RMCP+ on UDP 623) and disable it where Redfish over HTTPS can replace it.
• Treat BMC accounts as privileged identities: replace factory default accounts on delivery, avoid one shared administrator password across the fleet, use directory login with MFA where supported and vault any local break-glass account. See the Break-Glass Account Guide.
• Machine credentials: provisioning, monitoring and power tools that call Redfish or IPMI hold credentials with full hardware control. Scope, vault and rotate them. See the Service Account Security Guide.
• Update and lock down: patch BMC firmware with host firmware, enforce signed firmware, and disable virtual media, SNMPv1/v2c, Telnet and unencrypted web interfaces you do not use.

Firmware updates and platform resiliency

NIST SP 800-147 sets the client BIOS baseline: vendor-signed authenticated updates, integrity protection of the flash and no way to bypass the update mechanism. SP 800-193 Platform Firmware Resiliency adds protection, detection and recovery, with roots of trust for update, detection and recovery so a platform can restore known-good firmware after corruption. SP 800-155 (BIOS integrity measurement) never left draft; NIST stopped developing it in 2024 and passed its content to Trusted Computing Group work.

fwupd's Host Security ID (HSI) scores hosts from HSI:0 to HSI:4 (HSI:5 has no tests yet), with a "!" suffix for runtime problems such as Secure Boot off. Its attributes make a practical baseline: BIOS write-enable cleared (HSI-1), TPM 2.0 (HSI-1), Intel ME not in manufacturing mode (HSI-1), Boot Guard or AMD PSB (HSI-2), IOMMU on (HSI-2) and pre-boot DMA protection (HSI-3). CISA's UEFI call to action asks owners to "audit, manage, and update UEFI components" like other software and to collect logs of UEFI changes. See the Patch Management Guide.

Implementation roadmap

1. Inventory: model, firmware version, Secure Boot state, TPM version, db and KEK certificate status and BMC firmware for every endpoint and server, from fwupdmgr security, Windows status values and Redfish queries.
2. Baseline: UEFI only (CSM off), Secure Boot in standard mode, TPM 2.0 on, supervisor password set, VT-d or IOMMU on, external boot disabled.
3. Pilot the 2023 certificates: one device per model with recovery keys escrowed and refreshed media. Apply 0x5944, observe for a patch cycle, then 0x80.
4. Ring the rollout: pilot, early adopters, broad, then servers and kiosks. Until the dbx step, devices still trust 2011-signed media; after it there is no rollback while Secure Boot stays on, only recovery with updated media, so promote a ring only when the previous one is clean.
5. Harden BMCs in parallel: management VLAN, default accounts removed, directory login, IPMI over LAN off.
6. Add attestation in report-only mode, then feed health results into conditional access or network admission.
7. Operate: monthly firmware compliance reporting, quarterly checks of dbx and SBAT currency, annual review of model end-of-support dates.

Decision points

• Standard or custom keys: standard for almost everyone. Custom keys suit fixed-function servers or appliances with a team able to sign its own boot chain, at the cost of key management and broken vendor updates. See the Cryptographic Key Management Guide.
• Distrusting the third-party UEFI CA: reasonable on Windows-only devices; the separate Option ROM CA 2023 lets GPUs and NICs work without trusting third-party boot loaders.
• Small or large estate: small organisations should buy Secured-core or equivalent hardware, rely on vendor update channels and focus on inventory, BMC isolation and recovery media. Large estates add attestation, per-model rings and firmware versions in the CMDB.

Detection and measurement

NSA's BlackLotus guide recommends integrity scanning of the EFI system partition, alerting on changes to bootmgfw.efi or bootmgr.efi and on new binaries such as shimx64.efi or grubx64.efi, and preventing a reboot until an unexpected change is restored. Also alert on Secure Boot or Memory Integrity being disabled, BitLocker suspended outside maintenance, firmware tools run by unexpected accounts, BMC logins from outside the management network and attestation failures. See the EDR Evasion and Defence Guide.

• Secure Boot coverage: devices with Secure Boot on and CSM off (target 100 per cent of supported hardware).
• Certificate readiness: devices with Windows UEFI CA 2023 in db and the 2023 KEK, by model.
• Revocation coverage: devices with PCA 2011 in dbx and current SBAT.
• Firmware currency: devices within one vendor release, and median days to deploy critical firmware fixes.
• BMC exposure: BMCs reachable outside the management network or on default or shared accounts (target zero).

Common failure patterns

• Patching without revoking: the new boot manager is installed but PCA 2011 never reaches dbx, so old vulnerable boot managers still load, the gap BlackLotus used.
• Revoking before refreshing media: stale USB, ISO and PXE images stop booting just when recovery is needed.
• Secure Boot on paper only: CSM left on, Secure Boot disabled for a driver test and never re-enabled, or no setup password.
• BMCs on flat networks with default credentials: an unmonitored path to every server, below EDR.
• Measured boot with no verifier: TPMs record everything and nothing checks the quotes.
• Signing keys outside HSMs: once firmware or boot signing keys leak, as in the MSI case, customers cannot fix the trust problem themselves.

Framework mapping

Practitioner checklist

• Report Secure Boot state, CSM status, TPM version and firmware version for every device.
• Confirm the 2023 KEK and db certificates model by model, and chase OEM firmware where KEK updates fail.
• Complete the KB5025885 steps through dbx revocation after refreshing media and escrowing BitLocker keys.
• Keep Linux shim, GRUB and SBAT current and check shim is signed by the UEFI CA 2023.
• Set unique firmware supervisor passwords and vault them.
• Move every BMC to an isolated management network, remove default and shared accounts and disable IPMI over LAN.
• Enable Kernel DMA Protection and pre-boot DMA protection; require TPM plus PIN on high-risk laptops.
• Deliver firmware only through signed channels with per-model rings.
• Monitor the EFI system partition and alert when Secure Boot, Memory Integrity or BitLocker is disabled.

Standards and references

• NIST: SP 800-193 Platform Firmware Resiliency Guidelines
• NIST: SP 800-147 BIOS Protection Guidelines
• NSA: UEFI Secure Boot Customization
• NSA: BlackLotus Mitigation Guide
• Microsoft: Windows Secure Boot certificate expiration and CA updates
• Microsoft: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932
• MITRE ATT&CK: T1542 Pre-OS Boot
• fwupd: Host Security ID Specification

Related NHI Mgmt Group resources: Endpoint Security Guide · Windows Endpoint Hardening Guide · Device Trust and Posture Guide · Patch Management Guide · Privileged Access Management Guide