Microsoft reboot note hits BitLocker workflows

Windows Update is doing something unusual on some Windows 11 machines — and for once the “extra reboot” is not a bug. Microsoft has tied recent April 2026 updates to its Secure Boot certificate rollover, which means some devices restart one more time than admins expect. That sounds minor, but it lands right in the part of the stack BitLocker watches most closely. If your deployment flow, maintenance window, or help desk script assumes one reboot, this is the kind of detail that turns into recovery-key prompts and confused users. (support.microsoft.com) ### What is actually being updated? This is about Secure Boot certificates stored in firmware. Windows devices have long relied on Microsoft-issued 2011 certificates in the UEFI trust chain — the KEK and DB entries that tell firmware which boot components are allowed to run. Those certificates start expiring in Jun(support.microsoft.com)out. (support.microsoft.com) ### Why does that need another reboot? Because this is not a normal app or driver patch. Secure Boot servicing has to update trust anchors and, in some cases, the boot manager in a controlled sequence that spans Windows and the device’s UEFI firmware. Microsoft’s troubleshooting guide spells out(support.microsoft.com)o finish the firmware-side trust update safely. (support.microsoft.com) ### Why does BitLocker care so much? BitLocker measures the pre-boot environment through the TPM. By default, Secure Boot state feeds into PCR 7, which BitLocker uses to decide whether the machine still looks trustworthy. Change the boot chain, firmware state, or critical startup files, and BitLocker can decide something important moved und(support.microsoft.com)e rollout terms, it is also a support event. (learn.microsoft.com) ### Didn’t Microsoft already see that problem? Yes — and that is part of why this note matters. In the April 14, 2026 KB5083769 release notes, Microsoft explicitly said the update expands eligibility for automatic Secure Boot certificate delivery and also “addresses an issue” where devices might enter BitLocker Recovery after the Secure(learn.microsoft.com)he boot-trust change can surface as a BitLocker problem. (support.microsoft.com) ### Where do IT workflows get hit? Imaging, autopilot-style provisioning, remote patching, and any maintenance plan with tight reboot assumptions. If a task sequence suspends BitLocker for one restart but the device needs two, the second restart is the risky one. If recovery keys are not escrowed cleanly, or if use(support.microsoft.com) doing exactly what it is supposed to do. (support.microsoft.com) ### Does every PC get this immediately? No. Microsoft says certificate delivery is phased and gated by device eligibility and successful update signals. Some machines will receive the new certificates automatically, some may need OEM firmware support, and commercial devices may not even surface the Windows Security(support.microsoft.com). (support.microsoft.com) ### Why does this matter beyond one patch cycle? Because devices that miss the new certificates still boot and still get ordinary Windows updates, but they stop being able to take future boot-level protections. That includes new Boot Manager protections, Secure Boot database updates, revocation lists, and mitigatio(support.microsoft.com). (support.microsoft.com) ### Bottom line? The news is not “Windows rebooted twice.” The news is that Microsoft’s deadline-driven Secure Boot certificate rollover has reached the point where update mechanics now affect BitLocker operations in the real world. For IT teams, that means planning for one more restart, validating firmware readiness, and making sure recovery-key handling is boringly solid before June 2026 turns this from a note in release docs into a fleet-wide headache. (support.microsoft.com)