Windows 11 23H2 KB5134130: Certificate Trust Refresh and boot.stl Deployment Warning

What KB5134130 actually changes​

Microsoft's support page gives the target audience plainly. The update is for devices that don't receive current CTL updates, including updates to the list of untrusted certificates. Its examples:

• Devices in disconnected environments
• Devices that cannot reach Microsoft's certificate-update service
• Devices where automatic CTL updates are disabled

The release notes list one change, under the [Certificates] tag: an updated trusted root certificate payload inside the Windows cumulative update, aimed at the same three groups.

Microsoft's KB names no known issues. It says the package includes the fixes and quality improvements from the October 13, 2026 update, KB5126653 (OS Build 22631.7652). If a device already has earlier updates, it downloads and installs only the new parts.

Section summary: This is a certificate delivery update, not a patch for a new vulnerability. Its value depends on whether your devices are cut off from Microsoft's normal certificate-update path.

Why root certificates matter​

Microsoft's "Certificates and trust in Windows" documentation on Microsoft Learn explains the background. Windows and its applications check trusted and untrusted root certificates to decide whether a PKI hierarchy or a digital certificate can be trusted. Untrusted roots are certificates publicly known to be fraudulent. Both lists ship as CTLs, called the Trusted CTL and the Untrusted CTL.

By default, Windows fetches these lists from the internet through a mechanism Microsoft calls the CTL Updater. Microsoft's documentation says administrators can turn this off, though it doesn't recommend doing so. They can also use Group Policy to point it at an internal server. Windows stores the lists in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate (the EncodedCtl and DisallowedCertEncodedCtl values).

What happens if a device misses those updates? Over time its view of trust drifts away from the real world. A new legitimate root may not be recognized, and a newly distrusted root may still be accepted. Think of a bouncer working from last year's guest list: some real guests get turned away, and some people who were banned get waved in. KB5134130 hands those devices a current list through ordinary Windows servicing. Many disconnected environments already import updates that way, even when they block everything else.

Who is still on 23H2?​

Microsoft's KB says the update applies to "Windows 11 version 23H2, all editions," but in practice the audience is narrower. Russian Windows news site Comss.ru reports that the package targets x64 and ARM64 systems running Enterprise and Education editions. It also notes that support for Windows 11 version 23H2 in Home and Pro editions ended on November 11, 2025. Comss.ru adds that Microsoft recommends moving to version 25H2.

Based on Microsoft's published lifecycle (general industry knowledge rather than anything in this KB), Enterprise and Education servicing for 23H2 is due to end in November 2026. That's only weeks away. KB5134130 is therefore one of the last updates 23H2 fleets will get. Treat it as a stopgap and keep working on your migration plan.

Prerequisites before you install​

Microsoft lists the same baseline for every channel:

The servicing stack update bundled with this release is KB5126652, version 22621.7641. The SSU uses a 22621 number while the OS build is 22631. That's expected: 23H2 shares its servicing branch with 22H2 and is switched on by an enablement package.

That enablement package explains a line in Microsoft's notes that confuses people. The KB tells you to use enablement package KB5027397 to update to 23H2. KB5134130 does not upgrade a 22H2 machine to 23H2. It services devices that are already on 23H2.

Microsoft lists Windows Update, Windows Update for Business, the Microsoft Update Catalog and WSUS as release channels. The standalone package comes from the Catalog. For many disconnected environments the Catalog is the realistic route: download the package on a connected machine, then carry it across the air gap.

Deployment-media warning: don't forget boot.stl​

This part of the KB is for teams that build installation media rather than click "Check for updates." If you apply dynamic updates such as this one to an existing Windows image, Microsoft says the installation media must include the boot.stl file. Without it, devices may fail to start from that media and can show error 0xc0430001.

Key points from Microsoft's guidance:

• Windows uses boot.stl during Secure Boot validation.
• The file must match the Windows version and architecture of the image you're updating. An ARM64 file on x64 media won't work.
• Recommended: update the image with Microsoft's Update WinPE script.
• Alternative: copy boot.stl by hand from the device's Windows\Boot\EFI folder to the matching folder on the installation media before deployment.

Microsoft's "Update Windows installation media with Dynamic Update" article on Microsoft Learn shows how the scripted route works. Its sample PowerShell copies boot.stl from the serviced WinPE image (boot.wim), next to bootmgfw.efi and bootmgr.efi. Later it writes the file to \efi\microsoft\boot\boot.stl on the new media, even if the original media didn't have one. The same article reminds administrators that servicing media involves several images: WinPE, WinRE, the OS image in \sources\install.wim, and the full media folder tree.

Section summary: If you only install the update on running PCs, the boot.stl step doesn't apply to you. If you maintain golden images or USB install media, add it to your checklist so you don't end up with media that won't boot and shows 0xc0430001.

A practical checklist for admins​

1. Find the affected devices. List 23H2 machines that are offline, firewalled away from Microsoft's certificate-update service, or have automatic root updates disabled by policy.
2. Check any internal CTL redirection. Microsoft documents redirecting the CTL Updater to an internal source. If you do that, confirm your internal copy is actually current. A redirected updater that nobody maintains is no better than one that's switched off.
3. Confirm the baseline. Make sure each target has a July 8, 2025 or later update and the latest SSU.
4. Get the package. Use the Catalog for offline transfer, or WSUS and Windows Update for Business for managed networks.
5. Check the build. After installation, running winver should show 22631.7654.
6. Fix your media. If you service images, run the Update WinPE script or copy boot.stl by hand.
7. Plan the migration. 23H2 is near the end of its servicing life, and this update only buys a little time.

The bigger picture​

Microsoft has used out-of-band releases often this year for 23H2. Its release health pages show a September 14, 2026 out-of-band update that resolved, among other issues, USB audio devices failing to start or producing no sound. KB5134130 is quieter by comparison. It doesn't fix a crash or a broken Remote Desktop session. It refreshes trust data for machines that can't refresh it themselves.

Is it fair for Microsoft to call this "non-security"? Technically yes: no CVE is attached. In practice, stale root and distrust lists on isolated systems are a slow-building security risk. Whether you install KB5134130 should depend on how your devices get certificate updates today, not on the "non-security" label.