Windows says Secure Boot is on. The compliance report says the machine is non compliant. Both are reading the same firmware and both are correct, because Secure Boot has more than two states and most tools only report two.
Enabled means the firmware setting is switched on. Active means the firmware is actually checking signatures against a loaded key database. A machine in Setup Mode has Secure Boot enabled and no keys, so it checks nothing and reports as enabled.
BackgroundThe states a machine can be in
UEFI defines several, and four of them turn up in the field.
| State | What it means | Reported as |
|---|---|---|
| Disabled | Off in the firmware | Off, correctly |
| Setup Mode | On, but the key database is empty | Often on, incorrectly |
| User Mode | On, keys loaded, signatures checked | On, correctly |
| Audit Mode | Checking and logging, not blocking | Varies by tool |
Setup Mode is the one that produces the ticket. It exists so that an organization can enroll its own keys during provisioning, and a machine left in it after a firmware reset or a battery change is enforcing nothing at all.
DiagnosisGetting a straight answer
Two commands, and they disagree usefully.
Confirm-SecureBootUEFI
# The states, read from the firmware variables directly
Get-SecureBootUEFI -Name SetupMode
Get-SecureBootUEFI -Name PK
Read them together. SetupMode returning 1 means the key database is empty. An empty or missing Platform Key means the same thing from the other direction: nothing has taken ownership of the firmware, so nothing is being enforced.
The graphical answer is msinfo32, which shows Secure Boot State on its own line. It says On or Off and nothing about Setup Mode, which is exactly why the machine looked compliant.
Before you touch itSuspend BitLocker first
This is the step that turns a five minute firmware change into an afternoon, and it is missing from most instructions.
BitLocker seals its key to a set of platform configuration registers, and on a machine with Secure Boot on, PCR 7 is one of them. PCR 7 measures the Secure Boot configuration itself, including the key database.
Loading the default keys changes the key database, which changes PCR 7, which means the sealed key no longer unseals. The machine comes back to a recovery prompt and asks for a 48 digit number.
Suspend BitLocker for one reboot before entering the firmware, and it reseals itself against the new values on the way back up.
Suspend-BitLocker -MountPoint C: -RebootCount 1
# The same thing from an elevated command prompt
manage-bde -protectors -disable C: -rebootcount 1
One restart is the right number. It covers the trip into firmware and back, and if the machine reboots again for any other reason the protection is already on rather than left suspended on an estate nobody audits.
Have the recovery keys to hand anyway. If the keys are escrowed in Active Directory or Entra, confirm that before the first machine rather than after it, because the recovery prompt is where you find out the escrow was never working.
ReferenceWhat each tool reports, for each state
The disagreement in the ticket is not a bug in any one of these. Each answers a different question, and only one of them answers the one that matters.
| State | msinfo32 | Confirm-SecureBootUEFI | SetupMode | Actually enforcing |
|---|---|---|---|---|
| Disabled | Off | False | 0 or 1 | No |
| Setup Mode | On | True | 1 | No |
| User Mode | On | True | 0 | Yes |
| Audit Mode | On | True | 1 | Logging only |
| Not supported | Unsupported | Throws | Absent | No |
Read down the SetupMode column and the article's whole point is visible in one place: it is the only value that separates a machine that is checking signatures from one that has the setting on and an empty database.
Note also that Confirm-SecureBootUEFI throws rather than returning false on hardware without support, so a script that does not catch that records an error where it meant to record a No.
RepairMoving a machine into User Mode
The work happens in the firmware, not in Windows, and the order matters.
Enter the firmware setup and find the Secure Boot section. There is normally a key management submenu with an option named Restore Factory Keys, Install Default Secure Boot Keys, or something close. Applying it loads the manufacturer key set and moves the machine out of Setup Mode. Save, exit, and confirm from Windows that SetupMode now returns 0.
If the option is missing, the usual reason is that CSM is still enabled. A machine with legacy boot support switched on often greys out key management entirely, and the fix is the conversion described in the linked comparison rather than anything to do with Secure Boot.
ConsequencesWhat breaks afterwards, and what does not
Enforcement is the point, so it is worth knowing what actually gets caught.
Unsigned boot loaders stop working. That is the whole feature. In practice this affects old rescue media, some Linux distributions installed before signing was routine, and a handful of imaging tools.
Unsigned drivers that load before the operating system stop loading. Rare on modern hardware, common on machines with old add in cards.
Nothing about applications changes. Secure Boot checks what runs before Windows, not what runs after it. A machine in User Mode is no more restricted at the desktop than it was in Setup Mode.
Test one machine of each build before pushing the change across an estate. The failure mode is a machine that will not start, and discovering it on forty of them at once is a bad morning.
The other halfUser Mode with a stale revocation list
Moving a machine into User Mode makes it check signatures. It does not make it check them against anything current.
The key database has two halves. One lists what is trusted, and the other, the forbidden signature database, lists what was trusted and is not any more: boot loaders with known bypasses, signed by a key that is still valid and revoked individually.
Signed malicious loaders are the reason it exists, and a machine that never receives an update to that list will happily boot one.
Windows Update delivers those revocations, which means a machine in User Mode that has been offline, imaged from an old reference or rebuilt from vendor media is enforcing an out of date opinion about what is safe. It reports as compliant on every check in this article and it is still exposed.
Get-SecureBootUEFI -Name dbx | Select-Object -ExpandProperty Bytes | Measure-Object
The byte count on its own means nothing in isolation. It means a great deal compared across an estate: a machine sitting well below the others has missed the revocations the rest received, and that is the machine to look at.
Firmware updates matter for the same reason. Some revocations are delivered by the manufacturer rather than by Windows, so a machine two years behind on firmware can be behind on this too.
FleetReporting on it properly
Any tool that reports Secure Boot as a boolean is going to count Setup Mode machines as compliant. If the reporting is yours to write, collect three values per machine rather than one: whether Secure Boot is enabled, whether SetupMode is 0, and whether a Platform Key is present.
A machine is genuinely protected only when all three agree, and here is the script that collects them.
[pscustomobject]@{
Enabled = Confirm-SecureBootUEFI
SetupMode = (Get-SecureBootUEFI -Name SetupMode).Bytes[0]
PK = [bool](Get-SecureBootUEFI -Name PK -ErrorAction SilentlyContinue)
}
Wrap it in a try block so unsupported hardware records a state rather than an exception, run it as a custom inventory field in whatever manages the estate, and the compliance number stops being a boolean that counts Setup Mode as a pass.
- Read SetupMode and PK, not just the boolean
Confirm-SecureBootUEFI returns true in Setup Mode. SetupMode returning 1, or a missing Platform Key, means nothing is being enforced.
- Suspend BitLocker for one reboot
Loading the default keys changes PCR 7, which is what BitLocker sealed its key to, so the machine comes back to a recovery prompt. Suspend-BitLocker with RebootCount 1 covers the trip into firmware and re-protects itself on the way back.
- Load the default keys in the firmware
The option is usually called Restore Factory Keys or Install Default Secure Boot Keys, in the Secure Boot key management submenu.
- If key management is greyed out, turn CSM off first
Legacy boot support disables key management on most boards. Convert the disk to GPT before turning CSM off, or the machine stops booting.
- Test one machine per hardware build before the estate
Enforcement catches unsigned boot loaders and pre boot drivers. Discovering that on forty machines at once is the failure mode worth avoiding.
The three values to collect
A machine is protected only when all three agree, and one boolean cannot tell you that.
FAQQuestions from the comments
Why does Windows say Secure Boot is on when it is not enforcing?
Because the API it reads reports the setting rather than the state. A machine in Setup Mode has the setting on and an empty key database, so it checks nothing.
What puts a machine into Setup Mode?
Clearing the Secure Boot keys in firmware, a firmware reset, and on some boards a CMOS battery replacement. It is also the state machines ship in when the vendor expects you to enroll your own keys.
Does fixing this require a reinstall?
No. Loading the default keys is a firmware setting and nothing on disk changes.
Will Linux still boot afterwards?
Current mainstream distributions ship a signed shim and boot normally. An older installation, or one with third party kernel modules, may need its own key enrolled.
Does Windows 11 check for this?
The upgrade check reads Secure Boot capability, not enforcement, so a Setup Mode machine passes it. That is why the estate report and the upgrade report can disagree.
Will loading the default keys trigger a BitLocker recovery prompt?
Yes, on any machine whose key is sealed to PCR 7, which is most of them once Secure Boot is on. PCR 7 measures the Secure Boot configuration including the key database, so changing the database changes the measurement and the sealed key no longer unseals. Suspend BitLocker for one reboot first and it reseals itself against the new values.
What is Audit Mode for?
It checks signatures and records what would have been blocked without blocking it, which is how you find the one unsigned boot component in an estate before enforcement finds it for you. Most consumer firmware does not expose it and most reporting tools show it as simply on, which is why it belongs in the same conversation as Setup Mode.
A machine is in User Mode. Is it finished?
Not quite. User Mode means it checks signatures against the database it holds, and the forbidden half of that database is updated over time as loaders are revoked. A machine that has been offline, imaged from an old reference or rebuilt from vendor media is enforcing an out of date opinion and passes every check in this article.
Can I enroll our own keys instead of the manufacturer set?
Yes, and Setup Mode is the state that exists to let you. It is a real project rather than a setting: every boot loader, firmware update tool and pre boot agent has to be signed by a key you control, and a machine that boots something you forgot to sign does not boot at all.
Does any of this help against ransomware?
Only against the part that loads before Windows does, which is a small and serious category. Secure Boot checks the boot chain and stops once the operating system is running, so it does nothing about a document that arrives by email. It is worth having and it is not an endpoint control.
The firmware has no Restore Factory Keys option at all.
Check for legacy boot support first, because CSM greys out key management on most boards. If CSM is already off, the option is sometimes behind an administrator password set at the factory or hidden until Secure Boot is toggled off and on.
On a small number of boards it genuinely is not there, and the vendor firmware update is the only route.