Secure Boot CA 2023 and BitLocker Recovery

Summary

In early 2026, Microsoft published guidance around the Secure Boot CA 2023 transition. Once there was operational space to address it, I worked with the head of operations to review the change, classify the affected tenant, validate prerequisites, and roll out the implementation through Intune in a hybrid environment. Lab validation and the first pilot group succeeded, so the rollout was expanded.

After broader deployment, several client devices began requesting BitLocker recovery keys at boot. Most recovered after a single key entry, but a smaller subset continued prompting on every restart. I helped contain the operational impact, narrowed the repeated failures to a specific hardware and BIOS combination, brought one affected device into the lab for hands-on analysis, and traced the issue to incomplete Secure Boot CA 2023 transition behaviour at boot time. I then documented a repeatable remediation path that an onsite technician used to resolve the remaining impacted systems.

Context

In January 2026, Microsoft published its Secure Boot certificate transition guidance and the topic was raised internally. It stayed on the radar, but other operational priorities took precedence until there was room to handle it properly.

When the work was revisited, I raised it with the head of the operations team and we began working through implementation planning. A tenant of roughly 30 devices made inventory and classification straightforward enough to handle directly, and because the environment was hybrid, the decision was made to implement the rollout through Intune.

Rollout Plan

We reviewed Microsoft guidance and supporting rollout material, then worked through the prerequisite checks before making changes. A configuration profile was created and assigned to a lab device. That succeeded. The rollout was then expanded to the first pilot group, and those devices also completed successfully.

With those early stages looking healthy, the rollout was expanded further. What those results established was that policy delivery worked on the tested devices; they did not yet prove that platform transition behaviour was safe across the tenant's full hardware profile. Intune reported successful application, but we deliberately allowed time to observe post-deployment behaviour before treating the work as complete.

Incident Trigger

In mid-April 2026, client users started reporting devices asking for BitLocker recovery keys during boot. The timing lined up with the release window around KB5083769, where BitLocker recovery prompting was documented as possible behaviour during Secure Boot transition activity.

After contacting the client, we isolated the impacted devices and started enumerating their state. Recovery keys were provided so the affected users could regain access. For most systems, one recovery-key entry was enough and the prompt did not return. Three systems, however, continued requesting the key at every boot.

At that point, the decision was made to share the relevant recovery keys with the office administrator so the client could maintain uptime, even with more friction than normal, while we worked the problem properly.

Investigation

The first useful distinction was that this was not a tenant-wide collapse. Most devices either completed the transition cleanly or stabilized after a single recovery event. The stubborn failures were confined to a much smaller set.

From there, I compared the repeatedly impacted devices and found they shared the same BIOS version on the same hardware type. That BIOS version was already as current as the platform supported, which ruled out a simple firmware-update escape path.

Because the problem was now narrow and hardware-linked, I provisioned a replacement computer for the client so one affected machine could be swapped out and returned to the lab for direct analysis.

With the device in hand, I checked event logs, Secure Boot servicing state, and the transition behaviour more closely. The CA 2023 certificates were present in BIOS, but the changeover was not actually completing at boot time. That explained why the systems could enter BitLocker recovery repeatedly even though the rollout itself initially appeared to have applied successfully.

Root Cause

The repeated recovery prompts were not caused by a simple BitLocker configuration failure.

The narrower problem was that on a specific hardware and BIOS combination, Secure Boot CA 2023 transition activity was not converging properly during boot. The required certificate material was present, but the platform state was not completing the changeover cleanly, which kept triggering BitLocker recovery on the affected systems.

Response and Remediation

The response had two tracks running at the same time:

• keep client systems usable by providing controlled access to recovery keys
• investigate one affected device deeply enough to produce a safe field fix

Once the lab analysis made the pattern clear, I documented the remediation sequence as a practical step-by-step guide for field use. The fix centered on controlled BitLocker suspension, verification of Secure Boot servicing state, enabling the relevant CA 2023 trust anchors in BIOS, and repeated reboot-and-check cycles until servicing status showed the transition had completed.

That guide was handed to the onsite technician, who then used it to remediate the remaining impacted devices.

Outcome

The immediate operational impact was contained without resorting to broad destructive actions such as wiping devices or disabling protections across the estate.

Most affected devices recovered after a single key entry. The smaller group of repeatedly impacted devices was isolated, analysed, and tied to a specific hardware and BIOS pattern. A documented remediation path was then produced and applied in the field to resolve the remaining systems.

Just as importantly, the work turned a vague “BitLocker is broken” reading into a more accurate platform-trust diagnosis tied to Secure Boot transition behaviour. It also left a durable operational lesson: a successful staged rollout is not the same thing as a fully bounded rollout, and reported deployment success is not enough on its own when firmware state and hardware-specific boot behaviour are still in play.

Lessons Learned

• Successful policy application in Intune does not, by itself, prove platform transition work has completed safely.
• This incident reinforced a lesson that now shapes my rollout approach: a staged rollout can still outrun what has actually been bounded if hardware-specific boot behaviour has not been classified well enough up front.
• During staged platform changes, reported success should be treated as one signal rather than final proof, especially where firmware state and trust-chain changes are involved.
• Repeated BitLocker recovery prompts can be a downstream symptom of Secure Boot transition state, not only an encryption-policy problem.
• Narrowing incidents by hardware type and BIOS version can cut through a lot of noise quickly.
• A good rollout does not end at deployment; the post-change investigation can become the knowledge base for safer future implementations.

Reuse Value

The investigation enriched our baseline knowledge for future Secure Boot CA 2023 rollouts. In later implementations, the enumeration and pre-check phase could be more informative up front, especially around hardware class, BIOS state, and expected recovery behaviour during the transition window.