Windows 10/11 Freezes After Boot: Secure-Boot-Update Task, Firmware Failures and Safe Checks

What affected users are reporting​

The pattern is consistent across reports. The freeze usually comes three to five minutes after startup. Some users found it didn't happen if they stayed offline at first.

One detailed Microsoft Q&A thread from March 2026 shows it clearly. The poster's Windows 10 PC froze at about five minutes and ten seconds after every normal boot. Safe Mode worked fine. Staying disconnected for the first six minutes and then turning Wi‑Fi on avoided the freeze. The poster later said that disabling the Secure-Boot-Update task stopped the freezes completely. A Microsoft support responder answered that this Reddit-sourced fix was third-party community advice, not official guidance.

Similar reports keep coming in:

• Ten Forums: A long Windows 10 thread titled after the January 2026 ESU update, KB5073724, describes freezes after four or five minutes. In it, some people have said BIOS updates have helped.
• Dell Community: An owner of a Dell XPS 8910 running Windows 10 on extended support wrote that the problem started around 9 June 2026, the day of the June 2026 Windows update. The system, which had worked perfectly fine for about a decade, would completely freeze fairly shortly after booting. That user said disabling the task in Task Scheduler seemed to fix it.
• Firmware support ending: On the Q&A thread, an Alienware 15 R2 owner said disabling the task fixed the freezes, and that Dell/Alienware won't release a BIOS update to support the new certificates.
• Windows 11 as well: Another Q&A thread, filed under Windows 11, involved a Dell XPS 8700 on Windows 10 Home ESU. A response there said the freeze occurs when the \Microsoft\Windows\PI\Secure-Boot-Update scheduled task runs. That's a community Q&A answer, not a Microsoft known-issue entry.

Not every freeze is this bug. In a separate Q&A thread, one user disabled Secure-Boot-Update and freeze was still occurring. The responder there noted that if a clean boot stops the freezing, this strongly indicates the issue is caused by a third‑party service or startup program, not the Windows scheduled task itself. Another commenter on the original thread blamed Microsoft PC Manager instead. A five-minute freeze is a symptom, and more than one thing can cause it.

Section summary: The reports are real, repeated, and common on older Dell desktops and laptops running Windows 10. But they're anecdotes, and Microsoft hasn't acknowledged the freezes.

What the Secure-Boot-Update task actually does​

This task has a real job. Microsoft is moving Windows PCs from the Secure Boot certificates issued in 2011 to replacements issued in 2023. The certificates don't all expire on the same day. Microsoft's certificate expiration page (KB5062710) lists these dates:

So the idea that "the old certs have expired" is only partly true as of late September. The Windows boot loader signing certificate is still valid for a few more weeks.

Microsoft also says devices without the 2023 certificates will keep booting and installing normal Windows updates. What they lose is new protection for the early boot process, such as Boot Manager updates, revocation list updates and fixes for new bootkit-level vulnerabilities.

Microsoft's Secure Boot troubleshooting guide explains how the task works:

• The task runs as Local System. By default, it runs at system startup and every 12 hours thereafter. Each time it runs, it checks whether Secure Boot update actions are pending and attempts to apply them in sequence.
• Secure Boot certificate updates require coordination between Windows and UEFI firmware, including writing UEFI variables that store Secure Boot keys and certificates. A scheduled task allows Windows to attempt these updates when the system is in a state where firmware variables can be modified.
• A 32-bit bitmask called AvailableUpdates tracks the work. It lives at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot. Each bit stands for one action, and the steps run in a fixed order:
  1. Add Windows UEFI CA 2023 to the DB (0x0040)
  2. Add the Option ROM CA (0x0800) and the UEFI CA 2023 (0x1000) where applicable
  3. Apply the OEM-signed KEK (0x0004)
  4. Install the new boot manager (0x0100)
• When a step succeeds, its bit is cleared. When a step fails, Windows logs an event, leaves the bit set and tries again on the next run.

About the internet clue: Neowin wrote that the task runs "whenever you are online." Microsoft's documentation doesn't say that. It says the task runs at startup and every 12 hours. Users did report that staying offline avoided the freeze, but nothing in Microsoft's guide describes a network trigger. Treat the internet link as something users observed, not a confirmed mechanism.

Section summary: The task writes to firmware Secure Boot variables, and it retries failed steps on a schedule. On a device with firmware problems, you could see the same failing step attempted again and again. Whether that's what freezes these PCs is still unconfirmed.

Where firmware gets in the way​

Microsoft's guide is candid about firmware limits. If UEFI firmware doesn't fully support the required behavior, the updates can "stall, retry indefinitely, or result in boot failures." The KEK step is the main weak point:

• Updating the KEK requires authorization from the device's Platform Key, which the OEM owns.
• If the OEM never gave Microsoft a PK-signed KEK for that model, the 0x0004 bit stays set and Event ID 1803 keeps appearing in the System log.
• Microsoft says that on older or out-of-support hardware, the device "can remain permanently unable" to finish servicing, and there's no supported manual recovery.

The guide also lists Event ID 1795, which usually means the firmware failed while writing a Secure Boot variable. Events 1032, 1796 and 1802 point to firmware or platform limits.

That fits the pattern of the freeze reports: 10-year-old Dell XPS towers and Alienware laptops that Dell no longer updates. It's a plausible link, and I'm inferring it from the documentation. Microsoft's own write-up covers stalls, BitLocker recovery prompts and boot failures. It doesn't mention hangs a few minutes after sign-in.

How to check your PC, step by step​

If your PC freezes on a regular timer a few minutes after boot, work through these steps before you touch anything:

1. Rule out other causes first. Try a clean boot. If the freezes stop, a third-party startup app or service is more likely than the Secure Boot task.
2. Check the task. Open PowerShell as administrator and run:
   schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
   Look at the Status field:
   • Ready means the task exists and is enabled. It doesn't mean servicing finished.
   • Disabled means someone switched it off.
   • Error or Not Found means the task is broken or missing.
3. Read the registry. Go to HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot.
   • Check AvailableUpdates. Microsoft says a final value of 0x4000 means every applicable step completed.
   • If the value stays at something like 0x4004 across several runs, the KEK step is stuck.
   • Also look at UEFICA2023Status, UEFICA2023Error and UEFICA2023ErrorEvent.
4. Check Event Viewer. In the System log, look for Secure Boot events. Microsoft lists 1043, 1044, 1045, 1799 and 1801 as progress events, and 1795, 1796, 1802 and 1803 as failure indicators.
5. Check with your PC maker. If the evidence points to firmware, look for a BIOS/UEFI update on the manufacturer's support page. Microsoft recommends this route, and some Ten Forums users say it fixed their freezes.

If the task has been disabled or deleted, Microsoft offers a sample script to re-enable it (Enable-SecureBootUpdateTask.ps1). Microsoft says the script isn't officially supported and admins should review it first.

The workaround and what it costs​

Disabling the task in Task Scheduler is the fix users keep passing around, and many say it works. The trade-off is simple. If this task is disabled or missing, Secure Boot certificate updates cannot be applied. The Secure‑Boot‑Update task must remain enabled for Secure Boot servicing to function.

Some forum posters went further and turned Secure Boot off entirely in the BIOS. That removes the bootkit protection Secure Boot provides, which makes it a worse option than disabling one task.

One Dell owner summed up how many people feel: "At this point I care more about the computer working than secure boot being up to date." For a family PC that's frozen every morning, that's a fair call. If you make it:

• Record the task's state before you change anything.
• Check whether some certificates already installed. Neowin suggests disabling the task only after confirming you have the updated certificates.
• Check back regularly for a firmware update or a Microsoft fix.
• Remember that Windows Production PCA 2011 expires on October 19, 2026.

The bigger picture​

This is the awkward part of rotating a security certificate across hundreds of millions of devices built over 15 years. Windows handles the process, but it depends on firmware written long ago and on OEM keys that some manufacturers never delivered. Microsoft's documentation explains how the process should work and how it fails at the firmware level. It doesn't explain why an unsupported Dell tower might lock up minutes after boot.

Users on the Q&A thread asked Microsoft directly for an explanation and a fix. In late March, the support responder said Microsoft hadn't published detailed documentation on the task's internal behavior or scheduling. The responder suggested sending logs through Feedback Hub. The troubleshooting guide has filled in much of that detail since, but there's still no known-issue entry for these freezes.

If your PC froze on a timer and the task was the cause, please report it in the forums with your PC model, BIOS version, Windows build and the AvailableUpdates value. That kind of detail is what helps turn a pile of anecdotes into a confirmed bug.