Microsoft’s Secure Boot certificate refresh and the Intune “High Confidence Opt-Out” setting are now central pieces of enterprise patch planning: Microsoft is replacing the 2011 Secure Boot trust anchors with new 2023 certificates and offering multiple delivery paths — including an OS‑side scheduled task, Group Policy, WinCS, and an Intune/MDM control — to apply the changes. The update sequence is order‑sensitive (DB, optional UEFI CA entries, KEK, then the boot manager) and requires careful inventory, BitLocker recovery planning, and, for Microsoft‑managed automatic deployment, devices to transmit
required diagnostic data so Microsoft can classify them as “high confidence.” Failure to prepare can trigger BitLocker recovery prompts, require OEM firmware intervention, or in the worst cases prevent devices from accepting future Secure Boot updates once the 2011 certificates begin to expire in mid‑2026.
Background / Overview
Secure Boot depends on a small set of firmware trust anchors: the Platform Key (PK), Key Exchange Key (KEK), the Allowed Signature Database (DB), and the Revoked Signature Database (DBX). Microsoft provided three CA entries in 2011 that many devices still rely on; those certificates are being replaced by a set issued in 2023 to maintain Secure Boot continuity and allow firmer control over what firmware and pre‑boot components are trusted. The 2011 certificates begin expiring in June 2026 and continue through October 2026, making this transition time‑sensitive for organizations that care about pre‑boot integrity and future ability to receive Secure Boot–related security updates. Why this matters now:
- Expiry windows: key 2011 CAs begin expiring in June 2026 (KEK and some UEFI CA entries) and extend to October 2026 for the Windows boot‑signing PCA. Devices that don’t accept the 2023 certificates before expiry risk losing the ability to install future Secure Boot updates.
- Multiple new certificates: Microsoft’s renewal created four 2023 certificates (Windows UEFI CA 2023, Microsoft UEFI CA 2023, Microsoft Option ROM UEFI CA 2023, and Microsoft Corporation KEK 2K CA 2023) to separate boot loader trust from option ROM trust and allow finer policy decisions.
- Operational risk for IT: firmware variability, BitLocker interactions, and recovery‑media compatibility are the primary operational hazards; OEM firmware is the ultimate gating factor for some devices.
How Microsoft’s OS‑side flow works
Microsoft built an OS‑driven servicing flow that performs the certificate rotation and boot manager update in a carefully ordered sequence so systems are never left trusting a new boot manager without having the matching certificate in firmware.
The staged sequence (high level)
- Add the Windows UEFI CA 2023 entry to the Secure Boot DB.
- If the old Microsoft UEFI CA 2011 is present, add Microsoft Option ROM UEFI CA 2023 and Microsoft UEFI CA 2023 to DB.
- Add the Microsoft Corporation KEK 2K CA 2023 to KEK (this step often requires OEM‑signed KEK material).
- Replace the Windows boot manager with a version signed by Windows UEFI CA 2023; this requires a device restart and is scheduled to occur when the device naturally restarts (for example, during monthly cumulative updates).
This ordered approach avoids a class of failure where a boot manager is updated before the firmware is prepared to trust its signer, which would block updateability and could cause boot integrity problems. The OS flow is orchestrated by a scheduled task that polls a per‑machine registry bitmask and processes requested operations in sequence.
Registry and state instrumentation
Administrators will see and can automate around the following registry keys and status indicators:
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecureBoot\Servicing\AvailableUpdates (REG_DWORD) — a bitmask the scheduled task inspects; IT guidance commonly uses the value 0x5944 to request the full deployment.
- UEFICA2023Status (REG_SZ) — NotStarted / InProgress / Updated.
- UEFICA2023Error (REG_DWORD) — non‑zero value indicates a per‑device error code to triage.
- HighConfidenceOptOut and MicrosoftUpdateManagedOptIn — flags that affect whether Microsoft’s controlled rollout path will automatically attempt updates for a device.
Event log IDs to monitor include specific TPM‑WMI / Secure Boot entries such as Event ID 1808 (informational — device has applied the new certificates and boot manager) and Event ID 1801/1795 variants for error and DB/DBX update failures. Centralizing these events in SIEM or via Event Forwarding is strongly recommended for large fleets.
Delivery options for IT‑managed fleets
IT teams can choose one of several supported deployment paths; mix‑and‑match across a single device is discouraged because the OS flow expects a single control mechanism per device.
- Microsoft‑managed Controlled Feature Rollout (CFR): Microsoft targets “high‑confidence” devices and pushes changes automatically as part of monthly cumulative updates. This path depends on Microsoft being able to classify the device via diagnostic telemetry; devices must send the required diagnostic data. Administrators can opt devices out of Microsoft’s automated assist via the High Confidence Opt‑Out setting.
- Group Policy (GPO): An ADMX policy under Computer Configuration > Administrative Templates > Windows Components > Secure Boot can set a delivery preference that writes AvailableUpdatesPolicy = 0x5944; the servicing task will enact it. This method suits traditional on‑prem domain environments and leaves telemetry unchanged.
- Windows Configuration System (WinCS) CLI: A command‑line module (WinCsFlags.exe / WinCS PowerShell module) provides per‑machine scripted application and query of the same enablement key and is useful for scripted or audited rollouts.
- Intune / MDM CSP (coming / available): Microsoft released or is releasing a CSP that allows Intune and comparable MDM products to orchestrate the same OS‑side flow. Where available, MDM is recommended for cloud‑managed fleets because it supports scale, targeting, and reporting; Intune controls also include the HighConfidenceOptOut semantics described below.
The Intune setting: Configure High Confidence Opt‑Out
- Setting name (Microsoft Intune / MDM): Configure High Confidence Opt‑Out.
- Purpose: Controls whether Secure Boot certificate updates are applied automatically through Windows monthly security and non‑security updates when Microsoft has validated a device as capable of processing Secure Boot variable updates.
- Behavior:
- Enabled (opt‑out): Automatic deployment through monthly updates is blocked — Microsoft’s CFR will not apply the certificate updates on devices targeted for the managed rollout.
- Disabled (default): Devices that Microsoft has validated and that have sufficient diagnostic data will automatically receive certificate updates as part of cumulative monthly updates and apply them automatically.
The rationale is that Microsoft relies on telemetry and targeted testing to identify “high‑confidence” devices that are safe for automatic OS‑driven firmware variable writes; where diagnostic data is unavailable or the device is not in a high‑confidence bucket, Microsoft will not assume it should auto‑apply changes. This preserves safety and reduces the chance of widespread hardware incompatibility, but it requires organizations to be explicit about whether they want Microsoft to take on the risk of automated deployment.
Preparation checklist: inventory, recovery, and piloting
Before enabling any automated approach, follow a disciplined preparation plan.
Inventory and classification (first, critical task)
- Capture per‑device attributes: System manufacturer/model, BIOS/UEFI version and date, Secure Boot state (enabled/disabled), presence of 2011 CA entries in firmware (if detectable), Windows build, SSU/LCU status, management channel (WSUS/Intune/CFR), BitLocker status and where recovery keys are escrowed. Use Confirm‑SecureBootUEFI, Get‑SecureBootUEFI, msinfo32, and WMI/CIM queries to build the dataset.
- Build representative pilot sets by OEM/model/firmware family — include older models, high‑value infrastructure, and virtualized hosts because firmware behavior can vary widely.
Recovery posture and imaging hygiene
- Ensure BitLocker recovery keys are backed up to Azure AD, AD DS, or a secure offline vault. Back up and validate recovery media, WinRE, and golden images; inject updated Safe OS Dynamic Updates into recovery media where required. A failed firmware variable write may trigger BitLocker recovery or require recovery media to restore a device.
- Update WinRE and image toolchains to guarantee they include compatibility with the new boot manager; test “Reset this PC,” cloud reinstall, and offline image scenarios.
Pilot cadence and restarts
- Pilot rings: keep small rings per OEM/model family (5–10 devices minimum) and allow ~48 hours and multiple reboots for the full servicing sequence to complete before broad expansion. The scheduled task runs roughly every 12 hours and will defer steps that require a restart until one occurs.
Monitoring and verification: practical steps for admins
- Registry and status keys: Poll AvailableUpdates, UEFICA2023Status, UEFICA2023Error, and HighConfidenceOptOut to track per‑machine progress. UEFICA2023Status transitions NotStarted → InProgress → Updated when the servicing task completes steps.
- Event logs: Aggregate TPM‑WMI / Secure Boot event IDs (notably 1801, 1808, 1795, 1797/1798) into SIEM. Event ID 1808 is a helpful success indicator that the device has applied the certificates and updated the boot manager.
- Low‑level verification: Mount the EFI system partition and inspect the signer of bootmgfw.efi to confirm it’s signed by Windows UEFI CA 2023 (forensic checks using Get‑PfxCertificate or scripts are possible for lab validation).
OEM coordination and firmware realities
The single largest operational dependency is OEM firmware behavior. Some firmware rejects OS‑initiated variable writes or fails to persist updates after firmware resets. For those models, OEM firmware updates that embed the 2023 certificates or accept OS writes are necessary; IT should:
- Request per‑model minimum BIOS/UEFI versions from OEM support pages and apply vendor firmware updates in a controlled manner. OEM advisories (HP, Dell, Lenovo and others) confirm timelines and model lists.
- Escalate KEK application failures to OEMs; a KEK step failure generally requires vendor intervention because the KEK change is signed by the OEM PK and involves firmware semantics.
Privacy and telemetry implications
Microsoft’s CFR depends on devices sending
required diagnostic data and, in some cases, additional telemetry so Microsoft can classify devices as “high confidence.” Organizations with strict telemetry policies must explicitly decide whether to:
- Allow telemetry at the required level so Microsoft can assist with automatic updates, or
- Keep telemetry restricted and use self‑service methods (GPO, WinCS, Intune push) which require more IT effort. The Microsoft Learn guidance on configuring Windows diagnostic data explains how to manage telemetry settings by Group Policy and MDM and the categories (0–3) organizations can set.
Be explicit in procurement and privacy planning: diagnostic endpoints and diagnostic levels are part of the processor/controller conversation for organizations handling personal data.
Risks, limitations, and critical analysis
This effort is technically solid and operationally pragmatic, but it comes with unavoidable tradeoffs.
Strengths
- Multiple delivery paths (Microsoft CFR, GPO, WinCS, Intune) give IT teams flexibility to choose the safest method for each device class.
- Sequenced updates and status instrumentation (registry keys, event IDs) enable measured rollouts and automation of triage workflows.
- OEM collaboration reduces the need for manual key enrollment on many modern platforms; major vendors have committed to firmware updates for supported models.
Weaknesses and operational risks
- Firmware variability is the primary unresolved risk: older or vendor‑unsupported models that refuse OS writes will require firmware updates or device replacement. There is no pure‑OS workaround for some KEK failures.
- Irreversible actions: DBX revocations and some Safe OS image injections are effectively irreversible on many platforms. Improper sequencing or insufficient testing could permanently block legitimate media or recovery paths. Proceed carefully with DBX operations.
- BitLocker recovery and helpdesk impact: changes to boot components and Secure Boot variables commonly trigger BitLocker recovery if protectors were not suspended. This is the single most frequent and costly operational failure mode if recovery keys are not accessible.
- Telemetry dependence: enterprises that decline required diagnostic data will not be eligible for Microsoft’s CFR assist and will need to perform the work themselves. This increases complexity and potential for human error.
Caveat on dates and vendor coverage
- The key expiry windows (June 2026→October 2026) and per‑vendor firmware schedules are publicly documented by Microsoft and OEMs, but OEM coverage is variable per model and SKU. Treat vendor lists as authoritative for supported platforms and plan budget and replacement for unsupported hardware as needed.
Practical playbook and recommended steps for IT
- Inventory (immediately)
- Export OEM, model, firmware date/version, Secure Boot state, TPM status, Windows build, SSU/LCU, management channel, BitLocker escrow status. Use PowerShell and existing CMDB/Intune reporting to automate.
- Prepare recovery and images (weeks 0–2)
- Confirm BitLocker keys are escrowed. Update WinRE/golden images with Safe OS DUs and test recovery media on pilot hardware.
- Pilot (2–6 weeks)
- Create representative pilot rings grouped by OEM/model. Set AvailableUpdates via GPO/WinCS/Intune on pilot devices (or let Microsoft CFR target high‑confidence pilot buckets) and monitor UEFICA2023Status, UEFICA2023Error, Event IDs 1801/1808. Allow 48+ hours and multiple reboots per device.
- OEM remediation
- For devices that reject KEK or DB writes, coordinate firmware updates or offline KEK enrollment procedures with OEMs. If OEM support is unavailable and the device is critical, plan replacement.
- Phased rollout and post‑deployment controls
- Expand in waves only after validating success in each hardware family. Avoid indiscriminate DBX revocations or irreversible steps until broad compatibility is confirmed. Maintain ability to pause/opt‑out devices via the Intune High Confidence Opt‑Out control where Microsoft‑managed rollout is enabled.
Conclusion
The 2011→2023 Secure Boot certificate migration is both a necessary security refresh and an operational challenge for enterprises. Microsoft has provided a cautious, instrumented OS‑side update flow plus multiple management options — including a targeted Controlled Feature Rollout that depends on diagnostic telemetry, a GPO path for traditional on‑prem control, WinCS for per‑machine scriptability, and MDM/Intune integration for cloud scale. The right organizational approach combines thorough inventorying, tested recovery media, staged pilots, OEM coordination, and clear telemetry policy decisions. For many fleets, the path to readiness will be straightforward; for some hardware families the route requires firmware updates or replacement. The most important immediate actions are inventorying your estate and securing BitLocker recovery posture so the organization is ready to apply these crucial Secure Boot updates well before the 2026 expiry windows.
Source: Microsoft Support
Microsoft Intune method of Secure Boot for Windows devices with IT-managed updates - Microsoft Support