Maynor in the Cloud / Beyond the Tenant

The Windows servicing transition exposed a BitLocker configuration conflict that was already sitting on the endpoint.

BitLocker Recovery on Windows 11 24H2

The BitLocker recovery Windows 11 24H2 issue first appeared during a Windows servicing transition.

Users with BitLocker configured for TPM + PIN could no longer use their normal startup PIN. The PIN was correct, but BitLocker rejected it and forced the device into recovery, requiring the 48-digit recovery key before Windows would boot.

Microsoft troubleshooting found TPM resealing activity, but no TPM hardware failure.

At first glance, it looked like the Windows upgrade had broken BitLocker.

The deeper investigation showed something else.

The Windows servicing transition exposed a BitLocker configuration conflict that was already sitting on the endpoint.

Symptoms

BitLocker startup PIN rejected even when entered correctly
device forced into BitLocker Recovery
48-digit recovery key required to boot
TPM resealing activity observed
no TPM hardware failure identified
devices using TPM + PIN protectors
legacy BitLocker configuration still present outside the intended Intune model

That changed the troubleshooting question.

What is actually controlling BitLocker on this endpoint?

Microsoft Has Documented the Same Failure Pattern

Microsoft has documented a Windows 11 24H2 BitLocker issue where the correct startup PIN can be rejected after a specific Windows servicing rollback scenario.

In Microsoft’s documented case, the issue can occur after uninstalling a cumulative update and rolling the OS build back below 26100.4770 after KB5063878 or a later update had previously been installed. The device can then fail to unlock even when the correct BitLocker PIN is entered.

That does not prove this environment was affected by that exact Microsoft defect.

The value of the Microsoft documentation is that it confirms the failure pattern itself is real: on Windows 11 24H2, a servicing transition can result in a valid BitLocker PIN being rejected.

In our case, the investigation went further. The endpoint contained legacy BitLocker configuration that did not align with the intended Intune-managed state.

Microsoft: BitLocker recovery known issues

Investigation

The first assumption was that Group Policy was still enforcing the older BitLocker configuration.

That would have made sense.

The devices were configured with TPM + PIN, advanced startup requirements, legacy BitLocker behavior, and settings that did not align with the intended Intune-managed target state.

So we checked Group Policy.

GPResult did not show an active BitLocker GPO enforcing the configuration.

But the registry values were still there.

That was the point where the investigation changed direction.

The policy was no longer coming from an actively linked GPO. The configuration had been embedded in the golden image used to build the devices.

During troubleshooting, we specifically looked at BitLocker FVE registry state, including values such as TPMPin and UseAdvancedStartup.

Those values were still influencing the endpoint even though Intune was supposed to become the management authority.

The Configuration Conflict

Legacy Endpoint State

Golden-image configuration
TPM + PIN protector
Advanced startup requirements
Persistent FVE registry state

↔

Intune Target State

Intune-managed BitLocker
TPM-only protector
Standardized configuration
Single intended management authority

Figure 1. Desired state in Intune is not necessarily the effective state on the endpoint while legacy configuration is still present.

Root Cause

The devices retained legacy BitLocker policy state inherited from the desktop image.

That legacy state did not align with the intended Intune-managed protector configuration.

During the Windows servicing transition, TPM and BitLocker resealing activity exposed that existing conflict. Affected devices began rejecting the expected startup PIN and forcing users into BitLocker Recovery.

The issue was not an active GPO in this environment. It was persistent configuration state from the golden image.

The Same Configuration Conflict Can Come From Group Policy

The delivery mechanism matters for the RCA, but the troubleshooting pattern is broader.

In this incident, the legacy configuration came from the golden image.

In another environment, the same effective-state conflict could come from:

an active Group Policy configuration
residual registry-based configuration originally introduced through Group Policy
a provisioning script
an endpoint build process
another management platform
registry configuration that survives after the original control has been removed

The troubleshooting question stays the same:

What is actually enforcing the BitLocker state on the endpoint?

Having an Intune policy does not automatically make Intune authoritative.

Corrective Action

The remediation strategy was to remove the competing legacy state and allow Intune to become the actual management authority.

Remove the legacy BitLocker FVE registry configuration inherited from the image.
Remove the TPM + PIN configuration remnants.
Clear the TPM where required on affected devices.
Allow the existing Intune BitLocker policy to reapply.
Normalize the protector configuration to TPM-only.
Validate the change through a pilot before wider deployment.
Use Intune detection and remediation scripts to identify and correct affected endpoints at scale.

The goal was not to decrypt and re-encrypt every drive just because the configuration was wrong.

The goal was to correct the management state while keeping BitLocker protection in place wherever possible.

Why Clearing the TPM Was Not the First Step

Clearing the TPM is not the first troubleshooting step just because BitLocker enters recovery.

It is a consequential operation.

You first need to understand why the protector state is wrong.

If the endpoint is still receiving or retaining conflicting configuration, clearing the TPM without fixing that control path does not solve the actual architecture problem.

I would start with protector state, Group Policy, FVE registry configuration, endpoint build history, Intune policy, and effective configuration on the device. Then determine whether TPM remediation is required.

That order matters.

Validation

The fix is not complete because a registry value was removed.

The endpoint needs to prove that the intended management model is actually working.

Validation should include:

BitLocker remains enabled
the expected TPM-only protector is present
recovery information is escrowed correctly
the device restarts normally
the user is not unexpectedly forced into recovery
Intune reports the expected BitLocker configuration
the legacy FVE state does not return
compliance remains healthy after policy refresh and restart

If the old values return, then the original enforcement source has not actually been removed.

The Troubleshooting Lesson

The most important part of this issue was not Windows 11 24H2 by itself.

The Windows servicing transition exposed a control conflict that already existed on the endpoint.

In this environment, the conflict came from the golden image. In another environment, it could be Group Policy or another legacy configuration source.

The troubleshooting model is the same:

When Intune says one thing and the endpoint behaves differently, validate the effective configuration on the device before assuming Intune is the source of authority.

Closing Position

Modern management is not authoritative simply because the Intune policy exists. It becomes authoritative only when legacy configuration sources are no longer enforcing a competing state on the endpoint.

The 24H2 transition exposed it. Legacy BitLocker state was the environmental root cause we identified.

This BitLocker recovery Windows 11 24H2 incident reinforced that effective endpoint configuration matters more than intended policy state.