Firmware and UEFI Security: Hardening Enterprise Endpoints Against the Most Persistent Threat Layer
Firmware is the most privileged and least monitored attack surface on enterprise endpoints. Code running in the UEFI firmware layer executes before the operating system, before endpoint detection and response agents, and before any security software the organization has deployed. A firmware implant persists through OS reinstallation, disk replacement, and every remediation step a security team would take in response to a discovered compromise. Nation-state actors have understood this for over a decade; the commercial threat actor ecosystem caught up with the commercial availability of UEFI bootkit capabilities (BlackLotus, CosmicStrand, MoonBounce). This guide covers the firmware threat landscape, the controls that actually work, and a practical hardening approach for enterprise endpoint fleets.
Why Firmware Attacks Are the Most Persistent Threat
The persistence advantage of firmware-level compromise is architectural. The UEFI firmware layer initializes hardware and launches the OS bootloader. Code running here executes with higher privilege than the OS kernel, before any OS-level security control is active, and in a storage location (SPI flash chip on the motherboard) that is not wiped by a disk format or OS reinstall.
The threat actor motivation: For a sophisticated attacker, firmware persistence provides an implant that survives all conventional incident response actions. If a defender discovers the compromise and reinstalls the OS, the firmware implant reinfects the new OS installation during the next boot. If they replace the hard drive, the firmware implant remains on the motherboard. The only remediation is a verified firmware flash -- a process that many organizations have never performed at scale and that requires vendor tooling and physical or remote access to the BMC.
The commercial proliferation problem: Until 2022, firmware implants were considered exclusively nation-state capabilities. BlackLotus changed that. BlackLotus is a UEFI bootkit sold commercially on cybercriminal forums for approximately $5,000. It exploits CVE-2022-21894 (a Secure Boot bypass vulnerability) to install a firmware-resident implant on fully patched Windows 11 systems with Secure Boot enabled. ESET's analysis in March 2023 confirmed active deployment of BlackLotus against real targets, demonstrating that firmware attacks are now a commercial threat actor capability, not a nation-state-exclusive technique.
The firmware vulnerability surface: Modern enterprise endpoints have multiple firmware components beyond the main UEFI/BIOS:
- UEFI/BIOS firmware (Intel Management Engine, AMD PSP)
- Baseboard Management Controller (BMC/IPMI) on servers
- Drive firmware (NVMe, SATA SSD controller)
- Network adapter firmware
- GPU firmware
- Thunderbolt controller firmware
Each is a distinct attack surface with its own vulnerability history and update cadence. Most enterprise vulnerability management programs have no visibility into any of these firmware components.
UEFI Secure Boot: How It Works and Where It Fails
Secure Boot is the foundational firmware security control, but it is frequently misconfigured, poorly understood, and has been bypassed by attackers who understand its implementation weaknesses.
How Secure Boot works: Secure Boot uses a chain of cryptographic signatures to verify that each component of the boot process is signed by a trusted key before execution. The UEFI firmware contains a database of trusted certificates (the db) and a list of revoked certificates and hashes (the dbx). When the system boots:
- UEFI firmware loads and checks its own integrity (stored in SPI flash)
- The bootloader is loaded and its signature verified against the db
- The OS kernel is loaded and verified
- Only if all signatures validate against trusted keys does the boot proceed
The PKfail problem: In July 2024, Binarly discovered that approximately 900 device models from major manufacturers (AMI, Insyde, Phoenix, among others) shipped with Secure Boot signing keys that were test keys generated during development -- the same keys that device manufacturers warn must never be used in production. These test keys were not protected (the private key material was publicly available in some cases). An attacker with access to the test signing key can sign a malicious bootloader that Secure Boot will accept as trusted. The remediation is a firmware update that replaces the test key with a production key -- but only if the manufacturer issued an update, and only if the enterprise has a firmware update management process.
Secure Boot hardening requirements:
- Verify Secure Boot is enabled in UEFI settings -- enrollment in MDM or endpoint management does not guarantee Secure Boot is enabled; verify via OS API or BIOS configuration audit
- Enable UEFI Setup password to prevent unauthorized Secure Boot configuration changes
- Enable dbx updates -- the dbx is the revocation database for Secure Boot; Microsoft distributes dbx updates to revoke vulnerable bootloaders (including the bootloaders patched by CVE-2022-21894 / BlackLotus); ensure these updates are applied
- Restrict the boot device order -- configure UEFI to boot only from the internal drive; disable network boot (PXE) and external media boot in the production configuration
- Enable UEFI Secure Boot in "Custom" mode with organizational CA -- for highest-assurance environments, replace the default Microsoft key with a custom organizational key, preventing any Microsoft-signed code from booting unless the organization has verified it
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The Firmware Vulnerability Landscape: BootHole, LogoFAIL, and BlackLotus
Several firmware vulnerability classes have demonstrated that firmware attacks are practical against fully patched enterprise systems.
BootHole (CVE-2020-10713): A buffer overflow in the GRUB2 bootloader that allowed attackers with physical access or OS-level privilege to bypass Secure Boot and execute unsigned code in the UEFI context. The remediation required dbx updates to revoke vulnerable GRUB2 bootloaders -- a complex patch deployment that took years to fully propagate across enterprise fleets.
BlackLotus (exploiting CVE-2022-21894): The first commercially available UEFI bootkit. Exploits a Windows Secure Boot bypass vulnerability where a signed but vulnerable Windows bootloader from before the patch was applied could still be booted -- because Microsoft had not revoked the old bootloader via dbx at the time of the initial patch. BlackLotus installs a UEFI module that persists in the ESP (EFI System Partition) and survives OS reinstallation. It disables Windows security features (Defender, HVCI, BitLocker) after boot. Remediation requires applying the Windows May 2023 security update AND the updated Secure Boot dbx revocation, in the correct order.
LogoFAIL (2023): Disclosed by Binarly in December 2023, LogoFAIL is a class of vulnerabilities in UEFI firmware image parsing libraries used by virtually all major PC manufacturers (Lenovo, HP, Dell, AMI, Insyde, Phoenix). UEFI firmware displays a manufacturer logo during POST (Power-On Self-Test); the image parsing libraries used for this display contained critical vulnerabilities. An attacker who can write to the EFI System Partition (accessible with OS-level privilege) can place a malicious image file that exploits the logo parser to execute arbitrary code in the UEFI context, before Secure Boot has a chance to validate the bootloader. LogoFAIL bypasses Secure Boot entirely because it executes before the Secure Boot verification step.
MoonBounce and CosmicStrand (APT41, APT group): Nation-state firmware implants that write directly to the SPI flash chip containing the UEFI firmware, surviving not just OS reinstallation but also complete EFI System Partition wipes. Detected by Kaspersky in 2022, these implants persist in the firmware itself rather than in OS-accessible storage.
Firmware Scanning and Monitoring Tools
Most vulnerability management scanners (Nessus, Qualys, Rapid7) have no visibility into firmware versions or vulnerabilities. Addressing firmware security requires purpose-built tooling.
Binarly REscan and FwHunt: Binarly is the leading firmware security research firm and provides FwHunt, an open-source firmware hunting tool, and the commercial REscan platform for enterprise firmware analysis. REscan analyzes firmware images for known vulnerabilities, binary patterns matching malware families (including BlackLotus, CosmicStrand, and MoonBounce), and supply chain integrity issues (embedded test keys, outdated libraries). For large enterprise fleets, REscan provides centralized firmware visibility that no other commercial platform currently matches.
Microsoft Defender Firmware scanner: Microsoft Defender for Endpoint includes UEFI scanner capability (released 2020) that boots into a protected environment to scan UEFI firmware for malware without the firmware itself being able to interfere with the scan. This provides blacklist-based detection of known firmware malware families. Available on Microsoft Defender for Endpoint Plan 2 and Microsoft 365 Defender.
HP Sure Start, Dell SafeBIOS, Lenovo ThinkShield: Enterprise laptop manufacturers offer platform firmware assurance features:
- HP Sure Start: automatically detects and recovers from BIOS corruption or tampering by comparing BIOS to a "golden copy" stored in a dedicated security chip
- Dell SafeBIOS: provides BIOS image verification and off-host BIOS verification via Dell Trusted Device
- Lenovo ThinkShield: BIOS Absolute Persistence and hardware-based boot verification
These vendor-specific capabilities vary significantly by device model and require the specific hardware platform. Include firmware security capability as an evaluation criterion when procuring enterprise laptops.
Platform firmware update management: Most enterprise endpoint management platforms (SCCM, Intune, Jamf for macOS) support firmware update deployment for specific device models. Configure automated firmware update deployment within 30 days of vendor release -- the same cadence as OS security updates. Track firmware version compliance in your asset management platform alongside OS version and patch level.
Enterprise Firmware Hardening Checklist
UEFI configuration (enforce via MDM or BIOS configuration tool where possible):
- Secure Boot enabled and in active enforcement mode (not setup mode)
- UEFI Setup (BIOS) password set on all devices; passwords stored in privileged credential vault
- Boot order restricted to internal drive; external media and network boot disabled
- dbx (Secure Boot revocation database) updated to current Microsoft-distributed version
- UEFI Secure Boot key verification: audit for PKfail-affected devices by checking signing key against Binarly's public PKfail certificate list
- Intel Boot Guard or AMD Platform Security Processor enabled (hardware root of trust that signs UEFI firmware itself)
- USB boot restricted or disabled; Thunderbolt security level set to "User" or "Secure Connect" minimum
Firmware update management:
- Firmware version inventory maintained for all managed endpoints (UEFI version, EC firmware, BMC version for servers)
- Firmware updates deployed within 30 days of manufacturer release
- Firmware update deployment tested on a representative set of devices before fleet-wide rollout (a bad firmware update can brick a device)
- End-of-support devices identified: manufacturers stop providing firmware updates for older models; identify and plan replacement for devices that no longer receive firmware security patches
Server BMC/IPMI hardening (applies to on-premises server infrastructure):
- BMC network interface on a dedicated out-of-band management network, not accessible from general corporate network
- BMC default credentials changed immediately after deployment
- BMC firmware updated on same cadence as server BIOS firmware
- IPMI v2.0 authentication enforced (IPMI v1.5 has known authentication weaknesses)
- Remote BMC access requires VPN or jump server authentication
Detection and monitoring:
- Microsoft Defender for Endpoint UEFI scanner enabled (requires MDE Plan 2)
- Secure Boot status monitored via endpoint management telemetry -- alert on any device with Secure Boot disabled
- BIOS version compliance reported in endpoint management dashboard
- Log Secure Boot failures (Windows Event ID 1796) -- unexpected Secure Boot failures may indicate tampering attempts
The bottom line
Firmware security is the gap most enterprise security programs have not addressed because the tooling has historically been immature and the threat was considered theoretical. It is neither anymore. LogoFAIL affects virtually every enterprise PC shipped in the last decade. PKfail affected 900 device models from every major manufacturer. BlackLotus brought UEFI bootkit capability to commercial ransomware operators. The starting point for most organizations is unglamorous but necessary: establish firmware version inventory, configure Secure Boot properly with dbx updates applied, and deploy firmware updates on the same cadence as OS patches. Add firmware scanning capability (Binarly REscan, Microsoft Defender UEFI scanner) for higher-risk environments.
Frequently asked questions
Does reinstalling Windows remove a firmware implant?
No. Firmware implants like BlackLotus, MoonBounce, and CosmicStrand persist in the UEFI firmware stored on the SPI flash chip or in the EFI System Partition, which is not affected by an OS reinstallation or disk format. More sophisticated implants that write directly to the SPI flash (MoonBounce, CosmicStrand) persist even if the hard drive is physically replaced. The only reliable remediation for a firmware implant is a verified firmware re-flash using a known-good firmware image, performed by the device vendor or by IT staff with the appropriate tooling and a verified-clean firmware image. In cases where SPI flash write protection has been disabled by the implant (a common technique), this may require specialized hardware intervention.
What is the PKfail vulnerability and how do I know if my devices are affected?
PKfail refers to the discovery in July 2024 that approximately 900 device models shipped with Secure Boot Platform Keys (PK) derived from an AMI test key that was never intended for production use. The private key material for this test key was publicly available, meaning anyone can sign a bootloader that Secure Boot on affected devices will accept as trusted. Check your device models against Binarly's public PKfail advisory list at binarly.io. Affected devices require a firmware update from the manufacturer that replaces the test key with a production key. Not all manufacturers issued updates for all affected models -- contact your hardware vendor for device-specific guidance.
How do I check whether Secure Boot is properly configured on Windows endpoints?
Run 'msinfo32' and check 'Secure Boot State' in System Summary -- it should show 'On'. From PowerShell (as administrator): 'Confirm-SecureBootUEFI' returns True if Secure Boot is enabled and enforcing. Via endpoint management: Microsoft Intune reports Secure Boot status in Device Compliance policies; SCCM can query Secure Boot status via WMI class Win32_ComputerSystem. Alert on any managed device reporting Secure Boot disabled, as this may indicate tampering or a device that was not properly configured during provisioning.
What is Intel Boot Guard and why does it matter?
Intel Boot Guard is a hardware security technology that provides a cryptographic root of trust for the UEFI firmware itself. Before UEFI firmware executes, Boot Guard verifies the firmware's signature against a key blown into the processor's fuses during manufacturing. This prevents attackers from replacing the UEFI firmware with a malicious version even if they have physical access to the SPI flash chip. Boot Guard is enabled at the hardware level by the manufacturer (OEM blows the keys during manufacturing) and cannot be enabled or disabled after manufacture. When purchasing enterprise devices, verify that Boot Guard (or AMD's equivalent, Platform Secure Boot) is enabled by the manufacturer -- this is documented in the device's security specifications.
How does LogoFAIL bypass Secure Boot?
LogoFAIL exploits vulnerabilities in the image parsing libraries embedded in UEFI firmware that render the manufacturer logo displayed during Power-On Self-Test. These parsing libraries contain memory corruption vulnerabilities. An attacker who can write to the EFI System Partition (accessible with OS-level admin privilege) places a malicious image file in the ESP. When the system boots, the UEFI firmware loads and parses the malicious image to display the logo -- executing attacker-controlled code in the UEFI context before the Secure Boot verification step runs. Because execution occurs before Secure Boot validation, the attack is not blocked by Secure Boot. Remediation requires a firmware update from the device manufacturer that patches the vulnerable image parsing library.
Should firmware security be part of our vulnerability management program?
Yes, but it requires different tooling than standard OS and application vulnerability management. Standard vulnerability scanners (Nessus, Qualys, Rapid7) cannot enumerate firmware versions or assess firmware vulnerabilities. Add firmware to your vulnerability management program by: maintaining a firmware version inventory for all managed endpoints (UEFI version, BMC version for servers), subscribing to firmware security advisories from your hardware vendors, deploying firmware updates through endpoint management platforms (Intune, SCCM, Jamf) on the same SLA as OS patches, and periodically scanning high-risk endpoints with dedicated firmware analysis tools (Binarly REscan, Microsoft Defender UEFI scanner).
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.