Secure Boot is a UEFI firmware feature that verifies the digital signature of every boot component before running it, so that a computer starts only bootloaders, firmware drivers and operating system loaders signed by trusted keys. As the first link in the boot chain of operating systems, it is configured in the UEFI setup and stored in protected firmware variables.
The goal is to stop bootkits and rootkits that load before the operating system and can hide from antivirus software. Secure Boot does not encrypt anything and does not protect a running system; it establishes a verified starting point on which the operating system builds its own protections.
How Secure Boot verifies the boot chain
Secure Boot is defined in the UEFI specification. When the firmware loads an executable, such as a graphics card option ROM, a boot manager or a shim loader, it computes the file’s hash and checks its Authenticode signature against keys stored in the firmware. Only code that matches an allowed key or hash, and is not on the revocation list, is allowed to run.
Trust then passes along a chain of verification. The firmware verifies the bootloader, the bootloader verifies the operating system kernel, and the kernel verifies drivers. Each link is responsible for checking the next, so a single unsigned stage that skips verification breaks the protection for everything after it.
Changes to the key databases themselves must be signed by a higher-level key, which prevents malware with operating system access from simply adding its own key. Only someone with physical access to firmware setup, or holding the right private key, can alter the trust configuration.
The key hierarchy behind Secure Boot
Secure Boot relies on a small hierarchy of keys and databases stored in authenticated UEFI variables. Understanding this hierarchy explains how vendors, operating systems and administrators share control of the boot process.
| Element | Role | Typical owner |
|---|---|---|
| Platform key (PK) | Root of trust; authorizes changes to KEK | Motherboard or PC manufacturer |
| Key exchange key (KEK) | Authorizes updates to db and dbx | Manufacturer and operating system vendor |
| Signature database (db) | Certificates and hashes allowed to boot | Operating system vendors and third parties |
| Forbidden database (dbx) | Revoked certificates and hashes | Updated by operating system vendors |
| Machine owner key (MOK) | Extra keys trusted by the shim loader | System administrator on Linux |
Most PCs ship with Microsoft certificates in db, one for Windows and one for third-party UEFI components such as Linux shim loaders and some option ROMs. Linux distributions boot under Secure Boot through a Microsoft-signed shim that then verifies the distribution’s own GRUB and kernel.
Revocation through dbx updates is essential. When a signed bootloader turns out to be vulnerable, adding its hash or certificate to dbx prevents attackers from using that old, legitimately signed file to bypass protection.
Firmware modes and settings on motherboards
Motherboard firmware typically exposes Secure Boot through a few related settings. Their names vary by vendor, but the underlying states are standardized, and they determine whether the platform enforces signatures or only records them.
| Setting or state | Meaning | Practical effect |
|---|---|---|
| Setup mode | No platform key is enrolled | Keys can be installed without authorization |
| User mode | Platform key enrolled | Signatures are enforced when Secure Boot is on |
| Standard or default keys | Factory key set loaded | Windows and signed Linux loaders boot |
| Custom mode | Owner manages keys manually | Allows own keys and removal of vendor keys |
| CSM (legacy BIOS support) | Compatibility support module enabled | Usually must be disabled for Secure Boot |
Secure Boot requires UEFI boot from a GPT-partitioned disk; a legacy BIOS boot through CSM bypasses it entirely. This is why enabling it on an older installation sometimes requires converting the system disk from MBR to GPT first.
Secure Boot compared with TPM and measured boot
Secure Boot is often confused with the TPM, another security feature on modern motherboards. They are complementary: Secure Boot enforces which code may run, while the TPM records and attests what actually ran.
| Mechanism | Main function | What it protects against |
|---|---|---|
| Secure Boot | Blocks unsigned or revoked boot code | Bootkits and unauthorized loaders |
| Measured boot | Hashes each boot stage into TPM registers | Undetected changes to the boot chain |
| TPM | Stores measurements and keys in hardware | Key theft and tampering with boot records |
| Disk encryption with TPM | Releases keys only for expected measurements | Offline access to a stolen drive |
Because the Secure Boot state is part of the TPM measurements, changing Secure Boot settings can cause full-disk encryption such as BitLocker to request its recovery key at the next start. Administrators should therefore suspend encryption protection before changing firmware settings.
Limitations, pitfalls and troubleshooting
Secure Boot raises the bar for boot-level attacks, but it is only as strong as its keys and revocation lists. Signed but vulnerable bootloaders, leaked platform keys and firmware flaws have all allowed bypasses in practice, which is why timely firmware and dbx updates matter.
- Unsigned kernel modules such as some graphics or virtualization drivers on Linux fail to load until they are signed and the key is enrolled as a MOK.
- Older graphics cards without UEFI GOP firmware may produce no display when CSM is disabled for Secure Boot.
- Disabling Secure Boot to fix a boot problem often hides the real cause, such as an outdated bootloader blocked by a dbx update.
- Resetting firmware to defaults can restore factory keys and remove custom keys, which may stop self-signed loaders from booting.
- Some operating systems and anti-cheat systems require Secure Boot, so leaving it off can block installations or applications.
The safe default for almost every PC is Secure Boot enabled with the standard keys. Custom key management is worthwhile only for organizations or advanced users who sign their own bootloaders and want to remove trust in third-party certificates.
A non-technical view
When a computer starts, it runs a short series of programs before the operating system appears. Secure Boot acts like a guard checking identity badges at each step. Every program must carry a valid digital signature from a trusted maker, or it is not allowed to start.
This stops a dangerous kind of malware that tries to sneak in at startup, where it could hide from security tools. Secure Boot does not slow the computer down, and for most people the best choice is simply to leave it switched on.
A concrete example
An IT technician prepares office desktops for a Windows upgrade that requires Secure Boot. Several older machines were installed in legacy BIOS mode with MBR disks, so the firmware shows Secure Boot as unavailable while CSM is enabled.
The technician first suspends BitLocker protection, converts each system disk from MBR to GPT with the operating system’s built-in tool, then disables CSM, loads the standard factory keys and enables Secure Boot. After a restart, the operating system reports Secure Boot as on, encryption resumes without asking for recovery keys, and the machines meet the upgrade requirements with no reinstallation and no data loss.