CSC News Table of Contents
UEFI Secure Boot is the focus of new CISA and NSA guidance to strengthen bootkit malware protection across enterprise fleets. The December 2025 Cybersecurity Information Sheet directs organizations to verify, audit, and manage Secure Boot configurations at scale.
The CISA cybersecurity guidance responds to threats such as PKFail, BlackLotus, and BootHole that bypass boot controls and persist in firmware. Misconfigurations and test keys leave devices exposed.
The agencies urge administrators to confirm enforcement, export and validate UEFI variables, and restore trusted defaults. NSA released tools to streamline audits and reduce risk.
UEFI Secure Boot: What You Need to Know
- New CISA and NSA guidance prioritizes UEFI Secure Boot audits, key hygiene, and configuration management to block bootkits and protect device integrity.
Why UEFI Secure Boot Matters for Enterprises
Introduced in 2006, UEFI enforces signed boot policies using four variables: Platform Key (PK), Key Exchange Key (KEK), allowed database (DB), and revocation database (DBX).
When configured correctly, it prevents unsigned or tampered boot binaries from executing and raises the bar against supply chain compromise and firmware persistence.
The guidance also addresses the transition from Microsoft’s 2011 certificates to 2023 issuers, which can change what DB and DBX trust or revoke.
Many devices ship already enabled, yet disabled enforcement, leftover test keys, and permissive settings still expose systems.
Routine validation is essential. TPM or BitLocker do not replace UEFI Secure Boot, since a malicious bootloader can seize control before the operating system starts.
CISA Cybersecurity Guidance Overview
The new CISA cybersecurity guidance and NSA advisory instruct enterprises to inventory, verify, and manage UEFI Secure Boot across all devices.
The document emphasizes auditing modes, avoiding the Compatibility Support Module, and customizing keys for stricter control instead of disabling protections. NSA provides GitHub tooling to analyze exported certificates and hashes for inconsistencies.
For context on evolving bootkits, review research on a first-of-its-kind UEFI bootkit. To align hardening with broader strategy, see principles from Zero Trust architecture.
How to Verify and Audit UEFI Secure Boot
Begin by confirming enforcement, then export variables and analyze them across the fleet to improve bootkit malware protection and ensure UEFI Secure Boot integrity.
Confirm Enforcement
Windows: Run PowerShell command Confirm-SecureBootUEFI. A True value confirms active UEFI Secure Boot. See Microsoft reference for related commands on Secure Boot.
Linux: Run sudo mokutil –sb-state to check status. Export variables with efi-readvar for deeper validation of UEFI Secure Boot parameters.
Export and Analyze Variables
Windows: Use Get-SecureBootUEFI to export PK, KEK, DB, and DBX contents for UEFI Secure Boot assessment.
Linux: Use efi-readvar to export and validate certificates and hashes.
Analyze exports with NSA GitHub tools to detect test keys, unexpected signers, and missing revocations. Visit the NSA repository: NSA Cyber GitHub.
Highlighted Bootkit Threats and Vulnerabilities
PKFail
PKFail exposed devices that shipped with untrusted test certificates, allowing bypass of UEFI Secure Boot by abusing non-production keys that were never removed.
BlackLotus (CVE-2023-24932)
BlackLotus exploited bootloader flaws to disable enforcement while interfaces still reported UEFI Secure Boot as enabled. See the NVD entry for details: CVE-2023-24932.
BootHole
BootHole flaws in GRUB enabled arbitrary code execution via malformed configurations and could overwhelm DBX storage on older hardware when revocations expanded.
Expected Secure Boot Configuration
CISA and NSA indicate a healthy UEFI Secure Boot baseline includes:
- PK: A system vendor certificate, not test or placeholder keys
- KEK: Vendor and Microsoft 2011 and 2023 keys present and valid
- DB: Microsoft CAs plus relevant vendor entries with correct placement
- DBX: Revocation hashes for known bad binaries without duplicates
When anomalies appear, restore defaults in UEFI setup or apply firmware and OS updates that deliver signed capsule updates.
The guidance stresses auditing modes and avoiding CSM to maintain a verifiable boot chain. For broader supply chain context, review this analysis of NPM package compromises.
Operational Recommendations for Enterprises
Integrate UEFI Secure Boot checks into procurement and supply chain risk management so hardware never ships with test or permissive keys. Customize keys for tighter control instead of disabling features.
Build regular verification into endpoint hygiene, use NSA tools to compare variables at scale, and track Microsoft certificate transitions to prevent trust gaps that affect UEFI Secure Boot.
Related resources that can complement UEFI Secure Boot audits and data protection:
Use these options alongside UEFI Secure Boot validation to improve resilience:
Implications for Enterprise Security Programs
Correctly implemented UEFI Secure Boot strengthens the earliest trust boundary, blocks unsigned loaders, and constrains persistence that can survive OS reinstalls. Routine audits, certificate hygiene, and vendor key customization reduce exposure to BlackLotus, BootHole, and PKFail.
Integrating UEFI Secure Boot checks into lifecycle management improves compliance and resilience against firmware attacks.
Mistakes during certificate transitions or DBX updates can disrupt legitimate boot paths, especially on older hardware with limited DBX capacity.
Enterprises should plan change windows, test thoroughly, and coordinate firmware, OS, and capsule updates. Overreliance on default OEM settings creates blind spots, so disciplined and recurring UEFI Secure Boot audits are required.
Conclusion
CISA and NSA make clear that UEFI Secure Boot is a foundational control when it is configured correctly and continuously verified. It stops untrusted binaries at the earliest stage.
Security teams should confirm enforcement, validate PK, KEK, DB, and DBX, and remediate misconfigurations quickly. Use NSA tools to scale reviews and keep pace with certificate updates and revocations that affect UEFI Secure Boot.
With disciplined audits and strong SCRM practices, enterprises can sustain boot integrity against evolving bootkits. Review CISA and NSA resources and incorporate them into baseline configurations for UEFI Secure Boot across all managed devices.
Questions Worth Answering
What is UEFI Secure Boot?
It is a firmware control that verifies boot components using trusted keys and hashes, preventing unsigned or tampered code from executing.
Why is CISA’s guidance important now?
Recent bootkit campaigns such as BlackLotus and BootHole show that weak or misconfigured UEFI Secure Boot can be bypassed, which demands stronger audits.
How do I check if Secure Boot is enabled?
On Windows, run Confirm-SecureBootUEFI in PowerShell. On Linux, run sudo mokutil –sb-state. True or enabled indicates enforcement.
Which variables should be audited?
Audit PK, KEK, DB, and DBX for valid signers and current revocations as part of UEFI Secure Boot checks.
Should Secure Boot be disabled for troubleshooting?
No. NSA advises customizing keys and auditing thoroughly instead of disabling, which increases risk.
Where can I get analysis tools?
Use NSA’s GitHub tooling to analyze exported variables and compare against expected baselines for UEFI Secure Boot.
Does BitLocker or TPM replace Secure Boot?
No. They are complementary controls. UEFI Secure Boot protects the boot chain, while TPM and BitLocker protect data and integrity at other layers.
About CISA
The Cybersecurity and Infrastructure Security Agency is the United States lead agency for cybersecurity and critical infrastructure resilience.
CISA publishes alerts, advisories, and best practices to help organizations defend against cyber threats and improve readiness.
The agency partners with public and private sectors to reduce risk, strengthen national resilience, and advance trusted security standards.
