Fix Autopilot BitLocker Defaulting to XTS-AES 128-bit When 256-bit Is Configured

Your Intune disk encryption profile says XTS-AES 256-bit. Compliance and security baselines expect 256-bit. The Autopilot device finishes OOBE cleanly, recovery keys land in Entra, and nobody complains until audit day.

Then Get-BitLockerVolume returns EncryptionMethod : XtsAes128.

That mismatch is not always a bad policy assignment. Microsoft documents a known Autopilot race where some deployments of unregistered devices encrypt with the Windows default XTS-AES 128-bit even though the admin configured 256-bit. Separately, Microsoft’s Autopilot BitLocker guidance is clear: automatic device encryption starts during OOBE with XTS-AES 128-bit used space only unless your policy arrives before BitLocker is first enabled. Once the volume is encrypted, changing the cipher requires decrypt and re-encrypt.

Treat this as a policy-timing and registration problem first. Do not rebuild the entire BitLocker stack until you prove whether encryption started with the wrong method.

Quick fix checklist

Use this order on one affected device, then fix the fleet path.

1. Confirm the live cipher:

   Get-BitLockerVolume -MountPoint 'C:' |
       Select-Object MountPoint, VolumeStatus, EncryptionPercentage, EncryptionMethod, ProtectionStatus

2. Confirm the intended Intune setting is XTS-AES 256-bit for the OS drive under Endpoint security > Disk encryption > BitLocker.
3. Confirm the device was a Windows Autopilot registered device before OOBE, not a plain Entra join or bulk-provisioned machine that only later received a hash import.
4. Confirm an Enrollment Status Page (ESP) is assigned and enabled. Microsoft states that without ESP, the BitLocker policy does not apply before encryption starts.
5. Confirm the BitLocker profile is assigned to a device group that contains the Autopilot device object, not only a user group.
6. If the volume is already XtsAes128 and policy requires 256-bit, plan a controlled decrypt → sync policy → re-encrypt window. You cannot silently “upgrade” the cipher in place.
7. For new hardware that must ship at 256-bit, register the device in Windows Autopilot before first user OOBE, assign the BitLocker profile to the Autopilot device group, and keep ESP on.

Do not assume a failed escrow or a missing recovery key is the same issue. Wrong cipher and missing key are different failures.

What Microsoft says is happening

Known issue: unregistered Autopilot-path devices

On the Windows Autopilot known issues page, Microsoft states:

In some Windows Autopilot deployments of unregistered devices, BitLocker encryption might default to 128-bit even though the admin configured 256-bit encryption due to a known race condition. The issue is being investigated. Microsoft recommends that customers who need 256-bit BitLocker encryption register devices for Windows Autopilot.

That sentence is the panic-search match for auditors and security teams. The product path can look like Autopilot because the user sees ESP or OOBE enrollment, but the hardware was never registered in the Autopilot service. Unregistered devices are exactly where Microsoft still warns about the 128-bit default race.

Expected default for automatic device encryption

Microsoft’s Autopilot BitLocker article explains the normal platform behavior:

• BitLocker automatically encrypts internal drives during OOBE on devices that support Modern Standby or meet HSTI requirements.
• By default, automatic encryption uses XTS-AES 128-bit used space only.
• With Autopilot, BitLocker settings can be configured so they apply before automatic encryption starts, so the default algorithm or type is not applied.
• A device that receives the desired settings after it has already encrypted automatically must be decrypted before the encryption algorithm can change.
• During Autopilot, BitLocker is enabled after the device setup portion of the Enrollment Status Page.
• Available algorithms include AES-CBC 128/256 and XTS-AES 128/256. The Windows default remains XTS-AES 128-bit.

Those two Microsoft sources together explain almost every “policy says 256, disk says 128” ticket after Autopilot:

Condition	Typical result
Device registered in Autopilot, ESP on, BitLocker profile targeted to the device group before OOBE	Policy can apply before first enablement; 256-bit is attainable
Device not registered, or policy arrives after automatic encryption	Volume often ends as XtsAes128
Policy targeted only to users, ESP disabled, or device setup completes before the profile installs	Race favors the platform default
Volume already encrypted, then 256-bit policy assigned later	Cipher stays 128-bit until decrypt/re-encrypt

Root cause

BitLocker locks the encryption method at first enablement. Windows device encryption is designed to protect the disk early in OOBE. Intune can steer that first enablement only when:

1. the device is in scope for the BitLocker profile early enough,
2. ESP keeps device setup alive long enough for the policy to land,
3. the Autopilot registration path is the one Microsoft designed for pre-encryption policy delivery.

If any of those fail, automatic encryption proceeds with the platform default. Your 256-bit setting remains “assigned” in the portal while the volume quietly uses XtsAes128.

The known-issue race on unregistered devices is the worst version of that timing problem: the admin believes Autopilot and Intune are in control, but the service path Microsoft recommends for 256-bit customers was never established.

Logs and where to check

1. Prove the cipher on the device

Get-BitLockerVolume |
    Select-Object MountPoint, VolumeType, VolumeStatus,
                  EncryptionPercentage, EncryptionMethod,
                  ProtectionStatus, KeyProtector

Healthy target for a 256-bit OS drive policy:

• EncryptionMethod = XtsAes256
• VolumeStatus = FullyEncrypted
• ProtectionStatus = On

XtsAes128 with a 256-bit policy is the mismatch this article covers.

You can also use:

manage-bde -status C:

Look for the Encryption Method line. Capture a screenshot or export before any decrypt work.

2. Confirm Autopilot registration state

In Intune:

1. Devices > Windows > Windows enrollment > Devices (Windows Autopilot devices).
2. Search by serial number.
3. Confirm the device exists, shows the expected profile, and profile status is Assigned.

On the client, during or after OOBE diagnostics:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot' |
    Select-Object CloudAssignedTenantId, CloudAssignedTenantDomain,
                  CloudAssignedOobeConfig, IsAutopilotDisabled

If the serial is missing from Autopilot devices, treat the box as an unregistered deployment for this failure mode, even if the user completed Entra join through another path.

3. Confirm BitLocker policy assignment and ESP

In Intune:

1. Endpoint security > Disk encryption
2. Open the BitLocker profile that sets Choose drive encryption method and cipher strength
3. Verify OS drive method is XTS-AES 256-bit
4. Verify assignment is a device group containing Autopilot devices
5. Devices > Windows > Enrollment > Enrollment Status Page
6. Confirm ESP is assigned and device ESP is not effectively skipped for that cohort

Microsoft’s Autopilot BitLocker page is explicit: if ESP is not enabled, the BitLocker policy does not apply before encryption starts.

4. MDM report on the client

mdmdiagnosticstool.exe -area DeviceEnrollment;DeviceProvisioning;Autopilot -cab C:\Temp\autopilot-bitlocker.cab

Also review:

Get-WinEvent -LogName 'Microsoft-Windows-BitLocker/BitLocker Management' -MaxEvents 100 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

and:

Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 200 |
    Where-Object { $_.Message -match 'BitLocker|Encryption|./Device/Vendor/MSFT/BitLocker' } |
    Select-Object TimeCreated, Id, Message

You are looking for whether BitLocker CSP settings arrived before or after the volume became protected.

5. Graph / inventory spot-check for fleet scope

After Graph auth in your normal admin session:

# Example: list managed Windows devices and later join to a local cipher inventory export
Get-MgDeviceManagementManagedDevice -All |
    Where-Object { $_.OperatingSystem -eq 'Windows' } |
    Select-Object DeviceName, SerialNumber, AzureADDeviceId, EnrolledDateTime |
    Export-Csv .\windows-managed-devices.csv -NoTypeInformation

Pair that export with a proactive remediation or endpoint analytics script that records EncryptionMethod so you can find every XtsAes128 outlier instead of waiting for the next audit sample.

Repair a device that already encrypted at 128-bit

Policy alone will not re-cipher an encrypted OS volume. Microsoft states that a device receiving the desired settings after automatic encryption must be decrypted before the algorithm can change.

Controlled repair path

1. Capture recovery key status in Entra ID / Intune before you touch encryption.
2. Put the device in a maintenance window. Full decrypt and re-encrypt can take hours on large disks.
3. Suspend BitLocker only if your runbook requires it for intermediate reboots; for a full method change you need decrypt.
4. Decrypt the OS volume with an approved admin identity:

   Disable-BitLocker -MountPoint 'C:'

   or:

   manage-bde -off C:

5. Wait until decryption completes:

   while ((Get-BitLockerVolume -MountPoint 'C:').VolumeStatus -ne 'FullyDecrypted') {
       Get-BitLockerVolume -MountPoint 'C:' |
           Select-Object VolumeStatus, EncryptionPercentage, EncryptionMethod
       Start-Sleep -Seconds 60
   }

6. Confirm the device is still in the Autopilot device group and the BitLocker profile shows success or pending on next sync.
7. Sync Intune:

   Get-ScheduledTask |
       Where-Object { $_.TaskName -match 'PushLaunch|Schedule to run' } |
       Start-ScheduledTask
   # or Settings > Accounts > Access work or school > Info > Sync

8. Re-enable BitLocker only after the 256-bit policy is present on the client. Silent enablement from the Intune profile is preferred over a one-off local command that might use a different method.
9. Verify:

   Get-BitLockerVolume -MountPoint 'C:' |
       Select-Object EncryptionMethod, VolumeStatus, ProtectionStatus, KeyProtector

   Expect XtsAes256, FullyEncrypted, and recovery protectors backed up to Entra.

If the device was never Autopilot-registered and must remain 256-bit going forward, complete registration and correct group assignment before the next wipe or redeploy. Repairing one disk without fixing registration recreates the race on the next hardware refresh.

What not to do

• Do not delete recovery keys from Entra “to force rotation” as a cipher fix.
• Do not assume turning the policy off and on re-encrypts at 256-bit.
• Do not target the BitLocker profile only to user groups and expect Autopilot device setup to honor it in time.
• Do not wipe production devices solely because of cipher mismatch if a planned decrypt/re-encrypt is acceptable and keys are escrowed.

Configure Autopilot so new devices encrypt at 256-bit the first time

Follow Microsoft’s Autopilot BitLocker configuration path.

1. Create the BitLocker profile

1. Intune admin center > Endpoint security > Disk encryption
2. Create policy
3. Platform Windows, profile BitLocker
4. Under BitLocker Drive Encryption, set Choose drive encryption method and cipher strength to Enabled
5. Set Operating system drive to XTS-AES 256-bit
6. Set fixed and removable drive methods to match your standard
7. Under Operating System Drives, configure Enforce drive encryption type on operating system drives if you must force full-disk vs used-space-only. Remember silent enablement and Modern Standby hardware can influence type unless enforced

2. Assign to Autopilot device groups

Assign the profile to the device group used for Autopilot hardware, not only the user cohort that signs in later. Microsoft calls this out as important on the Autopilot BitLocker page.

3. Keep ESP enabled

Configure and assign an Enrollment Status Page for the same Autopilot audience. ESP is the gate that lets BitLocker policy apply during device setup before automatic encryption wins the race.

4. Register devices before first OOBE

For any fleet that requires 256-bit:

• OEM or partner registration, or
• hash import before shipping, or
• existing-device Autopilot registration completed before the user reset

Microsoft’s known-issue guidance is direct: customers who need 256-bit BitLocker encryption should register devices for Windows Autopilot.

5. Pilot validation checklist

Before broad rings:

1. Register a pilot serial in Autopilot.
2. Assign deployment profile, ESP, and BitLocker profile to the pilot device group.
3. Reset and run OOBE once.
4. At desktop, run Get-BitLockerVolume and confirm XtsAes256.
5. Confirm the recovery key exists on the Entra device object.
6. Only then promote the ring.

PowerShell: fleet cipher audit snippet

Run from a management context that can reach endpoints, or package as a remediation detection script:

$os = Get-BitLockerVolume -MountPoint $env:SystemDrive -ErrorAction Stop

[pscustomobject]@{
    ComputerName         = $env:COMPUTERNAME
    MountPoint           = $os.MountPoint
    EncryptionMethod     = $os.EncryptionMethod.ToString()
    VolumeStatus         = $os.VolumeStatus.ToString()
    ProtectionStatus     = $os.ProtectionStatus.ToString()
    EncryptionPercentage = $os.EncryptionPercentage
    MeetsXtsAes256       = ($os.EncryptionMethod.ToString() -eq 'XtsAes256')
    TimestampUtc         = [datetime]::UtcNow.ToString('o')
} | ConvertTo-Json -Compress

Detection rule idea:

• exit 0 when method is XtsAes256
• exit 1 when method is XtsAes128 or another non-compliant cipher

Remediation should not blindly decrypt. Queue the device for a change window and technician or automation that already verified key escrow.

Prevention for desktop engineering and security

Bake cipher proof into the Autopilot Definition of Done.

Gate	Pass condition
Hardware intake	Serial present in Windows Autopilot devices before ship
Encryption policy	OS drive method = XTS-AES 256-bit, assigned to Autopilot device group
ESP	Assigned and required for device setup
Pilot sign-off	Get-BitLockerVolume shows XtsAes256 on first OOBE
Audit export	Periodic inventory of EncryptionMethod across Windows managed devices
Redeploy	Registration retained or re-imported before wipe; do not rely on post-encryption policy alone

Security baselines that “require BitLocker” without checking cipher strength will green-light XtsAes128 devices. Add the method check to compliance reporting if 256-bit is a contractual or internal control.

Conclusion

When Autopilot devices show XTS-AES 128-bit despite an Intune 256-bit BitLocker profile, start with Microsoft’s two facts:

1. Automatic device encryption defaults to XTS-AES 128-bit, and the method is set when BitLocker is first enabled.
2. Some Autopilot deployments of unregistered devices can still land on 128-bit because of a documented race; Microsoft recommends Autopilot registration for customers that require 256-bit.

Verify EncryptionMethod, Autopilot registration, device-group assignment, and ESP timing. For already-wrong volumes, decrypt only after recovery keys are confirmed, sync the 256-bit policy, then re-encrypt and re-check. For new hardware, register first, assign BitLocker to the Autopilot device group, keep ESP on, and refuse to call the pilot done until Get-BitLockerVolume returns XtsAes256.