Windows 11 Extra Restart in Spring 2026: Secure Boot 2023 Certificate Update

Microsoft has confirmed that some Windows 11 PCs may restart more than once while installing recent and upcoming updates in spring 2026 because Windows is applying Secure Boot 2023 certificate changes before older 2011 certificates begin expiring in June 2026. That is the plain answer to the anxiety many users felt after April’s update cycle turned a routine reboot into a longer, stranger ritual. The more interesting answer is that Microsoft is quietly renovating one of Windows’ deepest trust systems in public, through the same update machinery users already distrust. A second reboot is not a disaster; it is a reminder that modern PC security now depends on firmware, cloud policy, OEM cooperation, and operating-system servicing all arriving in the right order.

Microsoft’s Extra Reboot Is a Security Migration Wearing a Patch Tuesday Mask​

For most Windows users, a monthly cumulative update has a familiar rhythm. Download, install, restart, wait through the percentage counter, and return to the desktop with a faint suspicion that something somewhere is now different. The April 2026 updates broke that rhythm for some systems by adding another restart, and in some cases stretching the process beyond the tidy expectations of a normal Patch Tuesday.
Microsoft says this behavior is expected for a limited set of consumer and business devices as the Secure Boot certificate update process rolls forward. The important phrase is certificate update, because this is not merely another Windows component being swapped out under C:\Windows. Secure Boot’s trust material lives in firmware variables controlled by UEFI, the system layer that runs before Windows itself has even begun.
That makes the update feel more dramatic than a browser patch or a Notepad refresh. Windows can stage the work, but the platform must complete part of the transaction at boot, when the machine is verifying what it should trust. If the PC restarts once to apply the operating-system update and again after Secure Boot trust material is adjusted, that second trip through firmware is not Windows losing the plot. It is Windows crossing a boundary most users never see.
The timing also matters. Microsoft’s older Secure Boot certificates, introduced with the Windows 8 era in 2011, begin expiring in June 2026. The company has spent months warning enterprises and OEMs that the platform needs to move to newer 2023 certificates before that deadline becomes operationally ugly. The April expansion brings that back-room transition into the living room.

The Certificate Clock Finally Reaches Ordinary PCs​

Secure Boot has always been sold as a simple promise: your PC should only load trusted boot software before the operating system starts. Underneath that promise is a chain of certificates, signature databases, revocation lists, and firmware-managed trust anchors. Microsoft’s 2011 certificates helped define that chain for more than a decade of Windows hardware.
That longevity is both a strength and a liability. A certificate infrastructure that survives from Windows 8 through Windows 11 created consistency across OEMs, servers, gaming rigs, tablets, and enterprise fleets. But certificates are not immortal, and long-lived trust anchors eventually become a risk in their own right.
The expiring set includes certificates used for Windows boot components, third-party UEFI software, and updates to Secure Boot databases. Microsoft’s newer 2023 certificates are intended to keep that trust chain viable for the next era of Windows hardware. This is not a feature update in the usual sense; it is preventative maintenance on the plumbing that decides what code is allowed to run before the OS can defend itself.
That is why the rollout is happening before the actual cliff edge. A PC without the refreshed certificates does not necessarily stop booting the moment an old certificate reaches its expiration date. The danger is subtler: future boot-level security updates, revocations, mitigations, and trust changes may become harder or impossible to deliver correctly. In security, deferred maintenance rarely announces itself with fireworks. It usually waits until the next vulnerability turns a neglected corner into the main entrance.

The Weirdest Windows Update Is the One That Touches Firmware Trust​

Users are right to be nervous when an update reboots twice. For years, multiple restarts outside a feature upgrade have been associated with driver bundles, firmware updates, recovery attempts, or something going sideways. Microsoft has trained users to expect one restart for monthly cumulative updates, so breaking that expectation carries a cost even when the reason is legitimate.
The deeper problem is that Secure Boot sits at an awkward intersection of responsibilities. Microsoft can write the guidance, sign the boot components, publish the update logic, and surface the status in Windows Security. But the firmware belongs to the OEM, the UEFI implementation may have quirks, and the machine may have years of accumulated configuration changes from BIOS updates, BitLocker settings, virtualization tools, dual-boot experiments, or enterprise policy.
That is why this transition cannot be reduced to “Microsoft pushes a patch.” Updating Secure Boot certificates means adjusting trusted firmware databases in a way that must not brick systems, break bootloaders, trip BitLocker unexpectedly, or invalidate legitimate hardware paths. Caution is not optional. The extra restart is a visible symptom of that caution.
It also explains why Microsoft is rolling this out gradually and describing the affected population as limited. A staged deployment gives the company and OEMs room to see which combinations of firmware, device age, configuration, and policy behave correctly. It is less satisfying than a universal switch, but universal switches are how platform vendors create global outages.

Windows Security Becomes the Dashboard Microsoft Should Have Built Years Ago​

One of the more useful changes arriving alongside this transition is the appearance of Secure Boot certificate status inside the Windows Security app. Previously, Windows could tell ordinary users whether Secure Boot was enabled, but that was not the same as telling them whether the relevant certificates had been refreshed. For enthusiasts and administrators, PowerShell and Event Viewer could provide clues. For everyone else, Secure Boot was either “on” or an inscrutable firmware setting best left untouched.
That binary presentation no longer fits the problem. A PC can have Secure Boot enabled and still be relying on older trust material. A PC can also be ready for the 2026 transition without the user understanding why. By exposing certificate status through Device Security, Microsoft is acknowledging that on is not a sufficient security posture anymore.
The green, yellow, and red status model is not elegant, but it is practical. A green state should indicate that Secure Boot is enabled and that required certificate updates have been applied. A yellow warning suggests the system is still on older boot trust configuration and may be waiting for Windows Update or firmware support. A red warning means the platform needs attention because Windows cannot complete the certificate update path.
The detail matters: users should not stop at the icon color. The meaningful status is the message that says Secure Boot is on and all required certificate updates have been applied. Anything less deserves patience, investigation, or a firmware check, depending on the machine.

The Real Fragility Is Not Windows 11, but the PC Ecosystem Around It​

The uncomfortable truth is that Microsoft can only automate this transition for hardware that still participates in the modern Windows servicing model. Newer Windows 11 PCs, especially those built in the last couple of years, are far more likely to have firmware and OEM support aligned with the Secure Boot 2023 rollout. Older PCs may technically run Windows 11, but the trust infrastructure underneath them may be less cooperative.
This is where the story stops being a minor reboot annoyance and becomes an ecosystem audit. Secure Boot certificate updates may require firmware that knows how to accept and store the new trust material correctly. If an OEM has abandoned the device, if firmware is outdated, or if the machine sits in an unsupported configuration, Windows Update may not be able to finish the job.
That distinction will irritate users who think of Windows as the thing they update and firmware as the thing they ignore unless a motherboard vendor forces the issue. But the boot chain is shared territory. Microsoft’s trust decisions, OEM firmware behavior, and user configuration all meet before the Windows logo appears.
For enterprise IT, that shared territory becomes a planning problem. Fleets contain generations of hardware, virtual machines, specialized endpoints, lab systems, and devices with custom Secure Boot policy. A certificate transition that is invisible on a brand-new laptop can become a ticket storm on an older fleet with uneven firmware baselines.

BitLocker Turns a Routine Reboot Into a Trust Test​

The Secure Boot transition also arrives in the same neighborhood as another anxiety trigger: BitLocker recovery prompts. When boot measurements change, BitLocker may decide that the system no longer matches the expected trusted state and require the recovery key. That is not BitLocker being broken in the simple sense; it is BitLocker doing exactly what it was designed to do when the pre-boot environment changes in a way that affects measured trust.
The problem is that “working as designed” is cold comfort when a user is staring at a recovery screen without the key. Secure Boot updates, boot manager signing changes, firmware updates, and TPM validation policies all live close enough together that a perfectly rational security transition can feel like a lockout. Microsoft can document the difference, but users experience the whole thing as Windows suddenly distrusting their own PC.
This is one reason enterprises should treat the Secure Boot 2023 rollout as more than a background Windows Update event. Recovery key escrow, firmware baselines, staged rings, and pilot groups matter. A second reboot is harmless; a second reboot followed by a BitLocker prompt on a remote executive laptop is an incident.
Consumers have a simpler but still important lesson. Make sure BitLocker recovery information is saved to the Microsoft account or otherwise stored before assuming any firmware-adjacent update will be uneventful. The era when most home users could ignore boot security details is ending not because Microsoft wants to burden them, but because attackers have spent years proving that the earliest stages of startup are worth targeting.

Microsoft Is Right to Automate This, but Wrong to Assume Trust Comes Free​

There is a temptation to criticize Microsoft whenever Windows changes something below the user’s line of sight. That instinct is understandable, especially after years of forced updates, surprise reboots, confusing telemetry settings, and feature changes presented as inevitabilities. But Secure Boot certificate renewal is exactly the kind of maintenance a platform owner should automate for mainstream users.
The alternative is worse. Asking hundreds of millions of users to manually understand UEFI certificate stores, OEM firmware packages, DB and KEK variables, bootloader signing, and revocation lists would be fantasy. Even many IT departments would struggle if every device model required bespoke handling. Automatic deployment is not just convenient; it is the only plausible way to prevent a security expiration from becoming a global support event.
Still, automation does not erase the need for communication. If a monthly update may restart more than once, Windows should say so plainly before it happens and after it completes. If Secure Boot certificates are being updated, the Windows Security app should explain the status in language users can act on. If firmware support is missing, Microsoft should distinguish between “wait for Windows Update” and “your OEM needs to provide something Windows cannot.”
Trust is not simply a cryptographic concept here. It is also the user’s belief that the machine is behaving intentionally. A second reboot with no explanation looks like failure. A second reboot with clear messaging looks like maintenance.

The 2011-to-2023 Shift Is a Dress Rehearsal for Windows’ Next Hardware Line​

The Secure Boot certificate rollover is not happening in isolation. It sits inside Microsoft’s broader campaign to make Windows a more tightly attested, hardware-rooted platform. TPM 2.0 requirements, virtualization-based security, memory integrity, Pluton-capable hardware, BitLocker defaults, Smart App Control, and more aggressive driver signing expectations all point in the same direction.
Microsoft wants Windows to be less permissive at the bottom of the stack. That is a rational response to modern threats, but it also changes the culture of the PC. The old Windows bargain was messy compatibility: if the hardware could limp along and the driver could load, the platform often made room. The new bargain is conditional trust: if the device can prove enough about itself, Windows will protect it more deeply.
Secure Boot 2023 certificates are part of that shift. They refresh the roots that allow Windows to keep signing and revoking boot-level components safely. They also draw a line between machines that remain inside the supported trust ecosystem and machines that merely still power on.
That line will become more important over time. A device may continue to run, browse, and launch apps without the newest Secure Boot trust material. But if it cannot receive future boot security protections, it becomes a poorer citizen in a world where firmware threats, bootkits, and supply-chain compromises are not theoretical.

Older PCs Are Discovering the Difference Between Compatible and Supported​

Windows enthusiasts have long lived in the gap between what works and what is supported. Windows 11 itself sharpened that divide with its CPU, TPM, and Secure Boot requirements, which many users bypassed on otherwise functional hardware. The Secure Boot certificate transition adds another layer: a machine can run the OS yet struggle to participate fully in the security lifecycle that modern Windows assumes.
That does not mean every older PC is doomed. Many will receive the update normally. Some will need a firmware update from the OEM. Others may sit in a warning state until deployment logic expands or compatibility checks pass. But the direction of travel is clear: unsupported hardware is no longer merely missing performance optimizations or cosmetic features. It may increasingly miss trust updates that define whether the platform can be secured against new boot-level attacks.
This will be frustrating for users who see e-waste pressure in every hardware requirement. They are not wrong to worry. The PC industry has a long history of abandoning firmware support while the hardware remains physically capable. A certificate rollover that depends partly on OEM cooperation exposes that weakness.
But Microsoft also has a defensible position. Security promises made at the boot layer require predictable firmware behavior. If a device’s firmware cannot safely accept new trust anchors, or if no vendor will validate it, pretending that the platform is fully protected would be worse than admitting the limit.

Enterprise IT Should Treat the Extra Restart as an Early Warning, Not a Nuisance​

For managed environments, the immediate issue is not whether one update takes 20 minutes instead of 10. It is whether the organization knows which devices have received the 2023 certificates, which remain pending, and which are blocked by firmware, policy, or virtualization edge cases. That is inventory work, not help-desk improvisation.
The best-run environments will fold Secure Boot certificate status into existing compliance reporting. They will validate pilot groups, check BitLocker recovery readiness, update firmware where necessary, and avoid deploying firmware-adjacent changes blindly to sensitive populations. They will also communicate that an extra reboot during a defined maintenance window may be expected.
The worst-run environments will discover the issue through scattered tickets. One user sees two reboots and panics. Another sees a yellow warning in Windows Security. A third hits BitLocker recovery. Someone in IT then has to reverse-engineer whether these are related, whether the device is healthy, and whether an OEM firmware package is missing.
This is the value of Microsoft surfacing the status in Windows Security, but it is only the beginning. Enterprises need scriptable checks, reliable eventing, clear failure states, and documentation that separates normal rollout delay from genuine remediation. The Secure Boot chain is too fundamental to be managed by icon color alone.

The Gaming PC and Dual-Boot Crowd Should Read the Fine Print​

Secure Boot has always had a more complicated reputation among enthusiasts. Gamers increasingly encounter it because anti-cheat systems use platform trust signals to make cheating harder. Linux dual-boot users encounter it because third-party bootloaders and shim chains depend on how firmware trusts Microsoft’s UEFI CA. Custom PC builders encounter it when motherboard settings, CSM toggles, BIOS updates, and fTPM behavior collide.
The 2023 certificate transition does not automatically mean these scenarios break. In fact, part of the renewal is designed to preserve Secure Boot continuity while creating more granular trust distinctions. But enthusiasts are often the users with the most unusual boot paths, and unusual boot paths are exactly where certificate and firmware transitions deserve caution.
If a machine uses a custom Secure Boot policy, alternative bootloaders, older option ROMs, or firmware settings changed years ago and forgotten, the “it just updates” assumption becomes less safe. The same goes for systems that have Secure Boot technically enabled but have been toggled through compatibility modes, cloned across drives, or modified for unsupported OS installs.
The lesson is not to disable Secure Boot reflexively. That is the wrong instinct. The lesson is to understand whether the machine is using a standard trust path before assuming Microsoft’s automated rollout will treat it like a retail laptop with factory defaults.

A Second Reboot Is Annoying; an Expired Trust Chain Would Be Worse​

The user-facing inconvenience here is real. A PC that restarts twice without warning can interrupt work, trigger fear, and reinforce the old belief that Windows Update is something to survive rather than trust. Microsoft should not wave that away just because the underlying cause is sensible.
But the hierarchy of problems matters. A longer update cycle in April or May 2026 is preferable to a brittle Secure Boot ecosystem after June 2026. Microsoft is trying to replace aging trust anchors before they become a security and compliance liability. That is the kind of maintenance users rarely notice when it goes well and never forgive when it goes badly.
The challenge is that Windows sits on an enormous variety of hardware. Microsoft’s official story can be true — the extra restart is expected for some systems — while individual users still encounter complications caused by firmware age, OEM neglect, BitLocker configuration, or nonstandard boot setups. Platform transitions are cleanest in diagrams and messiest on actual PCs.
That is why the new Windows Security status matters so much. It gives users and administrators a way to distinguish between a completed transition, a pending update, and a system that needs intervention. It turns an invisible firmware trust migration into something at least partly observable.

The Reboot Message Windows Users Should Actually Take Away​

The practical answer is not to panic when a Windows 11 system restarts an extra time during this rollout, but also not to ignore what the extra reboot represents. Microsoft is changing the trust chain that helps protect the machine before Windows starts, and that work deserves a little more attention than a normal cumulative update.

• A Windows 11 PC may restart more than once during recent or upcoming updates because Secure Boot 2023 certificates are being applied.
• The older Microsoft Secure Boot certificates issued in 2011 begin expiring in June 2026, with related expirations continuing later in 2026.
• A green Secure Boot status in Windows Security is most meaningful when it explicitly says Secure Boot is on and all required certificate updates have been applied.
• A yellow or red Secure Boot warning should prompt users to keep Windows updated, check for firmware updates, and avoid making random BIOS changes without understanding the system state.
• BitLocker users should make sure recovery keys are backed up before firmware-adjacent update work, because boot trust changes can expose weak recovery planning.
• Older or unsupported PCs may continue to run but may not be able to receive the same boot-level security protections as fully supported systems.

The most charitable reading of Microsoft’s move is that this is boring infrastructure work arriving just in time; the less charitable reading is that Windows users are once again being asked to trust an opaque update process with too little explanation. Both readings can be true. The Secure Boot 2023 transition is necessary, but necessity does not make surprise reboots feel better. If Microsoft wants Windows to become a more hardware-rooted, security-forward platform, it must treat communication as part of the security boundary too — because the next generation of Windows trust will be measured not only by what the firmware accepts, but by whether users understand why their machines are doing exactly what they were designed to do.

---

Source: Windows Latest Microsoft confirms Windows 11 may restart multiple times after updates and your PC isn't broken, as it's due to Secure Boot 2023