A Windows 11 upgrade, a game's anti-cheat or an audit question often lands on the same setting. Secure Boot is either on, off, or unsupported, and each answer leads somewhere different. Here's how to check if Secure Boot is enabled, how to turn it on when it isn't, and what the 2026 certificate change means for machines that already have it.
TL;DR
- Check in seconds with
msinfo32(Secure Boot State),Confirm-SecureBootUEFIin an admin PowerShell, or Windows Security under Device security. - Enable it in firmware setup. Reach it from Windows through Advanced startup, then UEFI Firmware Settings.
- If it won't turn on, the PC is almost always booting in Legacy (CSM) mode from an MBR disk.
mbr2gptconverts the disk without wiping it. - Microsoft's 2011 Secure Boot certificates expire in 2026. The Windows Production PCA 2011 goes on 19 October 2026, and devices need the 2023 replacements to keep receiving boot-level fixes.
- Check the new certificates with the
UEFICA2023Statusregistry value, then report both answers across the fleet from one script.
What Secure Boot Does
Secure Boot is a UEFI firmware feature that only lets signed code run before Windows starts. The firmware checks each boot component against a list of trusted signatures. Anything unsigned or revoked gets blocked before it can load.
That list lives in a small set of firmware databases. The Platform Key (PK) belongs to the PC maker and controls who can change the rest. The Key Exchange Key (KEK) signs updates to the two lists that do the daily work: the allowed database (DB) and the forbidden database (DBX). Windows Boot Manager is checked against DB, and known-bad bootloaders sit in DBX.
This chain is why Secure Boot stops bootkits. Malware that tampers with the boot manager breaks its signature, and the firmware refuses to run it. It also explains the 2026 certificate work later in this guide: the certificates in KEK and DB are the ones reaching expiry.
How to Check if Secure Boot Is Enabled
Four checks answer the question. Two work from Windows without touching firmware, one is scriptable, and one is the fallback when Windows won't boot.
System Information (msinfo32)
Press Win+R, type msinfo32, and open System Summary. Two lines matter:
- Secure Boot State: On, Off, or Unsupported.
- BIOS Mode: UEFI or Legacy.
On with UEFI means you're done. Off with UEFI means the feature exists and is switched off in firmware. Unsupported almost always pairs with Legacy, which means the PC is booting the old way and Secure Boot can't run until that changes.
PowerShell: Confirm-SecureBootUEFI
For scripts and remote checks, open PowerShell as administrator:
powershellConfirm-SecureBootUEFI
It returns True when Secure Boot is on and False when it's off. Two error messages mean something else. "Cmdlet not supported on this platform" means the PC is in Legacy BIOS mode or has no UEFI Secure Boot support. "Unable to set proper privileges. Access was denied." means the shell isn't elevated, so run it again as administrator.
To see the boot mode alongside it, $env:firmware_type returns UEFI or Legacy.
Windows Security
Open Windows Security and go to Device security. On current Windows 10 and 11 builds, a Secure Boot section shows whether it's on and, since April 2026, whether its certificates are up to date. More on that status below.
The Firmware Setup Screen
If Windows won't start, check in firmware setup. The setting usually sits under a Boot, Security or Authentication tab and reads Enabled or Disabled. Some boards add a Secure Boot Mode (Standard or Custom) and a key state. "Setup Mode" there means the keys were cleared and Secure Boot won't enforce anything, even if the toggle says Enabled.
On Linux, mokutil --sb-state gives the same answer from a terminal.
This short walkthrough shows the Windows side of the check:
Whichever check you use, read the boot mode with it. "Off" and "Unsupported" look similar in a report and need very different fixes.
How to Enable Secure Boot
When the check says Off and BIOS Mode says UEFI, the fix is one firmware toggle.
Get into firmware setup from Windows so you don't have to race a boot key. Go to Settings, System, Recovery, and select Restart now next to Advanced startup. Then pick Troubleshoot, Advanced options, UEFI Firmware Settings, and Restart. The PC reboots straight into setup.
Find the Secure Boot option, set it to Enabled, and save with the vendor's save key (usually F10). If the option is greyed out, look for a prerequisite on the same screen: CSM has to be off, or a supervisor password has to be set before the firmware lets you change it. If the key state shows Setup Mode, choose the option to install or restore the factory default keys first.
If the drive is encrypted, suspend BitLocker before you change anything. Secure Boot state is part of what BitLocker measures, so flipping it can drop the next boot into a recovery-key prompt. Run Suspend-BitLocker -MountPoint C: -RebootCount 1 first and confirm the recovery key is escrowed. Our guide to BitLocker on Windows 10 covers where those keys should live.
Secure Boot and the TPM often get changed in the same visit, since Windows 11 checks both. If the TPM is also off, our guide to enable TPM 2.0 walks through the vendor menu names.
The question comes up on every kind of hardware, including small form factor PCs where the firmware menus differ from a desktop board:
Does Windows 11 Need Secure Boot On?
Microsoft's Windows 11 requirement is a PC that is "UEFI, Secure Boot capable". Capable, not enabled. The upgrade check wants UEFI firmware that supports Secure Boot, which is why a PC in Legacy mode fails it even when the hardware could pass.
In practice, turn it on anyway. A machine that already boots in UEFI mode loses nothing by enabling it, and the 2026 certificate work only protects devices where Secure Boot enforces. Some software now checks for it as well. Anti-cheat systems in several online games refuse to start without it, which explains a good share of the "is Secure Boot on" questions that reach a help desk from home users.
For a business fleet, treat "capable but off" as a finding. It passes the Windows 11 check and still leaves the boot chain unguarded.
Why Secure Boot Won't Turn On
When the toggle is missing, greyed out, or the PC won't boot after you flip it, the cause is usually one of three things.
The PC boots in Legacy (CSM) mode. The Compatibility Support Module lets UEFI firmware pretend to be an old BIOS. Secure Boot can't run in that mode. Microsoft's Windows 11 guidance says to switch the boot mode from Legacy (CSM) to UEFI before changing Secure Boot.
The system disk is MBR. This is the trap. A Windows install made in Legacy mode sits on an MBR disk, and UEFI mode can only boot from GPT. Turn CSM off without converting and the PC finds nothing to boot. Our explainer on what UEFI is covers why the two partition styles don't mix.
Check the partition style first with Get-Disk, and read the Partition Style column. If it says MBR, Windows ships a converter that keeps your data:
powershellmbr2gpt /validate /allowFullOS mbr2gpt /convert /allowFullOS
Per Microsoft's MBR2GPT documentation, the disk can have at most three primary partitions and no extended ones, and BitLocker protection must be suspended. After a successful conversion, the firmware has to be switched to UEFI mode or the disk won't boot. So the order is: suspend BitLocker, validate, convert, reboot into firmware, turn CSM off, turn Secure Boot on.
The keys are missing. A board in Setup Mode has no Platform Key, so Secure Boot can't enforce. Restoring the factory keys fixes it. The same menu sometimes appears after a firmware reset or a board replacement.
If the TPM also vanished after firmware changes, that's a separate problem with its own fix, covered in TPM device not detected.
Secure Boot on Virtual Machines
Virtual machines have their own Secure Boot switch, separate from the host's.
In Hyper-V, only Generation 2 VMs support it. The setting sits in the VM's Security settings, with a template that decides which certificates it trusts. "Microsoft Windows" suits Windows guests. Linux guests usually need "Microsoft UEFI Certificate Authority", since their shim bootloader is signed through that CA. A Generation 1 VM has no UEFI, so Confirm-SecureBootUEFI inside it reports the cmdlet as unsupported, and no guest setting will change that.
In VMware, the VM needs EFI firmware selected before the Secure Boot checkbox appears in its boot options. Guests created years ago on BIOS firmware need the same MBR-to-GPT thinking as a physical PC.
VMs matter for the 2026 certificate change too. A guest's Secure Boot databases belong to the virtual firmware, so check the 2023 status inside each Windows guest rather than assuming the host result covers it.
The 2026 Secure Boot Certificate Expiry
Machines that pass every check above still have one more question in 2026. The Microsoft certificates that Secure Boot has trusted since 2011 are expiring, and Microsoft is replacing them with 2023 versions.
Microsoft Support lists three expiring certificates. The KEK CA 2011 expired on 24 June 2026 and the Microsoft UEFI CA 2011 on 27 June 2026. The Windows Production PCA 2011, which signs Windows Boot Manager, expires on 19 October 2026. Our BIOS update guide covers the full timeline and the firmware updates some models need first.
A device that misses the update keeps booting. The cost is quieter. In Microsoft's words, it "will no longer be able to receive new security protections for the early boot process", which covers Boot Manager updates, DBX revocations and fixes for new bootkits.
For IT, the job has three parts. Confirm Secure Boot is on, since a machine with it off gets none of this. Confirm the 2023 certificates landed on every device that has it on. Then chase the stragglers, which are usually devices waiting on an OEM firmware update or ones where the update errored.
How to Check if the 2023 Certificates Are Applied
There are three ways to check, from quickest to most scriptable.
Windows Security. Under Device security, Secure Boot now shows a certificate status. Microsoft's labels are "Fully updated", "Not yet updated", and "Requires action", which means an update exists that can't be delivered to this device.
The registry. Windows records progress in one value:
powershellGet-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' | Select-Object UEFICA2023Status, UEFICA2023Error
UEFICA2023Status reads NotStarted, InProgress or Updated. UEFICA2023Error stays at 0 on success, so any other number is worth a ticket.
The key update shows up in community threads too:
The firmware database itself. On builds with the April 2026 updates or later, Get-SecureBootUEFI -Name db -Decoded lists the certificates in DB in readable form. Look for Windows UEFI CA 2023. On older builds, this string match does the same job:
powershell[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
Devices Microsoft rates as high confidence get the certificates through Windows Update. For IT-managed rollout, Microsoft documents setting AvailableUpdates to 0x5944 under the SecureBoot key, which deploys all certificates and the new boot manager. A scheduled task at \Microsoft\Windows\PI\Secure-Boot-Update picks it up every 12 hours. Group Policy, Intune and the WinCS APIs are the other supported routes.
When a device sticks, the status tells you where to look. NotStarted for weeks on a machine with Secure Boot on usually means nothing has triggered it yet, so it's waiting on Windows Update's confidence rating or on your opt-in. InProgress often clears after a restart or two, because the firmware variables and the new boot manager are applied around boot. A nonzero UEFICA2023Error points to the firmware refusing the change. Microsoft's Secure Boot troubleshooting guide and the PC maker's latest firmware are the next stops there.
Reporting Secure Boot Across a Fleet
Clicking through Windows Security on fifty machines isn't a report. One script answers both questions per device and returns a row you can sort:
powershell$sb = try { Confirm-SecureBootUEFI -ErrorAction Stop } catch { 'Unsupported' } $svc = Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' -ErrorAction SilentlyContinue [pscustomobject]@{ Computer = $env:COMPUTERNAME Firmware = $env:firmware_type SecureBoot = $sb CA2023 = $svc.UEFICA2023Status CA2023Err = $svc.UEFICA2023Error BootDisk = (Get-Disk | Where-Object IsBoot).PartitionStyle }
Run it elevated, since Confirm-SecureBootUEFI needs admin rights. Every row lands in a group with one next step. Legacy with MBR needs mbr2gpt and a firmware change. UEFI with Secure Boot off needs the firmware toggle. On with NotStarted needs the update triggered or opted in. InProgress usually needs a reboot. Any nonzero error goes to the OEM firmware queue. Updated means done until the next firmware change.
Microsoft's own Intune remediation sample does the same thing at scale. It reads the SecureBoot registry keys plus event IDs 1801 and 1808 in the System log, and reports devices as "Without issue" once Secure Boot is on and UEFICA2023Status reads Updated.
Without Intune, any tool that runs a script across devices and collects the output will do. OpenFrame can run it as a script across a client's devices and gather the results in one place, so the "not yet updated" list shrinks where you can see it.
Rerun the report after each fix round. The Windows Production PCA 2011 date is the one to plan against, since Boot Manager updates signed after it depend on the 2023 certificate being in place.
The Short Version
To check if Secure Boot is enabled, read Secure Boot State and BIOS Mode in msinfo32, or run Confirm-SecureBootUEFI as administrator. Off on UEFI is a firmware toggle. Unsupported on Legacy means an MBR disk, a mbr2gpt conversion, and CSM off before Secure Boot will stick. Suspend BitLocker before any of it.
Then check the 2023 certificates with UEFICA2023Status, because Secure Boot being on no longer means Secure Boot is current. For the firmware side of that change, see what a BIOS update is.

"Fae" Grace Meadows
Lead AI Fairy
Some things defy easy explanation: magic dust, the northern lights… and Flamingo’s AI Angels. Think Charlie’s Angels, reimagined with automation brains and serious RMM (Remote Monitoring & Management) chops. Weird? A little. Effective? Absolutely. That’s the job.
