How to Enable Secure Boot, and What to Check Before You Do

What it checksWhat Secure Boot actually checks

The setting is one line in a BIOS menu and the mechanism underneath it is a small public key infrastructure held in firmware.

The platform key, the PK. One key, owned by whoever controls the machine, which in practice means the manufacturer. It authorizes changes to everything below it.

Key exchange keys, the KEK. Keys that are allowed to update the signature databases. Microsoft holds one on essentially every consumer machine, which is how Windows boot components get their signatures trusted.

The allowed database, db. The signatures and hashes of boot loaders the firmware will run. A signed Windows boot loader matches an entry here.

The forbidden database, dbx. Signatures and hashes that are explicitly refused, even if something in db would otherwise allow them. This is the revocation list, and it grows when a signed boot loader turns out to be exploitable.

At power on, the firmware checks the boot loader against those databases before executing it. Anything unsigned, signed by a key not in db, or listed in dbx does not run, and the machine stops with a security violation rather than booting.

Two limits are worth stating plainly. Secure Boot verifies the boot chain and stops there, so it says nothing about anything the operating system loads afterward.

And it is a check against a list, not an opinion about whether code is malicious: a signed boot loader with a vulnerability in it passes, which is exactly why dbx exists and why firmware updates that extend it matter.

Check firstCheck before you change anything

Two values decide whether this is a toggle or a project. Both are in one place.

Press the Windows key and R, type msinfo32, press Enter, and read System Summary. Two lines matter.

BIOS Mode says either UEFI or Legacy. Legacy means the machine boots the old way, which is the difference between UEFI and BIOS doing the deciding, and Secure Boot cannot be enabled at all until that changes.

Secure Boot State says On, Off, or Unsupported. Off means it is available and disabled. Unsupported usually means the machine is in legacy mode, and occasionally means genuinely old firmware.

If that line says Off while the BIOS menu says Secure Boot is enabled, the machine is in setup mode and the firmware is not enforcing anything. That case has its own section below, because the fix is not the toggle.

A third value is worth checking at the same time, because it comes up in the same conversation: press Windows and R again and run tpm.msc to see whether a TPM is present and what version. Secure Boot does not require a TPM, and Windows 11 requires both, which is why the two are usually discussed together.

Write down what those three say before touching anything. If BIOS Mode already says UEFI and Secure Boot says Off, skip to the vendor steps: you are two minutes from done.

ConvertingIf the machine is in legacy mode

This is the case that turns a toggle into a task, and it is the common one on any machine imaged before about 2020 or reimaged from an old template.

Legacy mode means the disk is partitioned as MBR and the boot loader lives in the first sector. UEFI needs a GPT disk with an EFI system partition holding a boot file. Those are different layouts, and the machine cannot simply be switched.

Windows includes a converter that does this in place, without reinstalling and without touching data.

mbr2gpt /validate /allowFullOS
mbr2gpt /convert /allowFullOS

The first command checks whether the disk can be converted and changes nothing. Read what it says. If validation fails it will name the reason, and the usual reasons are too many partitions or not enough room at the end of the disk for the EFI partition.

The second performs the conversion. Then, and only then, change the firmware from legacy to UEFI, because the machine will not boot in the mode its disk is not laid out for.

Three cautions that are not optional.

Back up first. The conversion is reliable and it is a change to the partition table of the boot disk, which is the one operation where a failure means starting from an image.

Do the disk before the firmware. Convert, then reboot into firmware and switch the mode. Doing it the other way produces a machine that will not start, and the fix is to switch back.

Watch for encryption. BitLocker must be suspended before the conversion and resumed afterwards, or the machine asks for a recovery key it may not have to hand. That recovery key is the thing to have printed before you begin.

The stepsThe steps, in order

Assuming the checks above came back UEFI and Off, this is how to enable Secure Boot from start to finish. It takes about two minutes.

1. Note your BitLocker recovery key. In Windows, select Settings, then Privacy and security, then Device encryption or BitLocker. Select Back up your recovery key and keep it somewhere off this device. Skip this step only if the disk is not encrypted.

2. Suspend BitLocker. Select Suspend protection on the encrypted drive. This avoids a recovery prompt after the firmware change, and protection resumes on its own at the next restart.

3. Restart into the firmware settings. Select Settings, then System, then Recovery, then Restart now under Advanced startup. When the blue screen appears, select Troubleshoot, then Advanced options, then UEFI Firmware Settings, then Restart. This avoids having to press a key on the keyboard at exactly the right moment.

4. Find the Secure Boot setting. The location differs per vendor and the table above says where. On most devices it is on a screen under a Security or a Boot heading. On an ASUS board, press F7 first to enter Advanced mode, or the setting is not shown at all.

5. Set a supervisor password if the option is greyed out. Several vendors require one before Secure Boot can be changed. Set it, note it somewhere durable, and the option becomes available.

6. Disable CSM. It may be called Legacy Support, Legacy Boot or Compatibility Support Module. Secure Boot and CSM cannot both be on, so this has to go off first.

7. Select Secure Boot and set it to Enabled. Where there is a mode option beside it, select Standard rather than Custom. Custom mode is for managing your own keys and is not what you want here.

8. Save and exit. Press F10 on most devices, or select Save and Exit from the menu. The computer restarts on its own.

9. Confirm it took effect. Back in Windows, press the Windows key and R on the keyboard, enter msinfo32, and check that Secure Boot State on that screen now reads On. A setting that failed to save looks exactly like one that worked, so this step is not optional.

10. Resume BitLocker if you suspended it and it has not resumed on its own.

If the device does not start after step 8, return to the firmware settings, select Secure Boot and set it back to Disabled, and enable CSM again. Nothing is damaged, and the cause is in the sections below.

Enabled, not activeEnabled in the firmware but not active

This is the most confusing state in the whole subject, and it is common enough to have its own name in vendor menus. The BIOS says Secure Boot is enabled, and Windows reports it as off.

What has happened. Secure Boot has two operating modes. In user mode the platform key is enrolled and the firmware enforces the signature check. In setup mode there is no platform key, so the databases can be written freely and the firmware enforces nothing.

A machine in setup mode with the toggle on is enabled and not active, which is exactly what some vendors print on the screen.

Setup mode is the intended state for a manufacturer provisioning keys, and machines arrive in it after a firmware reset, a CMOS clear, a battery change, or somebody switching Secure Boot to custom mode to enroll their own keys and not finishing.

How to check which mode you are in.

msinfo32                                Windows: Secure Boot State and BIOS Mode
Confirm-SecureBootUEFI                  PowerShell: True only when it is actually enforcing
mokutil --sb-state                      Linux: reports enabled or disabled

Confirm-SecureBootUEFI is the useful one here, because it returns False on a machine whose firmware menu says enabled. That disagreement is the diagnosis.

The fix is to enroll the default keys. On the BIOS security screen, look for a setting named Restore Factory Keys, Install Default Secure Boot Keys, or Enroll all factory default keys, and select it.

Applying it writes the manufacturer platform key and the standard databases, which moves the firmware into user mode, and Secure Boot starts enforcing on the next boot. Save and exit, and confirm from Windows rather than from the same screen.

Two other causes produce the same symptom and are worth ruling out in the same visit. CSM is still enabled, which keeps the machine in a compatibility mode where Secure Boot cannot become active whatever the toggle says.

And the disk is still MBR, which means the machine is booting in legacy mode and the check has nothing to apply to.

One warning before enrolling keys on a machine that dual boots. Restoring factory keys removes any machine owner key that was enrolled to sign a custom kernel or an out of tree driver, so that installation stops booting until the key is enrolled again.

TroubleshootingWhen it will not turn on, or breaks something

The setting is greyed out on screen. Almost always a supervisor password is required first, or CSM is still enabled. Set the password, disable CSM, and the option becomes available to select.

The device will not boot after enabling it. The boot loader is unsigned or the disk is still MBR. Enter the firmware settings again, select Secure Boot and set it off, save and exit, and start again from the check step.

A dual boot Linux installation stops working. Major distributions ship a signed shim and work fine. A custom kernel, a self compiled driver, or an out of tree module does not, and the answer is either signing them yourself with a machine owner key or accepting Secure Boot off on that machine.

A graphics card or add in card fails. Older cards carry unsigned option ROMs that Secure Boot will not run. There is no fix other than newer hardware or leaving it off.

A virtual machine has no option. Secure Boot on a guest depends on the hypervisor offering it, and on the virtual machine being of a generation that supports it. On Hyper-V that means generation 2, and a generation 1 machine cannot be converted.

Windows asks for a BitLocker recovery key. Firmware changes alter the measurements the key is sealed against. Suspending BitLocker before the change avoids it, and the recovery key gets you back in if you did not.

Why botherWhy it is worth doing

Secure Boot checks a signature at the one moment nothing else can check anything. Before it runs, no operating system exists, no antivirus is loaded, and nothing is watching. That is exactly the window a bootkit uses, and malware that installs itself there survives a disk format because it does not live on the disk.

Three practical reasons it now shows up on a task list.

Windows 11 requires it, along with TPM 2.0, so any upgrade project meets this.

Several security features depend on it. Memory integrity and other virtualization based protections check for it before they will enable.

Compliance frameworks and insurers ask. It appears in hardening baselines, and answering the question honestly requires knowing the state of the estate rather than the state of one machine.

It is worth being clear about the limit. Secure Boot verifies the boot chain and nothing after it. It does not stop malware that arrives later, and it is not a substitute for anything else. It closes one window, cheaply and permanently.

At scaleDoing it across an estate

One machine is a toggle. Two hundred is a different job, and the shape of it is worth knowing before starting.

Report before you change. The state of every machine, gathered centrally. In PowerShell, Confirm-SecureBootUEFI returns true or false and throws on a legacy machine, which is itself the answer. Collect that through whatever management tooling you already run.

Split the estate in two. Machines already in UEFI mode need only the firmware toggle. Machines in legacy mode need conversion first, and they are the ones that need a maintenance window and a tested backup.

Firmware settings can often be scripted. Every major vendor ships a tool for this: Dell Command Configure, HP BIOS Configuration Utility, Lenovo Thin Installer among them. On a server, the management controller does it over the network. Doing two hundred machines by hand is a choice rather than a requirement.

Do the awkward ones last. Machines with unsigned drivers, old add in cards, or dual boot arrangements. Knowing which those are before you start is the difference between a rollout and a series of interruptions.

ComparisonWhere each vendor hides the Secure Boot setting

The setting sits in the same place conceptually on every machine and has a different name in each vendor BIOS. Enter the firmware settings with the setup key for your vendor, or from Windows: select Settings, then System, then Recovery, then Restart now under Advanced startup, then select Troubleshoot, Advanced options and UEFI Firmware Settings.

Two vendor quirks that stop people. Acer and several others will not let you enable Secure Boot until a supervisor password is set in the BIOS. The option is visible on screen and greyed out, which reads as unsupported.

Set the password, then the setting becomes available to select. ASUS boards hide it in Advanced mode. The default simple BIOS screen does not show the setting at all, and the F7 key on the keyboard switches between the two views.

While in the firmware settings, two settings usually need to change together. Disable CSM, sometimes called Legacy Support or Legacy Boot, because it and Secure Boot are mutually exclusive. And where the boot mode is a choice between UEFI and Legacy, select UEFI.

Press F10 on the keyboard to save and exit, and let the machine restart. Then confirm with msinfo32 rather than assuming, because a BIOS setting that did not save looks exactly like one that did.

FAQFrequently asked questions

Keep readingRelated concepts

Read next · Firmware and boot What Is a BIOS? What the firmware is doing before any of this, and where the setting lives. Open this next12 min

• Firmware and boot · 10 min UEFI vs BIOS Why the machine has to be in UEFI mode before any of this is available.
• Disks and drives · 10 min MBR vs GPT The other prerequisite: a GPT disk. A machine still on MBR cannot enforce any of this.
• Identification · 9 min How to Check Which Motherboard You Have, and Why WMIC No Longer Works The other job msinfo32 does in one screen.
• Firmware and boot · 10 min What a BIOS Update Does, and Why the Old Advice Changed What the certificates are for.
• Cryptography · 10 min The BitLocker Recovery Key, and Why the Screen Appeared The neighboring setting.
• Firmware and boot · 9 min What Is ROM, and Why Read Only Is No Longer Accurate How the integrity check is switched on.
• Directory and identity · 13 min Group Policy Explained The configuration mechanism that covers everything above the firmware.