Event details
I'd say it is a very strong reason to believe so. But on the other hand, alone the fact that the vendor issued a firmware update in the timeframe the certificate updates have been running is a very strong argument that the update process is safe (does not lead to hangs or incompatibility issues).
OTOH, it is not a guarantee that it is successful (does not fail with a defined error code). There are cases (lost/replaced platform key) that cannot be remediated just by installing a firmware update, but only by following additional steps (e.g. suspending Bitlocker and resetting setup defaults). But I would expect the firmware vendor to clearly communicate those if they apply.
Mihi,
I appreciate your response and want to provide some more insight and clarification on my question and situation.
Our planned update flow is going to be:
- Deploy approved OEM firmware/BIOS updates via Dell Command Update.
- Dell is packaging the dbDefault certificates with most of its newer BIOS updates.
- Verify (via SCCM) that the firmware update successfully updates dbDefault and that systems remain healthy (Secure Boot enabled, normal boot, no intervention required)
- Build an SCCM collection scoped only to systems where dbDefault is confirmed updated
- Deploy a configuration to that collection that sets the Windows Secure Boot AvailableUpdates registry value to 0x5944 (IT‑managed Secure Boot update path)
Let me clarify two things about our fleet of devices:
- We do not send Windows diagnostics/telemetry to Microsoft.
- While we deploy only a small, controlled subset of hardware models, the total device count is in the thousands, and manual validation or reverse‑engineering of Microsoft “high confidence” buckets on a per‑model/firmware version/etc. basis is operationally infeasible for a small IT staff. I am practically taking this on by myself.
What I'm trying to validate is:
If an OEM firmware update successfully updates dbDefault without issue, can that outcome be used as an indicator that the platform falls into a “high confidence” category for subsequently applying the Microsoft OS‑initiated Secure Boot update (db via AvailableUpdates = 0x5944)?
I understand Microsoft’s intent and safety model, I'm just trying to confirm that successful OEM‑managed dbDefault updates can reasonably substitute for telemetry‑driven confidence signals in an IT‑managed, low‑model‑variance enterprise environment.
I fully recognize there are edge cases (e.g., lost PK, Setup Mode state, BitLocker remediation requirements), but we are trying to validate whether this assumption aligns with Microsoft’s intended deployment guidance for enterprises unable to rely on diagnostics‑based confidence scoring.