This blog will discuss a case where BitLocker policies pushed during Windows Autopilot appeared to be applied in the event logs, but they never actually were applied successfully. Instead, every BitLocker policy ended up with the familiar 65000 error in Intune. We’ll walk through what happens under the hood, why these policies land in the .DEFAULT policymanager instead of the regular system-wide HKLM, and how the behavior inside bitlockercsp.dll caused it, until Microsoft fixed it in the August build. Which raises the question: if it was broken all along, where was the official announcement?
The BitLocker 128-bit Issue
When you are enrolling a device with Windows Autopilot on modern hardware, BitLocker is automatically enabled with XTS AES 128-bit encryption. That default is fine for many environments, but if you want stronger encryption, such as 256-bit, or if you want to enforce startup authentication or removable drive encryption, you need to define a BitLocker policy through Intune.
Without a BitLocker policy, Windows just applies the default 128-bit BitLocker encryption. Here comes the first catch. If you were running a Windows build before the August update and you pushed those BitLocker policies, they all errored out with the infamous 65000.
The event logs told you the policies were applied. Intune told you they failed. And if you went digging in the registry, you discovered that BitLocker behaved differently from almost every other CSP.
Licensing confusion
Before we continue, let’s clear up some licensing confusion first. BitLocker, the feature is available on Windows Pro, but BitLocker management through Intune requires an Enterprise or Education license.
So yes, you can encrypt your drive on Pro, but you are not licensed to manage it centrally. It is an odd split, you are allowed to encrypt but not to manage… funny….
What error: 65000 really means
With that out of the way, let’s get back to the real problem: why BitLocker policies errored out with 65000 when you actually did push them. If you have read the Patch My PC blog on the Settings Catalog and error 65000 you know this code means Intune expected a value to land in the PolicyManager store but did not find it. It is the generic “policy not applied” signal.
We ran into the exact same pattern with BitLocker. Events 813 and 814 showed that the CSP Payload was delivered. (small hint: look at the enrollment type and scope, please)
Policies like AllowStandardUserEncryption and SystemDrivesRequireStartupAuthentication came down from Intune, the Current User was marked as Device, and a merge was requested. Yet all BitLocker policies errored out with 65000.
What happened with the BitLocker policies
So what went wrong? Time to look under the hood and see where those policies actually landed in the registry. Normal CSP flow is simple. Intune writes into the Providers hive. PolicyManager marks an area dirty and then merges the effective values into: HKLM\Software\Microsoft\PolicyManager\current\Device (or user, based on the assignment)
That is where Intune checks when it reports on policy application. With BitLocker, something different happened. All of the BitLocker settings and even the _Dirty markers ended up under: HKU\.DEFAULT\Software\Microsoft\PolicyManager\current\Device\BitLocker
.DEFAULT is not a fake hive. It is the profile for the Local System account, SID S-1-5-18. Services and system processes that run as Local System store their registry data there. The BitLocker policies were being written in the wrong place.
Why only BitLocker
That registry path was the first clue. The second came when we cracked open bitlockercsp.dll and looked at how it builds its scope data.(SetValue Function). Other CSPs, such as Update or Defender, always show Enrollment Type (0x6) and the Scope = 0x0 in the event log, which means “device” only.
They are forced into HKLM. BitLocker policies are different. Every BitLocker policy we traced showed Scope = 0x3F.
That scope mask is created inside bitlockercsp.dll when it builds its PolicyManagerScopeData.
The effect of 0x3F is simple: it tells PolicyManager that all scopes are valid, including Local System. That is why BitLocker policies land under .DEFAULT, even though HKLM is available and used successfully by other CSPs. There is no replay into HKLM afterwards, so the settings remain stuck in the wrong hive and Intune reports 65000.
Inside the code: SetValue
Digging deeper, the difference becomes clearer in the BitLocker CSP code itself. In the decompiled BitLockerNode::SetValue, the flow is not the same as other PolicyManager-backed CSPs.
- For most CSPs, SetValue simply writes into the provider hive and lets PolicyManager handle the merge.
- BitLocker’s SetValue takes extra steps: it checks PolicyType, Behavior, and additional feature flags (FallThrough), which weren’t there in the July Windows build.
- If conditions do not line up, it bypasses the normal merge path. Instead, it relies on the wide 0x3F scope, allowing values to be placed in whatever PolicyManager scope is available including .DEFAULT.
This explains both the stranded registry values and the persistent 65000 errors. It was not Intune misreporting. It was bitlockercsp.dll taking a different code path that made the policies valid only under Local System. That made me wonder… what if we just replace that DLL file?
Our Funny experiment
At one point, we did something really stupid… at first. We took over permissions and ownership of the broken bitlockercsp.dll and replaced it with the version from the August Windows build.
The moment we pressed sync again, the BitLocker policies landed correctly in HKLM Policy Manager, and with it, the 65000 errors disappeared like ice before the sun. That told us the bug was not Intune. It was the CSP implementation itself.
Another BitLocker trap: AP-DP and 256-bit
This is not the only place BitLocker policies behave differently. If you followed our Autopilot Device Preparation tests, you will remember the 256-bit encryption issue. AP-DP doesn’t care that you enforce 256-bit; instead, it applies the default 128-bit. The CSP cannot reconcile the requirement during provisioning, and you are left with 128-bit BitLocker encryption
Both issues highlight the same point. BitLocker CSP is not a normal CSP like Update or Defender. It has special handling, scope rules, and timing problems that show up in Autopilot and ESP.
Device vs. User assignment
I also tested this with different assignment types. Using Autopilot Device Preparation, I tried both device assignment and user assignment. The weird thing? With the user assignment, the Bitlocker policy actually arrived successfully??? you can see it in the event logs as Scope = 0x1.
It’s at least something, but that doesn’t solve the real issue, because the policy kicks in too late to be useful.
I tested the same scenario with Autopilot v1, and both the device and user assignments broke in the same way. The result is the same: BitLocker policies error out with 65000 regardless of assignment model, because the CSP itself is the problem.
Microsoft Reaction
Leaving this paragraph open for the moment, Microsoft is putting out an official announcement on when they will acknowledge this issue.
Troubleshooting
If you are hitting the 65000 error when you deploy a BitLocker policy:
- Open the DeviceManagement-Enterprise-Diagnostics-Provider log and look for Event 813 or 814. If you see Scope = 0x3F, you are in this scenario.
- Check the registry under:
- HKU\.DEFAULT\Software\Microsoft\PolicyManager\current\Device\BitLocker
- If values are there, the CSP wrote them under Local System.
- Verify HKLM\Software\Microsoft\PolicyManager\current\Device\BitLocker is empty. That mismatch is why Intune reports 65000.
On post-August builds, the BitlockerCSP.DLL was fixed, so BitLocker policies land correctly in HKLM and the errors disappear.
Closing
BitLocker will encrypt by default, but if you define a policy, you need the CSP to land correctly. On builds before the August fix, BitLocker policies were written unde .DEFAULT because of how bitlockercsp.dll handled SetValue and scope. Intune never saw them and returned 65000. After August, the CSP was corrected, and the merge went to HKLM Policymanager as expected.
It looks like Microsoft is really pushing new enforcement into OOBE, as evidenced by the quality updates being installed during Autopilot. At least those happen before BitLocker has a chance to lock down the drive.