How Secure Boot works
Secure Boot is a feature of UEFI firmware that checks the digital signature of every piece of code that runs before the operating system. If a bootloader, driver or graphics card option ROM is not signed by a key the firmware trusts, or appears on a revocation list, the firmware refuses to run it.
The UEFI Forum added Secure Boot to the UEFI specification in version 2.3.1 in 2011, and it became standard on PCs with Windows 8. The chain works in steps. The firmware checks the bootloader, the bootloader checks the operating system kernel, and the kernel can go on to check its drivers. Each stage only hands over to code it has verified.
The point is to stop bootkits and rootkits: malware that loads before the operating system and hides from security software. Code that runs that early can survive a reinstall, so blocking it at the firmware is far more effective than trying to detect it later.
The keys behind Secure Boot
Secure Boot decides what is trusted using a small set of key stores held in the firmware. Most computers ship with Microsoft’s certificates in the signature database, because Microsoft signs both Windows and the shim bootloader used by Linux distributions.
| Store | Full name | What it holds | Who controls it |
|---|---|---|---|
| PK | Platform Key | One key that owns the system and signs changes to the KEK | Board maker, or the owner in a custom setup |
| KEK | Key Exchange Key database | Keys allowed to update db and dbx | Board maker and Microsoft |
| db | Signature database | Certificates and hashes of code that may run | Microsoft, the board maker, sometimes the owner |
| dbx | Forbidden signature database | Revoked certificates and hashes of known-bad bootloaders | Updated by Microsoft and firmware releases |
| MOK | Machine Owner Key list (Linux shim) | Extra keys the owner enrols, for example for kernel modules | The system owner |
Microsoft’s original 2011 Secure Boot certificates began expiring in 2026. Microsoft is replacing them with 2023 certificates through Windows Update and firmware updates, so long-life systems that are rarely updated should be checked and updated on a planned schedule.
Secure Boot and TPM 2.0
Secure Boot and the Trusted Platform Module (TPM 2.0) and its role in measured boot do different jobs. Secure Boot enforces: it blocks code that is not signed. The TPM measures: it records a hash of each boot stage in its registers without stopping anything.
Together they let a computer prove its boot chain is unchanged. BitLocker uses the TPM measurements, including whether Secure Boot is on, to decide whether to release the disk encryption key. If someone changes the bootloader or switches Secure Boot off, the drive asks for its recovery key instead of unlocking.
What Secure Boot does not protect against
Secure Boot is one layer, not a full defence. It is worth knowing its limits when planning security for a fleet of computers.
-
//
Malware after start-up. Once the operating system is running, Secure Boot has done its job. Ordinary malware, phishing and network attacks need other controls.
-
//
Signed but vulnerable bootloaders. The BlackLotus bootkit of 2023 used an old, legitimately signed Windows boot manager with a known flaw. The fix is revoking it in dbx, which is why dbx updates matter.
-
//
Physical access to firmware settings. Anyone who can open the setup screen can switch Secure Boot off. A firmware password closes that gap.
-
//
Unsigned drivers you need. Some Linux kernel modules, such as GPU or capture card drivers built on the system, must be signed with an enrolled Machine Owner Key or they will not load.
Secure Boot on industrial and embedded computers
For computers in public places, vehicles, substations or unattended cabinets, physical tampering is a real risk, so Secure Boot is worth enabling. Microsoft recommends it, with TPM 2.0 and BitLocker, for Windows IoT Enterprise industrial PCs, and our guide to upgrading to Windows 11 IoT Enterprise covers the hardware it expects.
Arm and Jetson systems use their own secure boot, set by fusing keys into the processor at production. Once fused, it cannot be undone, so it is planned for production builds rather than development kits.
Fleet images need the same care. A golden image built with Secure Boot on will only boot on systems that trust the same keys, and any driver added later must be signed. Testing the image on the exact hardware revision, with the firmware version it will ship with, avoids a site visit to switch Secure Boot off.
Quick answers on Secure Boot
Secure Boot: common questions
What does Secure Boot do?
It stops unsigned boot code from running. The firmware checks the signature of each bootloader, driver and option ROM before running it, so a bootkit or tampered bootloader is blocked before the operating system starts.
How do I enable Secure Boot?
In the UEFI firmware settings. The system must boot in UEFI mode from a GPT disk, with CSM or legacy boot switched off. Then set Secure Boot to enabled, restoring the factory keys first if the menu offers it.
How do I check if Secure Boot is enabled?
Ask the operating system. On Windows, System Information (msinfo32) shows “Secure Boot State”. On Linux, mokutil –sb-state reports whether it is on.
Why does it say Secure Boot can be enabled when the system is in user mode?
Because no Platform Key is installed. Without a PK the firmware is in setup mode and cannot enforce signatures. Restoring the default or factory keys in the firmware settings installs one and switches it to user mode.
Is Secure Boot only for Windows?
No. Ubuntu, Debian, Red Hat Enterprise Linux and SUSE all boot with Secure Boot on, through a small bootloader called shim that Microsoft signs and that then checks the distribution’s own keys.
Should I turn Secure Boot off?
Usually not. It is safer to sign or enrol the driver or bootloader that is being blocked than to switch the check off for everything.
We enable Secure Boot and TPM 2.0 on the industrial PCs we supply as standard where the operating system supports them, and sign or enrol the drivers each build needs before the system ships.