Resolve Device Noncompliance for Locally Encrypted Workstations

Reconcile the workstation by confirming BitLocker is fully encrypted and actively protected, verifying that its recovery-password protector is escrowed to Microsoft Entra ID, then rebooting and manually syncing the device so Intune can recalculate compliance.

1. Confirm the local BitLocker state

Run PowerShell as administrator:

$volume = Get-BitLockerVolume -MountPoint $env:SystemDrive
$volume | Format-List MountPoint,VolumeStatus,ProtectionStatus,
    EncryptionMethod,EncryptionPercentage,KeyProtector

manage-bde.exe -status $env:SystemDrive
manage-bde.exe -protectors -get $env:SystemDrive

The expected state is:

• VolumeStatus: FullyEncrypted
• ProtectionStatus: On
• EncryptionPercentage: 100
• At least the protector required by policy, such as TPM or TPM+PIN
• A RecoveryPassword/Numerical Password protector for recovery and escrow

FullyEncrypted alone is insufficient if protection is suspended, the drive is waiting for activation, or its protector type does not match policy. Microsoft documents these local status fields and commands in the BitLocker operations guide.^1^

2. Verify recovery-key escrow

In the Intune admin center:

1. Go to Devices > All devices.
2. Select the workstation.
3. Under Monitor, select Recovery keys.
4. Select Show Recovery Key.
5. Match the displayed BitLocker Key ID to the recovery-password protector ID returned locally.

Viewing a key requires microsoft.directory/bitlockerKeys/key/read, included in roles such as Cloud Device Administrator, Helpdesk Administrator, and Global Administrator. Access to the key is audited.^2^

If Intune reports No BitLocker key found for this device, and the machine is Microsoft Entra joined, escrow the existing recovery-password protector from elevated PowerShell:

$volume = Get-BitLockerVolume -MountPoint $env:SystemDrive
$recovery = $volume.KeyProtector |
    Where-Object KeyProtectorType -eq 'RecoveryPassword'

if (-not $recovery) {
    $recovery = Add-BitLockerKeyProtector `
        -MountPoint $env:SystemDrive -RecoveryPasswordProtector
}

$recovery.KeyProtectorId | ForEach-Object {
    BackupToAAD-BitLockerKeyProtector `
        -MountPoint $env:SystemDrive -KeyProtectorId $_
}

The cmdlet saves the recovery-password protector to Microsoft Entra ID.^3^

Reopen Recovery keys and confirm the same protector ID appears. If escrow fails, verify network connectivity and inspect the device’s BitLocker event log; Intune specifically reports network unavailability and recovery-key backup failure as possible status details.^4^

3. Compare local state with Intune policy

Open Devices > Manage devices > Configuration > Monitor > Device encryption status, then select the workstation. Review:

• Encryption status
• Encryption readiness
• Profile state summary
• Status details
• Applicable profiles

Intune can report a locally encrypted device as erroneous when:

• The local encryption method differs from policy, such as XTS-AES 256 versus XTS-AES 128.
• Policy requires TPM, TPM+PIN, or another protector that is absent.
• The OS volume is encrypted but protection is suspended.
• Recovery-key backup failed.
• The device was encrypted locally rather than initiated by Intune, leaving the profile state in error.^5^

If only the encryption method differs, changing the policy to accept the deployed method is safer than decrypting devices. Microsoft’s documented alternative is to decrypt and let Intune encrypt again, but that temporarily exposes data and should be used only through a controlled migration.^5^

4. Trigger compliance recalculation

If the compliance policy uses Require BitLocker, its attested state is measured at boot. Therefore:

1. Restart the workstation after protection and escrow are correct.
2. After sign-in, go to Settings > Accounts > Access work or school.
3. Select the managed work account > Info > Sync.^6^
4. Optionally open Company Portal > Devices > Check Status.
5. In Intune, review Devices > Compliance > the applicable policy > Per-setting status.

A reboot can be required before Require BitLocker becomes compliant, and reporting can take up to 24 hours while the online device checks in, processes policy, and reports its result.^7^^8^

If it remains noncompliant after that interval, compare Calculated policy version with Latest policy version and capture the exact noncompliant setting and error code. A newer latest version means the displayed compliance result can be stale.^9^

References

1. Backs up the BitLocker recovery password protector to Microsoft Entra ID using the BitLocker PowerShell module.
2. Encrypt Windows devices with BitLocker using Intune
3. Saves a recovery password key protector for a specified BitLocker volume to Microsoft Entra ID using the BackupToAAD-BitLockerKeyProtector cmdlet in PowerShell.
4. Monitor device encryption with Intune
5. Troubleshooting BitLocker with the Intune encryption report
6. Sync enrolled device for Windows
7. Device Compliance settings for Windows in Intune
8. Monitor results of your Intune Device compliance policies
9. Intune Reports