Intune Surfaces Secure Boot Status and Certificate Updates in Windows Autopatch

Microsoft’s management toolchain now surfaces Secure Boot readiness and certificate status inside Intune, giving IT teams a single-pane view and control points to manage the platform-level certificate rotation required before Microsoft’s legacy Secure Boot CAs begin to expire in 2026. This change isn’t cosmetic: it turns previously opaque firmware trust-state into auditable, policy-driven controls that can be pushed, monitored, and reported from the Intune admin center, and it links directly to the Windows servicing tasks that perform the actual Secure Boot certificate enrollment.

Background / Overview​

Secure Boot is a UEFI firmware feature that enforces a small set of cryptographic authorities to validate pre‑boot components—bootloaders, option ROMs, and other EFI binaries—before the OS runs. Those authorities are represented as certificate entries in the firmware’s DB/KEK/DBX variables. Microsoft provided a set of platform certificates in 2011 (the “2011 CAs”) that many devices still rely on; those certificates are scheduled to begin expiring in mid‑2026, with a second set expiring later in 2026. If a device remains dependent on the 2011 CAs after expiry, it will be unable to accept newly signed Secure Boot updates and could lose the ability to receive important pre‑boot mitigations or compatibility fixes.
Microsoft’s operational response has two parallel tracks: work with OEMs to ship firmware that includes the new 2023 certificates, and provide an OS‑side servicing flow that can enroll the new certificates into firmware variables where OEM firmware permits authenticated writes. For managed fleets, Microsoft exposed controls and telemetry so IT teams can ask devices to run that servicing flow, opt devices into Microsoft’s controlled rollout assistance (when telemetry allows), or block automatic monthly delivery where full control is required. Those controls are now mapped into Intune’s Settings Catalog and surfaced in the Windows Autopatch / Secure Boot status reporting pages.

---

What changed: Intune now exposes Secure Boot controls and reporting​

Intune Settings Catalog mappings​

Intune exposes three discrete Secure Boot settings in the Settings Catalog (Platform: Windows 10 and later). These map directly to the OS servicing logic and the registry values that the scheduled task inspects:

• Enable Secureboot Certificate Updates — when enabled, Windows will begin the OS‑driven deployment of the new Secure Boot certificates on the device (this maps to the AvailableUpdates bitmask that the servicing task reads).
• Configure Microsoft Update Managed Opt‑In — opts a device into Microsoft’s Controlled Feature Rollout assistance; Microsoft may help deliver certificates for devices it classifies as “high confidence” if telemetry is available.
• Configure High Confidence Opt‑Out — this setting lets admins block automatic monthly delivery for devices that Microsoft has otherwise classified as high confidence (note the UI semantics: Enabled here means block automatic monthly deployment).

These Intune settings let administrators manage the enrollment flows centrally and tie those choices to compliance, reporting, and device groups. The Settings Catalog profile creation flow follows the usual Intune pattern (Devices → Configuration → Create profile → Platform: Windows 10 and later → Profile type: Settings Catalog).

New reporting: Secure Boot status in Windows Autopatch / Intune​

Microsoft added a Secure Boot status report inside Windows Autopatch (visible under Reports → Windows Autopatch → Windows quality updates → Reports → Secure Boot status) that answers three operational questions for admins:

• Which devices have Secure Boot enabled?
• Which Secure Boot‑enabled devices are already up to date with the 2023 certificates?
• Which Secure Boot‑enabled devices need certificate updates?

This report brings device-level detail into the same admin surface where update decisions are made and lets teams drill into device lists to see exactly which endpoints require follow‑up actions.

---

Registry, scheduled tasks, telemetry: how the OS‑side flow works​

Microsoft packages the OS‑side deployment into a scheduled servicing task that inspects a per‑machine registry bitmask and executes steps in a strict order. The ordering is critical: add the DB entries first, then KEK changes, then finally update the boot manager to a binary signed by the new CA family. This order prevents a device from being left with a boot manager it can’t verify.
Key operational registry entries and event signals you must understand:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\AvailableUpdates (REG_DWORD): an operational bitmask that requests the servicing sequence (for enterprise the recommended full-sequence bitmask is 0x5944). Setting this value triggers the servicing task to run the required steps.
• UEFICA2023Status (REG_SZ): transitions from NotStarted → InProgress → Updated as the sequence progresses. It’s the primary per‑device readiness marker for the Windows UEFI CA 2023 enrollment.
• UEFICA2023Error (REG_DWORD): a non‑zero code indicates a failure; when present, admins should examine the System event log for specific Secure Boot event IDs (Event ID 1808 = success; 1801 = failure during certificate apply; 1795 = firmware rejected authenticated variable write).
• WindowsUEFICA2023Capable (REG_DWORD): a peripheral indicator used in limited scenarios to show whether the 2023 CA is present in firmware or whether the system is booting from a 2023-signed boot manager. Use UEFICA2023Status for general reporting instead.

The servicing task runs roughly every 12 hours and some steps require a restart to complete; therefore, expect outcomes to appear over days as devices cycle through restarts and update windows.

---

How to verify Secure Boot readiness at scale​

There are three complementary data vectors that, when combined, give a reliable per‑device picture:

• PowerShell / Scriptable UEFI checks
• Confirm‑SecureBootUEFI returns True/False and is a safe, read‑only indicator of Secure Boot operation.
• Get‑SecureBootUEFI db returns the DB bytes; searching for the string "Windows UEFI CA 2023" is a quick test for presence. These commands are suitable for automated inventory scripts pushed via Intune or ConfigMgr.
• Registry state and scheduled task flags
• Poll AvailableUpdates, UEFICA2023Status, and UEFICA2023Error for per‑machine progress. Intune Settings Catalog writes map to these registry keys so you can use compliance scripts or compliance policies to collect values centrally.
• Event logs and SIEM integration
• Watch System log events (Event IDs 1808, 1801, 1795) and aggregate them via Event Forwarding, Defender telemetry, or SIEM to track large‑scale success/failure trends. Event-based alerts are essential for catching firmware rejection errors that require OEM intervention.

Use all three methods together to avoid false positives. For example, a DB entry might be present but the boot manager not yet updated (or vice‑versa) unless you verify both registry and DB contents and confirm the appropriate event IDs.

---

Operational playbook: inventory → pilot → rollout → verify​

This is not a monthly patch — it is a platform‑level certificate rotation that touches firmware, BitLocker, OEM firmware policy, and boot components. Treat it as a short multi‑month project with clear gates.

1. Inventory and classify (immediate)​

• Capture per‑device: OEM/model, BIOS/UEFI version, Secure Boot state, whether the device accepts OS‑initiated authenticated variable writes, Windows build, SSU/LCU status, management channel (Intune/WSUS/ConfigMgr), and BitLocker status (where keys are escrowed).
• Build a risk‑tiered inventory: Compliant, Misconfigured-but-fixable, and Unsupported (no firmware updates available). Prioritize internet‑exposed devices and high‑value endpoints.

2. Coordinate OEM firmware updates​

• OEM firmware is the ultimate gating factor for some devices. Consult vendor advisories (HP, Dell, Lenovo, Surface) for minimum BIOS versions that accept 2023 certificates and plan firmware pilots where required. Where OEM firmware is not available, plan mitigation or device replacement.

3. Prepare recovery posture​

• Back up BitLocker recovery keys and verify you can recover devices offline. Firmware variable writes can trigger BitLocker recovery prompts on some configurations; unsecured recovery processes will delay remediation and inflate helpdesk costs.
• Update golden images, WinRE, and recovery media to include the new boot manager where applicable. Test cloud/USB recovery workflows.

4. Pilot via Intune​

• Create a Settings Catalog profile with the three Secure Boot settings and apply to a small, representative pilot group organized by OEM/model/firmware. For pilot devices that cannot send diagnostic telemetry, use the registry/GPO or WinCS options instead. Monitor UEFICA2023Status and Event ID 1808 to confirm success.

5. Expand in waves and monitor​

• Roll out in firmware‑family waves. Use HighConfidenceOptOut to block automatic monthly delivery for rings where you want explicit control. If you opt devices into Microsoft Update Managed Opt‑In, ensure telemetry collection is compliant with privacy/regulatory policies.

6. Remediate failures​

• Devices with UEFICA2023Error or Event ID 1795 typically need firmware updates or OEM support; plan a remediation lane that includes vendor support escalation and, if necessary, device replacement. Keep a fast path to restore endpoints that hit BitLocker recovery.

---

Risks, failure modes, and what can go wrong​

Microsoft’s phased approach—ordered servicing + telemetry‑gated controlled rollouts—reduces blast radius but does not eliminate risk. Know the common failure modes:

• Firmware rejection (Event ID 1795): some OEM firmwares refuse authenticated writes or require OEM-signed KEK changes; these devices typically need a vendor BIOS update or manual OEM enrollment.
• BitLocker recovery prompts: firmware writes or boot manager swaps can trigger BitLocker recovery on some configurations. If recovery keys are not escrowed and validated, remediation is manual and expensive.
• Virtualized guests and special hardware: many hypervisors block guest‑initiated KEK updates; host/hypervisor updates or alternate deployment paths are needed. Appliance or embedded systems may be unsupported.
• Telemetry gating implications: Microsoft’s controlled rollout requires diagnostic data for “high confidence” classification. Organizations that restrict telemetry for privacy or regulatory reasons will not be eligible for Microsoft‑assisted updates and must use manual or OEM workflows. Document which devices can share telemetry and which cannot; handle privacy approvals and legal review where necessary.
• DBX revocation sequencing: revocations in DBX can be effectively irreversible on some firmware. Avoid blanket DBX pushes; follow Microsoft and OEM guidance to sequence changes safely.

Finally, treat alarmist “mass bricking” claims with conditional skepticism: while catastrophic outcomes are theoretically possible on unsupported or locked devices, the practical failure modes most organizations will encounter are firmware rejections and BitLocker recovery events—not universal bricking. Still, test thoroughly.

---

Practical scripts and checks (tactical)​

Use these safe read‑only checks for inventory sweeps and verification:

• Confirm Secure Boot enabled (PowerShell, run elevated):
  Confirm‑SecureBootUEFI
  (returns True when Secure Boot is enabled; returns False when supported but disabled; errors if UEFI is absent).
• Check DB for 2023 CA (PowerShell):
  :ASCII.GetString((Get‑SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
  (returns True/False). Use remoting and Intune scripts to collect at scale.
• Trigger local servicing (admin on a single device):
• Set AvailableUpdates to request DB updates (for example 0x40 for DB-only or 0x5944 for full sequence), then start the scheduled task:
  reg add HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
  Start‑ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
• Reboot as instructed and verify UEFICA2023Status becomes Updated. Only do this after firmware readiness and BitLocker recovery keys are validated.
• Monitor registry and event logs centrally: collect UEFICA2023Status, UEFICA2023Error, and Event IDs 1808 / 1801 / 1795 into your SIEM or Intune reporting pipelines.

---

Recommended governance and communications​

• Treat Secure Boot certificate rotation as a cross‑functional project: involve security, endpoint engineering, procurement, OEM support, and legal/privacy (telemetry approvals).
• Document a pilot success criteria: at least three OEM models from different families must report UEFICA2023Status = Updated, no unexpected BitLocker recoveries, and no critical app compatibility regressions before expanding waves.
• Use the Secure Boot status report in Autopatch/Intune as a living dashboard during rollout, and export snapshots for audit and compliance evidence. The report reduces reconciliation work by linking devices to certificate state.
• Where telemetry policies block Microsoft assistance, designate owners and approved maintenance windows for manual or OEM-driven enrollments. Do not leave these devices to chance.

---

Why this matters: risk to boot‑level security and updates​

The certificates that Microsoft issued in 2011 are the trust anchors for much of the Secure Boot ecosystem; their expiry would mean Windows Boot Manager and some pre‑boot components can no longer be re‑signed under the old chain. That would prevent the future delivery of Secure Boot updates and could undermine pre‑boot mitigations against sophisticated bootkits. Updating to the 2023 CA family maintains the ability to deliver boot-level security fixes and keeps the chain of trust intact across firmware and OS servicing. Microsoft and OEMs emphasize June–October 2026 as the critical window and advise organizations to prepare now.
Independent coverage and vendor advisories underline the same timetable and practical steps—many OEMs are publishing minimum BIOS lists and stepwise guidance, and security outlets have highlighted the dependency of anti‑cheat and other security components on a correct Secure Boot trust anchor update. These cross‑checks validate Microsoft’s timeline and the need for centralized, auditable controls in Intune.

---

Final analysis and recommended posture for IT teams​

Microsoft’s addition of Secure Boot status reporting to Intune and Windows Autopatch is a pragmatic and necessary evolution: it converts a previously opaque firmware trust problem into a manageable, auditable, and policy‑driven operational project. The Intune Settings Catalog mappings and the Secure Boot status report give administrators the tools to plan, pilot, and prove readiness across fleets—provided IT treats this as an operational project rather than a routine update.
Immediate recommended actions (priority order):

• Inventory your estate today for firmware readiness, Secure Boot state, OEM model, and BitLocker key escrow. Use Confirm‑SecureBootUEFI and Get‑SecureBootUEFI as baseline checks.
• Identify pilot candidates across OEMs and firmware families; secure BitLocker recovery keys for all pilot devices.
• Create an Intune Settings Catalog profile for Secure Boot controls and deploy to pilot rings; monitor UEFICA2023Status and event logs closely.
• Coordinate with OEMs to apply required BIOS updates for models that reject OS‑side writes. Maintain a remediation lane for firmware rejections.
• Use the Secure Boot status report in Windows Autopatch/Intune as the primary dashboard for rollout progress and compliance reporting. Export evidence for audits.

This is a platform‑level event with time sensitivity. Organizations that act now—inventorying, piloting, coordinating with OEMs, and leveraging Intune’s new visibility and controls—will avoid the most painful outcomes and keep pre‑boot integrity and updateability intact as Microsoft and OEMs rotate trust anchors. Microsoft’s tooling gives IT teams the levers they need; success depends on disciplined execution, robust recovery planning, and firmware coordination.

---

Conclusion
The Intune addition of Secure Boot status reporting and the Settings Catalog controls convert a complex, firmware‑adjacent security problem into an auditable, manageable program for enterprises. While the underlying mechanics still hinge on OEM firmware behavior and BitLocker recovery readiness, the new reporting surface and registry mapping make it possible to plan, prove, and execute a safe rollout at fleet scale. IT teams should treat Secure Boot certificate rotation as a short, high‑priority project: inventory now, pilot early, coordinate firmware updates, and use the Intune/Autopatch reports to measure success and provide evidence for compliance. With deadlines in mid and late 2026, the clock is real—start the work today.

---

Source: Windows Report https://windowsreport.com/microsoft-adds-secure-boot-status-reporting-to-intune-for-it-admins/

 

[ChatGPT]

Microsoft has quietly given IT teams a new lever: a built‑in Secure Boot status report in the Intune / Windows Autopatch admin surface that lets administrators see, at device granularity, which endpoints have Secure Boot enabled, which are already carrying Microsoft’s replacement Secure Boot certificates, and which devices need follow‑up before Microsoft’s legacy Secure Boot CAs begin to lapse in 2026.

Background​

Secure Boot is the UEFI mechanism that ensures a PC only runs signed, trusted components during early startup. It relies on a small set of certificates and key exchange keys (the DB/KEK/DBX variables stored in firmware) that act as the platform’s trust anchors. Those certificates are not permanent: the Microsoft certificates issued around 2011 are scheduled to start expiring in mid‑2026, and Microsoft/OEMs have published a coordinated program to rotate those trust anchors to a newer 2023 CA family. If devices aren’t prepared, they risk losing the ability to receive Secure Boot updates and, in some cases, losing compatibility for newly signed pre‑boot components.
Microsoft’s playbook frames this as a short, high‑priority operational project for IT — not a single monthly patch. That’s because a successful transition often requires two parallel actions: OEM firmware updates that permit the new KEK/DB values and an OS‑side servicing flow that enrolls the new certificates where firmware allows authenticated writes. The new Intune/Windows Autopatch reporting and the Settings Catalog MDM controls are intended to give administrators one place to read readiness and to push the OS‑side controls when appropriate.

---

What changed: the new Secure Boot status view​

Microsoft added a Secure Boot status report to Windows Autopatch (accessible through the Intune admin center under Reports → Windows Autopatch → Windows quality updates → Reports → Secure Boot status). The dashboard answers three operational questions at scale:

• Which devices have Secure Boot enabled?
• Which Secure Boot‑enabled devices are already up to date with the 2023 certificates?
• Which Secure Boot‑enabled devices require Secure Boot certificate updates?

The report exposes device metadata to help triage — device name, OS version, Microsoft Entra device ID, model, firmware version and release date, and a certificate status column you can drill into to see exactly which certificate(s) are missing or out of date. This visibility is integrated with Windows Autopatch so you can align certificate readiness with update deployment workflows.
This is not purely cosmetic: the UI links to the same controls and diagnostic signals used by the OS servicing task that performs the certificate enrollment. That means the report is intended to be the operational dashboard for a coordinated rollout, not just a passive health indicator.

---

Why this matters now (dates and deadlines)​

The calendar is important. Microsoft published guidance and a playbook in 2025 and has been phasing updates; but the firm dates to watch are:

• June 2026 — the first group of legacy 2011 Secure Boot certificates begin to expire.
• October 2026 — further trust anchor expirations that affect boot‑manager signing timelines.

Because those expirations are concrete and imminent, admins need to be able to inventory and remediate their fleets now — not later. Microsoft has repeatedly urged organizations to prepare well in advance, coordinate with OEMs for required BIOS/UEFI updates, and use the new management/reporting tools to avoid surprises.

---

The mechanics — what the OS and Intune are reporting​

To understand what the report shows and why it sometimes diverges from a simple firmware version check, you must grasp the three complementary data vectors Microsoft exposes:

• PowerShell / UEFI variable checks — read‑only, device‑level confirmation that Secure Boot is enabled and whether the new CA strings are present in firmware variables.
• Registry and servicing status — OS‑side registry keys and a scheduled servicing task that progress through deliberate steps to enroll the new certificates and update the boot manager.
• Event log signals — named event IDs that mark success or failure of specific update steps.

The recommended collection points and indicators include:

• Confirm‑SecureBootUEFI (PowerShell) — returns True if Secure Boot is enabled on the device.
• Get‑SecureBootUEFI db / dbdefault — inspect the DB and default DB bytes and search for the string "Windows UEFI CA 2023" to verify whether the 2023 certificates are present. Example quick test (run as Administrator): :ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023').
• Registry key path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing — includes keys such as AvailableUpdates (REG_DWORD), UEFICA2023Status (REG_SZ), UEFICA2023Error (REG_DWORD), and related indicators used by the servicing task. Administrators and management tooling can read or write these keys to observe status or request specific servicing steps. A common enterprise bitmask recommended in guidance is 0x5944 to request the full sequence of OS‑driven enrollment steps.
• Event IDs to monitor: Event ID 1808 (success — device applied newted boot manager), Event ID 1801 (failure during certificate apply), Event ID 1795 (firmware rejected authenticated variable write). These events should be collected centrally for audit and troubleshooting.

The Intune/Autopatch report surface is built from the telemetry and diagnostic signals the device supplies, correlated with the servicing progress indicators above. That explains why firmware versions alone are insufficient: a firmware update might include the 2023 keys but the OS servicing flow still must confirm and complete the final boot‑manager swap and record "Updated" in UEFICA2023Status to show as fully up to date.

---

How to verify Secure Boot status on an individual device (quick checks)​

These are safe, read‑only checks admins should use for spot‑checks and for validating pilot machines before mass deployment:

• GUI: Run msinfo32 → System Summary → look for "BIOS Mode" and "Secure Boot State". If BIOS Mode = UEFI and Secure Boot State = On, the device has Secure Boot enabled.
• PowerShell (elevated): Confirm‑SecureBootUEFI — returns True/False.
• Inspect active DB for 2023 CA strings: :ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windowsue, the DB contains the 2023 CA entry.
• Check servicing registry values: read UEFICA2023Status and UEFICA2023Error under the SecureBoot\Servicing path to see whether the scheduled task has been targeted and what outcome it reached.

Use these checks in combination — GUI + PowerShell + registry + event logs — to avoid false positives or false negatives. Microsoft’s public guidance and the playbook recommend this multi‑vector approach for reliability.

---

Practical checklist for admins (prioritized, sequenced)​

Treat ion as a short project with measurable gates. Below is a practical, prioritized checklist you can adopt immediately.

• Inventory and classify
• Identify all devices that report Secure Boot = On and list OEM, model, firmware vers signer.
• Use Intune/Windows Autopatch Secure Boot report as the primary dashboard for this inventory.
• Build a small, representative pilot
• Choose at least three models across different OEM families and firmware levels.
• Ensure you have BitLocker recovery keys backed up for those devices bges.
• Validate firmware prerequisites
• Confirm the OEM has published BIOS versions that include or permit KEK/DB changes for the 2023 CA family. Apply firmware updates in the pilot first.
• Verify OS readiness and diagnostics
• Confirm the device has the servicing bits set (if you plan to trigger OS-driven enrollment) or is eligible for Microsoft’s telemetry‑gated rollout.
• Confirm diagnostic/telemetry settings where the controlled feature rollout requires them.
• Run pilot enrollment and confirm success
• Use the scheduled servicing task or set AvailableUpdates = 0x5944 to request the full sequence, then monitor UEFICA2023Status and Event ID 1808. Only expand rollout after pilot success.
• Scale in waves and monitor
• Use Autopatch/Intune reports to measure device counts reporting "Up to date" and actively monitor event logs and UEFICA2023Error for failures.
• Maintain remediation lanes
• For devices that reject authenticated writes or show firmware rejections, prepare OEM escalation and replacement planning for unsupported hardware.

---

Intune / Settings Catalog and Group Policy knobs​

Microsoft mapped the OS servicing controls into Intune’s Settings Catalog. Key administrative settings you should know:

• Enable Secureboot Certificate Updates — when enabled on a device, Windows will run the OS‑side deployment steps mapped to AvailableUpdates.
• Configure Microsoft Update Managed Opt‑In — opt a device into Microsoft’s Controlled Feature Rollout assistance (Microsoft may help deliver certificates for devices it classifies as “high confidence” when telemetry is available).
• Configure High Confidence Opt‑Out — block automatic monthly delivery for devices that Microsoft would otherwise target. The UI semantics are inverted (Enabled = block).

For WSUS/SCCM or Group Policy — the playbook documents registry and GPO controls that map to the same behavior. Large domain environments can use the Windows Configuration System (WinCS) CLI and scripted registry changes to orchestrate the process at scale.

---

Real‑world issues observed so far (what admins are reporting)​

As organizations roll these controls into production, a few practical issues have surfaced in community threads and early adopter reports:

• Timing and telemetry lag — the report’s state is derived from device diagnostic data and can lag after firmware updates or servicing attempts, producing transient “Not up to date” results even when the firmware includes the 2023 keys. Administrators should allow a window for telemetry to surface before triaging.
• Export / pagination UX limits — some tenants reported trouble exporting full device lists and that the Autopatch view surfaced only partial device sets (pagination/export limits); Microsoft will likely iterate on the admin experience.
• Firmware diversity — OEM behavior varies. Some models require an OEM-signed KEK replacement and entirely firmware-side remediations; others accept OS-serviced enrollment. This diversity is the single biggest operational headache.
• Virtual machines and cloud images — VMs with UEFI firmware image variants may need updated virtual firmware or images to include the new keys; test cloud images early.

These are not fatal problems, but they show the need to treat this as an operational program: inventory, pilot, iterate, and escalate to OEMs where firmware refuses authenticated variable writes.

---

Strengths and what Microsoft did well​

• **Single‑pane fleet visibi Boot certificate status into Windows Autopatch/Intune provides a practical dashboard for admins to measure readiness without stitching together scripts and spreadsheets. That reduces manual reconciliation and speeds decision making.
• Policy and controls: Mapping the servicing controls into Intune’s Settings Catalog and providing registry/GPO equivalents gives organizations the choice between Microsoft‑managed convenience and explicit, auditable control for sensitive fleets.
• Playbook and diagnostics: Microsoft published a detailed playbook, event IDs, registry indicators, and PowerShell examples so admins have concrete artefacts to automate inventory and remediation. That reduces ambiguity in what used to be a firmware‑only problem.

---

Risks, limits, and what to watch out for​

• Telemetry dependency: The report relies on diagnostic/telemetry data. Environments that block diagnostic telemetry or that run fully air‑gapped networks will see limited value and require manual or OEMicrosoft documents these caveats and offers alternate methods, but the telemetry path is the easiest.
• False positives / timing: Because the OS must complete several steps and some require restarts, the report can show “Not up to date” until the entire sequence finishes and telemetry catches up. Don’t rush to remediation actions based on a single snapshot.
• OEM firmware variability: Some firmwares outright reject OS‑side KEK updates or require OEM PK workflows. Devices with no OEM support may need replacement — plan for that.
• Operational complexity: For some workloads (medical devices, industrial control systems, legacy peripherals) the update window and pilot discipline must be strict; BitLocker recovery procedures and rollback plans are essential.

---

Recommended short‑term playbook (30–90 day plan)​

• Day 0–7: Run Autopatch Secure Boot report and export your Secure Boot = On device list. Validate export completeness.
• Day 7–21: Run scriandidates: Confirm‑SecureBootUEFI, Get‑SecureBootUEFI db tests, and capture UEFICA2023Status. Back up BitLocker keys.
• Day 21–45: Apply OEM firmware updates to pilot machines (where required); trigger OS servicing on pilots (AvailableUpdates = 0x5944 if you intend to drive the flow) and confirm Event ID 1808 and UEFICA2023Status = Updated.
• Day 45–75: Expand in controlled waves, keeping a strict rollback and support window. Monitor the Autopatch report and SIEM for UEFICA2023Error and relevant event IDs.
• Day 75–90+: Remediate remaining devices by coordinating with OEMs, applying alternative remediation for air‑gapped systems, or replacing unsupported hardware.

This timeline is deliberately conservative to allow for diagnostic lag, firmware testing, and business approvals. Adopt the cadence that matches your change control but treat June–October 2026 as the hard, immovable window for completion.

---

Sample admin commands (for quick reference)​

• Confirm Secure Boot is enabled (run as Administrator):
• Confirm-SecureBootUEFI — returns True/False.
• Inspect active DB for the new CA (run as Administrator):
• (::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023') — True/False.
• Trigger the full OS servicing sequence (example; only after pilot validation and BitLocker recovery keys secured):
• reg add HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
• Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
• Reboot as required and monand Event ID 1808.

Treat these commands as operational — use management tooling (Intune scripting, ConfigMgr compliance scripts, or WinCS) rather than manual edits when working at scale.

---

Final analysis — why this is a net win for enterprise security​

Converting an opaque firmware trust problem into a set of auditable OS‑side controls and a single management surface is a pragmatic, operationally significant step. The Secure Boot status report in Autopatch/Intune gives security and endpoint teams the means to measure progress, prove readiness for audits, and align firmware updates with OS servicing workflows. When combined with Microsoft’s published playbook, event IDs, and PowerShell checks, organizations have a practical path to avoid the hard deadline risk in mid/late 2026.
That said, success depends on disciplined execution. Firmware heterogeneity, telemetry policies, and mission‑critical workloads are real constraints. For many organizations the work will be less about one click and more about a short cross‑functional project: inventory, pilot, escalate to OEMs when necessary, and document each wave. The new reporting surface makes that program feasible; it does not make it automatic.

---

Takeaways for IT teams (quick bulleted summary)​

• The Intune / Windows Autopatch Secure Boot status report lets admins see which devices are Secure Boot enabled and whether they have the new 2023 certificates.
• The 2011 Microsoft Secure Boot CAs begin expiring in June 2026; plan, pilot, and complete remediation well before then.
• Use a combination of Confirm‑SecureBootUEFI, Get‑SecureBootUEFI, UEFICA2023Status, and Event IDs (1808/1801/1795) for reliable verification.
• Prefer Intune/Autopatch and scripted orchestration (Settings Catalog / WinCS / GPO) to manual per‑device edits at scale.
• Expect telemetry lag, OEM variability, and some UX limits in early reporting — monitor and allow time for state to stabilize.

---

Microsoft’s new reporting and controls do not remove every operational hurdle, but they convert an otherwise opaque and risky platform task into a measurable program with clear gates. For IT teams, that is the difference between unplanned crisis in mid‑2026 and a controlled, auditable rollout that preserves boot‑time trust and the ability to receive future security updates. Start with the Autopatch Secure Boot status report, pick a conservative pilot, and use the playbook’s indicators to measure success.
Conclusion
The appearance of a Secure Boot status report inside Intune/Windows Autopatch is a timely and practical improvement for administrators facing a concrete certificate expiry deadline. It gives teams the visibility and control points they need to inventory fleets, pilot certificate enrollment, and scale rollouts with evidence. But the finish line still requires coordination with OEMs, careful pilot validation, BitLocker recovery readiness, and patience for telemetry to settle — treat the work as a short, cross‑functional program and start now.

---

Source: Neowin https://www.neowin.net/amp/it-admin...re-boot-in-windows-devices-across-their-firm/