Microsoft Intune: Secure Boot 2023 CA Certificate Update Rollout – Part 3

Validation: From “Triggered” to “Trusted”

This guidance reflects field‑tested experience. It is not an official Microsoft statement. Always review current Microsoft and OEM documentation for your environment.

TL;DR — Executive Summary

This post covers the validation phase of the Microsoft Secure Boot Windows UEFI CA 2023 certificate update rollout.

In this part, you’ll learn how to:

• Validate Secure Boot 2023 CA updates with evidence, not assumptions.
• Interpret Microsoft‑documented registry servicing state.
• Correlate registry, scheduled task behavior, and TPM‑WMI event logs.
• Understand why two reboots are required — and what breaks when they don’t happen.
• Distinguish Windows‑side servicing success from firmware‑level rejection.
• Categorize every device into clear operational buckets:
  • Fully updated.
  • Pending reboot.
  • Firmware‑blocked.
  • Never started.

By the end of this post, you’ll get to know exactly which devices have truly transitioned to the 2023 trust chain — and which ones still require intervention.

Introduction

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 about Reconnaissance (visibility) — 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 trust your fleet is actually running.

After going through the inventory hell, JSON explosions, Power Query gymnastics, and an unhealthy amount of staring at Autopatch reports, Part-2 was where things turned operational — where someone handed you the detonator and said: “Alright, now deploy this across 5,000 machines.”

Paths were chosen.
Triggers were pulled.
OEM quirks were acknowledged.
And yes, we reaffirmed the ancient rule: Never push platform security updates on a Friday.

But deploying ain’t the chequered flag waving at the finish line. That’s where Part 3 begins.

The Validation Phase

This is the part where Windows looks you dead in the eyes and says:

“I’ve updated the certificate, trust me.”

…and your dashboards reply,

“Cool story. Show receipts.”

This chapter exists because Secure Boot certificate servicing is:

• Silent by design.
• Multi‑reboot.
• Firmware‑dependent.
• Easy to misunderstand.
• Very easy to falsely mark as “done”.

This is the chapter where reporting lag causes temporary heart attacks, devices claim “updated” while still booting the old chain, and you — the admin — must determine who’s actually telling the truth.

Because…

Secure Boot 2023 CA Certificate Update Rollout isn’t over when you hit Deploy. It’s over only when the machines — firmware, Windows, and evidence — all agree.

From “Triggered” to “Trusted”

In Part 2, we set the registry trigger that instructs Windows to begin the Secure Boot 2023 update workflow.

But we still haven’t answered the only question that actually matters: How do we know it actually worked?

The Four Non‑Negotiables

This post is about answering four non‑negotiable questions for every device — questions you must be able to prove with evidence.

1. Did Windows Accept the Trigger?
   • Was the trigger (AvailableUpdates) set correctly?
   • Did Windows clear servicing bits as actions completed?
   • Did the Secure Boot servicing workflow actually start?
2. Did the Secure Boot Update Task Run?
   • Was the scheduled task invoked?
   • Did it complete successfully?
   • Or did it error out quietly?
3. Were the Certificates Actually Staged?
   • Is the Secure Boot DB updated with 2023 CAs?
   • Are KEK changes present?
   • Did firmware accept authenticated writes?
4. Is the New Trust Chain Enforced?
   • Is the device actively validating against the 2023 chain?
   • Or is it still booting happily on borrowed 2011 trust?

Part 3 is about proving — with evidence — that the transition from the expiring 2011 certificate chain to the new 2023 trust chain actually occurred.

Why This Validation Matters

Secure Boot updates are silent by design. And that silence is intentional — but dangerous if misunderstood.

• No UI
• No progress bars
• No toast notifications
• No “Update completed successfully” messages

A device can:

• Appear healthy
• Boot normally
• Report no obvious errors

…and still be stuck mid‑transition, leaving future boot‑level protections unavailable or unenforceable.

This is not hypothetical — it is real, and you will find this showing up in real fleets in your environment.

With the 2011 certificates expiring in June 2026 (and follow‑on expirations in October 2026), assuming success is not an option!

Outcome of Part 3

By the end of this post, you should be able to:

• Positively identify devices that:
  • ✅ Fully updated
  • ⏳ Staged but pending reboot
  • ❌ Failed or firmware-blocked
• Separate firmware problems from Windows problems
• Know which devices are truly secure — and which still require Secure Boot enablement.

The Technical Deep Dive: “How Windows Talks Back”

(a.k.a. the part where the machines finally start sending status updates instead of vibes…)

Now that we’ve triggered the Secure Boot 2023 certificate update workflow, our job of pushing the button is done.

From this point forward, we’re no longer deploying — we’re listening.

This is where the story shifts from execution to diagnostics —  from deployment to validation.

And yes —

Windows really does report the entire Secure Boot servicing progression back to the OS through a well‑defined set of registry keys that Microsoft explicitly documents for IT‑managed environments.

The Registry Keys That Tell the Story

Windows exposes an explicit, documented set of registry locations that govern Secure Boot certificate servicing for IT‑managed rollouts.

• HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot
• HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

Together, these keys control and reflect:

• Triggering the Secure Boot 2023 update
• Tracking its progress
• Detecting failures
• Understanding what happened after each reboot

While we’ve touched on these keys in Part- 2 already, the context back then was different — execution. Here in this post, the context is different — This time, we’re looking at the same keys through the lens of validation.

✅Important Clarification: AvailableUpdates vs UEFICA2023Status

You’ll see two different end‑state combinations referenced in this post, both of which can be valid:

Final Success State = {"AvailableUpdates = 0x4000" + "UEFICA2023Status = Updated"
} or {"AvailableUpdates = 0x0" + "UEFICA2023Status = Updated"}

✅ Why this behaviour: On some Windows builds, once the Secure Boot servicing workflow is fully complete and all required reboots have occurred, AvailableUpdates may reset to 0x0.This is expected. UEFICA2023Status = Updated is the authoritative final state indicator.

AvailableUpdates — The Trigger + Live Progress (Bitmask)

The hero of Part- 2 returns — this time with character development.

AvailableUpdates is a bitmask that both initiates and reports progress on the Secure Boot 2023 update.

Setting it to 0x5944 tells Windows to “Deploy all required Secure Boot components” as in:

• Add the 2023 Secure Boot DB CA.
• Add the 2023 KEK.
• Stage the new 2023‑signed boot manager.
• Prepare and execute the servicing workflow.

As Windows processes each action, the bitmask value changes to reflect intermediate servicing states, such as:

• 0x4100 → Certificates are “Staged” and is in “Pending reboot” state currently.
• 0x4000 → Certificates are “Updated” and fully processed.

⚠️ Important: AvailableUpdates is a transient state indicator, not a permanent success flag. Its job is to guide servicing — not to certify completion.

UEFICA2023Status — The Human‑Readable Status Flag

This is the rare Microsoft registry value that behaves like a normal person.

It reports one of:

• 🔴NotStarted
• 🟡InProgress
• 🟢Updated

If you’re building dashboards, health checks, or compliance logic: This is your primary success signal.

✅ Once set to Updated, Windows considers the Secure Boot 2023 CA servicing workflow complete.

UEFICA2023Error — Where Bad Things Announce Themselves

If something goes wrong during the Secure Boot CA certificate servicing workflow, Windows drops a numeric error code here.

This is critical for distinguishing between:

• OEMs blocking authenticated DB/KEK writes
• Firmware refusing Secure Boot database updates
• Failures within the Secure‑Boot‑Update scheduled task

Note that these are firmware realities, not Intune policy failures.

✅ Any non‑zero value here places the device firmly in the “needs attention” bucket.

The Scheduled Task That Does the Magic

When you set AvailableUpdates = 0x5944, Windows doesn’t immediately touch firmware or certificates. Instead, it queues the Secure Boot 2023 servicing workflow, which is executed by the following scheduled task: \Microsoft\Windows\PI\Secure-Boot-Update

The \Microsoft\Windows\PI\Secure-Boot-Update scheduled task only appears on modern Windows builds that include Microsoft’s Secure Boot 2023 CA servicing framework. In practice, that means all supported Windows 11 releases and fully patched Windows 10 22H2 (and select 21H2 Enterprise/Education devices) on extended support patched after November 11, 2025. Older or not in support Windows 10 builds will never receive this servicing pipeline and hence no amount of registry flipping will magically summon the task into existence on such systems. On these systems, attempting to trigger the task results in “task not found” or 0x80070002 failures.

This task:

• Runs every 12 hours
• Reads HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates
• Validates hardware compatibility
• Pulls certificate payloads from WinSxS
• Stages DB / KEK updates
• Places the 2023‑signed boot manager
• Prepares UEFI variable writes for reboot
• Retries safely across reboots

But here’s the catch:

The scheduled task does not finalize the Secure Boot update.

It only stages the changes. Actual application of the Secure Boot 2023 trust chain happens during reboot — and not just once!

The Two‑Reboot Truth Table (Because Reality Is Fun)

✅ Two real reboots are required.

Because…

• The first reboot allows Windows to apply staged changes and prepare firmware‑level updates.
• The second reboot is where Secure Boot variables are finalized and enforced by firmware.

⚠️ If reboot #2 is skipped, Intune will lie to you. Not maliciously — just early. Also note that Shutdown coupled with Fast Startup IS NOT counted as a Restart.

Here’s what your devices look like as they transition:

If you’re building a detection script — this table is your logic.

This scheduled task explains why:

• 0x4100 correctly means task ran, pending reboot
• Multiple reboot cycles are mandatory
• “Task success” ≠ “Secure Boot trusted”
• Registry state, task execution, and reboot history must all correlate

Understanding this task is the bridge between:

• registry intent, and
• firmware‑enforced reality

And it’s why validation in Part 3 matters far more than deployment in Part 2.

The Event Logs — Pathway to Valhalla

If the registry servicing keys are the headline, the event logs are the behind‑the‑scenes interview.

This is where Windows stops hinting and starts testifying.

For Secure Boot 2023 CA validation, you’re primarily watching TPM‑WMI events.

These events live under:
Applications and Services Logs → Microsoft → Windows → TPM‑WMI → Admin

The First Signal: Staged, Not Enforced

🟡 Event ID 1801 — “Updated certificates available, not yet applied.”

This is Windows politely saying:

“Hey, I’ve staged the new Secure Boot certificates in the DB.
I’m ready — I just need you to reboot me.”

⚠️ Seeing repeated 1801 events for days? You’ve got a reboot‑avoidance problem. You know the type: devices with 178 days uptime because users just keep closing the laptop lid.

At this stage, Windows is not failing.
It’s waiting.

From here, you can go two ways:

• 🟩Success, or
• 🟥Failure

✅ Success Path — Ascension Achieved

🟢 Event ID 1808 — “Certificates successfully applied and enforced.”

This is the golden event.

When you see 1808, it means:

• ✅ Firmware variables were successfully written
• ✅ Default and active DB / KEK stores are aligned
• ✅ The 2023 Secure Boot trust chain is now enforced

This is the moment to:

• mark the device green,
• stop chasing reboots,
• and celebrate appropriately (preferably with caffeine).

If you’re building dashboards, 1808 is your proof of enforcement, not just completion.

❌ Failure Path — When Firmware Pushes Back

If 1808 never appears after 1801, expect members of the gremlin family:

1795, 1796, 1797, 1798

These events surface when Secure Boot servicing collides with firmware reality —
DB / DBX / KEK writes or revocations that fail Windows’ safety checks.

🔴 Event ID 1795 — “The system firmware returned an error…”

This is Windows saying:

“I attempted an authenticated UEFI variable write.
Firmware returned a non‑success status.”

This almost always points to:

• firmware limitations, or
• OEM‑specific blocking behavior.

🔴 Event ID 1796 — “Certificates update failed.”

This is Windows saying:

“I hit an **unexpected error** while trying to apply a Secure Boot update (**DB**, **DBX**, **KEK**, **SBAT**, etc.). I’ll try again on the next reboot.”

Important nuance:

• This is not a permanent failure yet.
• It often precedes repeated retry loops.

🔴 Event ID 1797 — “The Secure Boot DBX update failed (Windows UEFI CA 2023 not present).”

This is Windows saying:

“You’re trying to revoke 2011 trust
before the 2023 trust chain is fully in place.”

This indicates a servicing order problem, not user error.

🔴 Event ID 1798 — “DBX update failed because the default boot app is still PCA 2011‑signed.”

This is Windows saying:

“Your boot manager is still signed with the 2011 PCA.
Update that before attempting revocation.”

This commonly appears when:

• the boot manager update didn’t stage properly, or
• firmware refuses to apply it.

Confirming the Actual Trust Chain Transition

Now for the endgame.

A device is considered fully transitioned when all of the following are true:

✅ Active DB contains “Windows UEFI CA 2023”
→ This replaces the legacy 2011 signing trust

✅ KEK contains 2023‑series updates
→ Required for approving future Secure Boot changes

✅ Boot Manager is signed with 2023 Production PCA
→ Required for early‑boot security updates post‑2026

PowerShell validation (simple and effective)

You can validate above with simple PowerShell as below.

# Active DB contains Windows UEFI CA 2023?
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Windows UEFI CA 2023')
# Optionally check KEK 2023
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023')

It returns a simple 🟢 True when the new 2023 CA certificate is present in the active DB.

And yes — firmware acceptance matters.

If:

• dbdefault contains 2023 entries
• but db does not

Then the firmware accepted the update in defaults,
but did not apply it to the active store.

Some OEMs will:

• Block authenticated variable writes
• Require BIOS or firmware updates
• Only expose Secure Boot update paths via OEM tools

This is where UEFICA2023Error usually tells the real story.

And this is why registry, task state, and event logs must all agree.

Admin Validation Flow

(a.k.a What to Look For… and What Not to Panic About!)

Use this checklist to validate each device after triggering the Secure Boot 2023 CA update.
Follow it top‑down — don’t skip steps.

Check the Trigger

If AvailableUpdates = 0x5944 → The device received the trigger.

If not present:

• confirm targeting,
• confirm opt‑in / opt‑out flags (High‑Confidence vs Microsoft‑Managed),
• confirm the Secure‑Boot‑Update task exists.

Check for Reboot Requirements

If AvailableUpdates = 0x4100 → The scheduled task ran. Device is pending reboot.

This means the update is staged on the device, not enforced yet. Do not trust reporting in this state.

Check Update Status

If UEFICA2023Status = Updated & AvailableUpdates = 0x4000 ( or 0x0) & UEFICA2023Error = 0 (or not present) → Device is fully transitioned.

➡️ This means the Secure Boot 2023 trust chain is applied and enforced.

Investigate Errors

If UEFICA2023Error is present & UEFICA2023Error != 0

➡️ Stop troubleshooting Intune.
➡️ This is a firmware conflict.

This typically means:

• OEM‑blocked authenticated writes
• missing BIOS / firmware updates
• Secure Boot settings controlled by OEM tooling

📞 OEM escalation time.

Spot “Silent Partial Success”

If a device:

• Boots normally
• Reports no obvious errors
• But is still validating against 2011 certificates

➡️ The update never staged correctly.

This is a known trap.

Microsoft’s own guidance states many devices will continue to boot on 2011 certificates, but will gradually lose security protections if not transitioned — meaning you cannot trust “the device boots fine” as an indicator of success.

Mapping Results to your Fleet view

By the end of Part 3, every device in your estate belongs to one of these four buckets — no maybes.

1. Fully Updated
   • AvailableUpdates = 0x4000 (or 0x0)
   • UEFICA2023Status = Updated
   • UEFICA2023Error = 0 (or missing)
   • Active DB / KEK reflect 2023 value
2. Pending Reboot
   • AvailableUpdates = 0x4100
   • UEFICA2023Error = 0 (or missing)
3. Staged but Blocked by Firmware
   • AvailableUpdates = 0x4100
   • UEFICA2023Error != 0.
   • Event IDs 1795–1798 present
4. Never Started ->
   • AvailableUpdates not set, or
   • UEFICA2023Status stuck at “NotStarted” with AvailableUpdates = 0x5944 for >24 h.

Validation is not about whether the device boots.
It’s about whether firmware, Windows, and evidence all agree.

Troubleshooting Matrix

Why This Matrix Matters

This troubleshooting matrix helps administrators quickly separate:

• Windows‑side issues
  (task didn’t run, wrong bitmask state, reboot missing)

from

• Firmware‑level issues
  (OEM blocks authenticated writes, outdated BIOS, incompatible Secure Boot implementation)

That distinction is critical.

👉 If the problem is Windows, you can fix it with:

• targeting,
• task execution,
• reboots.

👉 If the problem is firmware, no Intune policy or script will fix it — it’s an OEM problem.

When registry state, scheduled task execution, event logs, and firmware evidence don’t align — always trust the firmware reality.

Common OEM Peculiarities (Without Naming Names)

(a.k.a. “Why identical devices behave like siblings with wildly different personalities.”)

These scenarios map directly to the troubleshooting matrix above; this section explains why those rows exist.

These behaviors are not bugs — they are firmware decisions made by OEMs over multiple hardware generations. Below are the patterns IT-admins embarking on the Secure Boot CA Certificate 2023 Rollout should be prepared for.

The “Firmware Accepts KEK but Drops DB” Family

Behavior

These devices happily accept an updated Key Exchange Key (KEK), but silently reject updates to the Allowed DB.

Why this happens

• Some firmware allows KEK changes but blocks DB writes without an OEM‑specific confirmation step
• Outdated BIOS implementations restrict DB writes despite successful OS‑level staging
• Microsoft documentation explicitly notes that DB/DBX writes can be blocked by firmware policies

Symptoms

• UEFICA2023Status = Updated
• UEFICA2023Error = 0
• Firmware DB still shows 2011 CA
• Device continues booting on 2011 trust

Diagnosis

Devices that say yes on paper but boot like it’s still 2011.

Fix

• Update BIOS / UEFI firmware
• Use OEM Secure Boot utilities if required to authorize DB writes
• Re‑trigger AvailableUpdates = 0x5944 after firmware update

The “Silent Dropper” Group

Behavior

Firmware silently ignores authenticated UEFI variable writes from Windows. No failure. No refusal. No log.

Microsoft explicitly documents this behavior: firmware may reject writes silently.

Symptoms

• AvailableUpdates progresses normally
• UEFICA2023Status = Updated
• DB / KEK values never change
• No errors raised

Real impact

• Windows thinks the device is compliant
• Firmware thinks nothing changed
• Audits think you failed

Fix

• Check OEM firmware changelogs for Secure Boot write‑policy changes
• Update BIOS fleet‑wide
• Validate DB / KEK directly in firmware UI or enterprise assessment tooling

The “Two Devices, Same Model, Different Reality” Family

Behavior

The most maddening scenario: identical model, wildly different outcomes.

Why this happens

Microsoft ecosystem telemetry repeatedly shows fleets with:

• Different BIOS versions across “identical” models
• Different Secure Boot baseline databases
• Different OEM microcode revisions

Symptoms

• Half the devices update cleanly
• Half reject DB / KEK writes
• Some fall back to NotStarted after reboot

Diagnosis

These aren’t identical devices — they’re firmware siblings from different timelines.

Fix

• Normalize BIOS versions across the model family
• Re‑trigger 0x5944 after BIOS consistency is achieved

The “Never Leaves NotStarted” Group

Behavior

• Trigger set (0x5944)
• Reboots occurred
• Servicing never starts

Why this happens

Microsoft support documentation notes that servicing may not begin when:

• Firmware blocks prerequisite Secure Boot operations
• Opt‑in / opt‑out registry keys conflict
• Secure Boot is not fully enabled or locked into a restricted mode

Symptoms

• AvailableUpdates = 0x5944 indefinitely
• UEFICA2023Status = NotStarted
• No UEFICA2023Error

Fix

• Confirm Secure Boot is Enabled, not in Setup or Custom mode
• Check OEM BIOS settings like Secure Boot configuration locked
• Verify opt‑in / opt‑out keys (HighConfidenceOptOut, etc.)

The “Pending Reboot Forever” Group

Behavior

Task completes, but firmware will not apply modifications without a full cold restart.

Why this happens

Fast Startup / hybrid shutdown interferes with Secure Boot certificate enforcement — documented by Microsoft and widely observed in the community.

Symptoms

• AvailableUpdates = 0x4100 permanently
• No error codes
• Users swear they rebooted
• They didn’t — they shut down

Fix

• Temporarily disable Fast Startup
• Force restarts via Intune (shutdown /r /t 0)
• Require two real restarts

The “One Normal Reboot Ain’t Enough” Family

Behavior

Not OEM‑specific, but very common. Some firmware will not fully enforce Secure Boot changes until two complete restart cycles, with reporting lag between them.

Symptoms

• Reboot #1: DB / KEK staged
• Reboot #2: reporting finally aligns

Fix

• Treat all firmware as guilty until rebooted twice
• Never validate devices that haven’t completed two real restarts

The “Firmware Freezes for 10 Seconds and Terrifies Everyone” Devices

Behavior

Temporary UI freeze during Secure Boot servicing.

Why this happens

UEFI authenticated variable writes are slow. Some firmware performs secure flash writes synchronously. This behavior is documented and expected.

Symptoms

• Temporary UI freeze
• Fans spin up
• Admin Slack explodes
• System resumes normally

Fix

• Do nothing
• Document this behavior in user‑facing comms before rollout

The “Firmware Needs Manual Authorization” Family

Behavior

Firmware does not allow OS‑initiated DB / KEK updates without explicit admin action.

Why this happens

Some OEM Secure Boot designs mandate:

• BIOS Menu approval
• OEM Secure Boot update utilities
• Special BIOS password modes

Symptoms

• Windows reports success
• Firmware DB remains unchanged
• No error codes

Fix

• Use OEM Secure Boot update tools
• Apply BIOS update enabling OS‑initiated writes
• Re‑trigger servicing

The “UEFI NVRAM Behaves Like It’s Tired” Group

Behavior

Older firmware struggles with Secure Boot variable updates.

Why this happens

Pre‑2020 firmware often suffers from NVRAM fragmentation or limited variable write endurance.

Microsoft ecosystem analysis confirms these platforms may require extra cycles.

Symptoms

• Partial updates
• Transient errors
• Success only after multiple reboots

Fix

• Reboot again
• Yes, really
• Document as expected behavior on older platforms

✅ Final takeaway for readers:

Secure Boot CA rotation is not an Intune problem.
It is a firmware compatibility test — and firmware always has the final vote.

From Proof to Posture: Lining Up Part 4

Parts 1–3 of this Secure Boot Certificate Update Rollout series give you three things most important for the Secure Boot certificate rollouts:

• Visibility
• Execution
• Validation

But visibility and validation has a way of surfacing uncomfortable truths.

You will find devices that are:

• Fully UEFI
• Successfully updated to the 2023 trust chain
• Still running with Secure Boot disabled

They are technically updated. But they are not protected.

And validation alone does not fix posture.

The Awkward Middle Ground

This is the state many environments quietly drift into:

• The certificates are correct
• The boot chain is up‑to‑date
• The firmware is capable

…and yet Secure Boot itself is turned off.

Nothing is broken. But nothing is defended either.

Visibility exposes these devices.
Validation confirms them.

Security posture demands you deal with them.

What Comes Next: Part-4

The upcoming final post of the series, Part-4, is not about certificates anymore. That work is already done.

Part-4 is about something harder:

Enabling Secure Boot safely, deliberately, and at scale on devices already running UEFI — but coasting with Secure Boot disabled.

This is again not a checkbox exercise.
It’s a posture shift.

And it’ll be the natural conclusion of everything that Parts 1–3 set up.

By the end of Part- 4, you won’t just know:

• which devices are visible
• which devices are updated
• which devices passed validation

You’ll know which devices are actually protected. And that’s where this journey ends…