How to Turn On Secure Boot in UEFI Firmware for Windows Security Compliance

Secure Boot is one of the first checks a Windows PC makes before loading the operating system, and if you need to meet Windows security compliance, it matters more than most people realize. If you are figuring out how to turn on secure boot, the job usually involves checking UEFI settings, confirming the disk layout, and making sure firmware security features line up with Windows security requirements and related controls like TPM and BitLocker.

Understanding Secure Boot and Why It Matters

Secure Boot is a firmware-level protection that checks whether bootloaders and drivers are trusted before Windows starts. If a component is unsigned or tampered with, the firmware can block it before the operating system loads.

That matters because the earliest stage of boot is where malware can hide most effectively. Rootkits and bootkits are designed to load below or before the operating system, which makes them harder to detect and remove once Windows is already running.

Secure Boot is not a performance feature. It is a trust check at startup, and that trust check closes off an entire class of pre-boot attacks.

This control shows up in enterprise baselines because compliance frameworks care about device integrity, trusted startup, and resisting persistence at the firmware layer. Microsoft documents Secure Boot as part of the platform security model, and the U.S. National Institute of Standards and Technology (NIST) covers boot integrity and platform trust concepts in its guidance, including NIST SP 800-147 and NIST SP 800-155.

Secure Boot also fits into a broader chain of trust alongside TPM and BitLocker. Encryption protects the data at rest, TPM helps bind trust to hardware, and Secure Boot helps make sure the machine starts from a known-good state. For Windows security compliance, that combination is far more defensible than relying on a single control.

ITU Online IT Training covers these fundamentals in the Microsoft SC-900: Security, Compliance & Identity Fundamentals course, which is useful when you need to understand how endpoint protections fit into a larger compliance story. If you support a fleet, this is not just a technical setting; it is part of how you prove baseline security.

Prerequisites

Before you try to enable Secure Boot, check the machine carefully. A few minutes of preparation can prevent a broken boot sequence, a surprise recovery prompt, or a long afternoon spent undoing a firmware change.

• UEFI firmware must be available on the device instead of legacy BIOS.
• GPT partitioning should be used on the system disk if the machine is currently booting in legacy mode.
• Administrator access is needed to suspend BitLocker, enter recovery settings, and verify status in Windows.
• Firmware update access may be required if the motherboard BIOS/UEFI version is old or unstable.
• Recovery media or a recovery plan should be ready in case the machine does not boot after the change.
• BitLocker or device encryption should be reviewed before you modify boot settings.
• Vendor documentation is helpful because UEFI menus differ widely between OEMs.

If you are supporting a business device, verify the organizational policy first. Some environments allow Secure Boot changes only through endpoint management or under change control, especially when Windows security compliance reports depend on consistent device posture.

Older custom-built systems can be the most problematic. They may support UEFI but still boot in compatibility mode, or they may expose Secure Boot only after you update firmware and clear legacy settings. That is why prerequisites matter more than the actual click path.

How to Check Current Secure Boot Status in Windows

Current Secure Boot status is easiest to confirm from inside Windows before you change anything. The System Information utility shows whether the machine is using UEFI and whether Secure Boot is currently on or off.

1. Open System Information. Press Windows+R, type msinfo32, and press Enter. Look for BIOS Mode and Secure Boot State.
2. Check BIOS Mode. If it says UEFI, the machine is already using the right boot architecture. If it says Legacy, you will need to prepare the disk and firmware before Secure Boot can be enabled.
3. Review Secure Boot State. If the field says On, Secure Boot is already enabled. If it says Off, the firmware supports it but it is not active.
4. Use Windows Security as a cross-check. Open Windows Security and review device security or core isolation settings to see whether platform protections are reporting normally.
5. Document the baseline. Record the BIOS Mode, Secure Boot State, device model, and date so your compliance team has a before-and-after record.

The first warning sign is simple: if Secure Boot options do not appear in firmware or the system is still booting in legacy mode, the device is not ready yet. Another common symptom is a compliance dashboard that reports a mismatch even though the firmware screen looks correct, which usually means Windows is still detecting a legacy boot chain.

For admins who manage a fleet, this is the point to standardize evidence collection. A screenshot from msinfo32 is often enough for a small environment, but larger organizations usually want device inventory reports from endpoint management tools and a timestamped change record.

Preparing the System for UEFI and Secure Boot

Turning on Secure Boot is straightforward only when the machine already fits the expected boot model. If the system disk is using MBR instead of GPT, Windows may boot today but still block the move to full UEFI Secure Boot.

Microsoft provides the built-in mbr2gpt tool for many supported Windows 10 and Windows 11 systems. It can convert the system disk from MBR to GPT without reinstalling Windows, but it should still be used carefully and only after backup verification. The official guidance is on Microsoft Learn, where the UEFI and disk conversion documentation explains the supported path.

1. Back up the system. Create a full backup or at least a reliable file backup before touching firmware or partition tables.
2. Check partition style. Open Disk Management, right-click the system disk, and inspect the partition style. If it says MBR, plan the conversion.
3. Run the conversion if needed. Use mbr2gpt /validate first, then mbr2gpt /convert from an elevated command prompt if validation passes.
4. Update firmware. Install the latest stable BIOS/UEFI release from the system or motherboard vendor if Secure Boot support is incomplete or buggy.
5. Suspend BitLocker. If BitLocker is enabled, suspend protection temporarily so the machine does not ask for a recovery key after firmware changes.

Fast startup can also get in the way on some systems, especially when you are trying to diagnose boot behavior or enter firmware settings repeatedly. If you have trouble reaching the setup screen, disable fast startup temporarily so the machine does a clean reboot.

Do not ignore storage-controller compatibility either. Systems using unusual RAID or third-party boot configurations can still work under UEFI, but the boot files and driver chain must be compatible or the machine will fail before Windows loads.

How Do You Access UEFI Firmware Settings?

UEFI settings are usually available either from Windows recovery options or through a manufacturer-specific key pressed during startup. The exact path varies, but the workflow is the same: get into firmware setup, find the boot or security menu, and change the Secure Boot state.

Microsoft documents the advanced startup path in Windows, and that is often the most reliable method when the keyboard timing is inconsistent. On many systems, you can go to Settings, open Recovery, select Advanced startup, and then choose UEFI Firmware Settings after the restart.

• Desktop systems often use Delete or F2 during power-on.
• Laptops commonly use F2, Esc, F10, or a vendor-specific function key.
• Business-class OEM systems may provide a boot menu key separate from the setup key.
• Windows advanced startup is the safest method when keyboard timing is unreliable.

Once inside firmware, look under menus labeled Boot, Security, Authentication, or Trusted Computing. Manufacturers use different terminology, so do not expect the word Secure Boot to appear in the same place on every device.

Take photos of the current screens before making changes. If the machine fails to boot later, those photos are often the fastest way to restore the original configuration without guessing.

How to Turn On Secure Boot in UEFI Firmware?

How to turn on Secure Boot comes down to changing one firmware option, but the surrounding settings matter just as much. In most systems, Secure Boot only works when the machine is booting in pure UEFI mode and legacy compatibility support is disabled.

1. Open the firmware menu. Enter UEFI setup using the vendor key or Windows advanced startup path.
2. Find the Secure Boot setting. Look under Boot, Security, or Authentication. Some firmware uses a submenu called OS Type or Windows UEFI mode.
3. Switch Secure Boot to Enabled. If the option is greyed out, first change the firmware from legacy or CSM mode to UEFI mode.
4. Load default keys if needed. Many systems require factory keys or default secure keys before Secure Boot can be activated. Choose the option that loads standard keys from the firmware menu.
5. Disable legacy compatibility. Turn off CSM or legacy boot if the motherboard exposes it. This step prevents the firmware from falling back to an insecure boot path.
6. Save and reboot. Save the settings, exit firmware, and let the PC restart normally.
7. Re-enter firmware if the boot fails. If the system does not boot cleanly, return to setup and restore the previous settings before you proceed further.

Some firmware will not enable Secure Boot until you set an administrator password or select a Windows UEFI preset. That is not unusual. The firmware is protecting its own settings so that unauthorized users cannot weaken the boot chain.

If the option is hidden, read the vendor documentation for your exact model. Many OEMs move Secure Boot behind a compatibility toggle or place it in a submenu that only appears after you disable legacy mode.

For Windows security compliance, the goal is not just to “turn on a setting.” The goal is to create a boot path that stays trusted across reboots, updates, and audits.

Troubleshooting Common Secure Boot Problems

Secure Boot problems usually happen because the machine still depends on a legacy boot component, a missing key, or an incomplete conversion from MBR to GPT. When that happens, the fix is usually to reverse the last change, verify the boot path, and correct the underlying compatibility issue.

If the system shows a black screen or “No Boot Device Found,” enter firmware and confirm that the system disk is still listed as a boot option. In many cases, the drive is healthy but the boot mode no longer matches the installed operating system. Switching back to the correct UEFI setting or restoring the prior boot order often resolves the issue.

• BitLocker recovery prompt: This often appears after firmware settings change because the measured boot state changed. Use the recovery key, then suspend protection again before making additional changes.
• Secure Boot missing in Windows: If Windows still reports legacy mode, the firmware change did not fully take effect or the disk is still booting through a compatibility path.
• Greyed-out setting: Clear the legacy boot mode, load factory keys, or set a firmware administrator password if the vendor requires it.
• Bootloader incompatibility: Older Linux loaders, unsigned drivers, or custom boot chains can prevent a clean Secure Boot startup.

When a machine is badly misconfigured, the safest recovery step is often to return to default firmware settings, then reapply only the necessary changes one at a time. Manufacturer documentation is the best source for model-specific recovery, and advanced cases may justify professional support instead of trial-and-error.

One practical habit helps more than people expect: never change Secure Boot, CSM, and disk partition style all at once unless you have to. If something breaks, you want to know which change caused the failure.

How to Verify It Worked

Verification is the part that turns a firmware change into compliance evidence. If Secure Boot is enabled correctly, Windows should report it cleanly, the device should boot without compatibility mode, and related security controls should continue working normally.

1. Check System Information again. Open msinfo32 and confirm that Secure Boot State now says On.
2. Confirm UEFI mode. Make sure BIOS Mode still says UEFI and not Legacy.
3. Review device security status. Open Windows Security and verify that core protections show normal health indicators.
4. Check BitLocker. Make sure the drive is still protected and no unexpected recovery state is active.
5. Look at your compliance dashboard. Endpoint management or compliance reporting should now reflect the Secure Boot policy as satisfied.
6. Document the change. Record the date, device model, firmware version, and final Secure Boot state for audit purposes.

Success indicators are practical, not theoretical. The machine boots normally, Windows reports Secure Boot as on, and no additional warning appears after restart. If any of those do not line up, assume the configuration is incomplete until you reconcile the difference.

For organizations that rely on device attestation or endpoint protection integrations, this step is especially important. A single misreported boot setting can cause drift between the local machine, the management plane, and the audit record.

Best Practices for Ongoing Secure Boot Management

Ongoing Secure Boot management is about keeping the setting in place after the initial change. One successful reboot does not guarantee the next update, repair, or technician visit will preserve the configuration.

Keep firmware and BIOS/UEFI updates current, but apply them in a controlled way. Vendors regularly fix security issues, compatibility bugs, and boot-order problems that can affect Secure Boot behavior. Microsoft’s documentation on Windows device security and firmware trust, along with vendor release notes, should guide those updates.

In fleet environments, standardization matters more than heroics. Use endpoint management to enforce known-good UEFI settings where possible, and audit for drift on a schedule instead of waiting for a user complaint or a failed compliance check.

Secure Boot works best when paired with TPM, least privilege, strong patch management, and modern endpoint protection. That layered approach gives you a much stronger defense than any single control can provide.

If you are studying the compliance side of this topic, the Microsoft SC-900 material from ITU Online IT Training is a useful fit because it connects security controls, identity, and compliance language in a way that maps well to real admin work.

A secure boot chain is not a one-time setup task. It is a maintenance discipline.

Conclusion

Secure Boot is a foundational control for Windows security compliance because it helps ensure the machine starts from a trusted state. If you need to know how to turn on secure boot, the process is predictable: confirm UEFI support, verify GPT partitioning, suspend BitLocker if needed, change the firmware setting, and then verify the result in Windows.

The important part is not just enabling the feature. It is making sure the device stays compatible, the change is documented, and related controls such as TPM and BitLocker remain aligned with your security baseline. That is how Secure Boot becomes part of a practical endpoint hardening strategy instead of a one-time checkbox.

For IT teams, the best next step is to apply the same procedure consistently across systems, track exceptions, and review compliance status regularly. If you are building a stronger understanding of security, compliance, and identity fundamentals, the Microsoft SC-900: Security, Compliance & Identity Fundamentals course from ITU Online IT Training fits naturally with this kind of work.

Microsoft® and BitLocker are trademarks of Microsoft Corporation.