How to Check If Secure Boot Is Enabled on Your Computer

If you are trying to install Windows 11, fix a boot problem, or confirm a laptop is actually protected, Check Secure Boot is the first step. The tricky part is that Secure Boot can be available, supported, and enabled without all three being true at the same time.

That distinction matters. A system can have the right hardware but still boot in legacy mode, which means Secure Boot Status may show off or unsupported even though the firmware technically includes the feature. If you are working through BIOS Settings, verifying System Compatibility, or tightening Windows Security, you need to know where to look and what each result means.

This guide walks through the practical ways to Check Secure Boot in Windows and in UEFI firmware, how to read the results, and what to do if the setting is disabled. It also ties into related infrastructure skills covered in CompTIA Server+ (SK0-005), where boot validation, firmware configuration, and server hardening are part of everyday administration.

What Secure Boot Does and Why It Matters

Secure Boot is a UEFI feature that helps prevent unauthorized bootloaders and rootkits from loading before the operating system starts. It works by checking whether boot components have trusted digital signatures. If the signature does not match what the firmware expects, the boot component is blocked.

That makes Secure Boot one of the simplest defenses against low-level malware. Traditional antivirus tools run after the operating system is already active. Secure Boot acts earlier, which is exactly where bootkits and persistent malware try to hide.

Why everyday users should care

For most people, Secure Boot matters because it reduces the chance that a compromised bootloader or malicious driver can take control before Windows Security even starts. It is especially useful on shared systems, business laptops, and any machine that stores sensitive data or connects to corporate networks.

• Protection against rootkits: Helps stop malware from embedding itself in the boot chain.
• Better trust in startup code: Only signed and trusted components are allowed to run.
• Modern platform requirement: Often tied to UEFI mode, TPM, and operating system compatibility.
• Reduced attack surface: Makes it harder for tampered startup files to load silently.

Microsoft documents Secure Boot as a platform security feature for supported devices, and it is part of why Windows 11 has stricter hardware requirements. For official guidance, see Microsoft Learn and the Windows 11 hardware requirements in Microsoft.

Compatibility implications you cannot ignore

Secure Boot is a security win, but it can create compatibility issues with older operating systems, old boot media, unsigned drivers, and legacy hardware. If a machine was originally installed in BIOS mode, the firmware may support Secure Boot but not actually use it.

That is why people often discover the feature only when they try to install Windows 11 or troubleshoot a failed boot after a firmware update. If the platform cannot satisfy the System Compatibility requirements, the setting may be hidden, disabled, or reported as unsupported.

Secure Boot does not make a system invincible. It simply makes it much harder for unauthorized code to start before the operating system takes control.

How Secure Boot Works Behind the Scenes

Secure Boot is part of the UEFI boot chain. Firmware initializes the hardware, then hands off control to the boot manager, which loads the operating system loader, which then starts Windows or another OS. At each step, trusted signatures are checked before the next component is allowed to run.

The trust model depends on keys and certificates stored in firmware. Commonly, the firmware maintains a list of allowed signatures and certificates, plus a database of revoked or disallowed components. If a file is signed by a trusted authority, it is allowed to continue. If it is unsigned or tampered with, the boot process stops.

Boot chain basics

1. Firmware initializes CPU, memory, and attached devices.
2. UEFI firmware locates the boot manager on the system disk.
3. The boot manager loads the operating system loader.
4. The loader starts kernel initialization.
5. Windows or another operating system takes over.

This is one reason Secure Boot is closely associated with UEFI mode instead of legacy BIOS mode. Legacy boot does not have the same signature-validation model. If a system is using Compatibility Support Module, or CSM, you are typically not getting the full Secure Boot chain.

The UEFI specification and Microsoft’s Secure Boot documentation explain this model in detail. For reference, see the UEFI Forum and Microsoft Learn.

What happens when verification fails

If a component fails signature verification, the system may refuse to load it. Depending on the firmware and the exact failure, you may see a blank screen, a security warning, or a boot loop. That behavior is intentional. It is the control point that stops tampered startup code from taking over.

In an administration context, this matters when you are working with custom bootloaders, recovery tools, or dual-boot setups. A change that looks harmless on paper can break the chain of trust and prevent the machine from starting normally.

Secure Boot	Checks trusted signatures during startup and blocks untrusted boot components.
Legacy BIOS boot	Starts the system without the same signature-based trust checks.

How to Check Secure Boot Status in Windows

The fastest way to Check Secure Boot on most Windows systems is through System Information. Open the Start menu, type msinfo32, and launch the System Information tool. Look for the field labeled Secure Boot State.

The possible values are straightforward. On means Secure Boot is enabled and active. Off means the firmware supports it but it is currently disabled. Unsupported usually means the machine is booting in legacy mode or the firmware does not expose Secure Boot in the current configuration.

How to read the result correctly

• On: Secure Boot is enabled and the system is using it.
• Off: Secure Boot is available but not turned on.
• Unsupported: The current boot mode or firmware setup does not support it.

That last one is important. Many users assume unsupported means the hardware cannot do Secure Boot at all. Often, it simply means the system is running in legacy BIOS mode, CSM is enabled, or the OS was installed in a configuration that does not support Secure Boot reporting correctly.

Microsoft documents System Information and UEFI requirements through Microsoft Learn. For administrators comparing Windows server training, windows server course, or windows server training topics with workstation setup, this tool is the quickest built-in check before making any firmware changes.

How to Check Secure Boot in Windows Settings and Recovery

Windows does not always give you a big, direct Secure Boot toggle in normal Settings, but it does expose the recovery path you need to get into firmware. Open Settings, go to System, then Recovery, and use Advanced startup to restart into the UEFI firmware settings menu.

This route is useful when you need to confirm the system can reach firmware setup before you change anything. It is also the safest path if you plan to enable Secure Boot later and want to reduce the risk of getting stuck in a boot loop.

Why use Windows recovery first

1. Open Settings.
2. Go to System and then Recovery.
3. Select Advanced startup and choose Restart now.
4. Choose UEFI Firmware Settings if available.
5. Save and reboot into firmware setup.

This method helps you verify System Compatibility before changing a single firmware option. It also helps when you are not sure whether the issue is in Windows or in the firmware itself.

In practice, this matters during operating system upgrades, hardware refreshes, and security remediation work. If a system is being prepared for Windows 11 or hardened for business use, checking recovery access first can save time later.

For official recovery guidance, Microsoft documents advanced startup and UEFI access in Microsoft Support and on Microsoft Learn.

How to Check Secure Boot in UEFI/BIOS

If Windows is not enough, go straight into the firmware. Restart the computer and press the setup key during startup. Common keys include Del, F2, Esc, or F10, depending on the manufacturer.

Once inside, look for Secure Boot under menus such as Boot, Security, Authentication, or Advanced. The exact location varies across Dell, HP, Lenovo, ASUS, Acer, and MSI systems. That variability is normal, which is why the same feature can feel hidden on one device and obvious on another.

What to look for in firmware

• Enabled: Secure Boot is on and should be active after reboot.
• Disabled: The feature is present but turned off.
• Unavailable: Often tied to legacy mode, CSM, or unsupported boot configuration.

Be careful not to change unrelated settings while you are in the firmware. A small mistake in boot order, storage mode, or virtualization settings can create a larger support problem than the Secure Boot issue you were trying to solve.

For vendor-specific guidance, use the official documentation from your system manufacturer. Dell, HP, Lenovo, and ASUS all document firmware navigation differently, and those instructions matter more than generic advice from forums.

The right answer is not “find Secure Boot anywhere.” The right answer is “confirm the firmware mode, verify the setting, and make sure the machine still boots after the change.”

How to Interpret Secure Boot Status Messages and Edge Cases

Secure Boot messages can be misleading if you do not know what the firmware is actually doing. Enabled means the system is enforcing signature checks. Disabled means the feature exists but is not active. Not Supported usually points to legacy boot, CSM, or a machine that does not present Secure Boot in its current firmware mode.

One common edge case is a system where Secure Boot is enabled in firmware, but Windows still reports an unexpected value. That can happen after a firmware reset, a boot-mode change, or a motherboard update that reverts the secure boot keys to factory defaults.

Common causes of confusing status results

• Legacy/CSM boot: Secure Boot cannot fully operate in legacy boot mode.
• Dual-boot configurations: Some Linux bootloaders and unsigned components can conflict with Secure Boot.
• Custom keys: Non-default platform keys can change trust behavior.
• Firmware reset: A BIOS update or reset can restore default values or disable the feature.

If the computer was recently updated, reset, or had a motherboard battery issue, check the BIOS Settings again. Firmware updates can revert Secure Boot, boot order, or even the underlying keys that Windows depends on.

When dual-booting, some Linux distributions use signed bootloaders, while others may require manual setup. The important point is not that Linux and Secure Boot are incompatible. The important point is that the exact bootloader chain must still satisfy firmware trust rules.

For deeper troubleshooting and secure configuration practices, NIST guidance on platform security and boot integrity is useful. See NIST CSRC for current publications on system hardening and trusted boot concepts.

What to Do If Secure Boot Is Not Enabled

If Secure Boot is off, start by checking whether the machine is still using legacy BIOS boot. If it is, you usually need to switch the firmware to UEFI mode before Secure Boot can be enabled. That often means disabling CSM or Legacy Boot in the firmware first.

Do not make that change casually. On many systems, changing boot mode can stop the installed operating system from booting if the disk is not partitioned correctly. For modern Windows installations, the disk typically needs to use GPT rather than MBR.

General path to enable Secure Boot

1. Back up important files.
2. Check whether the system disk is GPT-based and the OS supports UEFI boot.
3. Enter firmware setup and disable CSM or Legacy Boot if needed.
4. Enable Secure Boot in the firmware menu.
5. Save changes and reboot.
6. Confirm the result in Windows using msinfo32.

If BitLocker is enabled, make note of the recovery key before changing firmware options. Firmware changes can trigger BitLocker recovery on the next boot, especially if the TPM sees a boot-chain change. That is normal, but only if you are prepared for it.

Official Microsoft guidance on Windows disk partitioning and UEFI boot behavior is available through Microsoft Learn.

Troubleshooting Common Secure Boot Problems

Sometimes Secure Boot will not stay enabled after reboot. In other cases, the option is there but does nothing useful. The usual cause is a mismatch between firmware settings, boot files, and operating system expectations.

Common problems and likely fixes

• Secure Boot turns off again: Reset the firmware to defaults, then re-enable UEFI and Secure Boot in the proper order.
• Old firmware: Update the motherboard or laptop firmware from the vendor’s official support page.
• Missing or damaged boot files: Repair the boot loader or rebuild startup files if the boot chain was modified.
• Dual-boot conflicts: Revisit Linux boot components, especially if the system uses unsigned bootloaders.
• Boot order issues: Make sure the correct Windows Boot Manager entry is first.

On Windows systems, startup repair tools and recovery media can help when the boot manager is damaged. On server or enterprise systems, this is where practical administration skills matter. A technician who understands website administration, what is an administrator job, and basic system software development life cycle concepts can diagnose the change history faster than someone guessing at the symptom.

It is also worth understanding that some low-level boot problems resemble storage failures, when the issue is actually in firmware trust, not disk health. That distinction saves time and keeps you from replacing good hardware unnecessarily.

For firmware best practices, use the device vendor’s support documentation first. If you need a broader security standard reference, the CIS Benchmarks are a useful baseline for secure system configuration.

Best Practices for Keeping Secure Boot Working

The easiest way to keep Secure Boot working is to treat it like a baseline, not a one-time checkbox. Keep firmware updated, use official operating system installers, and avoid unnecessary changes to boot order or firmware keys. Those habits reduce most of the failures administrators see in the field.

Secure Boot also works best when it is part of a wider control set. Pair it with TPM-based protections, disk encryption, regular patching, and sensible privilege management. That combination gives you a much stronger startup posture than Secure Boot alone.

Practical habits that prevent problems

• Update firmware regularly: Compatibility fixes often improve Secure Boot reliability.
• Use official recovery media: Avoid booting from unsigned or unverified installers.
• Document BIOS Settings: Record the original boot and security configuration before changing it.
• Minimize boot changes: Leave CSM, boot order, and key settings alone unless you have a reason.
• Verify after updates: Re-check Secure Boot Status after firmware or OS upgrades.

For admins studying linux administrator training, linux classes, or linux online training, Secure Boot is also worth understanding because it often shows up in mixed-platform environments. Knowing how UEFI, signed bootloaders, and firmware keys interact helps you avoid unnecessary downtime.

Vendor documentation remains the best source for platform-specific behavior. For operating system security and device management, Microsoft Learn and the UEFI Forum are stronger references than random forum advice. For server-side hardening and boot validation, that same discipline shows up again in CompTIA Server+ (SK0-005).

Conclusion

The quickest way to Check Secure Boot is still msinfo32 in Windows. If you need a deeper answer, go into the firmware and verify the setting directly. Those two checks together usually tell you whether the machine is secure, disabled, or sitting in a legacy boot mode that needs attention.

Secure Boot matters because it blocks untrusted code before the operating system loads. That makes it a practical defense for modern PCs, especially before OS installs, upgrades, or troubleshooting sessions where boot integrity matters.

If you are working on a system that will be used for Windows 11, hardened enterprise use, or mixed operating system setups, verify System Compatibility first, then confirm BIOS Settings, and finally check the Secure Boot Status in Windows. That sequence avoids most of the confusion people run into when they only look in one place.

For IT professionals, this is a basic skill that pays off fast. It belongs in the same toolkit as recovery planning, firmware management, and server hardening. If you are building those skills, the infrastructure topics in CompTIA Server+ (SK0-005) are a solid place to reinforce them.

Bottom line: use both Windows tools and firmware settings to confirm Secure Boot, and do it before major changes. It is a small check that can prevent a large support problem.

CompTIA® and Server+ are trademarks of CompTIA, Inc.

References

• Microsoft Learn
• Microsoft Learn: Windows and GPT FAQ
• UEFI Forum Specifications
• NIST CSRC Publications
• CIS Benchmarks