---

Why Your Intune BitLocker Policy Isn’t Updating (TPM + PIN, 128-bit → 256-bit)

BitLocker in Intune looks simple on paper.
You create a policy, choose TPM + PIN, set XTS-AES 256-bit, push it to devices, and expect Windows to just update.

In reality, it doesn’t work that way—especially if devices were already encrypted with an older policy.

This post breaks down what happened in the Reddit thread and what it means for your own environment.

---

Scenario: Changing BitLocker Policy in Intune

The admin in the thread did what many of us eventually do:

• Switched BitLocker protector from TPM only → TPM + PIN
• Changed encryption method from 128-bit → 256-bit
• Adjusted minimum PIN length:
  • Test: 8 digits
  • Production: 6 digits

After updating the Intune BitLocker configuration profile, they expected existing devices to:

• Move from 128-bit to 256-bit encryption
• Update the required PIN length from 8 to 6

But on the client machines:

• Drives stayed at 128-bit encryption.
• The registry under
  HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE
  still showed 8 for PIN length.

So the new policy wasn’t taking effect on already-encrypted devices.

---

Why Encryption Method Doesn’t Change Automatically

One of the replies (from an MVP) pointed out a key BitLocker behavior:

Changing the encryption method in policy does not re-encrypt existing drives.

If a device was originally encrypted with XTS-AES 128-bit, and you change the policy to XTS-AES 256-bit, Windows does not:

• Decrypt the disk
• Re-encrypt with the new algorithm

Instead, BitLocker keeps using the encryption method that was active when the drive was first encrypted.

What you must do for 128-bit → 256-bit

To move from 128-bit to 256-bit on already encrypted devices, you have to:

1. Decrypt the drive (suspend is not enough).
2. Confirm encryption is fully removed.
3. Trigger BitLocker encryption again under the new policy (256-bit).

Intune policies control how encryption happens when it starts, not retroactively. If you are planning a tenant-wide move to 256-bit, that means a planned decrypt + re-encrypt rollout.

---

PIN Minimum Length: Why It Also Stays on the Old Value

The second part of the problem is the PIN minimum length.

• Old test policy: 8-digit minimum PIN.
• New production policy: 6-digit minimum PIN.

Even after changing the policy, the registry still showed the old value (8). The OP wanted this to update automatically on devices that already had BitLocker set up.

From the reported behavior:

• Devices that already had a PIN configured under the old policy did not get their local policy value updated.
• The registry under …\FVE still enforced the old minimum.

In other words:

BitLocker policy settings like PIN minimum length don’t always “downgrade” or change in place on already-configured devices.

And there was no clear, automatic way in the thread to:

• Push a new minimum length
• And have Windows re-evaluate existing protectors without manual work

---

What This Means for Your Intune Design

The key takeaway from the thread:

Intune BitLocker configuration is “first-run critical.”
Once a drive is encrypted and a PIN is set, changing the policy later will not magically rework the existing setup.

So when you design your BitLocker policy:

1. Decide on the final encryption algorithm early
   • If you want XTS-AES 256-bit, start with that from day one.
   • Migrating later means decrypting and re-encrypting.
2. Lock in your PIN requirements before mass rollout
   • Minimum length
   • Complexity (numeric only or alphanumeric, depending on your policy)
   • User experience and helpdesk impact
3. Treat policy changes as a project, not a simple flip:
   • Plan maintenance windows for decrypt/re-encrypt if needed.
   • Communicate clearly with users.
   • Pilot on a small device group first.

---

What Can You Do If You’re Already in This Situation?

If you’re already live with 128-bit + TPM only, and you now want TPM + PIN and 256-bit, you basically have two paths.

Option 1 – Full Clean-Up and Re-Apply

For devices that must meet the new standard:

1. Backup recovery keys (ensure they’re in Entra / AD / Key Escrow).
2. Use Intune or a script to:
   • Disable BitLocker (decrypt).
   • Wait for decryption to complete.
   • Confirm the disk is unencrypted.
3. Ensure updated BitLocker policy (TPM + PIN, 256-bit, PIN length) is assigned.
4. Trigger BitLocker again (policy or script) so it encrypts under the new settings.

This is more work but gives clean, consistent BitLocker state.

Option 2 – Accept the Existing State and Apply Changes Only to New Devices

If a full re-encrypt project isn’t realistic:

• Leave existing 128-bit encrypted machines as they are.
• Make sure all new devices use the final policy (TPM + PIN, 256-bit, your chosen PIN length).
• Enforce the new baseline with:
  • Compliance policies
  • Security baselines
  • Conditional Access rules (if you want to block non-compliant devices over time)

You could then replace or rebuild older devices gradually instead of changing everything at once.

---

Why There Was No “Magic Fix” for the PIN Length

The thread ends without a neat solution for automatically updating PIN minimum length on already-encrypted devices.

That’s the honest reality:

• BitLocker policy is not a full “config drift correction” engine.
• It doesn’t:
  • Shorten existing PINs
  • Automatically reconfigure protectors on every change
• Any deep change (like PIN requirements, protector type, or encryption method) usually needs:
  • Manual steps, or
  • A scripted/automated workflow you control

For now, there is no built-in Intune button that says “re-apply BitLocker policy and rebuild all PINs to the new rules.”

---

Takeaways for Intune / BitLocker Admins

If you’re planning or reworking your BitLocker rollout in Intune, keep these lessons in mind:

• Plan once, deploy once: agree on TPM + PIN vs TPM only, 128-bit vs 256-bit, and PIN length before mass deployment.
• Policy changes don’t rewrite history: encryption algorithm and PIN requirements set at first run will stay unless you decrypt / re-encrypt or manually rebuild protectors.
• Treat major BitLocker changes like a migration project, not a quick policy edit.
• Use pilots: always test policy changes on a small group before rolling out to your whole fleet.