Intune reports devices non-compliant on BitLocker after Windows 11 25H2 — no TPM key protector is created, only ProtectorType 0x3

DanielS 0 Reputation points
2026-08-17T13:30:19.25+00:00

DETAILS

  • Environment
  • Windows 11 25H2, build 10.0.26200
  • Dell Precision 7680, BIOS 1.27.1
  • Microsoft Intune, Entra-joined (MDMDeviceWithAAD)
  • Compliance grace period: 3 days
  • Affects every device, regardless of make or model

Problem

Enrollment completes without any error. The BitLocker policy is delivered and applied successfully — RequireDeviceEncryption is set to 0x1 around 25 times in the log with no failures. The drive encrypts to 100%.

Despite that, Intune keeps reporting the device as non-compliant on BitLocker. The device drops into the 3-day grace period, after which Conditional Access blocks the user. New starters cannot work.

This behaviour started after upgrading to 25H2. The same policy on 24H2 resulted in compliant devices.

What I have already investigated

Device Health Attestation is healthy on 25H2. System → Event ID 1041 returns all expected values:

"SecureBootEnabled","ValueFromComputer":true,"ValueFromTcgLog":true "PcrsMatchTcgLog":true "TpmPresent":true, "TpmIsResponsive":true, "EkCertIsAvailable":true "BootTcgLogFoundInFileSystem":true "CurrentTcgLogFoundInFileSystem":true

On a 24H2 device I did see "ValueFromTcgLog":false intermittently, so I initially suspected the attestation regression. On 25H2 that mismatch is gone — yet the device is still non-compliant, which rules attestation out.

The recovery key is escrowed. Event ID 845 confirms backup to Entra ID, and manage-bde -protectors -get C: shows Backup type: AAD backup.

What the BitLocker log actually shows

From Microsoft-Windows-BitLocker/BitLocker Management:

Time Event ID Detail 10:02:34 796 Encryption started, IdentificationGUID 00000000-0000-… 10:02:35 775 Protector created — ProtectorType 0x3 (recovery password) 10:02:35 813 Warning, parameter CurrentPolicy — repeats 46 times 10:02:36 845 Recovery key backed up to Entra ID 10:02:38 768 Algorithm 32772 (XTS-AES 128) 10:02:39 900 ErrorCode 0

There is no ProtectorType 0x1 (TPM) protector anywhere in the log. Only a recovery password. Get-BitLockerVolume confirms the consequence:

VolumeStatus : FullyEncrypted ProtectionStatus : Off EncryptionPercentage : 100

So the volume is fully encrypted but not protected — which is presumably why RequireDeviceEncryption is never satisfied.

Questions

Why does Windows create only a recovery-password protector and never a TPM protector, when the policy applies without error? What causes Event ID 813 with parameter CurrentPolicy to repeat on every MDM sync? Is there a way to have this remediate at scale, without granting local administrator rights on client devices?

Any pointers appreciated. I will post back what I find.

Microsoft Security | Intune | Enrollment
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. DanielS 0 Reputation points
    2026-08-17T13:31:38.1733333+00:00

    Root cause

    Event ID 814 in Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin, policy SystemDrivesRequireStartupAuthentication:

    ConfigureNonTPMStartupKeyUsage_Name   = false
ConfigureTPMStartupKeyUsageDropDown   = 0
ConfigurePINUsageDropDown_Name        = 2    <-- Require startup PIN with TPM
ConfigureTPMPINKeyUsageDropDown_Name  = 0
ConfigureTPMUsageDropDown_Name        = 2

SystemDrivesMinimumPINLength          = 6
AllowStandardUserEncryption           = 1

    A value of 2 means Require. Because a startup PIN requires a human to type it, Windows can never complete the protector step silently. It encrypts the volume, creates a recovery password so the data is recoverable, and stops. That is exactly what ProtectorType 0x3 with no 0x1 means, and it is why Event 813 / CurrentPolicy repeats on every sync — BitLocker cannot reconcile the policy with the achievable state.

    Confirming it

    In an elevated prompt:

    powershell

    manage-bde -protectors -add C: -tpmandpin

    The fact that this prompts for a PIN is itself the proof — with the policy set to Require, that is the only protector type permitted. After setting one:

    Key Protectors Added:

    TPM And PIN:
      ID: {GUID}
      PCR Validation Profile:
        0, 2, 4, 11

    VolumeStatus         : FullyEncrypted
ProtectionStatus     : On
EncryptionPercentage : 100

    The drive had already been 100% encrypted throughout. The only missing element was the TPM protector — precisely what Intune evaluates.

    Important: a sync is not enough, you need a reboot

    After adding the protector the device was still non-compliant several minutes later. The reason:

    Compliance setting Data source Refreshes on
    Require BitLocker Device Health Attestation reboot
    -------- -------- --------
    Require BitLocker Device Health Attestation reboot
    Require encryption of data storage local WMI query sync

    The DHA blob is only regenerated at boot, so an MDM sync just re-uploads the stale one. After a reboot plus a sync, and roughly 15–60 minutes for server-side evaluation, the device reported Compliant.

    The scalable fix — no local admin needed

    Endpoint security → Disk encryption → your BitLocker profile → BitLocker – OS Drive Settings:

    Compatible TPM startup PIN: Required → Blocked

    Compatible TPM startup: leave at Required — that is the TPM-only protector you want

    Minimum PIN length can stay, it becomes inert

    Verify afterwards in the log: Event 814 should report ConfigurePINUsageDropDown_Name = 0. On the next sync BitLocker creates the TPM protector itself, silently, with no user interaction and no administrator rights on the client.

    The manage-bde route above is diagnostic only. It is per-device, needs an interactive PIN, and leaves the user with a boot PIN — not something to roll out to a fleet.

    Secondary finding — PCR 7 is missing

    Note the validation profile: 0, 2, 4, 11. On a Secure Boot system the expected profile is 7, 11. Windows falls back to the legacy profile when it cannot trust the Secure Boot measurement, which lines up with the ValueFromTcgLog: false seen on 24H2.

    PCR Measures Changes when…
    0 Firmware / BIOS code any BIOS update
    -------- -------- --------
    0 Firmware / BIOS code any BIOS update
    2 Option ROMs (dock, GPU, NIC) docking, hardware change
    4 Boot manager and boot path boot order change, USB boot
    7 Secure Boot state only a genuine Secure Boot change
    11 BitLocker state itself normal operation

    With PCR 0, 2 and 4 in the profile, every BIOS update, boot order change or docking variation triggers a BitLocker recovery prompt. Under 7+11 none of them do. If you are seeing recovery prompts after firmware updates, check your PCR profile — it is a separate issue from the compliance one.

    Related, same machine, System → Event ID 1801, level Error:

    Provider:              Microsoft-Windows-TPM-WMI
FirmwareManufacturer:  Dell Inc.
FirmwareVersion:       1.27.1
BucketConfidenceLevel: Under Observation - More Data Needed

    TPM firmware vulnerability check — this firmware revision is not yet classified as known-good. Does not block compliance, but points at the same remedy: update the BIOS.

    Two traps worth knowing

    manage-bde's version banner does not reflect your OS. It printed Configuration Tool version 10.0.26100, which suggested the 25H2 upgrade had not landed. The actual build was 26200 / DisplayVersion 25H2. Query the build directly instead:

    powershell

    [System.Environment]

    Encrypted is not the same as protected. A drive at 100% tells you nothing about compliance. ProtectionStatus and the protector list are what matter.

    Noise that led nowhere

    Event ID Count Code What it is
    454 106 0x82aa0002 Policy node not found
    -------- -------- -------- --------
    454 106 0x82aa0002 Policy node not found
    404 72 0x80070426 Service not running — Wi-Fi profile applied before WlanSvc started; self-resolves on a later sync
    1507 16 — MDM sync throttling
    808 / 821 / 809 26 0x80070424 HomeGroup services, which do not exist in Windows 11
    — — 0x86000002 PassportForWork node not found during delete phase — normal policy cleanup
    201 6 0x80072efe Connection aborted mid-sync, transient

    The 0x86000002 PassportForWork error in particular sends people down a rabbit hole. It is node not found on a Windows Hello PIN-complexity delete. Cosmetic.

    Summary

    Cause: the BitLocker profile requires a startup PIN, so no TPM protector can be created — only ProtectorType 0x3.

    Effect: Intune evaluates the OS volume as unprotected, RequireDeviceEncryption is never satisfied, the device enters the grace period and goes non-compliant.

    Not the cause: enrollment, policy delivery, TPM health, device attestation, or encryption itself.

    Fix: one Intune setting. No local administrator rights, no per-device work, no waiting on a patch.

    Separate issue: the PCR profile omits PCR 7, which explains recovery prompts after firmware and boot changes. Remedy is a BIOS update.

    25H2 did not break this. The policy was always wrong — 24H2 simply tolerated it. If you are on 24H2 today with Require set, this is waiting for you.

    Root cause

    Event ID 814 in Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin, policy SystemDrivesRequireStartupAuthentication:

    ConfigureNonTPMStartupKeyUsage_Name   = false
ConfigureTPMStartupKeyUsageDropDown   = 0
ConfigurePINUsageDropDown_Name        = 2    <-- Require startup PIN with TPM
ConfigureTPMPINKeyUsageDropDown_Name  = 0
ConfigureTPMUsageDropDown_Name        = 2

SystemDrivesMinimumPINLength          = 6
AllowStandardUserEncryption           = 1

    A value of 2 means Require. Because a startup PIN requires a human to type it, Windows can never complete the protector step silently. It encrypts the volume, creates a recovery password so the data is recoverable, and stops. That is exactly what ProtectorType 0x3 with no 0x1 means, and it is why Event 813 / CurrentPolicy repeats on every sync — BitLocker cannot reconcile the policy with the achievable state.

    Confirming it

    In an elevated prompt:

    powershell

    manage-bde -protectors -add C: -tpmandpin

    The fact that this prompts for a PIN is itself the proof — with the policy set to Require, that is the only protector type permitted. After setting one:

    Key Protectors Added:

    TPM And PIN:
      ID: {GUID}
      PCR Validation Profile:
        0, 2, 4, 11

    VolumeStatus         : FullyEncrypted
ProtectionStatus     : On
EncryptionPercentage : 100

    The drive had already been 100% encrypted throughout. The only missing element was the TPM protector — precisely what Intune evaluates.

    Important: a sync is not enough, you need a reboot

    After adding the protector the device was still non-compliant several minutes later. The reason:

    Compliance setting Data source Refreshes on
    Require BitLocker Device Health Attestation reboot
    Require encryption of data storage local WMI query sync

    The DHA blob is only regenerated at boot, so an MDM sync just re-uploads the stale one. After a reboot plus a sync, and roughly 15–60 minutes for server-side evaluation, the device reported Compliant.

    The scalable fix — no local admin needed

    Endpoint security → Disk encryption → your BitLocker profile → BitLocker – OS Drive Settings:

    Compatible TPM startup PIN: Required → Blocked

    Compatible TPM startup: leave at Required — that is the TPM-only protector you want

    Minimum PIN length can stay, it becomes inert

    Verify afterwards in the log: Event 814 should report ConfigurePINUsageDropDown_Name = 0. On the next sync BitLocker creates the TPM protector itself, silently, with no user interaction and no administrator rights on the client.

    The manage-bde route above is diagnostic only. It is per-device, needs an interactive PIN, and leaves the user with a boot PIN — not something to roll out to a fleet.

    Secondary finding — PCR 7 is missing

    Note the validation profile: 0, 2, 4, 11. On a Secure Boot system the expected profile is 7, 11. Windows falls back to the legacy profile when it cannot trust the Secure Boot measurement, which lines up with the ValueFromTcgLog: false seen on 24H2.

    PCR Measures Changes when…
    0 Firmware / BIOS code any BIOS update
    2 Option ROMs (dock, GPU, NIC) docking, hardware change
    4 Boot manager and boot path boot order change, USB boot
    7 Secure Boot state only a genuine Secure Boot change
    11 BitLocker state itself normal operation

    With PCR 0, 2 and 4 in the profile, every BIOS update, boot order change or docking variation triggers a BitLocker recovery prompt. Under 7+11 none of them do. If you are seeing recovery prompts after firmware updates, check your PCR profile — it is a separate issue from the compliance one.

    Related, same machine, System → Event ID 1801, level Error:

    Provider:              Microsoft-Windows-TPM-WMI
FirmwareManufacturer:  Dell Inc.
FirmwareVersion:       1.27.1
BucketConfidenceLevel: Under Observation - More Data Needed

    TPM firmware vulnerability check — this firmware revision is not yet classified as known-good. Does not block compliance, but points at the same remedy: update the BIOS.

    Two traps worth knowing

    manage-bde's version banner does not reflect your OS. It printed Configuration Tool version 10.0.26100, which suggested the 25H2 upgrade had not landed. The actual build was 26200 / DisplayVersion 25H2. Query the build directly instead:

    powershell

    [System.Environment]

    Encrypted is not the same as protected. A drive at 100% tells you nothing about compliance. ProtectionStatus and the protector list are what matter.

    Noise that led nowhere

    Event ID Count Code What it is
    454 106 0x82aa0002 Policy node not found
    404 72 0x80070426 Service not running — Wi-Fi profile applied before WlanSvc started; self-resolves on a later sync
    1507 16 — MDM sync throttling
    808 / 821 / 809 26 0x80070424 HomeGroup services, which do not exist in Windows 11
    — — 0x86000002 PassportForWork node not found during delete phase — normal policy cleanup
    201 6 0x80072efe Connection aborted mid-sync, transient

    The 0x86000002 PassportForWork error in particular sends people down a rabbit hole. It is node not found on a Windows Hello PIN-complexity delete. Cosmetic.

    Summary

    Cause: the BitLocker profile requires a startup PIN, so no TPM protector can be created — only ProtectorType 0x3.

    Effect: Intune evaluates the OS volume as unprotected, RequireDeviceEncryption is never satisfied, the device enters the grace period and goes non-compliant.

    Not the cause: enrollment, policy delivery, TPM health, device attestation, or encryption itself.

    Fix: one Intune setting. No local administrator rights, no per-device work, no waiting on a patch.

    Separate issue: the PCR profile omits PCR 7, which explains recovery prompts after firmware and boot changes. Remedy is a BIOS update.

    25H2 did not break this. The policy was always wrong — 24H2 simply tolerated it. If you are on 24H2 today with Require set, this is waiting for you.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.