Abstract

Firmware-level compromise sits below the operating system and survives reimaging, endpoint detection agents, and most forensic tooling. UEFI Secure Boot, when correctly configured and enforced, blocks unsigned bootloaders and drivers from executing before the OS hands off control. In practice, most enterprise Secure Boot deployments are partial: databases contain vendor keys from OEM provisioning that are too broad, custom-key enrollment is skipped, and endpoint management lacks the visibility to audit actual Secure Boot state at scale. Closing these gaps requires a firmware policy framework, not just a checkbox in device management.

The Secure Boot Key Database

Secure Boot relies on four UEFI databases: PK (Platform Key), KEK (Key Exchange Key), db (signature database, allowed), and dbx (forbidden signatures). The PK is the root trust anchor, held by the OEM in default configurations. Enterprise management of Secure Boot requires enrolling a custom PK and KEK - effectively taking ownership of the trust chain from the OEM - so that only keys the enterprise controls can modify the allowed signature database.

Most deployments skip PK/KEK enrollment and leave the OEM’s keys in place. This means any party who can obtain a certificate signed by the OEM’s KEK - which includes several software vendors - can add entries to db. The 2022 UEFI bootkit campaigns (BlackLotus and its precursors) demonstrated that the Microsoft third-party UEFI CA has been a vector for loading compromised boot components, prompting Microsoft’s August 2024 Secure Boot update that began revoking vulnerable bootloaders via dbx. Enterprises that had not applied that update were still running Secure Boot in name while permitting known-compromised bootloaders.

Enrollment and Key Management at Scale

Enrolling custom Secure Boot keys across a heterogeneous fleet requires a management layer. For Linux-centric deployments, sbctl provides key generation and enrollment tooling that integrates with systemd-boot and GRUB. For mixed Windows/Linux fleets managed via endpoint management platforms, the preferred pattern is using the platform’s firmware management API - Microsoft Intune supports UEFI policy settings for Surface and compatible third-party devices via the Endpoint Security policy, while tools like Dell Command

Configure and HP BIOS Configuration Utility expose UEFI database enrollment for supported hardware.

dbx updates require special attention: they revoke previously trusted bootloaders, and deploying an update without verifying that current boot components are not affected can render systems unbootable. A staged rollout with pre-flight validation - checking enrolled db certificates against the planned dbx additions - is mandatory before fleet-wide deployment.

Audit and Attestation

Visibility into actual Secure Boot state is a gap in most endpoint management programs. Group Policy can enforce Secure Boot enablement, but it relies on Windows reporting its own state. Independent attestation comes from the TPM. Secure Boot enforcement causes specific measurements to be recorded in TPM PCR registers (primarily PCR7 on UEFI systems), and remote attestation against known-good PCR values can confirm that Secure Boot ran with the expected key database at boot time. Microsoft’s Azure Attestation service and open-source attestation servers like go-attestation (from Google) support this verification pattern, enabling detection of firmware-level tampering even when the OS reports healthy state.