---
title: "Secure Boot Certificate User Guide"
slug: "secure-boot-certificate-user-guide"
updated: 2026-05-26T10:15:41Z
published: 2026-05-26T10:15:41Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.lakesidesoftware.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Secure Boot Certificate User Guide

## Overview

This DEX pack adds a **Secure Boot Certificate DEX Pack** dashboard to your SysTrack environment. The dashboard displays every Windows device in your fleet and its current state in the certificate update process.

The pack includes two components:

- **Daily status check** - runs automatically on every device to collect certificate status data and populate the dashboard. No action needed.
- **Remediation command** - backs up BitLocker keys and triggers the Microsoft certificate update. **Does not run automatically** - must be triggered by an administrator, either on-demand or via an optional schedule you configure.

## How This Feature Helps You

Microsoft Secure Boot certificates issued in 2011 are set to expire in 2026. All Windows devices that use UEFI Secure Boot require updated certificates; without them, devices may fail to boot or may lose trust for drivers and firmware updates. The roadmap for the expiration is as follows:

| Date | What Happens |
| --- | --- |
| June 24, 2026 | KEK CA 2011 expires - new certificate enrollment stops working |
| June 27, 2026 | UEFI CA 2011 expires - third-party drivers and firmware lose trust |
| October 19, 2026 | Windows PCA 2011 expires - Windows boot loader trust expires |

The Secure Boot Certificate DEX pack collects daily status from each client, tracks a remediation checklist, and can automatically trigger the certificate update on devices that have safely backed up their BitLocker recovery keys.

## Operational Scope and Safety

This pack does not perform any custom certificate operations. Specifically, it does not:

- Copy, write, or modify certificates
- Write to UEFI firmware
- Modify the boot configuration
- Force device reboots

Instead, the pack only invokes standard Microsoft‑provided mechanisms that an administrator could run manually.

## Microsoft‑Provided Actions Used

The pack performs the following actions:

- BitLocker key backup using built‑in Windows APIs (equivalent to Group Policy-based or manual administrative backup)
- Setting the `AvailableUpdates` registry value, the same value used by Windows Update
- Starting Microsoft’s Secure‑Boot‑Update scheduled task, which is the same task triggered by Windows Update

All remaining steps - including certificate staging, firmware commit, and boot manager updates - are handled entirely by Microsoft Windows and the device firmware.

This implementation follows Microsoft’s official deployment guidance as documented in [KB5025885](https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d).

## How to Use the Dashboard

In the dashboard list, go to **Secure Boot Certificate DEX Pack**.

The **Overall Progress** pie chart and the **Systems by Group and Update Stage** table show Windows devices and their current status.

![](https://cdn.document360.io/87d11426-6b1f-4b19-b593-b71e55a81af3/Images/Documentation/image(357).png)

| Status | What It Means | What To Do |
| --- | --- | --- |
| Pending Inventory - No Data | Device hasn't reported yet | Wait for the next daily collection cycle (up to 24h) |
| Not Applicable - Legacy BIOS | Device doesn't use UEFI Secure Boot | Nothing - device not affected by the certificate expiry |
| Not Applicable – Secure Boot Disabled | The device uses UEFI firmware, but Secure Boot is turned off. The Microsoft Secure Boot certificate update does not apply unless Secure Boot is enabled. | Nothing - device not affected by the certificate expiry. However, you may need to investigate why secure boot is disabled on a device. See also the [Secure Boot Disabled](/docs/secure-boost-disabled) sensor. |
| Step 1/8 - BitLocker keys need backup | BitLocker is enabled but no recovery key backup to Azure AD or Active Directory has been recorded. The Collection Extension attempts this automatically on every run - a machine stuck here has an underlying AD/AAD issue. | Investigate the machine's AD/AAD connectivity and permissions. Check that the device is properly joined (AAD or domain), that it can reach the relevant endpoints, and that the relevant Group Policy / Intune policy allows recovery key backup. |
| Step 2/8 - Secure Boot update needs to be triggered | Keys are backed up, ready for cert update | Run the remediation command to trigger the update |
| Step 3/8 - Waiting for task success confirmation | Update triggered, waiting for the task to complete | Wait - Microsoft's Secure-Boot-Update task runs automatically every 12 hours |
| Step 4/8 - Waiting for 2023 certs to be staged to UEFI | New certificates are staged, but not yet applied | Device needs a reboot to apply the certificates |
| Step 5/8 - Reboot needed to apply certs to firmware | Certificates need firmware commit | Schedule a reboot during the next maintenance window |
| Step 6/8 - Reboot needed to update boot manager | Boot manager needs to switch to 2023 chain | Schedule a reboot (often completes in the same reboot as step 5) |
| Step 7/8 - Waiting for boot manager update confirmation | Almost done, waiting for final verification | Wait - completes automatically after the reboot |
| Step 8/8 - Complete | All certificates updated, device is protected | Nothing - no further actions needed for this device |
| Stalled - Firmware blocked (OEM update needed) | Windows reports the cert update as done, but the firmware never committed the new 2023 KEK. The 2011 KEK is still active and will expire. For more info, see [When Secure Boot certificates expire on Windows devices](https://support.microsoft.com/en-us/topic/when-secure-boot-certificates-expire-on-windows-devices-c83b6afd-a2b6-43c6-938e-57046c80c1c2). | Update the device's BIOS/UEFI firmware to the latest vendor version, then re-run the **SecureBoot Remediation** action. Group by Model to identify affected hardware lines. |

### Systems by Group and Update Stage

The table includes the following information:

- System name
- Model
- Days since last seen
- Update status and days since last change
- Days to Microsoft certificate expiry: the red color means the Microsoft certificate is close to expiring or already expired.
- Microsoft certificate
- Days to OEM certificate expiry: the red color means OEM certificates are expired and require a BIOS update from the device manufacturer.
- OEM certificate
- Update error (see [Troubleshooting](/documentation/docs/secure-boot-certificate-user-guide#troubleshooting))

![](https://cdn.document360.io/87d11426-6b1f-4b19-b593-b71e55a81af3/Images/Documentation/image(354).png)

### Selected System Details

Select a device name to view detailed information, including timestamps for each step, which steps SysTrack completed, which steps Microsoft or firmware completed, and any error messages.

![](https://cdn.document360.io/87d11426-6b1f-4b19-b593-b71e55a81af3/Images/Documentation/image(356).png)

### Filters and Coverage Indicators

- Use the **Group** filter to narrow the data displayed in both the chart and the table.
- Use the **Step** filter in the table to focus on devices at a specific stage of the update process.

The dashboard also shows how many devices are covered by pack actions:

- **SysTrack BIOS Check**: Number of systems where SysTrack checked the Secure Boot state without requiring local BIOS access.
- **SysTrack BitLocker Backup**: Number of systems where SysTrack backed up BitLocker recovery keys. SysTrack checks the event log and backs up keys only when no prior backup exists, preventing duplicate work and ensuring recovery readiness.
- **SysTrack Repair**: Number of systems where SysTrack triggered the Microsoft Secure Boot update by setting the required registry values and starting the built-in Windows task without any technician or user involvement.

![](https://cdn.document360.io/87d11426-6b1f-4b19-b593-b71e55a81af3/Images/Documentation/image(355).png)

### Why the Pack Backs Up BitLocker Keys First

Under normal conditions, the certificate update and reboot complete without BitLocker issues. However, firmware errors, power loss, or hardware-specific issues can cause BitLocker to prompt for a recovery key after reboot.

As a precaution, the pack backs up all BitLocker recovery keys to Microsoft Entra ID or Active Directory before triggering the update, ensuring recovery keys are always available.

## Recommended Workflow

Follow these steps to get your entire fleet updated before the June 2026 deadline:

1. Wait 24 hours after deployment for the first collection cycle to complete. The dashboard will populate with status data from all devices.
2. Review the dashboard. Use the "All Systems" Group filter to get a fleet-wide overview. Check how many devices are at each step.
3. Run remediation. You have two options:
  1. On-demand**:**Go to **Prevent***>***Tools**, select the **SecureBoot Needs Remediation** group from the dropdown, then click **Take Action**. In the dialog, select **Automations**, then navigate to **Security > SecureBoot Remediation**. Set Run Mode to **Run Silently** and click **Run**.
  2. Scheduled (optional)**:** See [Optional: Automated Remediation Schedule](/documentation/docs/secure-boot-certificate-user-guide#optional-automated-remediation-schedule) below. The remediation triggers the Microsoft certificate update. This is safe - the script refuses to trigger the update until all BitLocker keys are confirmed as backed up.
4. Wait for steps 3-4 to complete automatically. The Microsoft scheduled task processes the certificate update within 12 hours. The daily status check will pick up the progress.
5. Schedule reboots for devices at step 4-6**.** After the certificates are staged, at least one reboot is needed for the firmware to apply them. Coordinate reboots during your normal maintenance windows. The pack does not force reboots.
6. Monitor until all devices reach step 8. Use the stage filter to find stragglers. Devices that stay stuck may have firmware issues - check the **Update Error** column.
7. Handle OEM cert warnings separately**.** Red values in the **Days to OEM Cert Expiry** column mean a vendor certificate (for example, Dell KEK) is expired. This requires a BIOS update from the device manufacturer - SysTrack cannot fix OEM certs. If the OEM has shipped a replacement cert via BIOS update, the expired cert is automatically skipped and the column shows the replacement's expiry instead.

## Optional: Automated Remediation Schedule

Instead of running remediation manually each time, you can set up a Tool Schedule that automatically remediates devices. This is optional - the on-demand approach via **Prevent > Tools** works fine for smaller fleets.

To set up the schedule, add a new Tool Schedule entry to the existing **SecureBootCert** role with these settings:

| Tool Type | Automation |
| --- | --- |
| When sensor is triggered | Every Eight Hours |
| Perform Automation | SecureBoot Remediation |
| Run Mode | Run Silently |
| Run On | Active |
| Minimum Interval | 10 minutes |
| Execute Once | No |
| Only run tool on group of systems | SecureBoot Needs Remediation (checked) |

This runs the remediation, but only on devices in the **SecureBoot Needs Remediation** group. As devices complete the process, they drop out of the group automatically and stop receiving the automation. The remediation is safe to run repeatedly - it checks the current state and only acts when needed.

## What SysTrack Does vs. What Microsoft Does

| Steps 1-3 (SysTrack) | Steps 4-7 (Microsoft / Firmware) |
| --- | --- |
| - Backs up BitLocker recovery keys - Sets the AvailableUpdates registry value (same as Windows Update) - Starts Microsoft's own Secure-Boot-Update scheduled task | - Writes 2023 certificates to UEFI store - Commits certificates to firmware on reboot - Switches boot manager to 2023-signed version - Verifies completion |

## Troubleshooting

| Situation | Cause | Action |
| --- | --- | --- |
| Device stuck at step 1 | BitLocker key backup failed (no AAD/AD connectivity?) | Check network connectivity, AAD join status, or AD computer object |
| Device stuck at step 2-3 | Secure-Boot-Update task not found or disabled | Verify the device has a recent Windows cumulative update installed |
| Device stuck at step 4-6 | Waiting for reboot | Schedule a reboot - the update cannot proceed without one |
| **Update Error** column shows a message | Firmware issue - often VMware VMs or old hardware | Check the error text. Event 1803 = missing OEM PK-signed KEK (unfixable by script). Event 1795 = firmware error (OEM BIOS update needed) |
| OEM cert expired (red), no successor | Device hasn't received a BIOS update with new OEM certs | Deploy a BIOS update from the device manufacturer (Dell, HP, Lenovo) |

## References

- [Microsoft: Secure Boot playbook for certificates expiring in 2026](https://techcommunity.microsoft.com/blog/windows-itpro-blog/secure-boot-playbook-for-certificates-expiring-in-2026/4469235)
- [Microsoft: Registry key updates for IT-managed Secure Boot updates](https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d)
- [Microsoft: Secure Boot troubleshooting guide](https://support.microsoft.com/en-us/topic/secure-boot-troubleshooting-guide-5d1bf6b4-7972-455a-a421-0184f1e1ed7d)
- [Microsoft: Enterprise Deployment Guidance for CVE-2023-24932](https://support.microsoft.com/en-us/topic/enterprise-deployment-guidance-for-cve-2023-24932-88b8f034-20b7-4a45-80cb-c6049b0f9967)
- [When Secure Boot certificates expire on Windows devices](https://support.microsoft.com/en-us/topic/when-secure-boot-certificates-expire-on-windows-devices-c83b6afd-a2b6-43c6-938e-57046c80c1c2)