Microsoft’s May 2026 cumulative update for Windows 11, KB5089549, introduced more than the usual monthly security fixes. Buried inside the release was something many IT professionals immediately noticed after patching their systems: a brand-new C:\Windows\SecureBoot folder containing several PowerShell scripts focused on Secure Boot certificate management.
For enterprise admins, endpoint engineers, and security teams, this update signals an important shift in how Microsoft is preparing organizations for the upcoming Secure Boot certificate expiration events beginning in June 2026.
This is not just another Patch Tuesday update. It is part of a much larger security initiative around UEFI trust, Secure Boot resiliency, and future-proofing Windows devices against boot-level security issues.
In this post, I’ll break down:
- What KB5089549 introduced
- Why Microsoft added the new SecureBoot folder
- Where the PowerShell scripts are located
- What each script does
- How organizations can use them safely
- Why this matters for modern endpoint management
What is KB5089549?
KB5089549 is the May 2026 cumulative security update for:
- Windows 11 version 24H2
- Windows 11 version 25H2
The update advances systems to:
- Build 26100.8457
- Build 26200.8457
Alongside normal Patch Tuesday security fixes, Microsoft also added infrastructure changes related to Secure Boot certificate deployment and validation.
One of the most important additions was this statement from Microsoft:
“This update adds a new SecureBoot folder under C:on eligible devices.”
Why Microsoft Added The Secure Boot Folder
The short answer is this:
Secure Boot certificates are expiring.
Many Windows devices currently rely on Secure Boot certificates that begin expiring in June 2026. If organizations fail to update these certificates correctly, some devices could eventually encounter secure boot validation problems or boot trust issues.
Microsoft is trying to avoid a repeat of past firmware and boot chain complications by introducing a controlled rollout process.
Instead of blindly deploying certificate updates to every device immediately, Microsoft is:
- Gathering device readiness telemetry
- Validating update success signals
- Providing staged rollout guidance
- Giving enterprises automation tools to manage deployments safely
That is where the PowerShell scripts come into play.
Where The Secure Boot Scripts Are Located
After installing KB5089549 on supported systems, you may notice a new directory:
C:\Windows\SecureBoot
Inside the folder are several PowerShell scripts and supporting files intended for IT administrators and enterprise deployment teams.
The folder is not malware, ransomware, or a hidden attack mechanism. It is a Microsoft-provided toolkit for Secure Boot certificate lifecycle management.
What Are These Scripts Designed To Do?
The scripts are primarily intended to help organizations:
- Detect Secure Boot update readiness
- Verify certificate deployment status
- Validate EFI and boot environment conditions
- Assist with staged deployment workflows
- Automate rollout procedures in managed environments
- Reduce risk during Secure Boot servicing
Microsoft specifically noted that the scripts are meant for:
“Organizations with IT professionals who actively manage updates across their device fleet.”
This is important.
These are not consumer-focused scripts. They are enterprise operational tools.
Understanding The Bigger Secure Boot Picture
To understand why this matters, you need to understand how Secure Boot works.
Secure Boot is part of the UEFI firmware security chain. Its purpose is to ensure only trusted bootloaders and signed operating system components are allowed to start during the boot process.
If malicious code modifies the boot sequence, Secure Boot helps block it before Windows even loads.
This is especially important because boot-level malware and UEFI attacks continue to evolve. Researchers have repeatedly demonstrated how firmware-level compromises can bypass traditional operating system protections.
The challenge is that Secure Boot itself relies on trusted certificates and signing infrastructure.
When certificates expire, systems must be updated carefully without breaking trust relationships between firmware, bootloaders, and operating system components.
That is exactly what Microsoft is preparing for here.
Common Scripts You Will Find
The exact contents may evolve over time, but administrators have reported scripts focused on areas such as:
- Certificate status validation
- Secure Boot eligibility checks
- Rollout orchestration
- Logging and compliance verification
- Detection reporting
Some scripts are designed to run locally, while others are intended to integrate into enterprise deployment workflows through:
- Microsoft Intune
- Configuration Manager
- Group Policy
- PowerShell remoting
- Deployment orchestration platforms
Example: Checking Secure Boot Status
One of the most common tasks is verifying whether Secure Boot is enabled on a device.
A simple PowerShell example:
Confirm-SecureBootUEFI
If Secure Boot is enabled, the result returns:
True
If the system does not support Secure Boot or it is disabled, you may receive errors or a False result.
Why Is Microsoft Taking A “Safe Rollout” Approach?
Microsoft specifically mentioned a “controlled and phased rollout” for these certificate updates.
That wording matters.
Secure Boot changes can potentially affect:
- Device bootability
- Firmware trust chains
- Third-party bootloaders
- Recovery environments
- Legacy hardware
- Custom imaging workflows
A failed Secure Boot deployment at scale could become a major operational incident for enterprises.
That is why Microsoft appears to be emphasizing:
- Telemetry validation
- Gradual deployment
- Readiness assessment
- High confidence targeting
The included scripts help administrators verify conditions before broad rollout.
How Enterprises Should Approach These Scripts
Do not immediately deploy these scripts blindly across production environments.
Instead:
1. Test In A Lab Environment
Start with:
- Test devices
- Pilot rings
- Non-production systems
Validate:
- Firmware compatibility
- BIOS versions
- BitLocker interactions
- Secure Boot state
- Recovery workflows
2. Inventory Your Environment
Understand:
- Which systems support Secure Boot
- Which devices have outdated firmware
- Which systems have custom boot configurations
This becomes especially important for older hardware and long-lived enterprise images.
3. Review The Scripts Before Deployment
Even though these are Microsoft-provided scripts, always review:
- Variables
- Registry changes
- EFI modifications
- Logging behavior
- Exit codes
- Rollback handling
Security and endpoint teams should understand exactly what automation is being introduced into the environment.
4. Integrate Into Active Deployment Rings
Organizations already using phased deployment models should integrate Secure Boot servicing into:
- Test rings
- Early adopters
- IT pilot groups
- Production waves
This aligns well with Microsoft’s own servicing philosophy.
Known Issues With KB5089549
Like many cumulative updates, KB5089549 has not been entirely problem-free.
Microsoft acknowledged installation failures associated with error:
0x800f0922
In many cases, the issue appears tied to insufficient EFI System Partition (ESP) free space.
Some admins also reported:
- Rollbacks during reboot
- Driver compatibility issues
- EFI partition servicing failures
- Container servicing errors
- Boot-related deployment complications
This further reinforces why Secure Boot servicing requires careful rollout planning.
Why This Matters For Modern Endpoint Management
This update highlights a larger trend in Windows management.
Endpoint security is increasingly moving deeper into the platform stack:
- TPM
- Secure Boot
- UEFI
- Virtualization-based security
- Hardware-backed identity
- Firmware trust
Modern Windows security is no longer just about antivirus or operating system patching.
Organizations now need operational visibility into firmware trust and platform integrity.
That is why Microsoft is investing more heavily in automation, telemetry, and managed rollout mechanisms around Secure Boot infrastructure.
Final Thoughts
KB5089549 may initially look like a normal cumulative update, but the addition of the SecureBoot folder and PowerShell tooling makes it one of the more interesting Windows 11 servicing updates in recent memory.
Microsoft is clearly preparing organizations for the next phase of Secure Boot certificate management, and these scripts are part of that preparation.
For IT professionals, this is a reminder that modern Windows servicing increasingly extends beyond the operating system itself and into firmware trust, boot security, and hardware-backed protection models.
If you manage Windows devices at scale, now is the time to:
- Review your Secure Boot posture
- Validate firmware readiness
- Test certificate deployment workflows
- Understand how these new scripts operate
The organizations that prepare early will likely avoid a lot of future troubleshooting pain later.
Sources
Microsoft KB5089549 Update Information
https://support.microsoft.com/en-us/topic/may-12-2026-kb5089549-os-builds-26200-8457-and-26100-8457-28ec2a99-4bbe-481d-a340-5c6cf18d9acb
Updated Boot Status Report With Windows Autopatch
https://techcommunity.microsoft.com/blog/windows-itpro-blog/updated-secure-boot-status-report-in-windows-autopatch/4517920
Deployment Research
https://www.deploymentresearch.com/secure-boot-rollout-scripts-added-in-may-2026-security-update
4sysops
https://4sysops.com/archives/windows-11-secureboot-folder-powershell-scripts-explained/
Research on UEFI and Boot Security
https://arxiv.org/abs/2601.07402
Reddit Community Discussion
https://www.reddit.com/r/WindowsUpdate/comments/1tbsm0v/202605_security_update_kb5089549_262008457/