Devices Showing 'Not Applicable' in Your Secure Boot Report? Two Very Different Things Cause That

Open the Secure Boot status report in the Intune admin center and you will usually see a chunk of devices sitting in a bucket called Not applicable. It sounds harmless - like the report is telling you this setting simply does not concern those devices. It is not telling you that. It is telling you one of two things, and the report itself cannot say which.

Either Secure Boot is genuinely switched off in that device's firmware, or the device is not sending Microsoft the diagnostic data needed to know either way. Those are very different problems with very different fixes, and mistaking one for the other is how a real security gap sits unnoticed for months.

The problem: what Secure Boot is, and what "Not applicable" actually means

Secure Boot is a firmware-level check that runs before Windows itself starts loading. When a PC boots, its UEFI firmware checks the digital signature of every piece of boot software - the bootloader, the drivers that load early, the operating system kernel - against a list of certificates it trusts. If any of that code is not properly signed and trusted, Secure Boot refuses to let it run. That is the whole point: it stops boot-level malware (a rootkit that tries to load before Windows and its own defences are even active) from ever getting a foothold, because the check happens earlier than anything Windows-side could catch it.

Every Intune tenant has a Secure Boot status report, and it groups devices into a handful of buckets:

Microsoft's own documentation for this report is direct about the "Not applicable" bucket: if Secure Boot is not enabled on a device, no action is required from a certificate-readiness point of view, and those devices are shown "for visibility" only. Read that carefully - it means "not applicable" is describing a device where Secure Boot is off, not a device the check does not apply to in some neutral sense.

Why it happens: a setting Windows itself cannot switch on

Here is the part that surprises people who assume every Windows setting has an Intune policy behind it somewhere: there is no CSP and no Group Policy setting that turns Secure Boot on. Not because Microsoft has not built one yet - because it is structurally impossible for one to exist.

So how does a device end up with Secure Boot disabled in the first place? Usually not by a deliberate decision - a BIOS reset during a warranty repair, an older imaging or deployment tool that touches firmware settings, a technician troubleshooting something unrelated and turning it off along the way, or hardware that shipped from the OEM with it off and nobody caught it during provisioning.

Because Windows genuinely cannot fix this from the inside, the only way to flip the setting programmatically is through whatever out-of-band BIOS management interface the device's own manufacturer provides - and every OEM built a different one. Lenovo exposes BIOS settings through a set of WMI classes (Lenovo_BiosSetting, Lenovo_SetBiosSetting, Lenovo_SaveBiosSettings) that do not exist on Dell, HP, or any other vendor's hardware. A script written against Lenovo's WMI classes only ever works on Lenovo devices - this is genuinely vendor-specific, not a gap in the script.

How to verify: check the device, not just the report

Because the report's "Not applicable" bucket is ambiguous, the reliable check is always on the device itself.

This returns True if Secure Boot is on, False if the device supports it but it is switched off, and a "Cmdlet not supported on this platform" message if the device is legacy BIOS rather than UEFI at all. It must be run elevated - without admin rights it fails with an access-denied message rather than a real answer.

At fleet scale, the report itself is still the right starting point - just treat its "Not applicable" bucket as a shortlist to confirm, not a verdict. In the Intune admin center, the documented path to this report is Reports › Windows Autopatch › Windows quality updates › Reports tab › Secure Boot status. If your tenant does not have Windows Autopatch enabled, search "Secure Boot" from the admin center's own search bar to find the equivalent report page.

The fix: a Lenovo BIOS remediation, step by step

Rather than touching devices by hand, this is a genuine candidate for an Intune Proactive Remediation - a detection script that flags non-compliant devices, and a remediation script that fixes them automatically on a schedule.

The remediation script does five things, in this order, and the order matters:

1. Disables the BitLocker scheduled tasks that would otherwise fire mid-run and race against what this script is doing.
2. Suspends BitLocker protection on the system drive first, and confirms the suspend actually took effect. This step exists because changing Secure Boot state changes the boot chain measurements BitLocker's key is sealed against - do this on a volume that is still actively protected, and the next boot can land the device in BitLocker recovery, asking for a 48-character key nobody has to hand.
3. Confirms the Lenovo BIOS WMI namespace is actually reachable before trying to use it, so a genuine access problem fails loudly instead of silently doing nothing.
4. Authenticates to the BIOS and sets Secure Boot to Enable, using whichever BIOS admin password your organisation has configured (see the callout below - there is deliberately no real password anywhere in this script).
5. Logs every step to C:\Windows\Logs\Scripts\SecureBootRemediation.log for troubleshooting.

Deploy this as an Intune Proactive Remediation

1. Sign in to the Intune admin center.
2. Go to Devices › Scripts and remediations › Proactive remediations.
3. Select Create and name it something like "Secure Boot - Lenovo Detect and Remediate".
4. On the Settings page, paste Detect-SecureBootLenovo.ps1 into Detection script file.
5. Paste Remediate-SecureBootLenovo.ps1 into Remediation script file.
6. Set Run this script using the logged-on credentials to No - this needs to run as SYSTEM to reach the BIOS WMI namespace and manage BitLocker.
7. Select Next, then assign to a device group scoped to your Lenovo hardware only - this script does nothing useful on any other manufacturer's devices.
8. Set the schedule (daily is reasonable) and select Next › Create.

Proof it worked

On the device itself, re-run the same check:

At fleet level, give the report time before drawing conclusions. Microsoft documents up to a 12-hour delay after a real firmware change before the Secure Boot status report reflects it, and a device can genuinely be fixed while still showing "Not applicable" or "Unknown" for a few hours afterward - that is reporting lag, not a failed remediation.

References

• Secure Boot status report in Windows Autopatch - what "Not applicable" and "Unknown" mean, the reporting-latency window, and the diagnostic-data prerequisites this post is built on.
• Confirm-SecureBootUEFI - the cmdlet reference, including the exact behaviour on non-UEFI hardware and without administrator rights.
• Secure boot enabled device shows Not Compliant in Intune - useful background on how Intune reads Secure Boot state more broadly.

Related on EndpointWeekly

• Secure Boot Certificate Update 2026: Fix Non-Compliant Devices with Intune - the other Secure Boot failure state: devices where Secure Boot is on but the certificates need rotating. If your devices show "Not up to date" rather than "Not applicable," that post is the one you want.