Boot failure 0xc000000d on some Dell devices after KB5127648 – related to Secure Boot 2023 certificate servicing?

Resetting the Secure Boot settings is Microsoft’s documented recovery step when firmware mishandles a DB update; after the device boots, install the latest Dell BIOS/UEFI before allowing Secure Boot certificate servicing to run again.^1^

Current Microsoft status

KB5127648 explicitly continues the targeted rollout of updated Secure Boot certificates to eligible, high-confidence devices. However, its published known-issues list does not identify a Dell boot failure with status 0xc000000d as a known KB5127648 issue.^2^

Microsoft does document the matching general failure mode: some UEFI implementations overwrite or corrupt the Secure Boot DB instead of appending the new certificates. That can remove the certificate trusted by the currently installed boot manager and prevent startup. A successful factory-key reset followed by normal boot is consistent with that scenario, but it does not by itself prove that this is the cause on these Dell units.^1^

The 0xc000000d entry documented for KB5127648 concerns Remote Desktop connections for non-administrators, not startup failure.^2^

Servicing order

For the normal AvailableUpdates = 0x5944 workflow, the Secure-Boot-Update scheduled task processes these operations:

1. 0x0040: add Windows UEFI CA 2023 to DB.
2. 0x0800: add Microsoft Option ROM UEFI CA 2023 to DB, if Microsoft Corporation UEFI CA 2011 was already trusted.
3. 0x1000: add Microsoft UEFI CA 2023 to DB under the same condition.
4. 0x0004: apply the OEM Platform Key-signed Microsoft Corporation KEK 2K CA 2023.
5. 0x0100: install the Windows Boot Manager signed by Windows UEFI CA 2023.

The corresponding expected values are:

0x5944 → 0x5904 → 0x5104 → 0x4104 → 0x4100 → 0x4000

Each completed operation clears its bit. Failures leave the bit set for retry. The boot-manager step normally records Event 1799; the initial DB step records Event 1036.^3^

One nuance: Microsoft states that if the OEM-signed KEK cannot be applied, the task can still process the boot-manager bit. Therefore, correlate the complete event sequence rather than assuming every device followed the ideal progression.^3^

Identifying units at risk

Before wider deployment, inventory by Dell model, BIOS version/date, and baseboard revision, rather than model alone. Different firmware revisions can explain why nominally identical devices behave differently.

Use these signals:

• BucketConfidenceLevel
  • High Confidence: observed peers successfully updated.
  • Temporarily Paused: known issue; do not deploy certificate servicing and look for Event 1802.
  • Not Supported – Known Limitation: exclude from automated certificate deployment.
  • Under Observation or No Data Observed: pilot manually before broad deployment.^4^
• Event 1795: firmware returned an error while updating DB, DBX, or KEK. Capture its firmware error code, DeviceAttributes, BucketID, and confidence level.
• Event 1796: unexpected update error; capture the named component and error code.
• Event 1803: required OEM PK-signed KEK is unavailable.
• Event 1808: all required certificates and the 2023-signed boot manager are already applied. It is a completion signal, not a predeployment warning.^5^
• Registry
  • UEFICA2023Status = Updated: completed.
  • UEFICA2023Error or UEFICA2023ErrorEvent: servicing error.
  • A persistent AvailableUpdates bit identifies the stalled stage.

Deferring only certificate servicing

Monthly quality/security updates can continue even when a device cannot receive the new Secure Boot certificates; only future boot-related protections requiring the new trust configuration are withheld.^6^

For managed deployment, do not target the affected firmware cohort with AvailableUpdatesPolicy = 0x5944 or the Secure Boot CSP. The CSP’s default value is 0; value 22852 (0x5944) initiates certificate and boot-manager deployment.^7^

Do not disable the scheduled task or manually manipulate individual bits as a pause mechanism. For automatically targeted devices, use the high-confidence deployment opt-out/reporting controls available through the supported management workflow, or rely on Microsoft’s Temporarily Paused classification. There is no documented KB5127648 uninstall requirement merely to stop certificate servicing.

Recovery and next actions

For the affected Dell cohort:

1. Preserve BitLocker recovery information before firmware work.
2. Restore Secure Boot settings/keys as you already did.
3. Confirm Windows starts and KB5127648 finishes.
4. Record the BIOS version, pre/post registry values, and TPM-WMI events.
5. Install Dell’s latest applicable BIOS/UEFI before another certificate attempt.
6. Pilot one unit per distinct BIOS revision.
7. If the failure recurs, provide Dell and Microsoft Support with BucketID, DeviceAttributes, Event 1795/1796 error data, AvailableUpdates, and UEFICA2023ErrorEvent.

Uninstalling KB5127648 is not the preferred response when restoring firmware defaults recovers the device and the update completes. Avoid repeatedly resetting factory keys after a unit has transitioned unless the installed Dell firmware defaults include the 2023 trust anchors; otherwise a reset can remove the certificate needed to trust the 2023-signed boot manager.^1^

References

1. Secure Boot troubleshooting guide | Microsoft Support
2. October 13, 2026—KB5127648 (OS Builds 26300.9711, 26200.9711 and 26100. ...
3. Secure Boot troubleshooting guide | Microsoft Support
4. Secure Boot status report in Windows Autopatch
5. Secure Boot DB and DBX variable update events | Microsoft Support
6. If you’re prevented from updating Secure Boot certificates
7. Policy CSP - SecureBoot