Secure Boot 2023 Certificate Update

Microsoft is moving Windows devices to a new set of Secure Boot certificates — the Windows UEFI CA 2023, the Microsoft UEFI CA 2023 and a new 2023 Key Exchange Key (KEK) — together with a boot manager signed by the new CA. Athena shows exactly where each Windows machine is in that rollout, tells you what (if anything) stands in the way, and lets you start the update — or re-run Windows' own update task with Retry now — on one machine or many without scripting it yourself.

Where to find it#

Open a machine from the Agents list and choose Boot & Security in the agent detail view's left-hand navigation. Under the Boot & Security Information card you'll find the Secure Boot certificates (2023) card with its Update progress checklist, followed by Certificate update readiness and, when they apply, the Start certificate update and Retry now buttons.

Reading the status#

The Status badge is worked out from all the evidence the agent reports — the Windows servicing status, the update stage, the Secure Boot servicing events in the System log and the certificates actually present in the firmware — not from the Windows status value alone, which can lag behind what has really happened. The states, checked in this order, are:

When the status is Pending restart, users with the agents.restart permission get a Restart computer button right next to the badge. It asks for a delay (0–3600 seconds, 60 by default), warns anyone signed in, and then restarts the machine.

Card fields

If the firmware already contains the Windows UEFI CA 2023 but Windows hasn't started the update (for example, because a newer BIOS shipped it), the card notes 2023 CA already present in firmware. If the firmware couldn't be read, the firmware fields say Could not read firmware; on an agent older than 1.2.108 they say Not reported by this agent (needs agent 1.2.108 or later).

Expand Technical details for the raw values: the Windows-reported status, the raw update-stage and policy registry values, Managed Opt-In (opted in to Microsoft-managed rollout), High-Confidence Opt-Out (opted out of automatic high-confidence rollout), Can Attempt Update After (a wait period Windows is observing), the Hardware group (Microsoft rollout bucket) — devices with the same make, model and firmware share a group, and Microsoft releases the update group by group — and the full list of Firmware db Certificates.

Update progress checklist

Under the card fields, Update progress breaks the rollout into the four pieces Windows has to put in place, each marked Done, Not done or Unknown:

Once the Windows UEFI CA 2023 and the 2023 boot manager are both in place, the checklist adds the summary Windows boot is protected (2023 boot certificate and boot manager installed). followed by Still outstanding: and every step that is still Not done — typically the KEK on machines whose firmware refused it.

Update stages

The Update stage always agrees with the status badge: a failed or blocked update is never described as "in progress", whatever the raw value says. The raw value (shown on hover) only picks the wording within a status:

Secure Boot servicing events

Athena translates the Secure Boot servicing event IDs Windows logs so you never have to look up a bare number:

With agent 1.2.109 or later, the agent watches the System log for these events and sends a fresh Boot & Security inventory as soon as one is logged, so the card follows Windows on its own — for example, it moves from Pending restart to Updated shortly after the post-restart task finishes, without waiting for the next scheduled inventory. With agent 1.2.111 or later, the "update applied" events (1034–1045) count as progress, so a later KEK update applied replaces an older failure as the card's latest event instead of leaving the machine shown as Failed.

Certificate update readiness#

Below the card, Certificate update readiness lists every reason the update can or cannot start, each marked Blocker, Warning or Info, with what to do and who does it. Any blocker disables the start button.

The two firmware findings carry a Why this fix ? that explains the reasoning: Windows can only add the 2023 KEK when the firmware accepts it, and the key it writes ships in Windows' cumulative updates — so the firmware and Windows both need to be current, and Windows' Secure-Boot-Update task has to run, before the KEK goes in. Only if a current firmware still rejects it does the fix have to come from the manufacturer.

Starting the update#

What the card offers below the readiness list depends on the status:

Both buttons need the secureboot.update permission. To start the update:

1. Click Start certificate update (disabled, with the reason in the tooltip, while a blocker is listed).
2. Confirm in the Start the Secure Boot certificate update? dialog.
3. Athena sends the machine a fixed PowerShell script, run as SYSTEM through remote command execution (5-minute timeout). The script:
   • checks that the Windows scheduled task \Microsoft\Windows\PI\Secure-Boot-Update exists and is enabled — if not, it stops with FAILED and changes nothing;
   • suspends BitLocker on the system drive for one reboot, but only if protection is on;
   • sets AvailableUpdates to 0x5944 — Microsoft's documented trigger for IT-managed updates — and starts the Secure-Boot-Update task;
   • after about 10 seconds, prints the new update stage and the Windows status.
4. The card shows Update started - a reboot (usually two) is required to finish with a View command result link to the script's output.

Retry now#

Windows applies the certificates through its own scheduled task, \Microsoft\Windows\PI\Secure-Boot-Update, and normally only retries a failed step at the next restart. After you've updated the firmware or installed the latest Windows cumulative update, you don't have to wait: Retry now runs that task immediately. It's offered when the status is Failed, or In progress with an update queued that Windows hasn't acted on yet. The hint under the button reads After updating the firmware or Windows.

1. Click Retry now (disabled while a blocker is listed).
2. Confirm in the Retry the Secure Boot certificate update now? dialog.
3. Athena sends the machine a fixed PowerShell script, run as SYSTEM through remote command execution. The script:
   • checks that the Secure-Boot-Update task exists and is enabled — if not, it stops with FAILED and runs nothing;
   • prints the current AvailableUpdates value, then starts the task;
   • waits up to 90 seconds for the task to finish (if it's still running, its result shows in the next inventory);
   • reports the task state, LastRunTime, LastTaskResult, the new AvailableUpdates value and the Windows status.
4. A toast confirms Windows' Secure Boot task was started. and the card shows a View command result link to the script's output. The card updates by itself as soon as Windows logs progress.

Unlike Start certificate update, Retry now never changes AvailableUpdates (so it can't queue anything new), doesn't touch BitLocker and never restarts the machine. If the run applies the remaining certificates, the status moves on to Pending restart or Updated on its own.

Permissions#

secureboot.update is separate from the general commands.execute permission: it only allows these two fixed scripts, so you can let operators run the certificate update without letting them run arbitrary scripts. See Roles & Permissions. Each start is recorded in the audit log as a command execution labelled Secure Boot certificate update, and each retry as Secure Boot certificate update retry.

Tracking the rollout fleet-wide#

These fields are available under the Security category wherever Athena builds a machine filter — dynamic collections, automatic tagging rules — and as columns in the report builder's Agents data source:

Typical uses:

• A dynamic collection SecureBootUpdateState = NotStarted as the target list for the next wave.
• A collection SecureBootRestartPending = True to schedule the finishing restarts.
• A report grouped by SecureBootBucketId with SecureBootUpdateState to see which hardware models are lagging.
• An automatic tag for SecureBootKekHas2023 = False machines whose last event was 1803, to hand to the hardware vendor for a firmware update.

REST API#

Each result has an outcome of Dispatched (with the commandId whose output shows what the script did), Blocked (with the blocking finding codes in reasons, e.g. SecureBootDisabled, KnownIssue, AlreadyUpdated), Offline, NotFound or Failed. In a bulk call, every machine that is ready and online is sent the script as a single command. Unlike the buttons, the API doesn't look at the status — only blockers and already updated stop it — so re-running either call from a script is harmless. Readiness findings that carry a Why this fix explanation return it in a help field.

# Start the certificate update on every machine in a list
$headers = @{ Authorization = "Bearer $token" }
$body = @{ agentIds = $agentIds } | ConvertTo-Json

$r = Invoke-RestMethod -Method Post `
  -Uri "https://athena.example.com:8443/api/agents/secureboot/update" `
  -Headers $headers -ContentType "application/json" -Body $body `
  -SkipCertificateCheck

$r.data | Select-Object hostname, outcome, reasons, commandId

Troubleshooting#

• The card says Not reported by this agent. Update the Windows agent to 1.2.108 or later (see Agent Binaries & Updates), then collect inventory. Legacy-BIOS and Linux machines never report it.
• Command result says FAILED: scheduled task … is missing or … is disabled. Windows can't apply the certificates without the Secure-Boot-Update task. Nothing was changed; restore or enable the task, then start again.
• Stuck on Pending restart. The update needs the restart (often two). After restarting, give Windows' task a few minutes to run; with agent 1.2.109+ the card updates itself when the next event is logged.
• Event 1795, 1796 or 1803 and KEK 2023 in Firmware: No. The firmware refused the new KEK. If the readiness list says the firmware is old, install the manufacturer's latest BIOS/UEFI update, then install the latest Windows cumulative update and press Retry now — restarting alone won't fix it.
• Current BIOS, still rejected. Bring Windows up to date and press Retry now: the KEK can go in only once both the firmware and Windows are current and Windows' Secure-Boot-Update task runs. If the firmware still rejects it, contact the manufacturer's support for that model with the error shown in the finding.
• Retry result says The task is still running after 90 seconds. Nothing is wrong; the outcome appears with the next inventory (or sooner, as soon as Windows logs an event).
• Blocked with a Known Issue ID. Microsoft is deliberately holding the device model back. Don't force it; wait for a firmware or Windows fix.
• Result Offline. Nothing was sent. Start the update again when the agent is connected.