The mystery of Secure Boot Intune compliance

Intune compliance is a fantastic tool – if done right – but it has it’s gotchas. Today I’m going to talk about a particular bugbear of mine which is Secure Boot compliance.

When setting up a compliance policy you can set the standard policy up to check for Secure Boot being enabled however if you have older devices in your estate then you may be heading for a fall.

In simple terms some chipsets will report Secure Boot as being non-compliant even if it’s enabled! This is primarily devices that have TPM 1.2 only. It seems that the check is done in a way that “some” TPM 1.2 devices just don’t know how to handle.

With this in mind I set out to find why this is the case and come up with a solution.

No-one knows what the MS compliance settings are actually looking for or HOW they are doing it and herein lies the problem. If you find one of these archaic devices and blow the years of dust off the keyboard then fire up PowerShell there is a command that will tell you what’s actually happening.

The return from this is True or False for the most part – if it’s True it means it’s enabled, false means that it’s not – there’s a third result which is Cmdlet not supported on this platform. Now that’s a bit easier right? The below only cares about True or False although you could easily adapt it for the third option if you wanted.

OK so now we know that this returns a REAL result that works on all devices we just need a Custom Compliance policy right? Yeah… let’s do this.

So first we need the detection script. Simple enough right? The return value from the above is a boolean but I prefer to work with strings to create my JSON. So here we go…

$status = Confirm-SecureBootUEFI
$hash = @{ SecureBoot = "$status" }
return $hash | ConvertTo-Json -Compress

Super simple. Get the result, create the hash and convert to compressed JSON.

Now what do we do with that? In Endpoint Manager go to Devices / Compliance Policies then navigate to Scripts. You need to add the above as a script (Give it a good name that makes sense). Once you have done that you can create your custom compliance policy. But to get it to work you have to also supply a JSON. This is as simple as it gets.

{
"Rules":[ 
    { 
       "SettingName":"SecureBoot",
       "Operator":"IsEquals",
       "DataType":"String",
       "Operand":"True",
       "MoreInfoUrl":"https://www.bing.com/ck/a?!&&p=a296d37f56e80087JmltdHM9MTY3ODQwNjQwMCZpZ3VpZD0yYThiYTc1My01NjgwLTZkOWQtMGI2YS1iNTljNTczYjZjYjImaW5zaWQ9NTIxOQ&ptn=3&hsh=3&fclid=2a8ba753-5680-6d9d-0b6a-b59c573b6cb2&psq=secureboot+microsoft&u=a1aHR0cHM6Ly9sZWFybi5taWNyb3NvZnQuY29tL2VuLXVzL21lbS9pbnR1bmUvdXNlci1oZWxwL3lvdS1uZWVkLXRvLWVuYWJsZS1zZWN1cmUtYm9vdC13aW5kb3dz&ntb=1",
       "RemediationStrings":[ 
          { 
             "Language":"en_US",
             "Title":"SecureBoot not enabled.",
             "Description": "BIOS needs to have SecureBoot enabled"
          }
       ]
    }
 ]
}

The URL can be anything. I chose to link directly to a BING search that was related to it – just because.

Now deploy this to your devices and you will see more accurate results. If Secure Boot is enabled then it will show as compliant. If it’s not compliant then there’s a reason – most likely thing is that it’s not enabled. Once you get the list of non-compliant devices you can find out if they will ever show as compliant eg. it’s so damned old that Secure Boot is not a thing and exclude them from the policy so that they don’t get checked – oh and then of course go and see the purse holder and tell them to pay up and upgrade these devices.

And finally, disable that built-in Secure Boot check. It’s not fit for purpose. It lies and no-one likes it when tech lies.

Why will Microsoft not fix this? They don’t want you using old hardware. They especially don’t want you using TPM 1.2 because it’s not compatible with Windows 11 (natively) and they want you to buy into Windows 11 don’t they? Eventually Win 10 will be deprecated and then those old devices will be doorstops.