About this page

Most of what has been written about the 2026 Secure Boot certificate expiry is about getting the new certificates onto devices. The registry trigger, the Intune policy, and the reporting options are all well covered. This series of posts is intended to cover the deployment side of the process, which I feel has not been covered as well. Specifically, it covers what happens to PXE, boot images, and task sequence media once devices start trusting the new certificates and, later, refusing the old ones. ...

This is the first deep dive in the Secure Boot 2023 and ConfigMgr Boot Images series. Configuration Manager 2509 added a checkbox to boot image properties named Use Windows Boot Loader signed with Windows UEFI CA 2023. The documentation says it “updates the boot loader files on PXE-enabled distribution points”. This post shows what that means in practice. It covers which flag the checkbox sets, which folder it changes, which files it does not touch, and how to prove from the server what a client received. ...

This is the second deep dive in the Secure Boot 2023 and ConfigMgr Boot Images series. The previous post showed that the 2023 boot loader checkbox is a package flag plus one staging folder per boot image on the PXE responder. Plenty of sites still run PXE through Windows Deployment Services, and those distribution points (DPs) work differently. On a WDS distribution point, the staging folder is somewhere else, and every boot image shares it. The checkbox does nothing there. ...

This is the third deep dive in the Secure Boot 2023 and ConfigMgr Boot Images series. Both of the PXE posts end at the same place. The boot image needs the current cumulative update inside it, and the two 2023-signed boot files need to be swapped into the standard locations. I tested the procedure on a workstation and on both of my lab site servers with the September 2026 cumulative update, KB5129195. I ran it again with the October 2026 update (KB5127648) on one of the servers. The tests ran on both the December 2024 ADK (10.1.26100.2454) and the September 2026 ADK (10.1.26100.9457). ...

This is the fourth deep dive in the Secure Boot 2023 and ConfigMgr Boot Images series. The previous posts got PXE and media to the 2023-signed boot files at the current version. This one is about what a device refuses once the BlackLotus revocations are applied to it, and what each refusal looks like. The Dell in my lab went through KB5025885 Steps 3 and 4. Three Hyper-V VMs stopped at Steps 1 and 2, Step 3 only, and Steps 3 and 4. I booted all of them against every boot file I could produce. The October 2026 update and a task sequence then showed what moves the Step 4 floor, and whether Windows can still be deployed to a revoked device. ...

This is the reference post for the Secure Boot 2023 and ConfigMgr Boot Images series. It is not part of the walkthrough. If you are working through the boot infrastructure, follow the deep dives in order. Come here when you need to look up which device can boot which image, decode a version screen, check a file, or work out why a PXE boot went nowhere. I measured every value here in September and October 2026, against the September 2026 and October 2026 cumulative updates. Those are KB5129195, which has the same boot files as Patch Tuesday’s KB5124008, and KB5127648. The ADK values apply to both the December 2024 (10.1.26100.2454) and September 2026 (10.1.26100.9457) ADKs, which ship the same winpe.wim. The numbers move monthly, but the method does not. ...

This is the living page for the Secure Boot 2023 and ConfigMgr Boot Images series. It holds the boot manager SVN history, every Security Version Number (SVN) that the Windows 11 24H2, 25H2, and 26H2 cumulative updates have shipped since June 2024, in one table. It also keeps the floors that Steps 3 and 4 set and the other values that change every month. Microsoft doesn’t publish the SVN, so I read it from each update’s own files. ...

This is the reference post for the Managing BIOS with Intune series. It is not part of the setup walkthrough. If you are deploying the solution, follow the deep-dive posts in order; come here when you need to look up a status line, understand the registry markers, decode a FailReason, or troubleshoot a device that isn’t behaving as expected. The registry markers A recurring remediation has to remember what it has done between runs, because the BIOS can only report whether a password is set, not which version. The scripts bridge that gap with registry markers under HKLM:\SOFTWARE\ConfigJonScripts\FirmwareManagement\. ...

This is the third post in the Intune BIOS Reporting series The first post covered the output format and the no-infrastructure reporting; the second built the Azure infrastructure. This one turns the Log Analytics reporting on, explains the data model, what it costs, and shows the KQL it enables. With the workspace, tables, app, and certificate from the setup post in place, the detection scripts can send a structured record on every run (full per-device, per-setting picture, queryable with KQL). ...

This is the second post in the Intune BIOS Reporting series. The first post, Reporting on BIOS management with Intune, covered what you can do with no extra infrastructure. This one builds the Azure infrastructure that lets the detection scripts push structured records to Log Analytics over the Logs Ingestion API. This is a one-time setup. It is the longest post in the series because there are several moving parts. ...