What Does Windows Security Mean by an Older Boot Trust Configuration?

A Windows 10 or Windows 11 PC can pass every Secure Boot check its owner knows how to run and still be trusting certificates that expired in June 2026. msinfo32 reports Secure Boot State: On. Nothing fails to start. And Windows Security, under Device security → Secure Boot, shows a yellow badge whose sentence opens with those same two words.

In the ordinary case the fix is one line: install the latest Windows updates and restart. What makes it worth more is that six status messages can appear in that spot, all six begin “Secure Boot is on”, and only one is fixed by patching. Two mean do nothing. Two point to Microsoft's guidance rather than anything the update screen can do. One is not a software problem.

The badge colour does not separate those cases: four of the six carry the same yellow warning. The text after the comma is what distinguishes them.

Start Here: Read the Sentence, Not the Badge

1. Open Windows Security → Device security → Secure Boot. Copy the sentence shown there.
2. Match it against the six below. Several share a first clause, so match the whole thing, including any second and third sentence.
3. If no Secure Boot section appears, the UI has not reached the device. Microsoft lists it as applying to Windows 11, Windows 10, Windows Server 2025, Windows Server 2022 and Windows Server 2019, rolling out from April 2026. Fall back to the registry read below.

One distinction settles most of the confusion. Whether Secure Boot is enforcing, and which certificates it trusts, are separate settings.

This article is the top right cell: enforcement on, certificate set old — the only combination that passes every quick check and is still losing something.

The Six Status Messages, Sorted by What They Ask of You

One message means patch and restart

The common case, and the only one a user action fixes:

“Secure Boot is on, but your device is using an older boot trust configuration that should be updated.”

Microsoft's stated action is “Make sure your device has the latest Windows updates installed. Restart if prompted.” If updates are paused, resume them; if a restart is pending, take it. Deferring the restart leaves the device here no matter how many updates download.

Two messages mean do nothing

Finished: “Secure Boot is on and all required certificate updates have been applied. No further certificate changes are needed.” Stated action: “No action is needed.”

And the one most likely to be misread as a fault:

“Secure Boot is on, but your device is affected by a known issue. To reduce risk, Secure Boot certificate updates are temporarily paused while Microsoft and partners work toward a supported resolution. The update will resume automatically once resolved.”

A deliberate hold, not a failure. Action: “No action is needed. The certificates update will resume automatically once the issue is resolved.” No override is documented for home devices.

Two messages send you to Microsoft's guidance, not to a fix

The first is the trap, because its opening sentence is word-for-word identical to the patch-and-restart message:

“Secure Boot is on, but your device is using an older boot trust configuration that should be updated. There is not yet enough data to classify your device for automatic update. Visit the link below for more information.”

Reading only the first line, one concludes that patching clears it. The second says otherwise. Microsoft's stated action is “Your device might need additional validation before the update can proceed automatically. Visit aka.ms/getsecureboot for more information.”

The second, and the only one marked with a red stop icon rather than a yellow badge:

“Secure Boot is on, but this device can no longer receive required updates for the Windows boot experience.”

The stated action is “Your device is still using an old certificate after the expiration dates. Visit aka.ms/getsecureboot for guidance.”

One message is not a software problem

“Secure Boot is on, but your device does not support the automated Secure Boot certificate update due to hardware or firmware limitations. Contact your device manufacturer for assistance.”

Microsoft's stated action is exactly that: “Contact your device manufacturer for assistance.” Note the message names two possible limits, hardware or firmware, without saying which applies to a given device. Microsoft routes both to the manufacturer rather than to any update.

Reading the Same Status Without the Security App

Microsoft documents registry values reporting update state, at:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

Two of them answer the question directly.

• UEFICA2023Status (REG_SZ) — the deployment status indicator. Microsoft's description, with the definition it attaches to each value: “Reflects the current state of the Secure Boot key update on the device. It will be set to one of the following text values: NotStarted: The update has not yet run. InProgress: The update is actively in progress. Updated: The update has completed successfully.” It adds that “Initially the status is NotStarted. It changes to InProgress once the update begins, and finally to Updated when all new keys and the new boot manager have been deployed. If there is an error, then the UEFICA2023Error registry value is set to a non-zero code.”
• UEFICA2023Error (REG_DWORD) — “This value remains 0 on success. If the update process encounters a fault, UEFICA2023Error is set to a non-zero error code corresponding to the first error encountered.” UEFICA2023ErrorEvent holds the event ID Windows used to report it.

One value in the same key looks like it answers the question and does not. Microsoft's note on WindowsUEFICA2023Capable is explicit: “For reference only - do not use this key when getting status on Secure Boot updates. Use the UEFICA2023Status key instead.”

A boundary worth respecting. These values come from a document titled for IT-managed devices, and the parent path holds write values driving deployment — AvailableUpdates, controlling “which Secure Boot update actions to perform on the device”, plus opt-in and opt-out values whose descriptions begin “For enterprises”. On a personal machine, read UEFICA2023Status and stop.

Which Certificate Expired, and What Each One Signs

Microsoft's table has four rows but only three expiring certificates. One splits into two replacements, so it appears twice.

• Microsoft Corporation KEK CA 2011 — expired 24 June 2026. In the KEK, “Signs updates to DB and DBX”. Replaced by Microsoft Corporation KEK 2K CA 2023.
• Microsoft UEFI CA 2011 — expired 27 June 2026. Held in the DB. The third-party certificate, replaced by two: Microsoft UEFI CA 2023, which “Signs third-party boot loaders and EFI applications”, and Microsoft Option ROM UEFI CA 2023, which “Signs third-party option ROMs”.
• Microsoft Windows Production PCA 2011 — expires 19 October 2026. In the DB, “Used for signing the Windows boot loader”. Replaced by Windows UEFI CA 2023.

The ordering is worth noticing: the KEK, whose documented job is signing updates to the DB, expired three days before the third-party DB certificate it would be used to update. Microsoft gives the roles and dates but not what that sequence implies for a device that missed the KEK update, and this article does not guess.

What the Calendar Says, and What It Does Not

Microsoft publishes the expiry dates but not what they amount to in calendar terms. The arithmetic, measured from 1 September 2026:

• 69 days since Microsoft Corporation KEK CA 2011 expired.
• 66 days since Microsoft UEFI CA 2011 expired.
• 48 days until Microsoft Windows Production PCA 2011 expires on 19 October 2026.
• 117 days from the first expiry to the last — a staggered set of dates, not one deadline.

What those dates do not tell you is when a given device gets updated. The tempting next step is a countdown of monthly releases: 8 September and 13 October 2026 are the second-Tuesday releases before 19 October, the next being 10 November. Nothing sourced here supports that countdown. No Microsoft document consulted ties certificate delivery to the monthly cadence, and Microsoft's page for home users, businesses, and schools with Microsoft-managed updates says only that they arrive “through regular Windows Update channels”, naming no delivery cadence.

What the registry documentation does describe is a staged rollout. Of BucketHash it says: “BucketHash identifies the deployment bucket that a device is assigned to as part of the Secure Boot certificate rollout. The value is a hash derived from device characteristics and is used to group devices with similar firmware and platform attributes for staged deployment and risk management.” And one of the six status messages says “There is not yet enough data to classify your device for automatic update.” Neither passage gives a delivery date for any particular machine. Treat 8 September and 13 October as the next scheduled release dates, and nothing more than that.

One more timing point: that same page says “The new certificate updates will continue gradually through June 2026”. It carries a 12 January 2026 stamp, and that window has closed. A device still reading “older boot trust configuration” is not simply waiting its turn in that schedule.

What Actually Stops Working

Worth getting right, because the wrong version — “your PC will not boot” — circulates widely and is not what Microsoft says:

“Devices that haven't received the newer 2023 certificates will continue to start and operate normally, and standard Windows updates will continue to install. However, these devices will no longer be able to receive new security protections for the early boot process, including updates to Windows Boot Manager, Secure Boot databases, revocation lists, or mitigations for newly discovered boot level vulnerabilities.”

Both halves matter. The machine keeps working and keeps patching; what it loses is the ability to accept fixes to the part that runs before Windows.

On third-party software, Microsoft's page on when the certificates expire is conditional, and the condition should be carried across rather than dropped: “Some third-party components that rely on Microsoft Secure Boot trust may fail to update if they require newer certificate entries.” That is may, and if — not a statement that third-party boot loaders will break.

Failures That Are Not This PC

The known-issues page lists three items, all virtual machines or managed devices.

• Azure Trusted Launch Gen2 VMs, unresolved. “On some Azure Trusted Launch (Gen2) virtual machines, Secure Boot certificate updates might not complete when attempting to update the Key Exchange Key (KEK).” Event ID 1795 appears in the System log. Microsoft's position: “At this time, there is no required customer action. A resolution that addresses this issue will be delivered through future updates.”
• Hyper-V VMs, resolved. The same Event ID 1795, with a firmware error reading “The system firmware returned an error: The media is write protected”. Fixed in the 10 March 2026 updates; Windows Server 2025 followed on 14 April 2026. The condition attached to that fix is easy to miss and decides whether it works: “To resolve this issue, you must deploy the fix on both the host and the guest.” Microsoft adds, “If you are managing the host Hyper-V server, install the latest Windows updates on both the guest and the host.” Patching the guest alone does not clear it. Azure-managed hosts and Azure Local have their own minimum update levels.
• Intune on Windows Pro, resolved. Policies blocked with Error Code 65000 and a log entry reading POLICYMANAGER_E_AREAPOLICY_NOTAPPLICABLEINEDITION. Windows 11 v23H2 needs KB5082052 or later.

Note what is absent: no entry for a physical consumer PC. Not proof such cases do not exist, but a home machine stuck at NotStarted matches no documented defect, and filing it against one of the three above sends the search the wrong way.

What Could Not Be Verified

A PowerShell one-liner that dumps the Secure Boot DB variable and searches it for Windows UEFI CA 2023 circulates widely, including in community threads on Microsoft's own Q&A site. It is not used here, because it could not be traced to a Microsoft support document, release note or specification — only to community posts, forums and blogs. The documented status source is UEFICA2023Status.

When This Doesn't Apply

• Secure Boot is off, or unsupported. All six messages begin “Secure Boot is on”; with it disabled, none of this appears.
• The device is managed by an employer or school. Rollout there runs on Intune, Group Policy or an update server. Reading status is fine; changing deployment values is not a user-side fix.
• The device is a virtual machine or a hosted Windows desktop. Azure Trusted Launch Gen2 and Hyper-V guests have their own documented behaviour, and patch-and-restart is not the path for the unresolved Azure case. Repeated readings of Microsoft's known-issues page returned different lists of affected products, so the full scope is not settled here.
• The concern is a Linux dual-boot or a third-party option ROM. Those ride the third-party certificate line, which splits into two 2023 replacements. Microsoft's language there is conditional, and shim behaviour on a given distribution is outside anything sourced here.
• The reading is after 19 October 2026. Every day count above is measured from 1 September 2026.
• The Secure Boot section is missing from Windows Security. The UI began rolling out in April 2026; its absence says nothing about certificate state. Use the registry value.

The Check, in Order

1. Windows Security → Device security → Secure Boot. Read the entire status.
2. If it mentions a known issue or says all updates have been applied — stop. Nothing to do.
3. If it says only that the device uses an older boot trust configuration — install pending updates, restart, re-read.
4. If it also says there is not enough data to classify the device, or that it can no longer receive required updates — follow Microsoft's linked guidance, not another patch cycle.
5. If it cites hardware or firmware limitations — contact the device manufacturer.
6. If the section is absent, read UEFICA2023Status under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing. Microsoft defines the three values as: NotStarted, the update has not yet run; InProgress, it is actively in progress; Updated, it has completed successfully. Check UEFICA2023Error for a non-zero value.
7. Re-check the status after the 8 September and 13 October 2026 releases, the two scheduled release dates before 19 October. Delivery is not promised on either; they are simply the next points worth another look.

The habit that matters is refusing to stop reading at the comma. Four of the six say “Secure Boot is on, but…” — and what follows is the diagnosis.

All quoted text is from Microsoft Support: “Windows Secure Boot certificate expiration and CA updates” (18 May 2026); “When Secure Boot certificates expire on Windows devices” (10 February 2026); “Secure Boot certificate update status in the Windows Security app” (3 April 2026); “Registry key updates for Secure Boot: Windows devices with IT-managed updates” (20 March 2026); “Windows devices for home users, businesses, and schools with Microsoft-managed updates” (12 January 2026); and “Known issues and resolutions for Secure Boot certificates updates” (14 July 2026). Day counts are calculated here, measured at 1 September 2026.