Microsoft Secure Boot Certificate Warning: What To Do Before June 2026

If Windows Security is suddenly complaining about a Secure Boot certificate update, do not treat it like a random nuisance warning. Microsoft is moving Windows devices from older Secure Boot certificate authorities to newer 2023 authorities before older trust anchors begin expiring in June 2026. Some machines need more than one reboot before Windows reports the update as complete.

This is a Microsoft and Windows maintenance issue. It is separate from Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway tutorial work. The overlap is only operational: if you run Windows servers, admin workstations, or Windows-based hosting roles, plan the reboot and verification work instead of dismissing the warning.

What changed

Secure Boot relies on trusted certificates in the device firmware trust store. Microsoft has published guidance for updating Windows systems from older 2011 Secure Boot certificates to the newer 2023 certificate chain. The user-facing symptom is usually a Windows Security notice under Device security, or a machine that looks patched but still needs another restart before the Secure Boot certificate status turns healthy.

The important part for admins is timing. This should be handled before the June 2026 certificate expiration window becomes an emergency maintenance event. On normal endpoints it may be a straightforward Windows Update and reboot cycle. On servers, BitLocker-protected machines, Hyper-V hosts, domain controllers, RDS servers, and exposed management workstations, it deserves a staged rollout.

Who should check this now

• Windows 11 and supported Windows 10 machines that use Secure Boot.
• Windows Server 2019, Windows Server 2022, and Windows Server 2025 machines where Secure Boot is enabled.
• Admin and support workstations used to access customer files, hosting dashboards, RMM tools, VPNs, or password vaults.
• IIS hosting servers, RDS and terminal servers, Hyper-V hosts, domain controllers, DNS and file servers, and backup servers.
• Azure Trusted Launch VMs and Confidential VMs, which have their own Microsoft guidance.
• OEM devices that may require firmware updates before the Secure Boot certificate status clears.

If Secure Boot is intentionally disabled on a specific machine, this exact status warning may not apply. Still document that exception, because disabling Secure Boot just to silence a warning is usually the wrong fix.

Safe patch plan for normal machines

1. Install current Windows updates from Windows Update or your normal RMM tool.
2. Install available OEM firmware and UEFI updates from the device vendor when they are offered through trusted vendor channels.
3. Restart the machine, then sign back in and check Windows Security again.
4. If Windows Security still says a Secure Boot certificate update is needed, restart again. Microsoft notes that some devices need multiple restarts before the status is up to date.
5. Confirm Secure Boot state with Windows Security, System Information, or the PowerShell Confirm-SecureBootUEFI check on systems where that command is supported.

Enterprise rollout guidance

For managed fleets, use a pilot ring first. Push current cumulative updates through WSUS, Intune, RMM, or your normal patch tooling, then watch for machines that still show the certificate warning after reboot. Do not push this across every critical server at once until you know how your hardware and firmware behave.

• WSUS: approve the current monthly updates for a small test group, then expand after reboot verification.
• Intune: use update rings or phased deployment so laptops, desktops, and admin workstations do not all reboot at the same time.
• RMM: track machines that need a second reboot and create a follow-up job for failed or pending-restart systems.
• Offline machines: use Microsoft Update Catalog packages only from Microsoft, and pair them with approved OEM firmware where needed.
• BitLocker: make sure recovery keys are escrowed before firmware or Secure Boot changes. Do not discover missing recovery keys during the reboot.

Windows Server role notes

The certificate update itself is not a reason to rush a production server reboot without planning. Treat it like any other boot-path maintenance window.

• IIS hosting servers: schedule outside peak traffic, verify sites after reboot, and confirm TLS bindings and application pools came back normally.
• RDS and terminal servers: drain user sessions before reboot and warn customers that the machine may require more than one restart.
• Hyper-V hosts: checkpoint or back up critical guests, live migrate where possible, and verify guest startup order after the host returns.
• Domain controllers: update one DC at a time, confirm replication health before moving to the next server, and keep DNS available.
• File and backup servers: pause backup windows if needed, complete the reboot cycle, then verify shares, backup jobs, and restore points.
• Exposed management machines: prioritize admin jump boxes, VPN-connected support machines, and workstations that handle customer data.

How to verify it worked

• Open Windows Security, go to Device security, and review the Secure Boot certificate update status.
• Open System Information and confirm Secure Boot is enabled where your policy requires it.
• Check Windows Update history and your RMM or Intune reporting for pending restarts.
• Review Event Viewer for Windows Update and Secure Boot related warnings if the status does not clear.
• On managed fleets, track systems that still report the older certificate state and schedule another maintenance reboot or firmware review.

What not to do

• Do not disable Secure Boot just to remove the warning.
• Do not manually edit UEFI Secure Boot keys unless you are following Microsoft or OEM guidance for that exact system class.
• Do not assume one reboot is enough on every model.
• Do not roll this straight to all production servers without a pilot group.
• Do not ignore laptops or admin workstations just because servers are louder.

Customer communication note

For managed customers, the plain-English message is simple: Microsoft is updating the Secure Boot trust chain before older certificates expire, and some Windows devices need extra reboots to complete the change. Let customers know that a short maintenance window now is better than a rushed firmware or boot security issue later.

Official references

• Microsoft Learn: Update Secure Boot certificates
• Microsoft Support: Secure Boot certificate update status in Windows Security
• Microsoft Support: Secure Boot certificate updates for IT professionals
• Microsoft Windows Server Blog: Prepare your servers for Secure Boot certificate updates
• Microsoft Support: Azure Trusted Launch and Confidential VM Secure Boot certificate update