Windows 11 Build 28020.3532 Lets Standard Users Set BitLocker PINs, Fixes Remote Desktop

Microsoft's release notes describe the update as a small set of general improvements and fixes, and say these changes are being rolled out gradually. Installing the build doesn't guarantee you'll see the BitLocker feature right away.

Where this build sits in the 26H1 track​

The 26H1 branch is not a normal Windows 11 feature update. Microsoft's release information page says Windows 11, version 26H1 is scoped to support new devices that started coming to market in early 2026 and is not designed as a feature update for existing devices. It also states that this version is not offered as an in-place update from 24H2 or 25H2 on existing devices. When Microsoft introduced the Beta (26H1) channel in June, it described 26H1 as a targeted release of Windows supporting specific silicon launching this year, including Qualcomm Snapdragon X2 Series devices.

Recent builds in this channel:

NTCompatible reported that the Nov. 6 Insider wave put Beta 26H1 at 28020.3445. Microsoft's release-health page lists the 26H1 production build as 2026-11 B | 2026-11-10 | 28000.3501 | KB5132059. In practice, the 28020 Beta builds are an enablement-package layer on top of the 28000 base. The Beta number moves a few days ahead of the shipping 26H1 servicing line.

Section summary: Build 28020.3532 is a one-week follow-up to 28020.3445 in a channel aimed at specific new hardware. It is not a sign of a broad Windows 11 upgrade.

BitLocker: standard users can now add their own preboot PIN​

What changed​

BitLocker with only a TPM protects a device without any user involvement. Microsoft's BitLocker overview says the TPM works with BitLocker to make sure a device hasn't been tampered with while it was offline. BitLocker can also hold startup until the user enters a PIN, which adds a second factor before Windows loads.

That second factor has always been awkward to deploy. Policy could require TPM+PIN, but a user without admin rights couldn't create the PIN. Admins had to grant elevation, set the PIN themselves, or give up and use TPM-only.

Build 28020.3532 adds a user-facing flow. When the required policies apply to a device that has no PIN yet, the user gets a notification asking them to add one. Selecting it opens a window where they set the preboot PIN.

The policy combination Microsoft specifies​

Microsoft says to configure these existing BitLocker policies in Intune or another device management tool to require TPM+PIN for non-administrators:

None of these policies are new; what's new is how the OS behaves when they're combined. Microsoft's general BitLocker configuration documentation explains the first two:

• Allow standard user encryption lets admins enforce the Require device encryption policy even when the signed-in user has no administrative rights.
• Allow warning for other disk encryption must be disabled for standard-user encryption to work. With the warning prompt disabled, the OS drive's recovery key is backed up to the user's Microsoft Entra ID account. Check that your recovery-key escrow is set up the way you expect.

Important: target a test group only​

Microsoft gives a clear warning. Apply the startup-authentication and device-encryption policies only to a standard-user test group whose devices have this feature enabled through the Windows Insider Program.

If you apply them more widely:

1. Encryption fails on standard-user devices without the feature, because those users can't add the required TPM+PIN protector.
2. Devices already encrypted with TPM-only show as non-compliant if their standard users don't have the feature.

Because the rollout is gradual, two machines on the same build may behave differently. The second point also affects Conditional Access. Microsoft's BitLocker documentation notes that Intune can use BitLocker status in compliance policies combined with Conditional Access. If one of these policies reaches the wrong users, they could be blocked from Exchange Online or SharePoint Online because of compliance status, even though nothing is actually wrong with their devices.

A sensible pilot sequence​

Based on Microsoft's instructions and its BitLocker documentation, a cautious rollout looks like this:

1. Build the group. Create a device or user group that includes only standard-user test accounts on Beta (26H1) devices running 28020.3532.
2. Scope the policies. Assign the four settings above to that group only, and exclude everyone else.
3. Watch for the notification. On a test device without a PIN, the user should get a prompt to add one. Selecting it should open the PIN-setup window.
4. Test a real reboot. The pilot only counts as successful when the device asks for the PIN before Windows starts and accepts it.
5. Check compliance reporting. Confirm the device reports as compliant in Intune afterward. Also confirm that non-pilot devices haven't been pulled into the policy scope.

Things to check before setting PIN rules​

• PIN strength. Microsoft's configuration guide explains that TPM 2.0 dictionary-attack protection limits guesses. In its example, a TPM allows 32 immediate attempts and then one every two hours, about 4,415 guesses a year. At that rate, every four-digit PIN could be tried in a little over two years. Longer PINs make attacks much harder.
• Tablets and touch-only devices. The Windows touch keyboard isn't available before boot. On slates, a PIN requirement needs another input method, such as an attached USB keyboard, and a related policy to allow it. This is a general BitLocker limitation and is especially relevant to the thin Arm devices 26H1 targets.
• PIN changes. BitLocker also has a separate policy, Disallow standard users from changing the PIN or password. Microsoft's notes don't say how that policy interacts with the new setup flow, so check your existing setting during the pilot instead of assuming.

Section summary: The new BitLocker flow makes TPM+PIN practical for standard users who can't elevate. For now, though, it's an Insider feature limited to test groups. A policy aimed at the wrong group can cause failed encryption and compliance problems.

Remote Desktop: certificate mismatch fix​

The second change is a fix for Remote Desktop Protocol connections that could fail on the client because of a certificate mismatch after recent Insider flights.

Microsoft doesn't say which earlier builds were affected, which certificate types or configurations caused it, or whether there was a workaround. All we can confirm is that 28020.3532 fixes this specific client-side failure.

If you've had RDP connections from a Beta (26H1) machine fail with certificate errors in the last few flights:

• Install 28020.3532 and try the connection again before changing certificates on the server.
• If it still fails, file a Feedback Hub report with the error and the target host. Since Microsoft hasn't said what caused the problem, careful bug reports are the best way to show whether the fix covers your case.

The usual Insider caveats​

Microsoft's standard reminders for the Beta (26H1) channel apply:

• The watermark in the lower-right corner of the desktop is normal on pre-release builds.
• Features in these builds can change, be removed or replaced, or never ship beyond Insiders. That includes the BitLocker flow above.
• Some features in development may not be fully translated yet, and Microsoft asks Insiders to report localization problems through Feedback Hub.
• Flight Hub lists which build is in each Insider channel.

Analysis: small update, real change for admins​

This is a short changelog, but the BitLocker item matters more than its length suggests. Many organizations settle for TPM-only BitLocker. They don't necessarily think it's enough. TPM+PIN has just been hard to deploy at scale without giving users admin rights, which security teams are rightly reluctant to do. A notification-based PIN setup for standard users addresses that problem directly.

There are reasons for caution. The feature is behind a gradual rollout on a branch that serves only certain new hardware, and Microsoft's own instructions focus on what breaks when the policies hit the wrong users. Also, preboot PINs bring their own costs: forgotten PINs mean helpdesk calls, and touch-only devices have no on-screen keyboard before boot. Making the PIN easier to set up doesn't remove either problem.

For now, the practical advice is to pilot it in a small, carefully scoped group and test it thoroughly. If you run Snapdragon X2-class hardware on the 26H1 track, this is a good chance to see whether TPM+PIN could work in your environment before it reaches a release you rely on in production.