Microsoft has confirmed that Windows 11 updates KB5083631 and KB5083769 may trigger an additional system restart during installation. The culprit isn’t a bug—it’s a behind-the-scenes Secure Boot certificate update that Windows Update is rolling out in phases to maintain long-term platform security.

IT administrators and power users noticed the unexpected extra reboot after deploying the February 2025 cumulative updates. Some machines restarted once to apply the operating system changes, then again moments later with minimal explanation. The behavior sparked confusion in enterprise environments where reboots are tightly controlled, but Microsoft’s documentation now clarifies the root cause.

What Are KB5083631 and KB5083769?

These updates are cumulative security patches for Windows 11 versions 23H2 and 22H2. KB5083631 addresses the Enterprise and Education editions, while KB5083769 targets Home and Pro. Both carry the same underlying OS fixes—including the Secure Boot certificate maintenance—but differ in edition-specific components. The updates arrived via Windows Update on February 11, 2025, as part of Microsoft’s monthly “Patch Tuesday” cycle.

Crucially, the extra restart is not a flaw. Microsoft engineered this behavior intentionally. During installation, Windows Update detects that the machine’s Secure Boot certificate store is outdated and applies new certificates to keep the boot chain trustworthy. Because the update touches a component loaded before the OS kernel, a separate reboot cycle is necessary to complete the process.

Why Secure Boot Certificates Need Rotation

Secure Boot relies on digital certificates to verify every piece of code that runs during startup—firmware drivers, boot loaders, and the OS itself. These certificates carry cryptographic signatures from the platform key (PK), key exchange key (KEK), and authorized database (db). When a certificate expires or is compromised, the entire trust chain becomes vulnerable. Attackers could sign malicious bootloaders that bypass integrity checks.

Microsoft performs periodic certificate rotations to phase out old keys and introduce fresh ones. The transition isn’t instantaneous: certificates have overlapping validity windows so that devices with stale firmware can still boot. Once the new certificates are widely distributed, the old ones are revoked via the Secure Boot forbidden signature database (dbx). The extra restart seen in KB5083631/KB5083769 corresponds exactly to the moment when the updated signature databases are committed to firmware.

This isn’t the first time a Windows update has touched Secure Boot certificates. In 2022, KB5012170 delivered an updated dbx to block vulnerable boot managers. That patch also required multiple reboots and triggered BitLocker recovery prompts on some systems. Microsoft learned from that experience and now takes a more gradual rollout approach for KB5083631/KB5083769.

Phased Rollout: Why Some PCs See the Extra Reboot Now

Microsoft is deploying the new Secure Boot certificates in waves. The first wave, starting with the February updates, only activates the extra reboot on a subset of devices. Additional waves will expand the pool until all eligible PCs receive the new certificates. Microsoft hasn’t published a precise schedule, but this strategy allows them to detect and mitigate unforeseen issues before a global rollout.

If your PC restarted an extra time after installing the February update, you’re in the active pilot group. If it rebooted only once, the certificate rotation hasn’t touched your device yet—but it likely will in a future monthly update. Administrators managing fleets should prepare for a gradual increase in the number of machines exhibiting this behavior over the next few months.

The BitLocker Recovery Angle

One of the tags associated with these updates—BitLocker recovery—deserves attention. Changes to the Secure Boot configuration can alter the boot measurements that BitLocker uses to validate the platform’s integrity. When BitLocker detects a mismatch, it enters recovery mode and demands a 48-digit recovery key. This exact scenario occurred during the KB5012170 rollout, catching many users off guard.

Microsoft has not publicly linked KB5083631/KB5083769 to widespread BitLocker recovery prompts, but the technical overlap is undeniable. Enterprise admins should verify that BitLocker recovery keys are backed up in Active Directory or Azure AD before deploying the update broadly. Even if the current certificate rotation doesn’t trigger recovery, any future Secure Boot change could. A proactive approach saves hours of helpdesk calls.

For individual users, the risk is lower because Home and Pro editions (KB5083769) rarely enforce BitLocker with pre-boot authentication. However, if you’ve enabled Device Encryption or manually activated BitLocker, make sure you have your recovery key stored safely—either in your Microsoft account or printed out.

What to Expect During Installation

When a device is selected for the certificate rotation, the Windows Update process proceeds normally until the final restart. After the system comes back up, Windows Update briefly shows a second installation phase, often with a message like “Working on updates, please keep your computer on.” Then another reboot occurs. The entire sequence typically adds 2–5 minutes to the update process.

No data loss, rollback, or feature disruption has been reported. The additional restart is cosmetic in nature—it simply reflects the deep-level firmware update that needs its own reboot boundary. Microsoft’s update history page for these KBs now includes a note: “After you install this update, your PC might restart one extra time. This is expected behavior when Windows Update applies maintenance to Secure Boot certificates.”

How to Identify if Your Organization Is Affected

In managed environments, system administrators can query update history for KB5083631 or KB5083769 and correlate with machines that experienced more than one restart in a short window. The extra reboot typically appears in event logs as Event ID 41 (Kernel-Power) followed closely by a normal boot (Event ID 6008). More telling, the Windows Update log (ETL) will show two distinct update agent sessions within minutes of each other.

For proactive monitoring, run this PowerShell command on a target machine to see if the new certificates are already applied:

Get-WmiObject -Namespace root\cimv2\security\MicrosoftVolumeEncryption -Class Win32_EncryptableVolume | Select-Object DriveLetter, ProtectionStatus, ConversionStatus

If the security database update triggers a BitLocker event, you’ll see a protection status change. But the command itself won’t flag the certificate update; instead, watch for a creation timestamp on the dbx file in the EFI partition.

Comparing KB5083631/KB5083769 to Previous Certificate Updates

The 2022 KB5012170 update was far more disruptive. It pushed an urgent revocation for the “BlackLotus” bootkit and caused BitLocker recovery prompts on devices where Secure Boot measurements had drifted. Microsoft later released tools to help administrators identify at-risk systems.

KB5083631/KB5083769 takes a less aggressive approach. Instead of a global dbx revocation, it first adds new certificates to the db and KEK databases. The old certificates remain valid during a transitional period, so no device is left unbootable. Once the new certs are broadly installed, Microsoft will presumably issue a future update that revokes the old ones—likely accompanied by another reboot cycle.

This phased, multi-step model is exactly what the cybersecurity community has asked for. It reduces the blast radius of any single change and gives hardware vendors time to validate compatibility. For IT shops, the lesson is clear: don’t ignore that extra reboot. It’s a sign that your device’s security posture is being modernized.

Guidance for IT Administrators and End Users

For IT teams:
- Track the rollout using Windows Update for Business deployment rings. Stagger the February updates so that a small pilot group sees the extra reboot first.
- Audit BitLocker recovery key storage. If keys are not in Active Directory, run Manage-bde -protectors -get C: on critical systems and export keys.
- Update firmware and TPM drivers before applying KB5083631/KB5083769. Outdated firmware can misreport Secure Boot state and cause false recovery prompts.
- Communicate with users about the expected extra restart to avoid confusion and unnecessary support tickets.

For home users:
- Let the update install normally. The extra reboot is harmless.
- Ensure your Microsoft account has a copy of your BitLocker recovery key if you use Device Encryption (common on modern laptops).
- If you experience repeated reboot loops, try temporarily suspending BitLocker (Control Panel > BitLocker Drive Encryption > Suspend protection), install the update, and then resume protection.

Beyond February: Ongoing Certificate Maintenance

Secure Boot certificate rotation is not a one-time event. Microsoft’s Trusted Root Program and the UEFI Forum’s certification process demand regular updates to keep pace with evolving threats. The company has signaled that KB5083631/KB5083769 are just the beginning of a series of maintenance events slated for 2025.

Future cumulative updates will continue expanding the certificate rollout. Eventually, the entire Windows 11 installed base should be carrying the new keys. After that, Microsoft will revoke the old certificates, triggering another reboot wave. IT admins should plan for these events as part of their patch management routine—not as anomalies.

The Bottom Line

An extra reboot during a Windows update usually spells trouble. This time, it’s the opposite: an intentional, security-driven process that keeps your device resistant to boot-level attacks. The confusion around KB5083631 and KB5083769 is understandable given Microsoft’s historically sparse communication, but the behavior is both documented and beneficial.

As phased certificate maintenance becomes a standard part of Windows servicing, users will encounter these additional restarts more often. Understanding the rationale—and ensuring BitLocker recovery keys are accessible—minimizes downtime and anxiety. For Windows enthusiasts and IT pros, that extra reboot is actually a quiet badge of a healthier, more resilient system.