Ablauf der Secure-Boot-Zertifikate – Teil 2: Discovery und Rollout mit Ivanti Neurons Bots

Im ersten Teil dieser Serie haben wir gezeigt, warum die Erneuerung der Secure-Boot-Zertifikate 2026 kein Selbstläufer ist: Windows Server erhalten keinen automatischen Rollout, Geräte mit veralteter OEM-Firmware scheitern am Update, und bei dauerhaft deaktiviertem Secure Boot droht die Henne-Ei-Falle beim späteren DBX-Widerruf. Die zentrale Erkenntnis: Ohne belastbares Reporting weiß niemand, welche Geräte betroffen sind – und genau dort setzen wir jetzt an.

In diesem Teil zeigen wir, wie Ivanti Neurons die Discovery und den gesteuerten Rollout der 2023-Zertifikate übernimmt – mit einem konkreten, produktiv einsetzbaren Bot, der beides in einem Workflow abbildet.

Warum Ivanti Neurons?

Natürlich lässt sich der Zertifikatsstatus auch per GPO-Logon-Skript, Netzwerk-Share und Excel-Auswertung einsammeln. Wer das schon einmal für ein paar tausend Geräte betrieben hat, kennt die Schwächen: veraltete Daten, fehlende Offline-Geräte, keine Rückmeldung, ob eine Remediation tatsächlich gegriffen hat.

Ivanti Neurons löst diese Punkte strukturell:

• Ein Agent, aktuelle Daten: Der Neurons Agent liefert die Gerätedaten direkt aus der Cloud-Konsole – ohne Logon-Skripte, Netzwerk-Shares oder manuelle Konsolidierung.
• Discovery und Remediation in einem Workflow: Ein Bot erkennt betroffene Geräte und stößt das Update an. Kein Medienbruch zwischen Report und Aktion.
• Low-Code mit PowerShell-Erweiterbarkeit: Der grafische Bots-Editor bildet die Logik (Filter, Verzweigungen, Reports, E-Mail) ab; die eigentliche Fachlogik steckt in zwei PowerShell-Stages, die sich exakt an das Microsoft Secure Boot Playbook halten.
• Zustandsverwaltung inklusive: Über den Bot Data Store merkt sich der Bot pro Gerät, wann die Remediation ausgelöst wurde – und eskaliert automatisch, wenn ein Gerät nach 14 Tagen immer noch nicht konform ist.
• Gesteuerter Rollout: Als Schedule Bot läuft der Workflow zyklisch gegen definierte Gerätegruppen. Pilotgruppe zuerst, dann Ausweitung – ganz ohne zusätzliche Infrastruktur.

Der Bot im Überblick

Der Bot besteht aus vier logischen Blöcken:

1. Detection: Eine PowerShell Query sammelt auf jedem Gerät den vollständigen Secure-Boot- und Zertifikatsstatus ein.
2. Filter: Nur Geräte mit UEFICA2023Status ≠ Updated laufen weiter – konforme Geräte verlassen den Workflow sofort.
3. Verzweigung nach Ursache: Geräte mit deaktiviertem Secure Boot, veralteter Firmware oder fehlender Remediation werden getrennt behandelt.
4. Remediation, Statusverwaltung und Reporting: Betroffene Geräte erhalten den Update-Trigger, der Fortschritt wird überwacht, und ein E-Mail-Report fasst alles zusammen.

Stufe 1: Detection – der komplette Status in einem Script

Die erste Stage ist eine PowerShell Query, die alle relevanten Datenpunkte einsammelt und als strukturierte Ausgabe an den Bot übergibt. Erfasst werden unter anderem:

• Status der Secure Boot Update Policy
• Update Status und evtl. Fehlermeldung
• Diverse Geräteattribute (Hersteller, Modell etc.)
• UEFI-Version und -Datum
• SecureBoot bezogene Events (Event IDs: 18xx)
• Status des Scheduled Tasks

Zwei Details lohnen sich besonders:

Firmware-Alter als Frühwarnindikator: Das Firmware-Release-Datum aus den DeviceAttributes verrät, welche Geräte seit Jahren kein BIOS-Update mehr gesehen haben – genau die Kandidaten, bei denen das Zertifikatsupdate an bekannten Firmware-Bugs scheitern kann (Teil 1, Abschnitt Risikoszenarien).

Empfehlungs-Engine: Das Script wertet die gesammelten Daten in Prioritätsreihenfolge aus und liefert pro Gerät eine eindeutige RecommendedAction: von EnableSecureBoot über OEMFirmwareUpdate (Event 1803) und Reboot bis Wait, wenn das Update schlicht im regulären Backoff steckt. Der Report zeigt damit nicht nur dass ein Gerät nicht konform ist, sondern was als Nächstes zu tun ist.

Stufe 2: Filter und Verzweigung

Nach der Detection filtert der Bot auf UEFICA2023Status ≠ Updated und verzweigt anschließend nach Secure-Boot-Status:

Secure Boot deaktiviert: Diese Geräte landen in einem eigenen Bots Report. Hier hilft keine Automatisierung – Secure Boot muss in der Firmware aktiviert werden, bevor Windows die DB/DBX-Updates schreiben darf (siehe Teil 1: Geräte mit dauerhaft deaktiviertem Secure Boot). Der Report macht diese Gruppe sichtbar, damit sie vor dem DBX-Widerruf abgearbeitet wird.

Secure Boot aktiv, Firmware älter als 700 Tage: Ein zweiter Filter identifiziert Geräte, deren Firmware-Release länger als rund zwei Jahre zurückliegt. Diese Geräte erscheinen in einem separaten Report als Kandidaten für ein OEM-Firmware-Update, bevor das Zertifikatsupdate erzwungen wird.

Secure Boot aktiv, Remediation möglich: Alle übrigen Geräte laufen in den Remediation-Zweig.

Stufe 3: Remediation – das Update gezielt anstoßen

Die Remediation-Stage führt genau die Schritte aus, die Microsoft für den manuell gesteuerten Rollout vorsieht:

1. Prüfen, ob das Script elevated läuft und Secure Boot aktiv ist
2. Optional: BitLocker-Protektoren für zwei Neustarts pausieren (manage-bde -protectors -disable -RebootCount 2)
3. Den Scheduled Task \Microsoft\Windows\PI\Secure-Boot-Update aktivieren
4. AvailableUpdates auf 0x5944 setzen – das Opt-in für das vollständige Zertifikats- und Boot-Manager-Update
5. Optional: den Task sofort starten
6. Ergebnis und Statuswerte in einen eigenen Registry-Zweig schreiben, den die nächste Detection wieder einsammelt

Wichtig: Das Script erzwingt keinen Reboot. Die Neustarts – das Update benötigt mehrere – laufen über die regulären Wartungsfenster. Damit bleibt der Rollout auch bei kritischen Systemen kontrollierbar.

Stufe 4: Bot Data Store – Wiederholungsschutz und Eskalation

Ein Detail, das den Bot vom simplen Skript-Rollout unterscheidet: Vor der Remediation liest der Bot aus dem Bot Data Store, ob für das Gerät bereits ein Update-Trigger gesetzt wurde (CertUpdateTriggeredTimestamp).

• Kein Eintrag vorhanden: Die Remediation läuft, anschließend werden Trigger-Flag und Zeitstempel gespeichert (Ablauf nach 180 Tagen).
• Eintrag älter als 14 Tage, Gerät weiterhin nicht konform: Das Gerät landet im Eskalations-Report „Remediated but not Compliant after 14 days“ – inklusive UEFICA2023Error und Error-Event. Diese Geräte brauchen manuelle Analyse, typischerweise wegen Firmware-Problemen (Event 1795/1802) oder fehlendem KEK-Update (Event 1803).

So triggert der Bot das Update pro Gerät genau einmal und macht hängengebliebene Geräte automatisch sichtbar, statt sie in einer Endlosschleife zu behandeln.

Reporting: alles in einer E-Mail

Am Ende führt eine Join-Stage die Zweige zusammen und verschickt einen E-Mail-Report an den initiierenden Benutzer: pro Gerät Hostname, UEFICA2023Status, Fehlercodes, Opt-in-Werte, Firmware-Stand und letzter Boot. Die Bots Reports der einzelnen Zweige bleiben zusätzlich in der Neurons-Konsole abrufbar – als Arbeitsvorrat für die manuellen Fälle.

Erweiterung: Tickets automatisch im ITSM erzeugen

E-Mail-Reports sind gut für den Überblick – für die nachverfolgbare Abarbeitung gehören die manuellen Fälle aber ins ITSM. Auch das lässt sich direkt im Bot abbilden: Neurons bringt fertige Integrations-Stages für Ivanti Neurons for ITSM und ServiceNow mit, über die der Bot pro betroffenem Gerät ein Incident oder einen Change erzeugt.

Sinnvoll ist das vor allem an drei Stellen des Workflows:

• Secure Boot deaktiviert: Ein Ticket pro Gerät, zugewiesen an das Client-Team – inklusive Hostname, Modell und der RecommendedAction aus der Detection. Die Aktivierung in der Firmware ist ohnehin ein manueller (ggf. Vor-Ort-)Eingriff.
• Veraltete Firmware: Ein Sammel- oder Einzelticket für das anstehende OEM-Firmware-Update, mit Firmware-Version und Release-Datum als Arbeitsgrundlage.
• Eskalationsfälle nach 14 Tagen: Geräte, bei denen die Remediation nicht gegriffen hat, erzeugen ein Ticket mit UEFICA2023Error, Error-Event und Known-Issue-ID (KI_*) – der Analyst startet damit direkt mit der relevanten Diagnose statt bei null.

Die Stage wird einfach hinter den jeweiligen Filter gehängt; die Feldwerte (Kurzbeschreibung, Beschreibung, Zuweisungsgruppe, Priorität) befüllt der Bot aus den Ausgaben der Detection-Stage. Wichtig für den Betrieb: Analog zum Update-Trigger sollte auch die Ticketerzeugung über den Bot Data Store gegen Duplikate abgesichert werden, damit ein wöchentlich laufender Schedule Bot nicht bei jedem Lauf ein neues Ticket für dasselbe Gerät anlegt.

Das Ergebnis: Aus einem Monitoring-Bot wird ein geschlossener Prozess – Erkennen, Beheben, und was nicht automatisch behebbar ist, landet mit vollem Kontext als Ticket beim richtigen Team.

Empfehlungen für den Betrieb

• Als Schedule Bot betreiben: Wöchentlich gegen die Zielgruppen laufen lassen. Die Detection ist rein lesend und damit unkritisch; die Remediation greift dank Data Store nur einmal pro Gerät.
• Mit einer Pilotgruppe starten: Erst eine kleine, hardwareseitig gemischte Gerätegruppe, dann schrittweise ausweiten – analog zur Empfehlung aus Teil 1.
• Die Sonderfälle aktiv abarbeiten: Die Reports für deaktiviertes Secure Boot und veraltete Firmware sind kein Selbstzweck. Diese Geräte scheitern sonst spätestens am DBX-Widerruf.
• Windows Server nicht vergessen: Gerade hier gibt es keinen automatischen Rollout – der Bot ist für Server der einzige gesteuerte Weg zum Opt-in.

Fazit

Die eigentliche Herausforderung der Zertifikatserneuerung 2026 ist nicht das einzelne Update, sondern die Transparenz über tausende Geräte hinweg – und die Fähigkeit, gezielt nachzusteuern. Mit Ivanti Neurons Bots lässt sich beides in einem einzigen Workflow abbilden: vollständige Discovery nach Microsoft-Playbook, gezielte Remediation per Opt-in, automatische Eskalation für Problemgeräte und ein Reporting, das aus Rohdaten konkrete Handlungsempfehlungen macht.

Damit schließt sich der Kreis zu Teil 1: Wer heute weiß, welche Geräte die 2023-Zertifikate noch nicht tragen, muss den DBX-Widerruf morgen nicht fürchten.

Sind noch Fragen offen? Melden Sie sich einfach – wir kümmern uns darum.