Windows BitLocker Registry Keys (FVE) Revert to 'Allow' (2) After encryption

[AdamBaali]

Fleet version: 4.78.3

Web browser and operating system: Windows 10/11 (Impacted devices are running Windows)

---

💥 Actual behavior

When configuring BitLocker to require a PIN via Fleet using PowerShell scripts, the registry values for the "Require additional authentication at startup" settings are reverting to a value of 2 (Allow) instead of the configured values (e.g., 1 for Require, or 0 for Do Not Allow).

Specifically, the user is deploying four scripts to achieve a CIS benchmark configuration:

• UseTPMPIN: Set to 1 (Require startup PIN with TPM)
• UseTPMKeyPIN: Set to 0 (Do not allow startup key and PIN with TPM)
• UseTPM: Set to 0 (Do not allow TPM)
• UseTPMKey: Set to 0 (Do not allow startup key with TPM)

Despite the scripts successfully setting these values initially, and the user successfully setting a PIN, the registry keys (HKLM:\SOFTWARE\Policies\Microsoft\FVE) revert to 2 shortly after. This behavior mimics a bug where deviceenroller.exe was found to be overwriting registry values.

🛠️ To fix

Investigate if the Fleet agent or deviceenroller.exe is incorrectly overwriting the FVE registry keys. Ensure that the values set by the custom scripts (1 or 0) are respected and not forcibly reset to 2 (Allow).

🧑‍💻 Steps to reproduce

These steps:

• Have been confirmed to consistently lead to reproduction in multiple Fleet instances.
• Describe the workflow that led to the error, but have not yet been reproduced in multiple Fleet instances.

1. Enroll a Windows device into Fleet.
2. Deploy the four attached PowerShell scripts to configure BitLocker "Require additional authentication at startup" settings (CIS compliance).
   • Set UseTPMPIN to 1
   • Set UseTPMKeyPIN to 0
   • Set UseTPM to 0
   • Set UseTPMKey to 0
3. Observe that the device prompts the user to set a PIN and encryption proceeds.
4. Monitor the registry path HKLM:\SOFTWARE\Policies\Microsoft\FVE.
5. Observe that the registry values for UseTPMPIN, UseTPMKeyPIN, UseTPM, and UseTPMKey revert to 2.

🕯️ More info (optional)

• Suspected related issue: Inconsistent behaviour when setting BitLocker PIN as required #37252
• The issue appears similar to a known bug where deviceenroller.exe resets values.
• Suggested to customer to run Process Monitor (ProcMon) to confirm the process responsible for the registry change.
• Powershell scripts.zip

[AdamBaali]

New Customer Update: Reproduction on Clean Install

The customer performed a clean install. They confirmed that the registry values are being actively set to 2 (Allow) by the system/MDM process, even when the custom configuration scripts are initially disabled.

Steps Taken & Observations:

1. Environment: Reinstalled a fresh OS (physical machine) and enrolled in Fleet via Okta.
2. Baseline: The custom scripts to configure UseTPM, UseTPMPIN, etc., were disabled to isolate behavior.
3. Initial State: The HKLM:\SOFTWARE\Policies\Microsoft\FVE registry key did not exist initially.
4. MDM Action:
   • The "MDM command will be sent..." message appeared in OS Settings.
   • A banner appeared in Self Service asking to create a PIN (successful).
5. Automatic Registry Creation: Immediately after the MDM action, the FVE keys were automatically created with the following default values (mostly set to 2 - Allow):
   • UseAdvancedStartup: 1
   • UseTPM: 2
   • UseTPMPIN: 2
   • UseTPMKey: 2
   • UseTPMKeyPIN: 2
6. The Revert (Bug Confirmation):
   • The customer manually ran the PowerShell script to set the desired CIS values (UseTPMPIN=1, UseTPMKey=0, etc.).
   • The registry updated correctly for a few seconds.
   • Result: The values automatically reverted back to 2 shortly after, confirming an active overwrite by the management process.

Impact: This confirms that the MDM agent or deviceenroller is enforcing a configuration of 2 (Allow) for these TPM settings, preventing the strict CIS compliance settings (1 or 0) from persisting.

[Sampfluger88]

Linked to Unthread ticket:

Multiple users experiencing recurring issue #11518

[getvictor]

Agreed to timebox to 1 day at estimation.