If you manage Windows devices in an enterprise environment, you need to be aware of something important happening in 2026: Microsoft is replacing the Secure Boot certificates that have been embedded in virtually every Windows PC since 2011, and the default rollout mechanism is not going to get most organisations across the line in time.
This post covers what’s happening, how to deploy and monitor the update with Intune, and what I found works significantly better than relying on Windows Update alone.
What Is Secure Boot and Why Do the Certificates Matter?
Secure Boot is a UEFI firmware security feature introduced with Windows 8. Before the operating system loads, the firmware verifies the digital signature of every piece of software in the boot chain — bootloaders, UEFI drivers, option ROMs — against a set of trusted certificates stored in the firmware itself.
Those certificates live in two main stores: the Key Enrollment Key (KEK), which controls who can update the certificate databases, and the Signature Database (DB), which lists the trusted boot software. Any code not signed by a trusted certificate gets blocked before it can run. This makes Secure Boot one of the most effective defenses against bootkit malware — the kind of threat that hides in the boot process where traditional antivirus can’t reach.
For over a decade, every Windows PC has shipped with the same three Microsoft certificates in these stores — all issued back in 2011. In 2026, those certificates are expiring.
What’s Expiring and When
| Expiring Certificate | Expiration Date | Replacement |
|---|---|---|
| Microsoft Corporation KEK CA 2011 | June 24, 2026 | Microsoft Corporation KEK 2K CA 2023 |
| Microsoft UEFI CA 2011 | June 27, 2026 | Microsoft UEFI CA 2023 + Microsoft Option ROM UEFI CA 2023 |
| Microsoft Windows Production PCA 2011 | October 19, 2026 | Windows UEFI CA 2023 |
Devices that miss the update won’t stop booting — but they lose the ability to receive new Secure Boot protections going forward: no updated revocation lists (DBX), no new boot manager signatures, no mitigations for newly discovered boot-level vulnerabilities. Over time this also affects scenarios like BitLocker hardening and third-party bootloader support.
Microsoft’s full breakdown is in KB5062710.
The Update Mechanism and How to Deploy It via Intune
Microsoft’s guidance for enterprise environments is clear: don’t rely on the automatic rollout. Use a controlled, registry-based opt-in so you can manage timing and deployment rings.
The mechanism is a single registry DWORD:
HKLM:SYSTEMCurrentControlSetControlSecureBoot
Value: MicrosoftUpdateManagedOptIn = 0x5944 (DWORD)Setting this tells Windows Update that the device is ready to receive the certificate update. Windows Update then delivers the payload and the device progresses through a series of compliance stages toward full certificate replacement.
Intune Deployment: Why Not the Built-in CSP?
Microsoft documents an official Intune configuration profile approach in KB5073196. In practice, the CSP path has a known bug that causes it to exit with error 65000 — the policy silently fails without any visible indication in Intune. Devices appear configured, but the registry key is never written.
The reliable approach is Intune Remediations (Devices → Remediations) with custom PowerShell scripts. This gives you:
- Full control over the registry write
- Structured per-device output visible in the Intune portal
- A schedule that runs on every device regularly
- The ability to add fallback logic
Setting Up the Remediation Package
- In the Intune portal, go to Devices → Remediations → Create script package
- Name it — e.g., Secure Boot Certificate Update 2026
- Upload the Detection script and Remediation script (links in the scripts section below)
- Set Run using logged-on credentials → No (must run as SYSTEM)
- Set Run script in 64-bit PowerShell → Yes
- Schedule to run once per day
- Assign to device groups in deployment rings: Pilot → Broad → Critical
One Prerequisite You Might Be Missing: Telemetry
Devices must have Required Diagnostic Data (telemetry level 1 or above) enabled, and the DiagTrack service must be running. The managed opt-in path relies on telemetry as the safety gate — Microsoft’s backend monitors whether the firmware update succeeded or failed, and will automatically block the update for a specific device if problems are detected. Without telemetry, this safety mechanism doesn’t work and Windows Update won’t reliably process the cert update.
Check the current state at:
HKLM:SOFTWAREPoliciesMicrosoftWindowsDataCollection
Value: AllowTelemetryMust be 1, 2, or 3. Value 0 (Security level) silently breaks the managed opt-in.
Monitoring Progress: The Detection Script and Compliance Stages
Microsoft provides official monitoring guidance via Intune Remediations in KB5080921. The detection script evaluates each device against six compliance stages:
| Stage | Status | What It Means |
|---|---|---|
| 0 | Secure Boot disabled | Manual BIOS/UEFI intervention required |
| 1 | Opt-in not set | Remediation will write the registry key |
| 2 | Configured, awaiting Windows Update | WU scan hasn’t delivered the payload yet |
| 3 | Update in progress | WU is actively applying certificates |
| 4 | CA2023 cert in UEFI DB | Cert written to firmware; one reboot away from compliance |
| 5 ✅ | Compliant | Fully updated, booting from 2023-signed boot manager |
A device is only truly compliant when WindowsUEFICA2023Capable = 2, meaning the device is actively booting from the new cert chain — not just that the cert is present in the UEFI DB.
The official detection and remediation scripts are published on GitHub:
🔗 mmelkersen/EndpointManager — Secure Boot remediation scripts
Converting Intune Reports to Excel
The export from Intune (Devices → Scripts and Remediations → [your policy] → Export) produces a CSV with JSON embedded in each row — not exactly readable. I wrote a PowerShell script that automates the conversion:
- Picks up the latest
DeviceRunStatesByProactiveRemediation_*.csvexport from the working directory - Parses the embedded JSON per device
- Exports an Excel file with a pivot table and pie chart showing update progress by status (Updated / NotStarted / Other)
- Maintains a running
SummaryReport.xlsxto track progress over time across multiple exports
Requires the ImportExcel module: Install-Module ImportExcel
📥 Download convert-report.ps1 (rename to .ps1 after download)
Why the Standard Approach Is Painfully Slow
Here’s the part nobody documents properly: even with MicrosoftUpdateManagedOptIn correctly set, Windows Update does not deliver the certificate payload in any predictable timeframe.
I observed a single device — a Lenovo ThinkPad with Windows 11 Enterprise, Secure Boot enabled, BitLocker on, fully patched — sit at Stage 2 for 36 consecutive days. Windows Update was fully active throughout. Cumulative updates installed normally multiple times during this period. The Secure Boot certificate payload simply never appeared in any update cycle during that observation window.
Across a mixed fleet of devices, organic progress through Windows Update alone runs at low single-digit percentages per week — sometimes less. This holds true even when:
- Windows Automatic Updates are fully enabled and working
- Vendor update utilities are installed and running (Lenovo Vantage, Dell Command Update, HP Support Assistant, and similar)
- No Windows Update category exclusions are configured
Vendor tools manage BIOS and firmware updates but don’t influence the Secure Boot certificate update delivery channel. And with the KEK CA 2011 and UEFI CA 2011 expiring in late June 2026, getting to meaningful compliance through Windows Update alone is not a realistic plan for most enterprise environments.
The Windows 11 Hotpatch rollout (available on Windows 11 Enterprise 24H2 with Autopatch) makes this worse: devices that receive most quality updates as hotpatches reboot far less frequently. A device can reach Stage 4 — certificate written to firmware, ready — and then sit there for weeks waiting for a reboot that never comes, because the update cycle no longer triggers one.
And to make things worse: even after a device does complete the update, the Intune portal takes its own time catching up. The screenshots below are from the same device — the first one taken on March 31, a day after the device successfully updated; the second taken on April 6. The report still hadn’t reflected the completed state.
The Mindcore Solution: What Actually Worked
After hitting this wall, I deployed the Intune Remediation approach described by the team at Mindcore. The results were clear: over 50 devices updated successfully in the first week.
How It Works
The solution uses two PowerShell scripts (Detection + Remediation) deployed as an Intune Remediation package. The key differentiator is a smart fallback mechanism that bypasses Windows Update when it stalls.
For devices not yet opted in (Stage 1): Sets MicrosoftUpdateManagedOptIn = 0x5944 and writes a timestamp (ManagedOptInDate) to the registry, then lets Windows Update attempt delivery normally.
For devices stuck at Stages 2–4 beyond 30 days: The fallback activates and bypasses Windows Update entirely using the direct method from Microsoft’s guidance:
- Sets
AvailableUpdates = 0x40and triggers theSecure-Boot-Updatescheduled task → writes the CA 2023 cert into the UEFI DB - Then sets
AvailableUpdates = 0x100and re-triggers the task → stages the boot manager update - Device moves to Stage 4; a reboot completes the transition to Stage 5
Version 4.0 adds integration with Microsoft’s modern WinCsFlags.exe API (WinCS), so the fallback works even on devices where the local payload .bin files under C:WindowsSystem32SecureBootUpdates are missing.
Every run writes structured diagnostic output to %ProgramData%MicrosoftIntuneManagementExtensionLogsSecureBootCertificateUpdate.log, with the current stage and key registry values visible directly in the Intune Remediations portal.
Risks to Know About
BitLocker recovery prompts. When the boot manager transitions to the 2023 certificate chain, PCR 7 measurements change, which can trigger a BitLocker recovery key request on the next reboot. In testing on Lenovo hardware it didn’t prompt — but this is hardware and firmware dependent. Always verify recovery key escrow in Entra ID before enabling the fallback at scale.
Requires a post-July 2024 cumulative update. The Secure-Boot-Update scheduled task used by the fallback was introduced with the July 2024 CU. Devices missing it will log FALLBACK_BLOCKED. Ensure your fleet is properly patched.
Stage 0 devices cannot be fixed in software. Secure Boot disabled in firmware requires manual BIOS/UEFI intervention. The detection script identifies and flags these clearly.
Stage 4 devices need a reboot. In hotpatch environments, enforce a reboot policy alongside the remediation. Consider filtering Intune reports for Stage 4 devices and tracking them separately — they’re one reboot away from done.
Benefits
- Actively breaks through the Windows Update stall rather than waiting indefinitely
- Fully observable: every device state is visible in Intune on a daily basis
- Idempotent and safe to run repeatedly
- Handles edge cases (missing payload files, WU never delivering) that basic approaches don’t
- No manual per-device intervention once deployed
Conclusion: Not Much Time, Not Much Help from Microsoft
Microsoft announced the certificate expiration with enough lead time to technically prepare — but not with enough tooling to make enterprise rollout manageable out of the box. The official CSP deployment path has a known silent failure bug. Windows Update delivery is unpredictably slow. And the June 2026 expiration deadline for two of the three certificates left very little runway for comfortable ring-based deployment across a large fleet.
The approach I’ve described here — Intune Remediations with a smart fallback mechanism — is what worked in my environment. But every organisation is different: different hardware vendors, different firmware versions, different telemetry configurations, different BitLocker setups. Run a proper lab test first. Validate on a representative sample of your hardware before broad deployment, check your BitLocker recovery key escrow, and understand which of your devices are Stage 0 before you start forcing reboots at scale.
This is my recommendation based on what I’ve seen. It’s not a guarantee. Make sure it fits your environment before you roll it out.
Sources
- Windows Secure Boot certificate expiration and CA updates – Microsoft Support (KB5062710)
- Secure Boot Certificate updates: Guidance for IT professionals – Microsoft Support (KB5062713)
- Microsoft Intune method of Secure Boot – Microsoft Support (KB5073196)
- Monitoring Secure Boot certificate status with Intune remediations – Microsoft Support (KB5080921)
- Act now: Secure Boot certificates expire in June 2026 – Windows IT Pro Blog
- Secure Boot Certificate Update – Making It Happen with Intune Remediations – Mindcore Techblog
- mmelkersen/EndpointManager – Secure Boot remediation scripts (GitHub)