Microsoft’s July 15 OEM Secure Boot Office Hours surfaced a stubborn reality: forcing the Windows 11 Secure Boot certificate update on HP and Dell business laptops can trigger BitLocker recovery loops—even when the devices run the latest BIOS firmware. The event, which gathered engineers from Microsoft and major PC manufacturers, left multiple IT administrator reports unanswered, exposing gaps between Microsoft’s rollout guidance and the uneven firmware implementations across the PC industry.

The unresolved cases that riled admins

The most alarming testimony came from an administrator managing more than 7,000 HP EliteBooks and ZBooks spanning G7 through current models. When they applied the certificate update through the AvailableUpdates registry key (set to 0x5944), test systems entered BitLocker recovery mode on every reboot. Following HP’s own documented BIOS-setting path produced the same result.

HP representatives advised ensuring the newest BIOS and letting Windows Update handle the certificate change without manual registry or firmware tweaks. But the admin replied that the fleet already used the latest BIOS versions distributed through HP Image Assistant. On an EliteBook 640 G10 running BIOS V75 01.12.01, forcing the update caused a recovery prompt each time; rolling back to V75 01.11.00 made the loop stop. That distinction—a single BIOS point-release determining whether BitLocker breaks—underscores how fragile the handshake between firmware and Windows encryption can be. Neither HP nor Microsoft offered a follow-up fix by the session’s end.

Another IT pro described roughly 700 HP EliteBook G9 and G10 systems where the Secure Boot database (DB) certificates updated successfully, but the Key Exchange Key (KEK) repeatedly reverted to “Not Started” after a reboot. HP suggested an explicit KEK trigger via registry and a BIOS refresh, yet even a freshly updated test device refused to advance. This aligns with Microsoft’s own troubleshooting documentation: Event ID 1803 flags a missing KEK, and ID 1795 indicates a firmware error—but Windows cannot itself force a UEFI firmware to accept or persist a new key.

Further confusion arose around the Secure Boot status indicator. Several attendees reported devices showing “Secure Boot Status = Unknown” despite having Secure Boot enabled, a functional TPM, and the 2023 certificates visible in the system. Microsoft’s engineers directed them to the Get-SecureBootRolloutStatus.ps1 script for a deeper view but did not pinpoint why the status field breaks on otherwise compliant machines. The discrepancy matters because Microsoft recently surfaced rollout state inside the Windows Security app; a wrong status could lead users or help desks to chase phantom issues.

Dell didn’t escape scrutiny either. An admin noted that OptiPlex 5000 systems ignored the registry-driven deployment commands, with no response from Dell’s representatives during the session. Meanwhile, HP drew sharp criticism over model support: one commenter detailed how HP’s published list originally included 2018-era EliteBook and ZBook models, then quietly dropped them when it became clear the NVRAM couldn’t accommodate the new certificates. A manual package for out-of-service devices was deemed an insufficient substitute for a proper BIOS fix.

These are not edge cases. The reports span multiple models, BIOS generations, and two OEM giants. They expose a painful truth: a security update that Microsoft treats as a Windows Update change is, in reality, a firmware-adjacent deployment whose success hinges on deep, vendor-specific UEFI behavior.

What the Secure Boot certificate transition actually means for you

The Secure Boot certificate update moves devices from expiring 2011 trust anchors to 2023 replacements. The certificate set governs the Secure Boot database (DB) and the Key Exchange Key (KEK), which authorizes updates to those firmware variables. Without the transition, future boot-chain protections—such as signed boot managers or pre-OS malware shields—may not be available, though Microsoft says PCs will still start normally and receive standard Windows updates.

For home users running a single Windows 11 PC, the rollout should proceed invisibly through Windows Update or via a firmware update from the manufacturer. The issues detailed at the Office Hours event primarily affected enterprise fleets where admins forced the update manually. That said, if you notice BitLocker recovery prompts unexpectedly—especially after a BIOS update or a system reboot—the certificate change could be the trigger. You’ll need your BitLocker recovery key, which might be saved to your Microsoft account, printed, or stored by your organization.

For IT administrators, the message is loud: treat Secure Boot certificate deployment as a separate, high-risk change window, not a routine patch. Do not combine it with broad BIOS updates, BitLocker policy changes, or other maintenance. Establish a pilot group covering each model, BIOS revision, TPM configuration, and disk-encryption state. Verify that BitLocker recovery keys are escrowed in Active Directory or Azure AD before touching any registry setting or firmware toggle. If a device is blocked by Microsoft’s safeguard holds (recognizable by a paused rollout status), do not override the block—those holds exist because a known firmware or hardware incompatibility needs a fix from the OEM.

How the rollout got so messy

Microsoft has been steering Windows 11 devices toward 2023 Secure Boot certificates for months. The push intensified after the April 2026 Patch Tuesday, when a batch of HP BIOS updates corrupted the PCR7 measurements that BitLocker uses to seal its encryption key, causing a rash of recovery prompts. The problem persisted into June’s cumulative update, where more HP and Dell machines experienced boot failures and BitLocker loops.

The current turbulence, as documented by Windows Latest, flows from a fundamental mismatch: Secure Boot’s trust anchors live in UEFI firmware, which every PC maker implements differently. Some older models lack sufficient NVRAM space for the new certificates. Others have firmware bugs that reject or corrupt the incoming keys. A new BIOS version may fix one issue and introduce another—as the EliteBook 640 G10 example shows. Microsoft can deliver the payload and the orchestration logic, but it cannot repair a firmware implementation that won’t cooperate.

The July 15 Office Hours were meant to give administrators direct access to Microsoft and OEM engineers. Instead, the unresolved threads highlighted that even with joint collaboration, some combinations of hardware and firmware remain stubbornly incompatible. Microsoft’s guidance acknowledges that certain devices are deliberately paused or blocked, and some might never receive the 2023 certificates if the manufacturer has stopped supporting the hardware.

What to do now: practical steps for every Windows 11 user

For individual users:
- Check your BitLocker status: go to Control Panel > System and Security > BitLocker Drive Encryption. Ensure your recovery key is accessible—check your Microsoft account (https://account.microsoft.com/devices/recoverykey), a USB drive, or a printout.
- Avoid manually forcing Secure Boot certificate updates unless directed by an IT department. Let Windows Update and OEM firmware tools manage the process.
- If you see a BitLocker recovery screen, use the key to unlock the drive. Once inside Windows, run manage-bde -status in an elevated command prompt to see if encryption is healthy.
- For general awareness, open Windows Security, go to Device security, and check the Secure Boot status. If it shows “Updated” or “Not yet updated,” that’s expected. “Unknown” might warrant further digging, but don’t panic.

For IT administrators:
- Implement a staged rollout. Start with a representative test fleet that mirrors production diversity. Monitor the System log for events 1795 and 1803, which flag firmware errors and missing KEK.
- Before any forced update, run Detect-SecureBootCertUpdateStatus.ps1 from %systemroot%\SecureBoot\ExampleRolloutScripts to baseline each machine’s certificate, KEK, and firmware state.
- When a device reports “Unknown” despite correct certificate presence, use Get-SecureBootRolloutStatus.ps1 to capture deeper telemetry. Compare with OEM advisories; Dell and HP each have separate support articles listing compatible models and known issues.
- Do not disable Secure Boot to sidestep a failure. That removes the pre-OS protection entirely and can break BitLocker.
- If a device is blocked by Microsoft’s safeguard holds, monitor the %systemroot%\SecureBoot\CertificateUpdateStatus.ps1 output and the OEM’s support site for a BIOS update; the hold should lift once a fix is validated.
- Escrow all BitLocker recovery keys in Active Directory or Azure AD and verify escrow success before any certificate‑related maintenance.

What comes next

The Secure Boot certificate transition is necessary, but the road is bumpier than Microsoft’s early documents suggested. Expect more firmware updates from HP, Dell, and others as they address the NVRAM and key persistence issues. Microsoft will likely refine the rollout-status tooling and perhaps add more explicit warnings when forcing the update via registry on risky hardware. For now, the safest posture is patience: let the normal rollout proceed where possible, and isolate experimental updates to a sandboxed test ring. The unresolved Office Hours cases prove that even with direct lines to the engineers, some firmware‑level problems simply need more time and more code—from the OEM side, not just from Windows.