Microsoft's recent support briefing on the
High Confidence Database pulls back the curtain on how Windows is phasing a large-scale Secure Boot certificate rotation, explaining the data-driven, device-class approach Microsoft uses to decide which systems receive automated Secure Boot certificate updates and why that matters to administrators now.
Background
UEFI Secure Boot is a firmware-level trust model that defends the system’s earliest execution environment by validating signatures on bootloaders, option ROMs, and other pre‑OS components. Those validation chains depend on a small set of firmware-stored certificates and keys; when Microsoft announced a generational refresh of its Secure Boot certificates (a “2023 CA” family to replace long‑lived 2011-era anchors), it also warned that the original 2011 certificates would begin expiring in mid‑2026—creating a time‑bound operational requirement for fleets worldwide. This lifecycle change has driven Microsoft to build an OS‑side mechanism for safely applying new certificate material to firmware across diverse hardware.
The technical and operational challenge is straightforward in principle but messy in execution: firmware implementations and update behavior vary wildly across OEMs, platform vendors, and firmware versions. To avoid causing boot or compatibility failures while still ensuring continuity of boot-time security, Microsoft is using empirical update telemetry to guide a cautious, phased rollout. The High Confidence Database is the product of that approach.
What the High Confidence Database is — and what it isn’t
The concept, in practical terms
- The High Confidence Database is a dataset Microsoft compiles from observed servicing and reliability signals to identify groups of devices that have demonstrated successful firmware-side updates when presented with the new Secure Boot certificates. Rather than target devices individually, Microsoft groups systems into device buckets that share hardware, firmware, and platform attributes and measures real‑world update outcomes at the bucket level.
- When a bucket reaches the update success criteria, Microsoft marks it as eligible for OS-delivered certificate updates via monthly cumulative updates. This enables a phased, risk‑aware deployment: devices that have already demonstrated safe outcomes receive automated updates, while others are deferred pending more evidence or vendor fixes.
What the database does not provide
- It is not a per‑device guarantee or push-button inventory: Microsoft does not publish confidential telemetry counts per individual device nor does it claim universal coverage across every SKU. The dataset is representative of where Microsoft has sufficient observed data to evaluate update readiness, and the absence of a device from the published buckets is a signal that additional administrator attention will likely be required.
- The human-readable repository Microsoft publishes is intended for inspection and analysis, not as the direct mechanism driving OS update behavior. Microsoft maintains a separate, servicing‑consumable form of the data for Windows to act on. The GitHub view is transparency for admins and OEMs, not the update payload used by Windows itself.
How Microsoft determines “confidence”
Device buckets and telemetry signals
Microsoft’s decision to include a device bucket in the High Confidence Database relies on observed servicing evidence: successful application of OS-side update logic, firmware acceptance of the new certificates (DB/KEK/DBX changes), and the absence of adverse events tied to the certificate install flow. Buckets are defined by a set of attributes (OEM, model family, firmware build, reported firmware variables) so behavior can be evaluated at scale rather than per system.
Event signals and registry indicators
Windows surfaces the bucket classification and update outcomes via a set of Secure Boot update events (Event IDs such as
1801, 1802, 1803, and 1808) and through a
ConfidenceLevel registry key for systems using IT‑managed updates. Administrators can consume these events via their existing logging pipelines to verify whether a device is in a high‑confidence bucket or whether an update attempt returned firmware-level error codes requiring follow-up. Microsoft documents these events and recommended log queries for enterprise telemetry pipelines.
Confidence classifications — what each status means
Microsoft uses simple, operational classifications to guide behavior and messaging:
- High Confidence: Devices in this group have demonstrated successful update outcomes in the field and are included in cumulative updates that will automatically enrol the new certificate material.
- Temporarily Paused: Microsoft and partners have identified a known issue affecting the update on these devices. Updates are paused while remediation (often a firmware update) is worked on; admins should look for event 1802 for details.
- Not Supported — Known Limitation: These devices do not support the automated OS-side certificate update path because of hardware or firmware limitations. No automatic resolution is available today; OEM firmware action may be required.
- Under Observation — More Data Needed: The device class is not blocked, but Microsoft has yet to observe sufficient successful updates to declare it high confidence; updates may be deferred pending more telemetry.
- No Data Observed — Action Required: Emitted when a device isn’t present in the database at all; automatic updates cannot be evaluated and administrator intervention is likely needed. Note that this classification is not part of the High Confidence Database but is generated by Windows when a device lookup fails.
How the database is published and consumed
Dual publication model
Microsoft publishes the database through two complementary channels:
- A servicing‑consumable format embedded in cumulative updates so Windows can make automated, on‑device decisions during normal monthly servicing. This is how the operating system learns which buckets are currently considered safe to update. The January 2026 cumulative packages already included subsets of high‑confidence targeting for some SKUs.
- A human‑readable representation hosted in Microsoft’s Secure Boot Objects repository on GitHub for inspection by admins, OEMs, and security teams. That repository is explicitly for transparency and analysis and is not the direct on‑device input used by Windows servicing. Administrators should use it to understand how device classes are grouped and to plan validation and remediation activities.
Where the updates appear (the real-world delivery path)
- The servicing path is closely tied to Microsoft’s monthly cumulative updates (the same servicing channel administrators already manage), and for many devices, the certificate payloads are applied during routine monthly maintenance once a device is in a high‑confidence bucket. Microsoft has already embedded targeting data in recent update packages to support early enrollments for qualifying devices.
- For systems that cannot receive an OS‑side update, OEM firmware updates or manual, vendor‑provided procedures will be the fallback path. Microsoft and OEMs have coordinated to provide firmware-based remedies for many affected SKUs, but coverage varies by vendor and model. Red Hat and other ISV guidance warns that virtualization hosts and non‑Windows OSes may also need platform work (for example, OVMF/edk2 updates on hypervisors) to keep VMs and alternative OS boot paths compatible.
Why this matters: the operational stakes
- If a device does not receive the new 2023 certificates before the 2011 certificates’ expirations, Microsoft warns the device will enter a degraded security state where it can no longer accept future Secure Boot updates delivered by Windows Update or may lose the ability to validate newer boot components. While most devices will continue to boot, they will progressively lose access to pre‑OS protections and revocation updates. That is why this migration is a caleal priority for administrators.
- The risk mix varies by environment. Consumer and broadly patched client devices are heavily represented in the telemetry that forms the database; servers, air‑gapped systems, IoT, and highly customized platforms are less represented and therefore more likely to need manual planning and intervention. Microsoft calls this out explicitly—lower representation does not equal lower support; it means the automated confidence signal is less certain.
How to check and triage: practical steps for IT teams
- Inventory: Identify which systems in your environment have Secure Boot enabled and which OEM/firmware versions they run. Use existing asset inventory and management tools to capture firmware release dates and model families.
- Monitor Windows event logs for Secure Boot update events (IDs 1795–1808) and extract the BucketId and Confidence fields where present. These events reveal whether a device was found in the High Confidence Database and whether an update succeeded, failed, or was paused. Microsoft documents how to interpret these events and includes example event payloads for automation.
- Check the ConfidenceLevel registry key on devices in IT‑managed update scenarios; Microsoft surfaces the classification here for scripted checks and enterprise telemetry.
- Validate on representative pilot hardware: perform staged rollouts using test rings, validate boot behavior (including PXE/WinPE and recovery media), and observe event telemetry for any firmware error codes. Firmware-level errors will be surfaced in the event payloads and must be correlated to OEM guidance.
- Plan fallback paths: for servers, air‑gapped devices, or vendor‑specialized platforms, expect manual firmware updates or OEM tools to be the primary path to install the 2023 certificates. Microsoft and OEMs have published lists and guidance for many supported devices; contact your vendor reps for specific remediation packages when needed.
- Document and automate: feed parsed event information into your SIEM or management platform to build dashboards for ConfidenceLevel, BucketId distributions, and update failure codes. This approach lets you spot classes of devices requiring vendor firmware work before the 2011 certificates expire. Community and forum reporting shows organizations that instrument these signals can detect problem buckets earlier and reduce last‑minute remediation.
Strengths of the High Confidence Database approach
- Empirical, safety‑first rollout: By qualifying groups using observed success signals, Microsoility of a large, indiscriminate firmware write that might brick or destabilize diverse devices.
- Scalability: Bucketing lets Microsoft reason about update behavior across millions of devices without requiring bespoke logic per SKU, enabling a controlled, repeatable process baked into existing cumulative updoft.com]
- Transparency and tooling: Publishing a human‑readable version on GitHub and surfacing deterministic event IDs and a registry key gives administrators the tools to detate issues with OEMs, rather than leaving behavior opaque.
- Multiple remediation channels: Where OS-side automation isn’t possible, OEM firmware updates remain a fallback—Microsoft and major OEMs have coordinated to provide firmware-level remediation for many at‑risk SKUs.
Potential risks, blind spots, and caveats
- Telemetry biases and under‑representation: Because Microsoft’s signals are strongest for consumer and broadly managed client devices, servers, IoT, and air‑gapped systems are typically under‑represented in the confidence signals. That means critical infrastructure teams must not assume automated enrollment and should plan conservative manual paths. Microsoft explicitly highlights this limitation.
- Firmware idiosyncrasies: Not all firmware behaves identically when receiving DB/DBX/KEK changes. Some platforms require a specific update order or an explicit firmware reset, and others may expose error codes that mean “manual intervention needed.” The event stream helps surface these conditions, but OEM coordination is often required to resolve them.
- Operational risk during large rollouts: Past cumulative updates that included new Secure Boot targeting data (for example the January 2026 servicing wave) showed the complexity of large-scale changes—some cumulative packages led to unrelated stability reports on particular hardware/driver combinations, reinforcing the need for conservative pilot rings and rollback plans. Public reporting about KB5074109 and KB5073724 shows administrators must treat each cumulative update as a testable change window, not a routine automatic patch.
- Unverifiable numeric claims: Microsoft provides classification states and example event payloads but does not publish per‑bucket device counts or precise thresholds used to declare “high confidence.” This means administrators must rely on the qualitative classification and local telemetry; any statements about the percentage of global devices in high‑confidence buckets are estimates unless the organization has its own telemetry proving otherwise. Treat such estimates with caution.
Real‑world signals from the field
Community conversation and incident threads show this migration is already an operational issue for many administrators. Forum posts and community reports describe:
- Early inclusion of confidence targeting in monthly cumulative updates and the need to instrument event logs to track rollout progress.
- Reports of vendor-specific behavior where firmware required manual activation or where option ROMs or drivers needed re-signing to keep compatibility after the new 2023 certificates were applied. These are the exact corner cases the High Confidence Database intends to catch before broad, automated enrollment.
- Examples of KB packages (notably the January 2026 cumulative set) that contained the first servicing mechanisms to start enrollments and that generated active discussion about pilot vs. broad deployment strategies. Those conversations underline how important pre‑production validation rings are as the rollout accelerates.
These community signals are consistent with Microsoft’s stated intent to be deliberate and evidence‑based; they also emphasize why administrators should treat the certificate rotation as a coordinated project, not a background update task.
Recommended runbook for administrators (concise)
- Perform a targeted inventory of Secure Boot‑enabled systems and sort by OEM/model/firmware date.
- Enable collection of Secure Boot update events (IDs 1795–1808) into your SIEM and build a dashboard for BucketId and ConfidenceLevel trends.
- Run staged pilots on representative hardware families and validate PXE, recovery media, and virtualization scenarios.
- For servers, offline systems, or OEM-specialized platforms, coordinate firmware updates with vendors and schedule maintenance windows well before the calendar expirations in mid‑2026.
- Where automated updates are not possible, plan manual certificate enrollment or OEM firmware application as the official fallback.
Final analysis — balancing security urgency and operational prudence
Microsoft’s High Confidence Database is a pragmatic answer to a real systems‑management problem: rotating root certificates that live in firmware across a sprawling, heterogeneous install base. The approach favors safety—using real-world evidence and phased inclusion to limit the blast radius of firmware writes—while exposing machine-readable signals and a public, human‑readable dataset for inspection. That balance is appropriate given the potential cost of failure: misapplied firmware changes can render devices unbootable or break critical pre‑OS subsystems.
That said, the approach is only as effective as the telemetry and vendor follow‑through that underpin it. Environments with limited telemetry, offline devices, or a high concentration of legacy firmware cannot rely on automated enrollment and must treat the migration as a discrete, high‑priority operational project. The community experience with early cumulative updates also reinforces the need for careful pilot rings and rollback plans. Microsoft’s public guidance and the event‑based telemetry provide the necessary levers for enterprise teams to execute that plan, but
action—inventorying, testing, and vendor coordination—remains the administrator’s responsibility.
Conclusion
The High Confidence Database is Microsoft’s attempt to walk the narrow line between aggressive security maintenance and real-world operational safety. By grouping devices into buckets, relying on observed update success signals, and surfacing deterministic events and registry values to administrators, Microsoft gives IT teams the visibility and control needed to manage a high‑risk, time‑bound change.
For administrators, the takeaway is clear and immediate: treat the Secure Boot certificate rotation as a scheduled engineering project. Start inventory and telemetry work now, run conservative pilots on representative hardware, and coordinate with OEMs for any systems that do not appear in the high‑confidence buckets. The database improves Microsoft’s ability to automate this work safely—but it does not eliminate the need for proactive, disciplined operations at the organization level.
Source: Microsoft Support
A Closer Look at the High Confidence Database - Microsoft Support