Securing an Autopilot device: compliance, BitLocker and LAPS

A device that provisions itself is only half the job. The other half is making sure that when it lands on someone’s desk it is encrypted, that its local administrator password is not the same on every machine, and that Intune can prove both.

This chapter covers compliance, Windows LAPS and BitLocker on a Windows 11 device that is Entra ID joined — no on-premises domain involved. It also spends a lot of time on a policy that silently refused to apply, because that is where the interesting part is.

The order matters

Do compliance first, LAPS second, BitLocker last.

Compliance is the cheapest to get right and it tells you whether the device is talking to Intune at all. LAPS gives you a way back into the machine if something goes wrong. BitLocker is the one that fights back, and you want the other two working before it does.

Compliance policy

A compliance policy does not configure anything. It evaluates the device and reports a verdict, which Conditional Access can later act on.

Windows LAPS

Every Windows machine has a local administrator account. If you set the password by hand, you set the same one everywhere, and it stays the same for years. Windows LAPS rotates a unique password per device and stores it in Entra ID.

Intune → Endpoint security → Account protection → Create policy → Local admin password solution (Windows LAPS).

Do not manage the built-in Administrator

The tempting option is to point LAPS at the built-in Administrator account. Don’t.

That account is RID 500 — the last three digits of its security identifier are fixed and identical on every Windows installation on earth. Renaming it changes the label, not the RID, and every credential-guessing tool looks it up by RID. It is also disabled by default on a modern install, and enabling it to manage it means creating an always-present, well-known target.

Use Automatic Account Management instead: LAPS creates its own account, with a name you choose and a random suffix.

Setting	Value
Backup Directory	Entra ID
Administrator Account Name	LocalAdmin
Automatic Account Management: Enabled	True
Automatic Account Management: Target	Automatic managed account
Password Age Days	30
Password Complexity	Large letters, small letters, numbers, specials
Password Length	20
Post Authentication Actions	Reset password and logoff the managed account

The resulting account is LocalAdmin####, where the digits differ per device.

Retrieving the password

Entra admin center → Devices → All devices → [device] → Local administrator password recovery.

BitLocker: the part that fights back

The goal is silent encryption: the disk encrypts itself with no user interaction, no PIN at boot, and the recovery key lands in Entra ID.

Intune → Endpoint security → Disk encryption → Create policy → BitLocker. The essential settings are: encryption method XTS-AES 256, OS drive encryption type Full, TPM required, no PIN, recovery key backed up to Entra, and “Allow standard users to enable encryption during Autopilot” enabled — because the Autopilot profile creates a Standard user, and without this the encryption never starts.

Then it did not work.

What manage-bde reported

Conversion Status:    Used Space Only Encrypted
Percentage Encrypted: 100.0%
Encryption Method:    XTS-AES 128      ← policy asked for 256
Protection Status:    Protection Off
Key Protectors:       None Found

Protection Off with Key Protectors: None Found on a volume that is 100% encrypted looks contradictory. It isn’t. This is pre-provisioning: Windows encrypts the volume during setup using a clear key, and waits for a policy to add a TPM protector and a recovery key. The policy never came.

First cause: a policy conflict, and it is silent

The Defender security baseline also contains BitLocker settings. When a baseline and a dedicated policy configure the same setting with different values, Intune puts that setting in Conflict — and applies neither. The device falls back to the Windows default.

Nothing tells you. No error on the device, no failure in the Enrollment Status Page, no red banner in the portal. The setting just quietly does not exist.

To see it: Devices → [device] → Device configuration → [policy name]. That view shows the state of each individual setting, with the Source Profiles that are fighting over it.

Setting in conflict	What the device got instead
Choose drive encryption method and cipher strength	XTS-AES 128
Enforce drive encryption type on operating system drives	Used Space Only
Require additional authentication at startup	TPM/PIN not governed by policy

That experience produced a rule worth keeping: dedicated policies win, baselines get trimmed — and if a baseline will not let you set something to Not configured, the fallback is to make its value identical to the dedicated policy, because identical values do not conflict.

Second cause: an error message that lies

With the conflict gone, encryption still refused to start. The BitLocker event log — Microsoft-Windows-BitLocker/BitLocker Management, event 853 — said:

Failed to enable Silent Encryption. TPM is not available.

Error: BitLocker Drive Encryption detected bootable media (CD or DVD) in the
computer. Remove the media and restart the computer before configuring BitLocker.

The first line is wrong. Get-Tpm reported TpmPresent: True and TpmReady: True.

The second line is the real cause: the Windows 11 and virtio-win ISOs were still mounted in the VM’s virtual CD drives. BitLocker refuses to start when bootable media is present, because it would alter the boot chain that the TPM measures.

Fix: Proxmox → VM → Hardware → each CD/DVD Drive → Do not use any media → reboot.

Third trap: looking in the wrong registry key

The obvious place to check whether a BitLocker policy reached the device is:

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker"

The three contested settings are not there, because they are ADMX-backed. Looking there and finding nothing makes it seem the policy never arrived. The real values live elsewhere:

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\FVE"

Value	Meaning
EncryptionMethodWithXtsOs	7 = XTS-AES 256 · 6 = XTS-AES 128
OSEncryptionType	1 = Full encryption · 2 = Used Space Only
UseTPM / UseTPMPIN	2 = required / 0 = no PIN at boot (silent)
EnableBDEWithNoTPM	0 = no encryption without a TPM

The result, including the part that did not work

Cipher and encryption type are chosen when encryption starts and cannot be changed while it runs. Changing them means decrypting and starting over:

manage-bde -off C:      # wait for "Fully Decrypted"
# reboot — the policy re-encrypts from scratch
manage-bde -status

Final state:

Encryption Method:  XTS-AES 256               ✅ as configured
Conversion Status:  Used Space Only           ❌ policy asked for Full
Protection Status:  Protection On             ✅
Key Protectors:     TPM + Numerical Password  ✅

The cipher changed. The encryption type did not, even though OSEncryptionType = 1 was correctly present in the registry.

The reason is by design: MDM-driven silent encryption always uses used-space-only. It is meant for new devices and optimised for speed. The ADMX setting that enforces encryption type governs encryptions started manually, not the silent path.

Note also that re-encrypting generates a new recovery key. The previous one in Entra becomes useless — worth knowing before you file it somewhere.

Diagnostics worth keeping

# did the policy reach the device? (non-ADMX settings)
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker"

# the ADMX-backed ones
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\FVE"

# is the TPM usable?
Get-Tpm

# is WinRE enabled? (required for silent encryption)
reagentc /info

# the actual reason for the failure
Get-WinEvent -LogName "Microsoft-Windows-BitLocker/BitLocker Management" -MaxEvents 15 |
  Format-List TimeCreated, Id, Message

What this chapter is really about

Three of the four problems here were silent. A conflicting policy that applies nothing and says nothing. An event log that blames the TPM for a mounted ISO. A registry key that looks empty because the values are somewhere else.

None of them produce an error the user would report. The device works, the desk is happy, and the disk is encrypted with a clear key and no recovery protector — which is to say, not protected at all.

The habit worth building is to verify the end state on the device, not the deployment status in the portal. manage-bde -status and a look at the recovery key in Entra take thirty seconds and answer the question the dashboard only appears to answer.