This blog dives into what “Policy is rejected by licensing” actually means inside Windows, why that decision is not based on what Intune reports or what the docs promise, and which licensing engine ultimately decides whether a policy is allowed or silently blocked.
Enable Secure Boot Certificate Updates
The clock is ticking on Secure Boot certificate expiration. Microsoft has documented the steps to rotate those certificates, and Intune provides a built-in policy to do exactly that.
On paper, it is straightforward. You configure the policy, assign it, and Windows takes care of the rest. In reality, many administrators ran into something else entirely. The policy deploys, reporting shows errors, and devices respond with the same familiar status. Error 65000.
Policy is rejected by licensing and error 65000
With the 65000 error appearing in Intune, the next place to start is the problem device itself. In the Enterprise Device management event log, you will see an MDM PolicyManager event that is very explicit about the real reason: Policy is rejected by licensing for EnableSecurebootCertificateUpdates, with 0x82B00006.
That 0x82B00006 error message is not new. It has existed for years, typically appearing when an Enterprise-only setting is applied to a Pro device. In those cases, the behavior makes sense. Secure Boot certificate updates, however, are documented as supported beyond Enterprise. That is where the confusion starts. The policy should apply. The device says it cannot. And licensing is blamed… which is why it is added as a known issue to the documentation
This is the point where most investigations stop. The policy fails, the error code is generic, and it has been documented as a known issue. With it, people revert to proactive remediations to set the same policy. But still…I was curious which decision- making engine is responsible for this erro: Policy is rejected by licensing.
What Actually Happens When a Policy Reaches Windows
When Intune delivers a configuration policy, the Windows MDM stack does not immediately write values to the registry. Every policy flows through the PolicyManager first. One of the PolicyManager’s responsibilities is to validate whether a policy is allowed on the device before any action is applied. That validation happens in layers. The policy area is checked. The policy name is checked, the enrollment type is checked, and from there on the platform restrictions are evaluated. Only after that does licensing come into play.
This is where many assumptions break down. Licensing is not just about activation state or installed edition. It is a full policy engine with its own rules, inputs, and protected data stores. If licensing rejects a policy, PolicyManager stops processing the policy and shows in the event log that the policy was rejected by licensing.
That means the failure occurs before any setting is applied, even if the policy should apply to Pro and Enterprise devices.
The First Policy is rejected by licensing Clue: MDMPolicyAllowList
While navigating from one function in the policy manager to the next, one name keeps appearing: MDMPolicyAllowList.
This string appears in multiple places. It appears in all corresponding Windows license files. The Enterprise xrml file as well as the professional license files.
Besides the MDMPolicyAllowList being mentioned in the license files, that MDMPolicyAllowList is also listed in the tokens.dat under the Software Protection Platform (SPP) folder.
At first glance, everything looks correct. Secure Boot-related policies appear inside those MDM allow lists, even on Pro devices. That would suggest the policy should be allowed, right? But the Windows Pro device still rejects it (well, the policymanager). That contradiction is the first real signal that those files are not the final source of truth.
Policy is rejected by licensing: Tokens and License Files
Tokens.dat and the license files in the SPP folder can be considered the decision source. They contain exactly the licensing data that the policymanager was looking for in the SLAPI code MDMPolicyAllowList.
As shown above, the decoded licensing tokens.dat file indeed showed the whole MDMPolicyAllowlist. When Secure Boot appears there (as it clearly did), it is reasonable to conclude that licensing should permit the specific policy. But those files are inputs, not decisions.
They describe potential capabilities…potential… They do not represent an evaluated policy state. Windows never directly uses those files when determining whether a policy is allowed to be applied. The actual decision is made elsewhere.
ProductPolicy: Names Without Answers
While running a procmon trace and syncing the device, another registry value magically appeared: HKLM\SYSTEM\CurrentControlSet\Control\ProductOptions\ProductPolicy
This Productpolicy value is a large hex binary blob. It is unreadable at first glance, but with a few PowerShell commands, the hex value became more readable.
As shown above, the productpolicy registry key, indeed again showed the same MDMPolicyallowlist as the tokens.dat. But the ProductPolicy registry key does not store the policy values. It stores policy identifiers. Think of it as an index. It tells Windows which policy names exist, and which ones should be queried. Nothing more…Nothing less.
The ProductPolicy registry key does not tell the policymanager whether Secure Boot is allowed or rejected by licensing. It only says Secure Boot-related policies exist. So Windows uses ProductPolicy to know what questions to ask. Not how to answer them.
Where the Real Answer Comes From
Once a policy name is identified, Windows calls into the Software Licensing API. Specifically, SLGetWindowsInformation.
This is a critical point. The PolicyManager does not parse tokens.dat. It does not decode the ProductPolicy, and it does not directly read the license XML files. The Policymanager asks the licensing engine a direct question. Is this policy allowed? (MDMPolicyAllowed). If the policy is not allowed, you can guess the outcome: Policy is rejected by licensing
SLGetWindowsInformation is not a simple registry lookup. The call travels through user mode into the kernel. From there, it enters the Client License Platform driver. That driver accesses a protected licensing store under: HKLM\SYSTEM\CurrentControlSet\Control\{7746D80F-97E0-4E26-9543-26B41FC22F79}
This is not a normal registry key. It is a compiled, protected licensing database (you need psexec to access it). It contains evaluated rules. SKU-specific gating. Feature restrictions. Edition boundaries. This is where Pro versus Enterprise actually matters.
The PolicyManager Licensing Check in Plain Terms
Within the PolicyManager (DLL), every policy follows the same logic. Once platform checks pass, PolicyManager asks whether a licensing check is required. For many security-related policies, the answer is yes. When that happens, the PolicyManager calls into the SLAPI path and requests a string-based policy value.
That string includes the policy namespace, the area, and the enrollment context.
The licensing engine responds with a single authoritative answer. Allowed or not allowed. If the answer is not allowed, PolicyManager emits an event stating the policy was rejected by licensing and returns error 65000 to the MDM stack.
Why Secure Boot Disappears on Pro
Once the investigation reached this point, the behavior finally made sense. On Enterprise devices, Secure Boot appears in the evaluated licensing data. On Pro devices, it does not. Even though Secure Boot exists in license files and tokens, the licensing engine resolves the final allow list differently depending on the SKU and build state.
When PolicyManager asks SLAPI whether Secure Boot is allowed, the answer returned on Pro devices is simply no. PolicyManager does not question that answer. It reports the policy as rejected by licensing and exits.
Why LicensingDiag Shows the Truth
This is where the LicensingDiag tool comes into play. The LicensingDiag tool does the same thing as the policymanager. It calls the same licensing APIs used by PolicyManager and exports the evaluated results into WindowsPolicyData.xml.
That XML file reflects precisely what licensing believes is allowed on the device at that moment. When Secure Boot does not appear in that XML on Pro devices, it explains everything. The policy is rejected because some internal licensing says no.
PowerShell script
To confirm this behavior, we wrote a PowerShell script that mimics the same flow.
The script first imports the slc.dll… as that’s the DLL the GetWindowsInformation function lives in.
From there on, it reads the ProductPolicy catalog from the ProductOptions trgistry key and extracts each policy identifier.
For each extracted identifier, it calls SLGetWindowsInformation.
The result matches LicensingDiag exactly. Secure Boot is resolved as allowed on Enterprise. It is missing on Pro. Different tools. Same licensing engine. Same answer.
The Full Policy Is Rejected by Licensing Flow, End to End
With the full picture, here is the flow of how the policymanager.dll handles the policy and determines whether it’s allowed. (aka policy is rejected by licensing)
Final Thoughts
This issue was never about Intune assignments or device health. It was never about broken CSPs or corrupted tokens. It was about licensing enforcing rules that were invisible unless you looked in the right place. Secure Boot certificate updates exposed that gap because they sit at the intersection of security, licensing, and platform enforcement.
LicensingDiag told the truth. The PolicyManager enforced it… based on an internal Software Licensing API (SLAPIE) and from there on the policy was rejected of licensing. The only thing we can do now is wait until Microsoft releases an update to fix this issue in the SLAPIE flow.