# How to manage the Secure Boot certificate update across your entire fleet ![Author](https://www.manageengine.com/ems/images/tools/employee/raghav-dp.png) **Raghav S** Last Updated: 22 May, 2026 7 Min Read The June 2026 Secure Boot certificate deadline isn't resolved by pushing a registry key. The UEFI CA 2023 migration is a sequenced workflow with multiple criteria like checking device readiness, firmware dependencies, coordinating reboots, and per-device confirmation. Teams that skip steps or trigger migration blind end up with errors they can't easily trace and a compliance posture they can't verify. This article covers the correct execution order, common failure modes, deployment method tradeoffs, and how to automate the Secure Boot certificate update across Windows at fleet scale. ## The migration sequence The Secure Boot upgrade comes with a set of prerequisites that need to be followed before you get started with the actual migration process. ### Inventory and segment devices Before touching anything, it is important to understand which devices are eligible for this migration: - Devices running on Legacy BIOS and those that have Secure Boot disabled, since they cannot migrate at all - Devices that need OEM firmware updates - Devices that are capable and idle (with Secure Boot 2011 certificates) - Devices that have already migrated Each segment has a different next action, and running them all through the same trigger wave produces failures. ### Apply OEM firmware updates A device with outdated firmware could fail mid-migration, often with errors that look like OS issues but trace back to firmware. Get OEM updates deployed before the migration trigger is set on any device. ### Confirm Secure Boot enabled status For devices in the capable-and-idle segment, confirm the following: - `Confirm-SecureBootUEFI = True` - `WindowsUEFICA2023Capable = 2` - Windows diagnostic data at "Required" level minimum Devices that don't clear all three go back to the remediation queue. ### Deploy the update Run the following on each target device — the first command initiates the certificate and boot manager deployment on the device. The second command causes the task that processes the AvailableUpdates registry key to run right away. ```powershell reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" ``` Allow 48 hours and at least one reboot before checking status. ### Manage reboots Expect one to two reboots. After the first, re-run the Secure-Boot-Update task, a second reboot may be needed to finalize certificate installation. A device that has rebooted once is often still InProgress, not done. ### Confirm completion Migration is complete only when `UEFICA2023Status = Updated` and Event ID 1808 appears in the System Event Log. Anything short of that is an open item. Event ID 1801 usually means certificates were not applied, and you may need to check the prerequisites again. Event ID 1795 indicates an error handing off certificates to firmware, which almost always points to an OEM firmware issue. ## Common failure points | Symptom | Likely Cause | Action | |---|---|---| | AvailableUpdates stuck at 0x4104 | OEM firmware gap | Apply OEM update, re-trigger | | UEFICA2023Error key present | Certificate deployment failed | Check firmware, review Event Log | | Event ID 1795 | Certificate handoff to firmware failed | OEM firmware update required | | Event ID 1801 | Certificates not applied | Verify prerequisites | | InProgress after 48h+ | Stalled migration | Investigate firmware, force second reboot | One consistent pattern: most failures trace back to OEM firmware that wasn't updated before triggering. The inventory and firmware steps aren't optional groundwork — they're what determines whether the trigger succeeds. **Warning:** Re-enabling Secure Boot on a disabled device can reset certificate databases to factory defaults. On BitLocker-enabled devices, this triggers recovery key prompts. Don't toggle Secure Boot as a troubleshooting reflex. ## Deployment options for migrating devices Microsoft suggests a few deployment methods for organizations to work through this Secure Boot migration. - **Registry key / PowerShell:** This works across all supported Windows versions and management platforms. The problem is that there's no state tracking — once the key is pushed and the task started, PowerShell has no native way to tell you which devices actually received it, whether the scheduled task ran, or whether migration completed. - **Group Policy:** This maps AvailableUpdates to the "Enable Secure Boot certificate deployment" policy and is consistent at domain scale. It works only for domain-joined devices, missing out on remote workers off VPN, non-domain-joined machines, and workgroup systems. State tracking after the update is also an issue. - **Windows Configuration System (WinCS) APIs:** A command-line path for environments with specific tooling requirements, but the scope is limited to domain-joined, Windows 11 23H2 and later devices only. Any device below that OS version or outside the domain needs a separate deployment method. **Warning:** Do not mix deployment methods on the same device. Microsoft explicitly advises against it. ## Automate the migration at scale: With ManageEngine DEX Manager Plus' pre-built workflow Most tools stop at the registry key, and manual efforts require you to execute these commands at a device level individually. They also fail to provide status once you've deployed the migration task. DEX Manager Plus addresses the migration execution problem through its [SecureBoot upgrade workflow](https://www.manageengine.com/digital-employee-experience/extensions.html?page=secureboot_upgrade) — a purpose-built automation layer that handles the full migration sequence, not just the registry trigger. Before touching any device, the workflow validates readiness. The [firmware readiness sensor](https://www.manageengine.com/digital-employee-experience/extensions.html?page=firmware_readiness) collects the data required to qualify devices, ensuring that those which don't meet the prerequisites are held in a separate queue rather than triggering a migration that will fail. For devices that pass validation, the workflow sets the AvailableUpdates registry key to `0x5944` and starts the Secure-Boot-Update scheduled task through its [SecureBoot update script](https://www.manageengine.com/digital-employee-experience/extensions.html?page=secureboot_update). It also initiates reboot sequencing with user confirmation and delay handling, ensuring users are kept informed and devices aren't forced to restart mid-session without warning. After the first reboot, the workflow re-runs the scheduled task to handle the second phase of certificate deployment. Throughout execution, DEX Manager Plus monitors `UEFICA2023Status` and `UEFICA2023Error` per device, surfacing errors with context rather than leaving IT teams to hunt through individual event logs. Devices that stall in `InProgress`, surface a `UEFICA2023Error`, or log Event ID 1795 are flagged automatically for investigation, with enough context to diagnose the failure without opening a remote session. Completion is confirmed per device by verifying that `UEFICA2023Status` reached `Updated` — not by inferring from the absence of errors. The workflow closes only when that state is confirmed. The full loop runs automatically — validate, execute, reboot, and confirm. IT teams can see fleet-wide migration status in real time: how many devices are complete, how many are in progress, how many have errors, and what those errors are. Manual intervention is only required for the edge cases that genuinely need it. That's the difference between setting a registry key and automating a migration. ## Meet the author ![Author Image](https://www.manageengine.com/ems/images/tools/employee/raghav-dp.png) ### Raghav S Raghav is a product marketer at ManageEngine, specializing in UEMS. With experience in enterprise marketing and a focus on digital employee experience, he explores how endpoint performance, user experience, and proactive IT help teams resolve issues before they impact users — improving productivity and reducing digital friction.