How to manage the Secure Boot certificate update across your entire fleet

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.

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

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.

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.

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 — 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 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. 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

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.