Microsoft's May 18 Secure Boot AMA was aimed squarely at IT administrators preparing for the June 2026 expiration of older Windows Secure Boot certificates, and one enterprise question now captures the core tension: How should organizations balance relying on OEM-provided dbDefault signatures versus Microsoft's high-confidence UEFI certificate chains when deploying updates across fleets? The query surfaced during a live Q&A session that drew hundreds of sysadmins, showcasing the complexity of a seemingly straightforward security update.

The clock is ticking. Every Windows device with Secure Boot enabled relies on a chain of trust rooted in certificates stored in UEFI firmware. The Windows Secure Boot CA 2011, used to sign bootloaders and kernel components, is set to expire in June 2026. After that, systems that haven't ingested the new certificate may fail to boot or lose Secure Boot protection. Microsoft has been rolling out patches—most notably via KB5012170 and subsequent updates—to inject the new Windows UEFI CA 2023 certificate into the Secure Boot signature database (db). But the process is anything but plug-and-play.

The Two Pillars: OEM dbDefault vs. Microsoft High-Confidence

During the AMA, an administrator from a Fortune 500 company asked: \"We deploy firmware updates through SCCM and have a mix of Dell, HP, and Lenovo devices. Some of our older machines only accept dbDefault updates from the OEM, while newer ones take Microsoft's high-confidence payloads. How do we create a unified rollout plan?\" This dichotomy lies at the heart of the certificate transition.

OEM dbDefault Proof

dbDefault is an OEM-supplied default Secure Boot signature database that ships with the motherboard. Many devices, especially from the era of Windows 8.1 and early Windows 10, only accept updates to their Secure Boot variables if they are signed by the hardware vendor's key, not by Microsoft directly. These machines require OEM-provided firmware capsules, typically distributed via Windows Update or manual download. The AMA panelists acknowledged that Microsoft's own KB5012170 patch often fails on these systems, returning error 0x800f0922, because the update relies on the presence of the Windows UEFI CA 2023 in the firmware's dbDefault store—a chicken-and-egg problem.

For IT departments managing thousands of such devices, the only recourse is to obtain OEM-specific firmware updates that embed the new certificate. This introduces testing delays, vendor coordination, and potential security gaps if OEMs drag their feet. Dell, for instance, released a firmware update in March 2024 for certain Latitude models, but older OptiPlex units remain pending. HP's rollout has been similarly uneven.

Microsoft High-Confidence Updates

On devices with UEFI firmware that trusts Microsoft's high-confidence certificate, the picture is simpler. Microsoft can push a signed update that directly writes the new CA to the db and dbx (forbidden signatures) databases. This is the mechanism behind the \"Windows UEFI CA 2023\" update offered via Windows Update. Systems with this capability typically include most PCs shipped with Windows 10 version 1703 or later and all Windows 11 devices. Microsoft's AMA hosts stressed that the high-confidence path is the preferred method because it can be automated through existing tools like SCCM, Intune, or WSUS, with full progress reporting.

Yet even here, pitfalls lurk. The update requires specific firmware versions that expose the necessary UEFI variable service. Some Lenovo ThinkPads, for example, block writing to the db unless a BIOS option \"Allow Microsoft UEFI CA Updates\" is enabled. Administrators discovered this the hard way, with failed deployments triggering helpdesk calls. The AMA clarified that such settings are manufacturer-specific and not under Microsoft's control, though the company is working with OEMs to establish defaults.

The Deployment Conundrum: SCCM and Beyond

The enterprise question that stole the AMA spotlight highlights a real-world use case: SCCM deployment. While SCCM can deliver Microsoft's high-confidence updates natively, handling OEM dbDefault updates requires packaging non-standard firmware binaries. This forces IT teams to maintain separate task sequences based on hardware models—a maintenance nightmare.

One participant shared a script that detects the Secure Boot state and attempts to install the Microsoft update first; if it fails, the script falls back to a model-specific OEM package. The AMA team endorsed this approach but cautioned that the fallback must be tested rigorously because a failed firmware update could brick a motherboard. They also noted that the new Windows UEFI CA will eventually be added to the dbDefault of new machines, so over time, the problem should diminish as hardware refreshes occur.

The Shadow of Revoked Hashes

Beyond getting the new certificate into the db, administrators must also ensure that the forbidden signature database (dbx) is updated. Microsoft regularly revokes vulnerable bootloaders and kernel drivers. The June 2026 expiry coincides with several planned revocations, meaning that devices with out-of-date dbx databases may block legitimate Windows components after the transition. This double-barreled requirement—add the new CA and update dbx—can trip up even seasoned teams.

During the AMA, Microsoft offered a timeline:
- Q2 2025: Expanded high-confidence updates for Windows 10 22H2 and Windows 11.
- Q3 2025: Mandatory dbx updates begin rolling out alongside monthly security patches.
- January 2026: Final opt-out deadline for the new UEFI CA injection.
- June 2026: Old certificate expires; systems without the new CA will enter a degraded Secure Boot state or fail to boot with BitLocker recovery prompts.

This timeline, while helpful, left some admins uneasy. \"What happens to disconnected devices in our labs?\" one asked. The reply was sobering: those machines may need manual intervention or risk being permanently untrusted.

Preparing Your Fleet: Lessons from the AMA

The AMA distilled several actionable strategies for IT administrators:

  • Inventory and segment. Use tools like Microsoft Endpoint Manager or PowerShell scripts to identify the current Secure Boot CA and dbx version across devices. Tag each machine as \"high-confidence capable\" or \"OEM-dependent.\"
  • Engage OEMs early. For the OEM-dependent group, request updated firmware capsules now. Many vendors are only now building these updates, and supply chain delays could push delivery well into late 2025.
  • Test BitLocker recovery scenarios. A Secure Boot policy change often triggers BitLocker recovery. Ensure recovery keys are escrowed in Active Directory or Azure AD, and simulate the experience on a pilot group.
  • Leverage community scripts. The AMA referenced a GitHub repository where admins share deployment wrappers that gracefully handle mixed environments. These scripts check for prerequisites, validate the update, and reboot intelligently.
  • Monitor Microsoft's Security Update Guide. Microsoft will publish KB articles for each update, and the AMA team stressed that the official documentation will always be the source of truth—don't rely on third-party summaries alone.

A Question of Proof

Returning to the enterprise question: OEM dbDefault proof versus Microsoft high-confidence. The phrase \"proof\" here is shorthand for the cryptographic proof required to update the firmware. OEM dbDefault proof means the update must come signed by the OEM's platform key (PK), whereas Microsoft high-confidence proof means the update is signed by Microsoft's UEFI CA, which is itself signed by the OEM's PK in a chain. The former is more restrictive and creates the deployment bottleneck.

Microsoft's long-term vision is to move all devices to a model where the UEFI CA is trusted by default, but legacy hardware won't magically adopt this. The AMA underscored that the 2026 expiry is a forcing function, but IT leaders must actively manage the transition rather than wait for automatic fixes that may never arrive.

The Broader Security Landscape

The Secure Boot certificate refresh is not happening in isolation. It parallels Microsoft's larger push toward hardware root-of-trust technologies like Pluton and Windows Defender System Guard. Together, they aim to combat firmware-level attacks that have grown in sophistication. The June 2026 expiration is a rare opportunity for organizations to baseline their firmware security, including updating BIOS settings, enabling Secure Boot entirely, and disabling legacy BIOS mode.

However, some admins worry about supply chain risks. If OEMs don't deliver updates for out-of-support models—and many older PCs still run perfectly well—those devices may become e-waste or operate in a less secure state. Microsoft acknowledged this tension but stated that maintaining the old certificate indefinitely would leave the entire ecosystem vulnerable to bootkits that exploit stale trust anchors.

Looking Ahead

The May AMA will be followed by a series of technical workshops in late 2025, and Microsoft promised to release an enterprise readiness kit that includes assessment scripts, deployment guides, and troubleshooting flowcharts. For now, the message is clear: start planning today. The gap between OEM dbDefault proof and high-confidence updates may be narrowing, but for the foreseeable future, a hybrid approach is the only practical path.

As one panelist put it, \"This isn't a switch you flip on June 1, 2026. It's a journey that has already begun.\"