Microsoft Intune: Secure Boot 2023 Certificate Update Rollout — Part 1

TL;DR for Execs

^{(And for engineers who are currently operating at a blood‑caffeine ratio of 1:1)}

• What’s happening: Microsoft’s original 2011 Secure Boot certificates, the now legacy KEK 2011 and UEFI/Windows boot signing CAs 2011, begins expiring June 2026, with additional Windows boot‑signing cert phases through October 2026. Devices must adopt the new 2023 cert chain — Microsoft Corporation KEK 2K CA 2023, Windows UEFI CA 2023, Microsoft UEFI CA 2023, Microsoft Option ROM UEFI CA 2023 — to continue receiving boot‑chain protections and future Secure Boot updates. [support.mi…rosoft.com], [techcommun…rosoft.com], [support.mi…rosoft.com]

• Who’s doing the updating: Microsoft via Windows Update for qualifying devices (you can opt‑in via Intune), or you manage rollout yourself via Intune/OEM firmware. Many 2024+ devices already ship with the 2023 chain. [support.mi…rosoft.com], [support.mi…rosoft.com]

• What will happen if you do nothing: Devices won’t turn into pumpkins at midnight. They’ll still boot, but they stop accepting future Secure Boot updates (e.g., Boot Manager changes, DB/DBX revocations). Over time, your managed-device fleet will drift out of protection and compatibility — That’s “degraded security state” territory. [support.mi…rosoft.com], [support.mi…rosoft.com]

• How to fix (High-level):
  • Collect inventory of your managed-device fleet at scale to review Secure Boot posture.
  • Enable Secure Boot on devices running in UEFI mode but with Secure Boot set to Disabled. (Yes, you will find more than you would’ve anticipated!)
  • Check for OEM guidance and look for firmware updates for your devices (if available). HP, Dell, Lenovo, Asus, etc. most OEMs have explicit Secure Boot transition notes & timelines. [support.hp.com], [dell.com], [asus.com], [lenovo.com]
  • Plan the rollout of Secure Boot certificate update, either via the Microsoft‑managed path or Deploy-It-Yourself (DIY, if you like) path.
  • Continue with inventory collection to verify update status of your device fleet.

• Things that you might need to consider:
  • Recovery media: Rebuild WinPE/WinRE/Autopilot sticks so they trust the 2023 path. Old media signed only with 2011 certs can age out. Microsoft ships a Make2023BootableMedia.ps1 to re‑sign media with the 2023 Boot Manager. [support.mi…rosoft.com]
  • BitLocker & DBX: DBX updates (e.g., KB5012170) have triggered BitLocker recovery prompts historically; plan suspend/resume choreography as needed.

Introduction

There comes a moment in every engineer’s life when you look at something and say:

“I deeply respect the architecture… but for now, I would simply like it to work.”

That was me last week, wrestling one of 2026’s hottest stability‑threatening, sleep‑destroying, most escalation‑summoning topics: Secure Boot certificate transition.

Secure Boot is one of those least glamorous but most important security foundations of modern Windows devices.

Think of it as the bouncer at your firmware nightclub — checking signatures and validating bootloaders and early boot components before anyone can get inside and on to the dance floor.

And now, Microsoft is rotating the 2011 certificate set — the ones that have been quietly protecting us for over the last 15 years — with the new 2023 certificate chain — a behind‑the‑scenes refresh that looks transparent — right up until it isn’t.

And if you ignore it, get ready to be greeted with surprises at exactly the wrong moments.

Devices with expired secure boot certificates (the 2011 chain) would eventually fail to validate pre‑boot components — no new Secure Boot fixes for such devices — compromising the whole foundation of security composure, and a future littered with mysterious boot issues.

If your current fleet of devices, most of which still rely on the old expiring 2011 certificates, continues as-is and you do nothing about this transition, you’ll eventually end-up running a security museum.

This is the kind of thing that gets my attention. And if you manage devices at scale — it should get yours too!

The good news?

With right discovery logic and Intune workflows, this goes from “we are doomed” to “we have a plan.”

Because:

Quiet problems are only quiet until they aren’t. Secure Boot is one of those problems. Handle it now, and future‑you will be grateful.

The work you do now prevents outages later. The visibility you create now prevents escalations later. The automation you build now prevents chaos later.

Remove chaos, create predictability, and make the future a lot less scary for your fleet.

What Exactly Is Rotating (and When)?

Think of Secure Boot’s trust as three main Microsoft‑provided certificates from 2011 sitting in firmware:

• Microsoft Corporation KEK CA 2011 (lets Microsoft/OEMs update DB/DBX) → expires starting June 2026. Replaced by Microsoft Corporation KEK 2K CA 2023.
• Microsoft Windows Production PCA 2011 (signs Windows Boot Manager) → expires October 2026. Replaced by Windows UEFI CA 2023.
• Microsoft Corporation UEFI CA 2011 (third‑party bootloaders) → expires June 2026. Replaced by Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023.

If you do nothing: Machines keep booting, but stop taking future Secure Boot updates (Boot Manager changes, DB/DBX revocations). That’s a slow slide into a degraded security state. Not a pumpkin — more like a car that never gets oil changes. It runs… until it doesn’t. [support.mi...rosoft.com], [support.mi...rosoft.com]

Why is this Different (& Why does it Matter)

This isn’t Patch Tuesday update. It’s a firmware trust‑anchor refresh.

Treat it like a Bootloader + BitLocker spa day. Bring towels.

As the 2011 certificates begin to expire starting mid‑2026, devices that haven’t adopted the 2023 chain cannot keep applying new boot‑level protections and mitigations.

And Microsoft is and has been very clear about the consequences:

Once the older certificates expire, Windows will no longer be able to validate certain boot components. Devices must trust the new 2023 certificates to continue receiving secure bootloader updates.

Microsoft’s guidance is explicit: Treat this as a Project.

On paper, this looks straightforward enough.
In practice? Not even close.

Here’s the non‑negotiable truth:

You cannot roll out the new Secure Boot certificates until your fleet is actually ready — not “probably fine,” but really ready.

And achieving that readiness requires more than just enabling a setting.

It requires proper assessment, device‑level validation, and careful coordination across firmware, OS, and OEM dependencies — preparatory work that is absolute essential to ensure a smooth and secure transition.

This is where the trouble begins. Because to prepare for readiness,

• You need visibility into your fleet of devices.
• You need accurate signals.

In simple words, you need inventory, and you need that at scale— Not optional. Not trivial.

Inventory before Impact

The questions your inventory must answer

1. How many devices have Secure Boot enabled?
2. How many run UEFI but have Secure Boot disabled?
3. How many are still legacy/CSM BIOS (UEFI incapable or misconfigured)?
4. Which devices already carry the 2023 CAs vs. still on 2011?
5. Which models/firmware lines need OEM updates to play nicely with the 2023 chain? [support.hp.com], [dell.com], [asus.com], [lenovo.com]

And yes, you’ll want this in a format your leadership can consume without summoning you to explain what “DB/DBX/KEK” means.

Which means it’s time to turn our attention to Microsoft Intune and see what Microsoft has placed in our toolbox to help us get a clear, accurate picture of our Secure Boot posture.

Intune Up Your Expectations: Here’s What We Actually Get

Can Secure Boot/UEFI state be collected via “Device Properties Catalog” in Intune?

Simple answer is No. There is no built‑in device property in Intune’s inventory catalog for:

• Secure Boot Enabled/Disabled
• UEFI/Legacy BIOS state
• Secure Boot certificate version

As such, we’ve got only two practical lanes:

Option A — Secure Boot status report (simple, surface‑level sanity check)

What it is: A built-in reporting provided by Intune that gives a quick device‑level view showing whether Secure Boot is enabled and whether the device’s Secure Boot certificates are up to date, helping IT admins identify machines that need the 2023 certificate update before the older certificates expire.

Where: Intune Admin Center → Reports → Windows Autopatch → Windows quality updates → Secure Boot status.

What you get: List of devices showing their status for

• Secure Boot: Enabled, Disabled, or Unknown (due to telemetry or diagnostic data, whatever)
• Secure Boot Certificates: Up to date, Not up to date, or Not applicable (because why not)
• Device metadata: Model, Manufacturer, and Firmware details.

Caveats:

• This report depends on the successful reporting and processing of Secure Boot diagnostic data, and thus, device telemetry plays a big role, which can also be a blocker in many cases. [Hello Worker’s Councils as they have such a love-hate relationship about sharing device telemetry data.]

• Till now, this report has been in flux. Microsoft had to temporarily pull this report off to fix issues with data consistency and completeness. It was re-introduced back recently, but in our tenant, we see non-Autopatch devices also appearing in this report, which should not be the case. [Read below for explanation.] As such, it’s too early, at least for me, to bet the farm on this report as the sole source of truth.

Verdict:

• Great as a top‑layer radar sweep. Can be used for a fast top‑layer view, but don’t bet the farm on it as the only source of truth yet, at least for now!

 Quirks I noticed: Per Microsoft’s current docs, the Secure Boot status report is supposed to show only Windows Autopatch–managed devices. Ref: Microsoft Doc

This same is also reinforced in an article in WindowsReport

But in my case, in our tenant, we can see devices not registered to Autopatch service (but managed seperately using Rings via WUfB) also getting listed in the report. Now I dont know for sure if this is really intended or its a temporary data‑scoping issue on our tenant from the report’s recent service changes.

For now, I have a support case opened with Microsoft to get more clarification on this. As and when I get updated from that case, I will also update in here.

Thus, with option A still requiring clarification related to the genuineness of the data being presented, let’s look at the other option we have with Intune for collecting device-fleet inventory related to Secure Boot state and certificate update status.

Option B — Intune Proactive Remediations with Microsoft’s sample script (detailed, JSON‑enthusiast approved)

What it is: A Microsoft sample detection script that runs on devices and emits a JSON payload with Secure Boot state, certificate‑update signals, OEM/firmware details, and event log hints — perfect for building your own analytics, but not “dashboard‑ready” out of the box. [support.mi…rosoft.com]

Why is this approach better than Option A:

• Captures UEFI vs. legacy, Secure Boot enabled/disabled, Servicing registry values (e.g., AvailableUpdates, UEFICA2023Status/Capable/Error), Boot Manager signer, OEM/model/BIOS version, and even Event IDs 1801/1808 from TPM‑WMI System events that appear during staged rollouts.

• Exports cleanly from Intune and can be parsed in Excel/Power BI for pivoting and dashboards.

Deployment notes (high‑level):

1. Open Intune Admin Center and navigate to Devices → Windows → Scripts and remediations and Create a script package with only detection script (no remediation action). [You can use the sample Microsoft script as-is]
   1. Script run behaviour set to SYSTEM context.
   2. Run this script using logged-on credentials: No
   3. Enforce script signature check: No
   4. Run script in 64-bit Powershell: Yes
2. Assign to the required group that contains all your corporate Windows devices (or your pilot rings).
3. Schedule run for hourly or daily to achieve quick convergence. Let it bake 24–48 hours for coverage.
4. Export results from the Device status blade — you’ll get a CSV file.

Inside the exported CSV file, you will get a column (PreRemediationDetectionOutput) which contains the JSON detection output per-device. (As shown in the image above.)

Turning JSON into insight → Excel Power Query (no macros, no tears):

• Open Microsoft Excel.
• Go to Data → Get Data → From File → From Text/CSV → pick the CSV you exported from Intune.

• Transform Data to open Power Query.

• Select the JSON column (often called DetectionScriptOutput or similar) → Transform → Parse → JSON.

• Click the expand icon on the new Record column → choose the fields you want (e.g., SecureBootEnabled, FirmwareType, UEFICA2023Status, Manufacturer, Model, BiosVersion, AvailableUpdates, BootMgrSigner, TPMEvent1801).

• Close & Load.

This creates a new file with all the JSON fields you selected in the previous step as individual columns you can work with. So the last step is really to analyse the data. For that, go ahead and…

• Insert a PivotTable. Bucket devices into:
  • Ready (2023 CAs present / status OK)
  • Needs Enablement (UEFI + Secure Boot disabled)
  • Needs OEM Firmware (flagged not capable yet / error)
  • Replace/Legacy (CSM BIOS, not UEFI‑capable)

The above is only for demonstration purposes. From here, you can publish to Power BI — add slicers, add a theme, make a more engaging dashboard, and win a meeting.

Tip: Create slicers by Manufacturer/Model and BiosVersion to surface “which models need love”. OEM readiness varies, and some generations have published cut‑offs. [support.mi...rosoft.com]

Verdict:

• This is the more grown‑up route. Undeniably, this requires more work, more signal, but at the end, you will get fewer surprises.

What the Data will inevitably tell You

Now, whichever way you get the data, it will reveal…

• A surprising percentage of UEFI‑capable devices have Secure Boot… disabled. (Why? Dual‑boot experiments, old imaging playbooks, that one vendor tool from 2017. We’ve all been there.)

• Legacy/CSM BIOS still lurks — sometimes because of that one RAID ROM or ancient NIC PXE requirement. Those are replace or re‑image candidates.

• Firmware outliers exist: a handful of models will need OEM BIOS updates to accept the 2023 chain cleanly — and some older platforms are out of support. Plan replacements.

Why I prefer Inventory with Intune Remediation

The Windows Autopatch’s Secure Boot report is a “bless its heart” view — quick, friendly, ready-to-use, but with historical hiccups and data‑scoping questions. [Already explained above, why?]

But the remediation approach gives you hard evidence, forensic-grade signals: registry flags, event trail, OEM fingerprints, and everything that you might need as you embark upon this quest of getting your managed-devices fleet transition to the new Secure Boot 2023 certificate chain.

That’s the difference between “a report” and readiness!

Closing (…and what’s in Part 2)

You cannot responsibly deploy new trust anchors without a clear understanding of your environment.

Accurate inventory transforms uncertainty into an actionable plan

And now you have that foundation in place.

Sneak peek at Part 2:
With visibility sorted, we move on to the fun part — exploring the rollout paths and options that Microsoft provides to transition our managed fleet to the new 2023 Secure Boot certificate chain.

Sources & Further Reading (curated)

• Microsoft guidance & blog:
  • Secure Boot Certificate updates: Guidance for IT pros (KB 5062713) — timelines, methods, CFR. [support.mi…rosoft.com]
  • Act now: Secure Boot certificates expire in June 2026 (Windows IT Pro blog). [techcommun…rosoft.com]
  • Updating Microsoft Secure Boot keys (Windows IT Pro blog). [techcommun…rosoft.com]
  • Registry key updates for Secure Boot (KB 5068202) — AvailableUpdates=0x5944, status keys. [support.mi…rosoft.com]
  • When Secure Boot certificates expire on Windows devices — “still boots but degraded security.” [support.mi…rosoft.com]
• Intune reporting & remediations:
  • Secure Boot status report in Windows Autopatch (Microsoft Learn). [learn.microsoft.com]
  • Monitoring Secure Boot certificate status with Intune Remediations (Microsoft Support). [support.mi…rosoft.com]
  • Community scripts/implementations and rollout patterns. [github.com], [endpointninja.com]
• OEM guidance:
  • HP / Dell / Lenovo / ASUS pages & timelines. [support.hp.com], [dell.com], [support.mi…rosoft.com], [asus.com], [lenovo.com]
• DBX / BitLocker considerations:
  • KB5012170 Security update for Secure Boot DBX + known BitLocker interactions; historical reporting. [support.mi…rosoft.com], [bleepingcomputer.com]