Microsoft Intune: Secure Boot 2023 Certificate Update Rollout – Part 2

There’s a moment in every major IT transition where the mood shifts from “Okay, this is fine” to “Oh no, this is definitely not fine.”

Part 1 was all about that moment.

We looked under the hood, poked around the firmware basement, stared at the 2011 certificates aging like milk in summer, and realized something important:

You can’t transition your fleet to the 2023 Secure Boot certificate chain unless you first understand what on earth your fleet even looks like.

And now that you’ve survived the inventory stage — JSON explosions, Power Query tantrums, and Autopatch report déjà vu included — you’re ready for the part where the real decision‑making begins.

If Part 1 was reconnaissance — pure visibility…
Part 2 is about mission planning and execution.

This is where the rollout starts — where someone hands you the detonator and says:
“Alright, now deploy this across 5,000 machines.”

This part of the series takes us from “What do we have?” to “How do we safely move thousands of devices to the 2023 trust chain without breaking Monday morning?”

Time to choose deployment paths.
Time to anticipate OEM mood swings.
Time to learn which updates you absolutely never push on a Friday.

Buckle up — as the Secure Boot 2023 CA Certificate Update Rollout is about to get real.

Quick Recap of Part 1

Disclaimer: If you haven’t read Part 1 yet, please do yourself (and your devices) a favour and read it first.

Not because I want the page views — but because jumping into Part 2 without the groundwork that is laid in Part 1 is like deploying GPOs during a production outage while someone “just quickly” reimages DHCP.

It’s technically possible, but your devices (and future‑you) will not thank you.

And if you still decide to skip ahead and things get… unpredictable, I cannot be held responsible for any spontaneous device mood swings.

1. The Problem We’re All Now Inherited

The 2011 Secure Boot certificates begin aging out in 2026. Devices won’t collapse dramatically, but they will stop accepting new Secure Boot updates — slowly drifting into a fragile, outdated security posture.

Think “software retirement home,” not “catastrophic failure.”

2. The 2023 Chain Steps In

Microsoft’s updated certificate chain (KEK 2K CA 2023, Windows UEFI CA 2023, etc.) becomes the new trust anchor.

Devices must adopt it to keep validating future boot components.

3. Why Inventory Was Step Zero

Before contemplating rollout, you needed to know:

• Who’s UEFI vs. who’s still rocking Legacy BIOS
• Who disabled Secure Boot (intentionally or otherwise)
• Who already carries the 2023 CAs
• Which models need OEM firmware updates

Skipping inventory = surprises. Surprises in firmware ≠ fun.

4. What Intune Actually Gives You

• Properties Catalog → No Secure Boot/UEFI fields whatsoever.

• Secure Boot Status Report → Helpful, with ifs and buts.

As also conveyed in Part 1, per Microsoft’s current docs, the Secure Boot status report is supposed to show only Windows Autopatch–managed devices. Ref: Microsoft Doc

However, in our tenant, we can also see devices not registered to Autopatch service (but managed separately using Rings via WUfB) getting listed in the report. Now I don't know for sure if this is really intended or it's 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.

• Intune Remediations → The only reliable, detailed, JSON-rich source of truth.

5. Why Remediations Came Out on Top

Remediations delivered:

• UEFI vs Legacy
• Secure Boot enabled/disabled
• Certificate readiness signals
• Registry state
• OEM + BIOS metadata
• Event log evidence
• Clean, parse-able JSON for real analytics

In short: The actionable intel you need before touching anything even remotely connected to firmware.

Making the 2023 Certificates Actually Arrive

Most IT admins think certificate rollout is purely automatic. It is… until it isn’t.

Here’s what Microsoft actually says:

• Most devices will get the updated 2023 certificates automatically via Windows Update

• Some devices won’t — thanks to disabled diagnostic data disabled, blocked update channels, unsupported SKUs, OEM firmware quirks, etc. [support.mi…rosoft.com]

• If the 2011 certificates expire before the device gets the 2023 replacements, it keeps booting, but enters a degraded security state where no new boot‑level protections can be applied. [support.mi…rosoft.com]

Now for organizations and enterprises, it is the IT admins who are expected to drive the rollout using Microsoft’s supported methods (Intune settings catalog profile, registry triggers, or OEM firmware updates where applicable). [support.mi…rosoft.com]

This is your fleet, your plan, your schedule — Don’t expect anyone to come and save you!

So in this part of the series, we’re going to walk through:

1. How to explicitly trigger Secure Boot certificate update using Microsoft’s registry‑based update signals (Yes, there are actual bits you set in the registry that tells Windows to “do it now.”)
2. How to monitor whether the certificates have been staged, applied, or rejected
3. How to validate that the device is now running with the 2023 Secure Boot trust chain
4. How to handle the device cohorts that don’t comply automatically (Because there will always be some.)

This is the behind‑the‑scenes bit — the mechanics of moving a device from the 2011 chain to the 2023 chain in the real world.

Let’s begin.

Understanding How Windows Applies Secure Boot Certificate Updates

Here’s how the new 2023 trust chain lands on devices:

• Windows Update (LCU/SSU): Carries the Secure Boot certificate payloads and orchestrates firmware variable writes when the device’s firmware allows it.
• Controlled Feature Rollouts (CFR): A Microsoft‑managed staged rollout that enterprise devices can opt into or out of depending on policy. [support.mi…rosoft.com],
• OEM firmware updates: Required for models whose firmware refuses OS‑initiated KEK/DB writes — these machines need the OEM to push a BIOS/UEFI update.
• WinCS CLI/Enterprise Tools: For platforms where admins need direct, local, command‑line control over Secure Boot updates (useful for servers or tightly‑controlled environments). [support.mi…rosoft.com]
• Registry-based Enterprise triggers: The officially documented way for IT to force deployment. It’s like giving an order to Windows to do the Secure 2023 update actions now.

The key insight:

Windows stores the new KEK/DB updates in firmware variables. Once staged successfully, they remain resident and will be enforced on next boot, only if Secure Boot is enabled — something which I will cover in Part 4.

Triggering the Deployment (a.k.a. Flipping the “Do the Thing” Switch)

Now that we understand how Windows applies the Secure Boot 2023 certificate updates behind the scenes, it’s time for the real hands‑on part — actually triggering the deployment.

Because here’s the truth nobody says out loud:

Windows will not always update the Secure Boot trust chain by itself.
Sometimes you have to give it a gentle… shove.

And that shove comes in the form of registry signals — Microsoft‑approved, fully documented, enterprise‑safe registry signals — that tell Windows:

“Perform all Secure Boot 2023 certificate/KEK/DB update actions. Start now. Not later. Not when you feel like it. Now.”

And at the center of all of this sits the star of the show:

The AvailableUpdates flag.

This is the closest thing we get to a big red button labeled “Push this to make Secure Boot do the thing.”

Meet the Registry Keys that Runs this Entire show

Microsoft provides a set of registry keys under:

HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot

Inside this hive sit multiple keys that let IT admins:

• Initiate certificate deployment
• Monitor deployment state
• Opt-in/out of Microsoft‑managed CFR buckets
• Validate whether DB/KEK updates have succeeded

The key we are interested right now, the “do the 2023 rollout now” trigger is AvailableUpdates (REG_DWORD) — the bitmask that controls which Secure Boot update actions Windows should perform.

You can think of it as the firmware‑update equivalent of “Release the Kraken.”

When set to:

• 0 (or missing entirely) → means No Secure Boot update actions to be taken by Windows.
• 0x5944 → Microsoft’s officially documented signal meaning:

“Deploy all required 2023 certificate updates, update the KEK, and switch to the new PCA2023‑signed Windows Boot Manager.”

Practical IT meaning:

Once the key is set to value 0x5944, Windows begins the Secure Boot update workflow:

1. Stage KEK updates
2. Write new DB entries for 2023 CAs
3. Stage the updated Boot Manager
4. Clear bits as actions complete
5. Mark progress through Servicing registry states
6. Wait for reboot to enforce the changes

This is the firmware equivalent of a multi‑phase, multi‑step dance routine — except Windows is the one dancing, and we are the stage managers pointing at the spotlight.

Why This Registry Approach Matters

Microsoft ships the refreshed Secure Boot 2023 trust chain as part of regular cumulative updates — but that doesn’t mean every device will actually apply it on its own.

A surprising number of devices will simply sit there, quietly holding the new certificates like they’re collectible trading cards… never enforcing them.

Reasons include:

• No diagnostic data → Windows can’t classify the device for CFR
• OEMs blocking authenticated firmware writes
• Update channel restrictions
• Hardware assigned to a “low confidence” bucket
• Firmware oddities or inconsistent NVRAM behavior
• Missing prerequisite KBs
• Windows Update configured in full “trust no one” mode

In other words: Unless your fleet consists entirely of identical, modern, single‑OEM devices fresh off a late 2024, and 2025-2026 assembly line, you cannot depend on the “automatic magic happens eventually” approach.

This is where the registry trigger earns its keep. It ensures:

• YOU decide the rollout timeline
• YOU control when devices stage the 2023 certificate chain
• YOU get centralized, predictable state tracking
• YOU avoid sliding unintentionally into the 2026 expiration window

In enterprise IT, control isn’t optional — it’s survival.

This registry‑driven method gives you exactly that.

How to Set the Trigger (Responsibly, Not Recklessly)

You have multiple ways to deploy the AvailableUpdates = 0x5944 update trigger:

1. Intune Proactive Remediations

The safest option. Why?

• Detection + Remediation allow guardrails
• You can track JSON outputs
• You can scale gradually

This is the Joy-preferred path.

2. Intune PowerShell Script

Simpler, but lacks guardrails.
Not recommended for large mixed‑OEM fleets unless you enjoy cliff‑diving without a rope.

3. Intune Win32 App (Scripted Installer)

Useful when you want a formal “package” with retry logic and detection logic that can handle reboot-request gracefully with defer logic (PSADT).

This is also a Joy-approved path if you would like to take upon the additional workload of packaging.

What Happens After You Set the Trigger

Once AvailableUpdates is set, Windows:

1. Notices the new bitmask
2. Checks Secure Boot state
3. Validates firmware capability
4. Schedules the Secure Boot Update Task
5. Stages certificates and KEK in UEFI NVRAM
6. Writes progress into the Servicing keys
7. Clears bits as operations complete
8. Waits for reboot
9. Enforces the new trust chain on next boot

About Reboots 🔁 (Yes, Two of Them)

Once the correct registry triggers are set on an eligible device, the Secure Boot 2023 update does not complete in a single restart. It requires two reboots. Yes, you heard that right!

This is not a delay.
This is not a failure.
This is how Secure Boot updates are designed to work.

Why two reboots?

First reboot — Intent is acknowledged

During the first restart, Windows takes cognizance of the registry changes you just made (AvailableUpdates, opt‑ins, CFR signals, etc.).

After the device comes back up, Windows invokes the Secure Boot update scheduled task, which begins the actual update workflow.

At this stage, Windows is effectively saying:
“Alright. I see what you want me to do. Let me prepare the firmware side of this.”

What happens during this phase?
If everything succeeds, Windows stages the new Secure Boot 2023 certificates into the Secure Boot DB (and related KEK updates) in UEFI NVRAM.

Second reboot — State becomes effective

On the next reboot, the newly staged Secure Boot DB entries are committed and enforced. This is the moment when the device actually begins validating boot components against the 2023 Secure Boot trust chain.

Only after this reboot will the device reliably report an updated Secure Boot state.

In short

• First reboot: Windows detects intent and stages the update
• Second reboot: Firmware enforces the new trust chain

Two reboots are expected, intentional, and entirely normal for Secure Boot DB updates.

Setting AvailableUpdates = 0x5944 signals intent immediately — but Secure Boot servicing only begins after the next restart.

If you only reboot once and think something is broken — it isn’t.
You’ve just left the job half‑finished!

This is because Microsoft intentionally avoids:

• Runtime firmware variable writes
• Secure Boot DB mutations during an active OS session

Secure Boot servicing is:

• Boot‑sequenced
• State‑driven
• Fail‑safe by design

That’s why:

• You don’t see the task fire instantly
• Devices sit at “pending” until reboot
• One reboot is never enough

What Not To Do Here

• Do not set 0x5944 on devices still running Legacy BIOS
• Do not set 0x5944 on devices with Secure Boot disabled until you fix that
• Do not force this on devices failing OEM firmware capability
• Do not blast 0x5944 tenant‑wide on a Friday afternoon
• Do not rely solely on the Autopatch status report to validate results
• Do not ignore devices stuck at 0x4100 (“pending reboot”) for days

This is firmware, not a Teams app update.

A Note on the Intune Settings Catalog Path (…and Why I Didn’t Use It)

Before we move on, let’s address the elephant in the room — because yes, Intune’s Settings Catalog can set the same Secure Boot registry keys that we triggered using scripts above.

Microsoft’s own documentation confirms the Settings Catalog is a fully supported way to deploy Secure Boot certificate updates. It maps directly to the underlying registry keys (EnableSecureBootCertificateUpdates, MicrosoftUpdateManagedOptIn, HighConfidenceOptOut) that ultimately influence the Secure Boot servicing pipeline.

So in theory, enabling the policy should:

• set the correct registry keys,
• initiate update staging,
• and move devices through Microsoft’s preferred “high‑confidence → staged → applied → enforced” path.

And this should make it

• cleaner
• native
• easier
• more “MDM‑purist”
• and safer than scripting

But sadly, all that is only in theory.

Why didn’t I rely on the Settings Catalog?

Because in my environment — and in testing — the policy behaved like that one colleague who says “on it” and then vanishes for the rest of the day.

Below is my observation of working with the Settings Catalog policy for the Secure Boot topic.

1. The policy kept failing with “policy rejected by licensing”

This was a known issue where Intune refused to apply Secure Boot update policies on devices whose base SKU was Windows Pro, even if they were legitimately running Enterprise via Windows Subscription Activation.

Microsoft has reportedly fixed this behavior earlier this year, and many admins have also confirmed the fix is live.

But in my tenant?

• Same error.
• Same rejection.

Still absolutely happening.

2. Even more confusing: The policy worked, albeit in parts…

When I drilled into the report of the policy, I found something… interesting.

• Some devices applied the policy succesfully. (Yes, they are there)
• Some ran the policy only after several reboots and a small prayer.
• Some reported failure.

For the devices which reported failure, I found out that the policy was able to write the HighConfidenceOptOut — the CFR opt‑out key, meaning Intune was able to write to the Secure Boot registry hive.

But the policy failed to write the AvailableUpdates and MicrosoftUpdateManagedOptIn keys of which AvailableUpdates is the main trigger that actually starts the Secure Boot 2023 update workflow.

For me, this is not the kind of variability you can build a production rollout plan around — especially when the update touches firmware trust anchors.

3. Instead… scripted rollout gave us guardrails + observability

On the other side, with the script via Intune Remediation — I get:

• Deterministic execution
• Visible pre‑check / post‑check output
• JSON output (for dashboards and slicing)
• Ability to block unready devices
• Ability to gracefully retry
• A direct view of the actual registry state

None of which the Settings Catalog currently gives me with this workload.

What’s My Recommendation? (Only if it matters to you…)

Simple as this:

• If the Settings Catalog works in your tenant, use it. It’s the cleanest, most Microsoft‑aligned method.
• If the policy partially applies, errors, or acts inconsistent as explained in my case here, use the scripted trigger path.

Or if you would like Microsoft to deliver the updates to your device at its own pace, you can only set the policy or registry key (MicrosoftUpdateManagedOptIn) to Opt-in and then wait… till eternity. [Not really recommended]

Now, before we terminate the session, shut down the lights and make the curtains fall, let me ask one last question — just to confirm expectations haven’t drifted —

Are you looking for the script I used… or did you assume it would magically appear in the appendix?

The Intune Remediation Script to… Valhala

Script I used as Detection

Detect-SecureBoot2023State.ps1

Script I used as Remediation (This is what sets the actual trigger on Windows…)

Set-SecureBoot2023UpdateTriggers.ps1

Link to my GitHub Repo for the same.

Closing (…and what’s coming in Part 3)

At this point, we’ve done the important — and slightly terrifying — part:

• We understood how Windows delivers the Secure Boot 2023 CA updates.
• We learned why automatic rollout isn’t guaranteed.
• We flipped the registry‑based “do the thing” switch responsibly.
• And we set the stage for devices to finally adopt the new trust chain.

But triggering the update is only half the battle (won, or… lost)

Now comes the part that separates the calm IT pros from the ones who suddenly develop stress‑induced coffee allergies:

• Did the device actually update?
• Did it stage the certificates?
• Did it apply them?
• Did it get stuck?
• Or did it quietly panic and pretend everything is fine?

Because Secure Boot updates don’t show progress bars.

They don’t send cheerful pop‑ups.
They don’t leave you love notes.
You have to go looking.

And that’s exactly where we’ll pick up next… in Part 3.

In other words, Part 3 will help you to validate that the update has actually happened — everywhere it was supposed to.