Kurzlage

In vielen Umgebungen steckt noch ein Mix aus alten UEFI-/Firmware-Ständen, OEM-spezifischen Secure-Boot-Datenbanken und unterschiedlich gepflegten Boot-/Recovery-Konfigurationen. Mit dem Auslaufen älterer Secure-Boot-Zertifikate ab Juni 2026 steigt das Risiko für Boot-Failures und BitLocker-Recovery-Events bei Updates oder Firmware-Rollouts.

Das ist kein Thema für „irgendwann“: Wenn ein Teil der Flotte betroffen ist, willst du das in einer kontrollierten Pilotwelle sehen – nicht beim nächsten regulären Patch-Fenster.

Praktische Schritte (1–2 Wartungsfenster)

  1. Inventar bilden: Geräteklassen/Modelle, UEFI-Versionen, Secure Boot aktiv ja/nein, BitLocker aktiv ja/nein, Management (Intune/SCCM/WSUS).
  2. Pilot-Ring definieren: repräsentativ (Notebook/Workstation/Server), inkl. „Problemkandidaten“ (ältere Geräte, Sonderimages, Dual-Boot, spezielle Bootloader).
  3. Recovery-Readiness prüfen: BitLocker-Recovery-Keys zentral vorhanden, Owner/Prozess klar, Zugriff auch bei Helpdesk-Ausfällen.
  4. Firmware & OS zusammen denken: Firmware-Update-Prozess und Windows-Update-Ring aufeinander abstimmen (kein blindes Parallelrollen).
  5. Rollback/Breakglass planen: Boot-/Recovery-Playbook (wer macht was, in welcher Reihenfolge), inkl. Offline-Zugriff und remote Hands.

Schnelle Verifikation (ohne Tool-Overkill)

  • Secure Boot Status prüfen und dokumentieren (Sample-Flotte, nicht nur „Green“ in einem Dashboard).
  • BitLocker: Recovery Keys abrufen/validieren (Stichprobe), nicht erst im Ernstfall.
  • UEFI-/Firmware-Versionen: Streuung sichtbar machen; Sondermodelle und abgekündigte Plattformen markieren.

Wenn du nur eine Sache priorisieren willst: Pilotgruppe + Recovery-Prozess. Das reduziert das operative Risiko am schnellsten.