KB5124013 Updates Windows 11 26H1 WinRE to 10.0.28000.3086

KB5124013 moves the Windows 11 26H1 recovery image to 10.0.28000.3086​

Microsoft's support entry is brief. It says the update "makes improvements to the Windows recovery environment (WinRE)" and gives four servicing facts:

• There are no prerequisites.
• No restart is needed after applying it.
• The update cannot be removed once it has been applied to a Windows image.
• It supersedes KB5124011.

The success check is a version number. After installation, WinRE should report 10.0.28000.3086. That revision matches the September 22 preview cumulative update for 26H1, KB5124006, which Microsoft lists as OS build 28000.3086. The two identifiers describe different things, though. KB5124006 is the cumulative update for the running operating system. KB5124013 services the separate recovery image that Windows boots into for repair and reset. Installing one doesn't mean the other is installed.

Microsoft doesn't say what changed in this release. The entry names no recovery scenarios, bug fixes or security vulnerabilities. It points only to a downloadable CSV of included files. That's normal for Safe OS updates, but it means you can't judge urgency from the release notes. The real reason to deploy it is to keep WinRE in line with the current 26H1 servicing baseline.

The support entry also repeats Microsoft's standing Secure Boot warning: certificates used by most Windows devices began expiring in June 2026, which could affect secure boot on devices that aren't updated in time. The warning appears on every recent Safe OS page. It isn't a KB5124013-specific change, but it's a reminder that boot-path components get extra scrutiny this year.

Twice-monthly releases explain why KB5124011 is already retired​

KB5124013 replacing a two-week-old package follows a pattern. Microsoft's support index for 26H1 Safe OS updates shows two releases a month, one on Patch Tuesday and one alongside the late-month preview update:

Microsoft's support index lists the May, June, August and September packages. The last two rows show the chain clearly. Microsoft's KB5124011 page says it replaced August's KB5121001 and targeted WinRE 10.0.28000.2949. Neowin, which covered the September 8 dynamic updates, reported the same 10.0.28000.2949 target for KB5124011. KB5124013 now takes that revision to 3086.

The version gap follows the OS builds. Microsoft's 26H1 release history lists KB5124006 (OS Build 28000.3086) Preview on September 22, KB5129194 (OS Build 28000.2956) Out-of-band on September 14, and KB5124012 (OS Build 28000.2954) on September 8. Each Safe OS package appears to pull WinRE up to about the level of that month's OS servicing. That's an inference from matching build numbers; Microsoft doesn't describe it as a rule. It does give you a simple check: a 26H1 device showing a 2949-series WinRE after September 22 hasn't picked up this update yet.

How Safe OS Dynamic Updates reach WinRE and installation media​

Dynamic Updates come in several types, and the name "Safe OS" confuses people. As Neowin explains, dynamic updates improve the Windows recovery process through WinRE updates, which are also called Safe OS updates, while Setup updates change the setup binaries. These packages are designed to be applied to existing Windows images before deployment, and they also help keep Language Pack and Features on Demand content during upgrades.

So KB5124013 has two audiences:

• Running 26H1 PCs. WinRE usually sits in a recovery partition as a winre.wim file, and Windows Update can service it in place.
• Deployment media. Imaging teams add the package to a Windows image or WinRE image before rolling out new machines. That's the scenario where "cannot be removed once applied to a Windows image" matters most: once you've baked KB5124013 into a master image, a bad result can't be rolled back by uninstalling the package. You go back to an earlier copy of the image.

For delivery channels, the captured KB5124013 page says to use "one of the following release channels", but the channel table itself wasn't captured. The previous 26H1 Safe OS package, KB5124011, listed Windows Update (automatic download and install), the Microsoft Update Catalog (standalone package) and Windows Server Update Services. For manual installs it pointed to Microsoft's procedure for adding an update package to Windows RE. KB5124013 probably uses the same channels, but that's an assumption. Check the KB5124013 channel listing in your console before you rely on automatic delivery for any group of machines.

Three ways to confirm the update landed​

Microsoft's verification guidance, KB5087037 ("Methods to verify the WinRE version installed," first published March 31, 2026), offers three methods. Pick based on how you installed the update.

Event Viewer and WinREAgent event 4501​

This is the lightest check if the update arrived through Windows Update:

1. Open Event Viewer.
2. Expand Windows Logs and select System.
3. In the Actions pane, choose Find, search for WinREAgent, and select Find Next.
4. Look for event ID 4501, the servicing-success event. Its General tab shows a message that servicing succeeded and gives the new WinRE version.

On a successfully updated 26H1 machine, that version should read 10.0.28000.3086. Microsoft's example shows 10.0.22621.4742, which is just a sample from a different Windows release. Don't compare against it.

Microsoft says these events are logged when WinRE is updated through Windows Update. If you serviced WinRE yourself with DISM, or the WinREAgent events are missing because of disk-space limits, Microsoft recommends checking with DISM instead.

DISM against winre.wim​

This method reads the image directly, so it works regardless of how the update was delivered:

1. Open Command Prompt as administrator.
2. Run reagentc /info and note the Windows RE location path. Microsoft's example is \\?\GLOBALROOT\device\harddisk0\partition5\Recovery\WindowsRE, but the path varies by installation.
3. Run Dism /Get-ImageInfo /ImageFile:<that path>\winre.wim /index:1, putting your actual path in place of the placeholder.
4. Read the version field in the output. It should read 10.0.28000.3086.

Microsoft notes that the default file name is winre.wim and the default index is 1, but either can differ in your environment. Custom-imaged or OEM-configured machines are where that caveat is most likely to apply.

GetWinReVersion.ps1​

Microsoft also publishes an MIT-licensed PowerShell script to run with administrator rights. It finds WinRE using reagentc /info, mounts winre.wim (index 1) to a mnt folder on the system drive, reads the file version of winpeshl.exe inside the image, then unmounts with /Discard and deletes the temporary folder.

The script prints only part of the version. It returns the revision field of the file version, so on a correctly updated 26H1 device it shows WinRE Version: 3086, not the full four-part string. That's enough to tell 3086 from the previous 2949. If your fleet reporting stores full version strings, keep the difference in mind. The script also assumes the default file name and index, and it will create and then remove a folder called mnt at the root of the system drive. If that path is already in use on your machines, check it before running the script at scale.

KB5124006 image-servicing rules also apply to KB5124013​

Two points from Microsoft's KB5124006 cumulative-update page apply to anyone adding KB5124013 to media. They come from the broader Dynamic Update guidance, not from the KB5124013 entry itself.

Match release months. Microsoft says that if you install additional Dynamic Update packages with KB5124006, you should use versions from the same release month. If no Safe OS or Setup Dynamic Update exists for that month, use the most recently released one. For September 2026 media built on KB5124006, KB5124013 is the matching Safe OS package, replacing KB5124011.

Keep boot.stl consistent. When deploying dynamic updates to an existing Windows image, the installation media must include a boot.stl file. Microsoft says this file is used during Secure Boot validation and must match the Windows version and architecture of the image being updated. If it's missing, devices may fail to start from the media with error 0xc0430001. Microsoft recommends its Update WinPE script. The alternative is to copy boot.stl manually from a device's Windows\Boot\EFI folder to the matching folder on the media before deployment.

The boot.stl requirement is the one most likely to cause trouble for imaging teams. A media build can finish with no errors and still fail at boot. Given the Secure Boot certificate changes this year, any media refresh that includes new Dynamic Update packages deserves a real boot test on representative hardware.

What Windows 11 26H1 admins should do with KB5124013​

If you manage running 26H1 PCs, deploy KB5124013 and check the version. If you maintain deployment media, rebuild with the September packages and test boot. Home users on 26H1 whose machines take updates automatically only need to confirm the version if recovery tools start misbehaving. Devices on other Windows 11 versions, such as 24H2 or 25H2, aren't covered by this KB; they get their own Safe OS packages.

• After deployment, a 26H1 device's WinRE should report 10.0.28000.3086. A device still on 10.0.28000.2949 is on the superseded KB5124011 level.
• Use WinREAgent event 4501 for updates delivered through Windows Update. Use reagentc /info plus Dism /Get-ImageInfo for DISM-serviced images or where the event is missing.
• GetWinReVersion.ps1 prints only the revision number, so a correctly updated machine shows 3086.
• KB5124013 can't be removed from an image once applied, so keep a clean copy of your master image before you add it.
• When building September 2026 media on KB5124006, pair it with KB5124013 and include a boot.stl that matches the image's version and architecture to avoid error 0xc0430001.

KB5124013 is routine maintenance. It keeps the 26H1 recovery image on the same 28000.3086 revision as the September preview cumulative update and gives admins one number to check against. With Microsoft shipping a new Safe OS package roughly every two weeks, expect a successor around the October Patch Tuesday release. Imaging teams that script the WinRE version check now can reuse it for each new target version.