Secure Boot Overview
Applies To: Windows 8, Windows 8.1, Windows Server 2012, Windows Server 2012 R2
Secure Boot is a security standard developed by members of the PC industry to help make sure that your PC boots using only software that is trusted by the PC manufacturer.
When the PC starts, the firmware checks the signature of each piece of boot software, including firmware drivers (Option ROMs) and the operating system. If the signatures are good, the PC boots, and the firmware gives control to the operating system.
The following versions of Windows support Secure Boot: Windows 8.1, Windows Server 2012 R2, Windows RT 8.1, Windows 8, Windows Server 2012, and Windows RT.
Did you see the "Secure Boot isn't configured correctly" watermark after upgrading to Windows 8.1, Windows Server 2012 R2, or Windows RT 8.1?
We've released a patch that gets rid of the watermark.
Windows 8.1 and Windows Server 2012 R2 users can install a patch to remove the watermark immediately: Microsoft Knowledge Base Article ID 2902864.
For more info, see Secure Boot isn't configured correctly: troubleshooting.
Frequently asked questions:
Do I need Secure Boot in order to upgrade to the latest version of Windows?
No. There are no additional hardware requirements from Windows Vista or Windows 7.
Secure Boot is an optional feature that can be activated by a PC manufacturer to enhance the security of a PC, and you’ll find it on all new logo-certified Windows 8.1, Windows RT 8.1, Windows 8 and Windows RT PCs.
What happens if my new hardware isn’t trusted?
Your PC may not be able to boot. There are two kinds of problems that can occur:
The firmware may not trust the operating system, option ROM, driver, or app because it is not trusted by the Secure Boot database.
Some hardware requires kernel-mode drivers that must be signed. Note: many older 32-bit (x86) drivers are not signed, because kernel-mode driver signing is a recent requirement for Secure Boot. For more info, see Secure boot feature signing requirements for kernel-mode drivers.
How can I add hardware or run software or operating systems that haven’t been trusted by my manufacturer?
You can check for software updates from Microsoft and/or the PC manufacturer.
You can contact your manufacturer to request new hardware or software to be added to the Secure Boot database.
For most PCs, you can disable Secure Boot through the PC’s BIOS. For more info, see Disabling Secure Boot.
For logo-certified Windows RT 8.1 and Windows RT PCs, Secure Boot is required to be configured so that it cannot be disabled.
How do I edit my PC’s Secure Boot database?
This can only be done by the PC manufacturer.
Secure Boot requires a PC that meets the UEFI Specifications Version 2.3.1, Errata C or higher.
Secure Boot is supported for UEFI Class 2 and Class 3 PCs. For UEFI Class 2 PCs, when Secure Boot is enabled, the compatibility support module (CSM) must be disabled so that the PC can only boot authorized, UEFI-based operating systems.
Secure Boot does not require a Trusted Platform Module (TPM).
To enable kernel-mode debugging, enable TESTSIGNING, or to disable NX, you must disable Secure Boot. For detailed info for OEMs, see Windows 8.1 Secure Boot Key Creation and Management Guidance.
How it works
The OEM uses instructions from the firmware manufacturer to create Secure Boot keys and to store them in the PC firmware. For info, see Windows 8.1 Secure Boot Key Creation and Management Guidance, Secure Boot Key Generation and Signing Using HSM (Example), or contact your hardware manufacturer.
When you add UEFI drivers (also known as Option ROMs), you'll also need to make sure these are signed and included in the Secure Boot database. For info, see UEFI Validation Option ROM Validation Guidance.
When Secure Boot is activated on a PC, the PC checks each piece of software, including the Option ROMs and the operating system, against databases of known-good signatures maintained in the firmware. If each piece of software is valid, the firmware runs the software and the operating system.
Signature Databases and Keys
Before the PC is deployed, the OEM stores the Secure Boot databases onto the PC. This includes the signature database (db), revoked signatures database (dbx), and Key Enrollment Key database (KEK) onto the PC. These databases are stored on the firmware nonvolatile RAM (NV-RAM) at manufacturing time.
The signature database (db) and the revoked signatures database (dbx) list the signers or image hashes of UEFI applications, operating system loaders (such as the Microsoft Operating System Loader, or Boot Manager), and UEFI drivers that can be loaded on the individual PC, and the revoked images for items that are no longer trusted and may not be loaded.
The Key Enrollment Key database (KEK) is a separate database of signing keys that can be used to update the signature database and revoked signatures database. Microsoft requires a specified key to be included in the KEK database so that in the future Microsoft can add new operating systems to the signature database or add known bad images to the revoked signatures database.
After these databases have been added, and after final firmware validation and testing, the OEM locks the firmware from editing, except for updates that are signed with the correct key or updates by a physically present user who is using firmware menus, and then generates a platform key (PK). The PK can be used to sign updates to the KEK or to turn off Secure Boot.
OEMs should contact their firmware manufacturer for tools and assistance in creating these databases. For more info, see Windows 8.1 Secure Boot Key Creation and Management Guidance.
After the PC is turned on, the signature databases are each checked against the platform key.
If the firmware is not trusted, the UEFI firmware must initiate OEM-specific recovery to restore trusted firmware.
If there is a problem with Windows Boot Manager, the firmware will attempt to boot a backup copy of Windows Boot Manager. If this also fails, the firmware must initiate OEM-specific remediation.
After Windows Boot Manager has started running, if there is a problem with the drivers or NTOS kernel, Windows Recovery Environment (Windows RE) is loaded so that these drivers or the kernel image can be recovered.
Windows loads antimalware software.
Windows loads other kernel drivers and initializes the user mode processes.
For more information, see the whitepaper: Secured Boot and Measured Boot: Hardening Early Boot Components Against Malware.