New NSA UEFI Guidance: Trust Starts Before the OS
By Patrick Miller
UEFI Secure Boot is widely assumed to be enabled and enforcing, yet recent vulnerabilities show how easily trust at boot time can silently fail. NSA’s new guidance breaks down how Secure Boot actually works, where configurations commonly go wrong, and how organizations can validate and recover trust in the earliest stages of system startup.
Overview
This week, the National Security Agency released Guidance for Managing UEFI Secure Boot, a detailed and timely publication addressing a layer of system security that is often assumed to be “on” but rarely verified in practice.
We routinely see organizations invest heavily in endpoint detection, disk encryption, and identity controls, while the integrity of the boot process itself remains largely unexamined. NSA’s guidance is a clear reminder that if the boot process is compromised, every security control that follows is built on an untrusted foundation.
Why Secure Boot Matters More Than Ever
UEFI Secure Boot was designed to prevent unauthorized or malicious code from executing during system startup. It does this by enforcing trust decisions using cryptographic keys, certificates, and revocation lists before the operating system ever loads.
Recent high-profile vulnerabilities including PKFail, BlackLotus, and BootHole demonstrated that Secure Boot can be bypassed or silently misconfigured, even on systems that appear healthy from an operating system perspective. In several cases, affected systems reported Secure Boot as enabled while enforcement had effectively been neutralized.
NSA’s guidance reinforces a critical point: Secure Boot is a supply chain security control, not just an endpoint feature. The certificates and keys embedded in firmware represent trust decisions made long before a device is deployed into production.
Secure Boot Is Independent of TPM and Disk Encryption
One of the most important clarifications in the document addresses a common misconception. The presence of a TPM, the use of BitLocker or other full disk encryption, or reliance on processor security features does not guarantee that Secure Boot is enabled or enforcing.
Secure Boot must be explicitly enabled, validated, and monitored. NSA notes that administrators frequently assume these controls are interdependent when, in reality, they operate independently and can fail independently.
For regulated environments and critical infrastructure operators, this distinction matters. Compliance checklists and audit artifacts often reference encryption and TPM usage without validating the state of Secure Boot itself.
Understanding the Secure Boot Trust Model
The guidance provides a clear explanation of the four UEFI Secure Boot variable stores that define trust at boot time:
Platform Key (PK): Defines who can modify Secure Boot configuration.
Key Exchange Keys (KEKs): Control who can update allowed and revoked boot components.
Allow Database (DB): Certificates and hashes permitted to execute.
Exclusion Database (DBX): Certificates and hashes explicitly denied.
Misplacement of certificates, use of test keys, expired signing chains, or incomplete revocation lists can all undermine enforcement without obvious indicators at the OS level.
NSA highlights that the industry is currently in a transition period from Microsoft’s 2011 signing certificates to the 2023 equivalents, increasing the likelihood of inconsistent or incomplete configurations, particularly on older or long-lived systems.
From Strategic Risk to Technical Reality
In our recent analysis of the U.S.-China Economic and Security Review Commission’s 2025 report, we examined how upstream supply chain influence can create long-duration risk across U.S. critical infrastructure. Much of that discussion focused on policy, procurement, and dependency. Secure Boot is where those risks become enforceable or exploitable at the technical level.
The trust decisions embedded in UEFI firmware, including platform keys, signing authorities, and revocation lists, are made long before a system is deployed into an operational environment. If those trust anchors are incomplete, outdated, or silently bypassed, no amount of endpoint monitoring or network visibility can restore confidence in the system’s integrity.
NSA’s new Secure Boot guidance reinforces a critical point. Strategic supply chain risk does not remain abstract. It materializes at boot time, before the operating system loads and before security controls have any opportunity to intervene.
What Organizations Should Be Doing Now
NSA’s recommendations are practical and actionable, and they align closely with what we advise clients across energy, manufacturing, transportation, and other critical sectors:
Verify Secure Boot enforcement, not just availability, on all systems.
Inspect Secure Boot variables and validate that keys and certificates match expected vendor and ecosystem baselines.
Perform acceptance testing for newly procured hardware, including firmware and boot integrity checks.
Monitor for misconfiguration indicators, such as test certificates, permissive modes, or Compatibility Support Module (CSM) enablement.
Plan for recovery, including firmware updates and restoration of known-good Secure Boot configurations.
For large environments, manual inspection is not scalable. Secure Boot state should be treated as a measurable security posture element and incorporated into asset management, procurement, and supply chain risk management processes.
Why This Matters for Critical Infrastructure
From an operational technology perspective, Secure Boot issues are not limited to laptops and servers. Engineering workstations, HMI systems, control center desktops, and even some embedded platforms rely on UEFI-based boot processes.
A compromised boot chain can enable persistent, stealthy access below the operating system, evading traditional monitoring and undermining forensic confidence during incident response.
In environments governed by NERC CIP, DOE/NARUC Baselines, TSA directives, or emerging international frameworks, Secure Boot integrity increasingly intersects with expectations around system trustworthiness and supply chain assurance.
Final Thoughts
Secure Boot is doing critical work quietly, at machine speed, long before humans or security tools have visibility. That invisibility is precisely why it deserves deliberate oversight.
NSA’s guidance does not introduce a new control. It reinforces the need to validate, audit, and maintain a control many organizations assumed was already working.
As firmware threats continue to mature, trust in the boot process will remain a prerequisite for trust in everything that follows.
