Secure Boot Certificate Update Readiness — Simplified

1. Background & Context

Microsoft has announced that the Secure Boot certificates originally provisioned in 2011 will expire in June 2026. This affects virtually every Windows device in enterprise environments and demands proactive preparation. The transition to the new 2023 certificates is not a simple patch — it requires thorough understanding of your hardware landscape, firmware readiness, and a deliberate governance-driven rollout plan.

This blog is the result of extensive hands-on work preparing thousands of enterprise devices for this transition. I am sharing the complete approach — from initial discovery scripts to PowerBI governance dashboards and the final registry-based deployment method — so that other IT professionals and organizations can benefit from a proven, production-tested playbook.

Key Microsoft References

The following official sources were instrumental in building this approach:

• Act now: Secure Boot certificates expire in June 2026 — Windows IT Pro Blog
• Secure Boot playbook for certificates expiring in 2026 — Windows IT Pro Blog
• Secure Boot Certificate updates: Guidance for IT professionals and organizations
• Secure Boot DB and DBX variable update events
• Microsoft Intune method of Secure Boot with IT-managed updates
• Registry key updates for Secure Boot: IT-managed updates
• OEM pages for Secure Boot
• Microsoft 2011 Secure Boot Certificate Expiration — Dell
• Secure Boot Certificate Expiration — Lenovo
• Secure Boot — Richard M. Hicks Consulting

2. What is Secure Boot & Why It Matters

Secure Boot Architecture & Components

Secure Boot is a security feature built into the UEFI (Unified Extensible Firmware Interface) firmware specification. It establishes a chain of trust from the moment a device powers on through to the operating system kernel loading. Its purpose is straightforward but critical: ensure that only trusted, cryptographically signed code is executed during the boot process.

The Secure Boot trust chain relies on several certificate databases stored in UEFI firmware:

Where Windows Gets Involved

When a Windows device boots with Secure Boot enabled, the firmware checks each component in the boot chain — the bootloader (bootmgfw.efi), the kernel, and early-load drivers — against the DB and DBX. Windows relies on the Microsoft Windows UEFI CA certificate in the DB to validate its boot components. The KEK certificate allows Microsoft and the OEM to update these databases through Windows Update or manual deployment.

Relevance to Enterprise Security in the Age of AI & Emerging Threats

In today's threat landscape, attackers increasingly target the pre-OS boot environment. Bootkits and firmware-level malware like BlackLotus have demonstrated that compromising the boot chain gives an adversary persistent, nearly invisible access that survives OS reinstalls and even disk replacements. Secure Boot is the frontline defense against these attacks.

With the rise of AI-powered attack techniques and sophisticated supply chain threats, maintaining a verified boot chain is no longer a "nice to have" — it's foundational to Zero Trust architecture. Many compliance frameworks (including conditional access policies in Microsoft Entra) increasingly require Secure Boot as a device health attestation signal.

Risks if Not Mitigated Before Certificates Expire

3. What is Changing?

Microsoft is replacing three critical Secure Boot certificates that were originally provisioned in 2011 with their 2023 successors. These certificates span the KEK database and the Signature Database (DB), and together they form the complete trust chain that Windows and third-party UEFI applications rely on during boot.

Each of these three certificates serves a distinct role in the Secure Boot trust chain. The KEK certificate is what authorizes Microsoft to update the DB and DBX databases on your devices — without a valid KEK, Windows cannot add new trusted signatures or revoke compromised ones, effectively freezing your security posture. The Windows UEFI CA is the certificate that validates the Windows boot loader, kernel, and early-load drivers — it is the reason Windows is allowed to boot at all on a Secure Boot-enabled device. The Third-Party UEFI CA validates non-Windows UEFI applications, drivers, and Option ROMs — this includes hardware add-in card firmware (network adapters, storage controllers, GPUs), third-party bootloaders (e.g., Linux shim), and other UEFI-signed components. If any of these three certificates expire without being replaced, the corresponding trust chain breaks.

The certificate update process involves writing the new certificates to the UEFI firmware's KEK and DB databases. This is a firmware-level change and requires a device reboot to apply. Microsoft has built servicing mechanisms into Windows to facilitate this, but the process is not automatic for IT-managed devices — organizations must explicitly enable the update.

4. Understanding Dependencies

Before deploying certificate updates at scale, you need to thoroughly understand your environment. This is not a "click and pray" situation. Each of the following areas can be a blocker.

Current Secure Boot State

Not all devices in your environment may have Secure Boot enabled. Legacy deployments, BIOS-based imaging, or manual overrides can leave Secure Boot turned off. Devices with Secure Boot disabled cannot receive certificate updates.

Hardware Landscape

Your fleet likely spans multiple OEMs (Dell, Lenovo, HP, etc.), dozens of models, and varying firmware versions. Each OEM has published minimum firmware requirements for Secure Boot certificate compatibility. A device on an old firmware version may not support the update — or worse, may brick during the process.

Firmware Inconsistencies

Even within the same model family, firmware versions can vary wildly across your fleet. OEM-specific BIOS/UEFI updates are a prerequisite in many cases. Microsoft has published OEM-specific guidance pages that map model families to minimum supported firmware versions.

Readiness Indicators

Microsoft provides several registry-based signals that indicate whether a device is ready for the certificate update:

• WindowsUEFICA2023Capable — Whether the device's servicing stack considers it compatible (values: 0, 1, 2)
• ConfidenceLevel — Microsoft's assessment of update confidence (High Confidence, Needs More Data, Unknown)
• UEFICA2023Status — Current update status (NotStarted, InProgress, Updated)

Success / Failure Indicators

Windows logs specific events to track the certificate update lifecycle:

5. Strategy: Data Gathering & Governance

The cornerstone of this entire approach is collecting the right data directly from the source of truth — the devices themselves. Rather than relying on potentially stale data from Intune device records, SCCM, or third-party tools, I built a custom telemetry collection pipeline that reads directly from each device's registry, firmware, event logs, and system APIs.

Architecture Overview

Mass Data Collection Approach

The deployment model uses a single Intune Platform Script that serves as a wrapper. This script:

1. Creates a persistent local folder on the device
2. Writes the embedded Audit Script content to a local .ps1 file
3. Executes the Audit Script once during initial deployment (silent execution)
4. Creates/updates a Scheduled Task to run daily as SYSTEM with highest privileges, whether or not a user is logged on, and runs ASAP if the scheduled time was missed

Script Architecture: A Reusable Modular Framework

The solution consists of two scripts working together: a Main Script (the Scheduled Task wrapper) and an Audit Script (the telemetry collector embedded within). This modular design makes the framework reusable far beyond Secure Boot — the Main Script can embed any PowerShell script that needs to run as a scheduled task on managed devices.

Main Script — Scheduled Task Wrapper

The Main Script is a self-contained Intune Platform Script that handles deployment, execution, and scheduling. It creates a persistent local folder, writes the embedded secondary script to disk, executes it once during deployment, and registers a daily Scheduled Task running as SYSTEM with highest privileges. If the scheduled time is missed (e.g., device was off), it runs as soon as the device is available.

All behavior is controlled through configurable values at the top of the script:

Audit Script — Telemetry Collector (Embedded)

The Audit Script is the payload embedded within the Main Script for this Secure Boot use case. It is a comprehensive device posture collector that gathers 45+ data points across Secure Boot readiness, hardware/firmware, identity, OS, patching, and reboot health. It runs under SYSTEM context, ensuring access to all necessary registry keys, UEFI firmware variables, and system APIs without user interaction.

Key configurable values within the Audit Script's $Config hashtable:

GitHub Repository & Scripts

6. Telemetry & Data Collection Deep Dive

The audit script collects an extensive set of data points from each device. Every field is designed to answer a specific question about readiness, health, or remediation status. Here is a breakdown of the key telemetry categories:

The table below is the complete reference of every field collected by the audit script, organized by category. This is derived directly from the script's output schema — every row sent to Log Analytics or written to CSV contains all of these columns.

Execution & Timestamp Fields

Device & Identity Insights

OS Insights

Reboot & Patching Insights

Hardware & Firmware Insights

Secure Boot Insights

KEK Certificate Insights

Event Log Insights

Overall Status

Overall Status Assessment

The script computes an OverallStatus field based on explicit criteria you define in the configuration:

$Config.Desired = [ordered]@{
    SecureBoot_Status                             = $true
    SecureBoot_Servicing_CertStatus               = "Updated"
    SecureBoot_Servicing_CertUpdate_Compatibility = "2"
    SecureBoot_Cert_Current                       = "CN=Microsoft Corporation KEK 2K CA 2023, ..."
}

If all criteria pass, the status is "All checks passed". Otherwise, it reports "Need Attention" with the specific failing columns, making remediation targeting straightforward.

Validation Before Mass Deployment

Before ingesting data at scale into Log Analytics, thorough validation is essential:

7. Building Insights with Power BI

With telemetry flowing into Azure Log Analytics, the next step is transforming raw data into actionable governance dashboards. I imported the Log Analytics data into Power BI using the MQuery (Kusto) method, which allows direct querying of the Log Analytics workspace from Power BI.

The Power BI report is organized into multiple focused pages, each addressing a different dimension of readiness and deployment tracking:

Secure Boot Insights Dashboard

This is the primary governance view. At a glance, you can see what percentage of your fleet has Secure Boot enabled, how many devices are compatible with the 2023 CA update, and the current deployment progress. The model and firmware breakdowns below help identify which hardware segments need firmware updates before certificate deployment.

Hardware Insights Dashboard

Understanding your hardware landscape is essential. This dashboard reveals OEM distribution (Dell, Lenovo, HP, etc.), the most common models, and critically, the spread of firmware versions and their release dates. Devices running firmware released before a certain date may need BIOS updates before the Secure Boot certificate update can proceed safely.

Device Insights Dashboard

This page surfaces operational health indicators that directly affect Secure Boot readiness. The Last Reboot Summary is particularly important: devices that haven't rebooted recently won't complete the certificate update (which requires two reboots). The Device Type breakdown helps prioritize deployment rings — you may want to start with standard laptops before tackling shared devices, kiosks, or AVD instances.

OS Insights Dashboard

Secure Boot Events Dashboard

This is the deployment progress tracker. The Event 1808 indicator is the definitive signal that a device has completed the certificate update. Over time, the green slice should grow until it encompasses your entire fleet.

Deployment Status & Last Run Info

8. Deployment: Certificate Update Rollout

After thorough data collection, insight building, and prerequisite verification, it is time to deploy the actual certificate updates. Microsoft provides multiple deployment methods, and understanding all of them — along with their prerequisites and trade-offs — is essential for choosing the right approach for your environment.

Prerequisites

Regardless of which deployment method you choose, the following prerequisites must be met on each target device:

Deployment Options

Microsoft documents several deployment methods. It is important to evaluate all of them and choose based on your environment, licensing posture, and risk tolerance:

1. Automated Deployment Assists (Microsoft-Managed)

Microsoft provides two automated assists that can help deploy the certificates without direct IT intervention:

2. Registry Key Method (IT-Managed)

The registry-based method gives IT full control over deployment by setting a single registry value that triggers the built-in Secure Boot scheduled task:

Here is the complete deployment script:

# ================== CONFIG ==================

$RegPath   = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot"
$ValueName = "AvailableUpdates"
$HexValue  = 0x5944

# ============================================

# Ensure registry path exists
if (-not (Test-Path $RegPath)) {
    New-Item -Path $RegPath -Force | Out-Null
}

# Set DWORD value
New-ItemProperty -Path $RegPath -Name $ValueName `
    -PropertyType DWord -Value $HexValue -Force | Out-Null

This script can be deployed via Intune as a Platform Script, a Remediation Script, SCCM/ConfigMgr, GPO startup script, or any other deployment mechanism your organization uses. The full script is available on GitHub: SecureBoot Certificate Update Deployment (Registry Config).ps1

Once set, a Windows scheduled task runs every 12 hours and processes the certificate updates in a specific order:

Each step must succeed before the next one begins. As bits are processed, they are cleared from the AvailableUpdates value: 0x5944 → 0x5904 → 0x5104 → 0x4104 → 0x4100 → 0x4000. For complete details on the registry keys, see Registry Key Updates for Secure Boot.

3. Microsoft Intune / Configuration Manager

Microsoft documents that Intune and Configuration Manager can be used to deploy PowerShell scripts that set the registry keys. A native Configuration Service Provider (CSP) is expected in a future update.

4. Group Policy Objects (GPO)

Microsoft has indicated that Group Policy support for managing Secure Boot updates will be provided in a future update. Since GPO manages settings only, monitoring will need to be done through alternate methods such as registry key checks and event log monitoring.

5. Windows Configuration System (WinCS) CLI

For domain-joined environments, administrators can use the Windows Configuration System (WinCS) command-line tools (both a traditional executable and a PowerShell module) to query and apply Secure Boot configurations locally. This is an option for environments where other methods are not feasible.

Why the Registry Method Was the Most Effective

The Reboot Requirement

Monitoring the Update Process

After deployment, the progress can be monitored through the following registry values and events:

All of these indicators are captured by the daily audit script, flowing into Log Analytics and surfacing in the Power BI dashboards. This creates a closed-loop governance model where you can track deployment progress in near-real-time without manual device checks.

Deployment Best Practices

1. Test on every hardware model in your environment before broad deployment. OEM firmware differences can cause unexpected behavior. Microsoft recommends testing at least 4 sample devices per unique device class (manufacturer + model + firmware version).
2. Ensure prerequisites are met on each device before enabling the update — Secure Boot on, firmware current per OEM guidance, OS patched, and device rebooting regularly.
3. Deploy in rings — start with pilot groups, expand to early adopters, then broad deployment. Pay particular attention to older devices that may no longer be supported by the manufacturer.
4. Avoid mixing deployment methods on the same device. Choose one method per device and stick with it.
5. Monitor the dashboards daily during rollout to catch failures early. Watch for Event 1795 (firmware errors) and stalled AvailableUpdates progression.
6. Have a remediation plan for devices where Secure Boot is off, firmware is outdated, or the update process stalls.

9. Conclusion & Key Takeaways

Preparing an enterprise environment for the Microsoft Secure Boot certificate expiration is not just about setting a registry value. It's about building a comprehensive understanding of your device landscape and establishing governance that extends well beyond this single event.

What This Approach Delivers

Governance Capabilities Established

The telemetry and insights framework built for this project enables ongoing governance across several dimensions:

• Gap identification: Devices with Secure Boot off, outdated firmware, inconsistent reboot or patching behavior are immediately visible and actionable
• Certificate update progress monitoring: Real-time tracking of NotStarted → InProgress → Updated status across the entire fleet
• Event log pattern analysis: Understanding the distribution and timing of 1801/1808 events to detect anomalies and validate rollout health
• Hardware lifecycle insights: Firmware age and version data that feeds into broader hardware refresh and compliance programs

Deployment Summary

While the preparation is extensive, multiple deployment paths exist. Evaluate all options — automated assists, registry keys, Intune/SCCM scripts, GPO, and WinCS CLI — and choose based on your environment:

1. Ensure prerequisites are met (Secure Boot on, firmware current per OEM guidance, device patched, rebooting regularly)
2. Choose your deployment method — the registry method (AvailableUpdates = 0x5944) has been the most effective and reliable in my testing, especially when delivered via Intune Platform Scripts
3. Allow natural reboots — no forced restart required; Microsoft estimates ~48 hours and one or more reboots
4. Monitor via Event 1808, the UEFICA2023Status registry value, and AvailableUpdates bit progression for confirmation

The key to success is thorough preparation, not the deployment itself. And while Microsoft has started automatic rollout for high-confidence device models, don't rely solely on that — keeping all deployment options evaluated and ready ensures your fleet is covered before the deadline.

10. References & Resources