How To Turn On Secure Boot State In BIOS For Managed Workstations

When a workstation fails a compliance check because Secure Boot is off, the fix is usually simple in theory and painful in practice. The real issue is rarely the toggle itself; it is the chain of dependencies behind how to turn on secure boot state, from BIOS configuration and UEFI mode to workstation security and device compliance checks in Microsoft-managed fleets.

Understanding Secure Boot and Why It Matters

Secure Boot is a UEFI security feature that checks the bootloader, option ROMs, and early operating system components before the firmware hands control to Windows. The point is not to “lock down” the machine for its own sake; the point is to stop unsigned or tampered code from loading before endpoint protections even start. Microsoft documents Secure Boot as part of Windows security architecture, and UEFI defines the mechanism that enforces trusted boot paths through signed code validation according to the Microsoft Secure Boot guidance and the UEFI specifications.

That distinction matters in enterprise environments because many attackers do not start inside the operating system. They start lower, where a bootloader or firmware component can persist below normal antivirus visibility. Secure Boot helps block bootkits, rootkits, and unsigned tampering during startup. It is not a replacement for BitLocker, TPM, or BIOS passwords; it complements them by protecting the boot chain while the other controls protect data and device integrity after startup.

Organizations usually require Secure Boot because it supports device attestation, standardized build baselines, and audit-friendly compliance reporting. Frameworks such as the NIST Cybersecurity Framework and CISA secure-by-design guidance both reinforce the value of trusted boot states. If your endpoint management policy expects Secure Boot on, then “off” is not just a setting mismatch; it is a compliance issue that can block conditional access, health checks, and enrollment trust.

Secure Boot does not make a workstation invulnerable, but it closes one of the most abused gaps in the startup chain: code that runs before the operating system can defend itself.

Prerequisites

Before you change firmware settings, make sure the machine can actually support the change without breaking startup. The most common failure mode is trying to force Secure Boot onto a device that still boots in legacy BIOS mode or uses an incompatible disk layout. A few minutes of validation now prevents a long help desk call later.

• UEFI firmware support on the workstation, not legacy BIOS-only mode.
• Administrative access to the local device or approved remote management access.
• BitLocker recovery keys backed up before making firmware changes.
• Vendor documentation for the exact BIOS keys, menu names, and save steps.
• Power stability, including AC power for desktops and a charged battery for laptops.
• Change window so users are not interrupted during startup testing or recovery.
• Endpoint management visibility through Microsoft Intune, Configuration Manager, or another approved compliance platform.

Many enterprises also require a remote recovery path. If a device is in a branch office or user home office, tools like Intel AMT, HPE iLO, or Dell iDRAC may be the only practical way to recover from a bad firmware change. If you are doing this as part of Microsoft MD-102 Microsoft 365 Endpoint Administrator Associate work, this is exactly the kind of change that should be staged, documented, and validated before you call it complete.

How Do You Check the Current Secure Boot State?

You check the current Secure Boot state in Windows by opening System Information and reviewing the Secure Boot field. Press Windows+R, run msinfo32, and look for Secure Boot State. If it says On, Off, or Unsupported, that tells you whether the system is already compliant, turned off, or not capable of using the feature in its current boot mode.

What the status values mean

On means Secure Boot is active and the machine is using a trusted boot path. Off means the firmware supports it but it is not enabled. Unsupported usually means the device is booting in legacy mode or the platform does not expose Secure Boot in its current configuration.

You can also confirm the state from Windows Security under Device security, where supported systems show a Security processor or Secure Boot-related status. For fleet reporting, PowerShell helps because it scales better than manual checks. A simple example is Confirm-SecureBootUEFI, which returns True or False on UEFI-capable Windows systems. Microsoft documents this cmdlet in the PowerShell SecureBoot module.

Confirm-SecureBootUEFI

If the result is False, the setting is not enabled. If the cmdlet errors out, the device may not be running UEFI, or the shell may not have the correct privileges. In managed environments, compliance reporting through endpoint management can surface this at scale, which is far better than discovering it one laptop at a time.

What Should You Prepare Before Changing BIOS Configuration?

BIOS configuration changes should be treated like production changes, not casual troubleshooting. The objective is to reduce risk before the reboot, because once you start changing boot settings, the issue can shift from a simple compliance gap to a startup failure. That is especially important for workstation security baselines that tie device trust to a specific boot posture.

Start by creating a maintenance window. If the user has unsaved work, scheduled updates, or an impending reboot from patch management, you need coordination. Then suspend BitLocker temporarily if your process requires it. On many devices, that avoids recovery prompts after firmware changes and makes the transition smoother. Microsoft’s BitLocker documentation explains how recovery behavior can be triggered by hardware and boot changes.

Document the current firmware state before touching anything. Capture screenshots if possible, note Secure Boot status, record whether the device is in UEFI or legacy mode, and note storage mode settings such as RAID versus AHCI if your image depends on them. If your company uses provisioning or OEM deployment standards, verify whether the current device build is supposed to inherit a fixed firmware baseline. That prevents accidental drift from your standard build.

Also verify power. A desktop should be on reliable AC power. A laptop should have a healthy battery plus AC power. Firmware updates, key resets, or platform key restoration can all fail if the machine powers off mid-process.

How Do You Enable UEFI Secure Boot in BIOS or UEFI?

You enable UEFI Secure Boot by entering firmware setup, switching to UEFI mode if needed, and then turning Secure Boot on from the firmware menu. The exact labels vary, but the logic is usually the same across Dell, HP, Lenovo, and Surface systems. If the machine is in legacy mode, Secure Boot may be hidden, grayed out, or blocked until you change the boot mode first.

1. Restart the workstation and press the vendor’s setup key during POST. Common keys include F2, Del, Esc, or a boot-menu key shown on screen.
2. Open the boot or security menu and find the setting for boot mode, UEFI, or legacy support. Some systems call this Compatibility Support Module or CSM.
3. Switch to UEFI boot if the device still uses legacy mode. On some systems, this requires disabling CSM before Secure Boot becomes available.
4. Enable Secure Boot and, if prompted, load default keys, factory keys, or a platform key set. Without the keys, the firmware may refuse to activate Secure Boot.
5. Save and exit, then allow the machine to reboot completely. Do not interrupt the first boot unless you see a recovery screen.
6. Check Windows again after startup to confirm the state changed successfully.

Some firmware menus separate “Secure Boot Control” from “Key Management.” Others require OS Optimized Defaults or an equivalent preset before the option appears. If you are using a standardized image, the safest approach is to align the firmware setting with the OS image rather than forcing one side to adapt to the other.

What Vendor-Specific Considerations Should You Expect?

Vendor firmware is not standardized enough to assume every device behaves the same way. On Dell systems, Secure Boot often appears under Boot Configuration or Secure Boot settings. On HP systems, it may live under System Configuration, Security, or Boot Options. On Lenovo systems, you may see it under Security, Startup, or UEFI/Legacy Boot. On Microsoft Surface devices, the menu structure is cleaner, but the terminology can still differ from a traditional desktop BIOS.

The key issue is not the brand name; it is the boot path. Settings such as RAID mode, virtualization, TPM availability, or trusted platform controls can affect whether the system can transition cleanly into Secure Boot. For example, if a device image expects a specific storage controller mode and the firmware was changed during troubleshooting, the machine may boot once and fail on the next restart. That is why firmware changes should be documented alongside operating system state and storage configuration.

Terminology also varies. A vendor may call the feature UEFI Secure Boot, Secure Boot Control, or simply Secure Boot. Some vendors expose a single toggle; others split the process into mode selection, key enrollment, and policy enablement. If you manage a mixed fleet, write your procedure around the outcome you need, not around one vendor’s menu layout.

For fleet imaging and provisioning, standardize the settings in the same change document used for deployment. That keeps firmware state aligned with endpoint management policy instead of relying on one-off technician judgment at the bench.

What If Secure Boot Is Greyed Out or Missing?

If Secure Boot is greyed out or missing, the device usually has one of three problems: it is booting in legacy mode, the firmware keys are not installed, or the system firmware is too limited for the feature. The first thing to check is whether the machine is using UEFI. Legacy boot mode is the most common reason Secure Boot is unavailable, and converting the boot path may be required before the setting can be enabled.

Another common issue is an incompatible disk layout. Some older systems boot from a legacy MBR partition style rather than GPT. If the operating system was installed in a way that depends on legacy boot, enabling Secure Boot without conversion can cause startup failure. Microsoft documents conversion tools and guidance for UEFI migration in its Windows deployment and boot documentation, including the GPT and UEFI guidance.

If the OS is unsupported or the bootloader is not signed correctly, the machine may refuse to boot after Secure Boot is enabled. That is where rollback planning matters. The practical rollback path is simple: re-enter firmware, disable Secure Boot, restore previous boot mode settings, and test startup again. If the issue happens across multiple systems, stop the rollout and investigate image consistency, driver signatures, and firmware baselines before touching the next device.

How Do You Validate the Change After Reboot?

You validate the change by confirming the firmware state in Windows and checking that the device still boots cleanly with all required security controls intact. The quickest verification is to run msinfo32 again and confirm that Secure Boot State now shows On. If you prefer PowerShell, Confirm-SecureBootUEFI should return True on a supported system.

Validation does not stop at the firmware flag. Check whether BitLocker is still healthy, whether the device reports compliance in your endpoint management console, and whether user-critical apps launch normally. If your environment uses device health attestation or conditional access, verify that the machine still passes policy checks after the restart. A setting that looks correct but breaks VPN or device trust is not a successful change.

Use a pilot group before rolling the change across the fleet. One pilot should include at least one model from each major OEM family if your environment is mixed. A model-specific firmware quirk is much easier to fix when it affects three pilot devices than when it affects three hundred production endpoints.

Finally, record the result in your asset system, configuration management database, or endpoint platform. That record becomes your audit trail and helps your help desk respond faster the next time a device comes in with Secure Boot disabled.

How Should You Manage Secure Boot at Scale?

Managing Secure Boot at scale is mostly about standardization and drift control. The setting should live in a documented firmware baseline, not in tribal knowledge held by one technician. If you use Microsoft Intune, Configuration Manager, or a provisioning workflow, make the desired state part of the device onboarding process so the setting is expected rather than fixed after the fact.

Use a pilot-and-rollout approach. Start with one model and one user group, confirm the boot path, and then expand in waves. That approach protects workstation security while reducing support calls. It also gives you time to identify models that need firmware updates, restored keys, or special handling for RAID, virtualization, or custom storage settings.

Compliance checks should run periodically, not only during onboarding. Firmware resets, motherboard swaps, and vendor service events can silently disable Secure Boot or reset the keys. If your control plan does not include recurring validation, the fleet will drift and your audit posture will weaken over time.

• Standardize firmware baselines across approved workstation models.
• Track firmware versions and vendor advisories that affect boot behavior.
• Use compliance policies to flag any machine with Secure Boot disabled.
• Document exceptions for lab systems, dual-boot machines, or niche peripherals.
• Retest after service events such as motherboard replacement or BIOS updates.

For security leaders, the operational goal is simple: make Secure Boot a repeatable control, not a one-time project. That is the difference between a clean baseline and a pile of exceptions.

What Are the Most Common Roadblocks?

The most common roadblocks are legacy boot mode, missing keys, incompatible bootloaders, and mismatched firmware settings. If a workstation was built from an older image, it may still be using a boot layout that does not support Secure Boot cleanly. In that case, the issue is not the switch; the issue is the underlying platform state.

Unsigned drivers can also cause trouble after Secure Boot is enabled. A device may start, then fail when a storage or security driver loads. That is why you should test the business-critical applications, VPN client, and any security software that hooks into startup. If something fails, do not guess. Review boot logs, verify driver signatures, and compare the failing device to a known-good pilot system.

When the problem affects many devices, escalate to endpoint engineering or vendor support. A fleet-wide failure suggests an image problem, a firmware regression, or a deployment standard mismatch, not a one-off user issue. The fastest way to recover is often to restore the previous firmware state, confirm the OS still boots, and then isolate the change that caused the break.

Why Does Secure Boot Matter for Compliance and Endpoint Security?

Secure Boot matters because it strengthens the trust chain that compliance tools depend on. If the device cannot prove it booted from a trusted path, the endpoint may fail health checks, fail conditional access, or appear noncompliant even if the operating system is patched and encrypted. That makes Secure Boot a practical device compliance control, not just a theoretical security feature.

It also supports broader endpoint hardening goals. The CIS Controls emphasize secure configuration and integrity protection, while the NIST Cybersecurity Framework focuses on protecting platform integrity and device trust. Secure Boot fits both models because it reduces the chance that a compromise starts before operating system defenses are active.

For IT teams, that means Secure Boot is not just a BIOS checkbox. It is part of the operating model for managed workstations. If your endpoint management policy, security baseline, and recovery process all assume it is enabled, then your change procedure should make it enabled consistently and verify that state routinely.

Conclusion

Turning on Secure Boot in BIOS or UEFI is one of the most useful changes you can make to improve managed workstation security, but it only works cleanly when you treat it as a controlled change. Confirm UEFI support, protect BitLocker recovery access, make the firmware change carefully, and verify the result in Windows before you call it done. That process protects the user, the device, and your compliance posture.

For IT admins and help desk teams, the lesson is straightforward: how to turn on secure boot state is not just a BIOS task. It is a workflow that spans BIOS configuration, boot integrity, recovery planning, and device compliance. Vendor documentation, endpoint management tools, and a disciplined pilot rollout make the process repeatable.

If you are learning these skills as part of Microsoft MD-102 Microsoft 365 Endpoint Administrator Associate preparation, this is the kind of operational task that matters in real environments. Use the vendor docs, validate on a test device, then roll it out with change control. Secure Boot is only one part of a layered endpoint security strategy, but it is a control worth getting right.

Microsoft® and Windows® are trademarks of Microsoft Corporation.