Rolling out the 2023 Secure Boot certificates with Intune before the last 2011 CA expires

The Secure Boot certificates that Microsoft put into every Windows PC's firmware back in 2011 are being replaced by a 2023 set, and that replacement has to be written into UEFI firmware on each device. Intune now has a dedicated Settings catalog category to trigger the update, a Secure Boot status report to track it and a Microsoft-supplied detection script for Remediations. In this post I'll walk through what expires, what to check first, how to stage the rollout by hardware model and what "done" looks like on a device.

What expires, and what happens if you do nothing#

The table below is Microsoft's, from its Windows Secure Boot certificate expiration and CA updates page. Note that the single Microsoft UEFI CA 2011 is replaced by two certificates so that trust for third-party boot loaders and for option ROMs can be managed separately.

Microsoft is clear that a device without the new certificates keeps starting and keeps installing standard Windows updates. What it loses is new protection for the early boot chain: updates to Windows Boot Manager, to the Secure Boot databases and revocation lists, and mitigations for newly found boot-level vulnerabilities. Scenarios that depend on Secure Boot trust, such as BitLocker hardening or third-party boot loaders, can be affected over time. Microsoft also says explicitly that disabling Secure Boot is not an acceptable workaround.

Prerequisites#

• Secure Boot must be on. Confirm-SecureBootUEFI in an elevated PowerShell window returns True. Devices with Secure Boot off are listed in the report for visibility but need no certificate action.
• A supported Windows version on a current servicing update. The Intune settings apply to Windows 11 and Windows 10 versions still in support; Microsoft's guidance says devices should be on a current update.
• Firmware readiness. The firmware does the actual writing, and some models need an OEM firmware update first. Microsoft recommends testing four or more devices for each unique manufacturer, model and firmware version combination before you go wider.
• Diagnostic data. Only the Microsoft-managed Controlled Feature Rollout assist requires Required diagnostic data, but Microsoft also uses diagnostic data to classify devices as high confidence, and the Secure Boot status report needs it (plus the Data Processor Service for Windows enabled in your tenant) to show anything but Unknown.
• Intune permissions to create assignment filters and Settings catalog profiles. If you want the monitoring remediation, Remediations need Windows Enterprise E3/E5, Education A3/A5 or F3 licences.
• BitLocker. Microsoft tells you to include BitLocker-enabled devices in the pilot and confirm there are no unexpected recovery prompts. Event ID 1032 means the current BitLocker configuration would trigger recovery; Microsoft's fix is to suspend BitLocker for two restarts. Make sure recovery keys are escrowed to Microsoft Entra ID before you start.

Step-by-step#

1. Baseline the fleet with the Secure Boot status report#

Go to Reports › Windows Autopatch › Windows quality updates, open the Reports tab and select Secure Boot status. The default columns include Secure Boot enabled, Certificate status (Up to date, Not up to date or Not applicable; select the value for per-certificate detail), Secure Boot trust configuration (Microsoft only, or Microsoft and non-Microsoft, which decides which certificates apply), Confidence level, Date last reported and Alerts. Optional columns add manufacturer, system board, SKU and firmware version, which is exactly what you need to build model groups. Data arrives after a restart and can take up to 12 hours to land, and devices inactive for more than 28 days drop to Unknown.

2. Create the Settings catalog profile#

Go to Devices › Manage devices › Configuration › Create › New policy, choose Windows 10 and later and Settings catalog, then Add settings and search for Secure Boot. The category has three settings:

Microsoft's own guidance for staged rollouts adds only the first setting to the profile. Finish the wizard without assigning yet.

3. Build a model-based assignment filter#

Go to Tenant administration › Assignment filters › Create, choose Managed devices, platform Windows 10 and later, and in the rule builder pick the model property. Use Preview devices to confirm the match. Microsoft recommends model scoping because OEMs implement Secure Boot differently and it lets you validate on a known-good hardware set first. In rule syntax a filter looks like this:

(device.model -eq "Surface Laptop 5") or (device.model -startsWith "Latitude 5")

4. Assign the profile with the filter#

Open the profile, select Properties › Assignments › Edit, add the All devices virtual group (Microsoft suggests it because it needs no group maintenance), select Edit filter, choose Include filtered devices in assignment and pick your filter. Intune evaluates the filter at enrollment, at every check-in and whenever the policy is re-evaluated, so widening the filter later is enough to widen the rollout.

5. Add the monitoring remediation (detection only)#

Go to Devices › Remediations › Create script package. The detection script is Microsoft's sample inventory script; the KB article that hosted it (KB5072718) has been retired, and after the 12 May 2026 Windows update the sample lives on every device in %systemroot%\SecureBoot\ExampleRolloutScripts. Leave the remediation script empty, set Run this script using the logged-on credentials to No and Run script in 64-bit PowerShell to Yes, and schedule it daily during the rollout. Results appear under Monitor › Device status once you add the Pre-remediation detection output column; Without issue means Secure Boot is on and UEFICA2023Status is Updated, and the whole table exports to CSV.

Verify#

On a pilot device, from an elevated PowerShell window:

Confirm-SecureBootUEFI
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' -Name AvailableUpdates, AvailableUpdatesPolicy -ErrorAction SilentlyContinue
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' -Name UEFICA2023Status, UEFICA2023Error -ErrorAction SilentlyContinue
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='TPM-WMI'; Id=1801,1808} -MaxEvents 5 |
    Format-List TimeCreated, Id, Message

Good looks like UEFICA2023Status equal to Updated, no non-zero UEFICA2023Error, AvailableUpdates settled at 0x4000 and an informational Event ID 1808 ("This device has updated Secure Boot CA/keys"). Event 1801 is the opposite: certificates not yet applied to firmware. Microsoft estimates 48 hours and one or more restarts per device, and the report needs up to 12 hours after that restart to show Up to date.

Rollout plan and gotchas#

1. Pilot: four or more devices per unique model and firmware version, including BitLocker-protected machines. Wait 48 hours and a restart, then check the registry, events and report.
2. Models: extend the filter one validated model at a time and let the Confidence level column guide you. High confidence devices update automatically through monthly updates unless you opted out; Under observation and No data observed need your own testing; Temporarily paused means a known firmware issue, so hold off and look for an OEM update (Event ID 1802); Not supported devices should be excluded and documented.
3. Broad: swap to Exclude filtered devices for the problem models and assign everything else.

References#

• Secure Boot certificate updates: Guidance for IT professionals and organizations (KB5062713)
• Applying Secure Boot certificate update settings using model-based targeting in Microsoft Intune (KB5084490)
• Secure Boot status report in Windows Autopatch