2023er Zertifikate – Warum erst der Aktivierungsstatus wirklich zählt Ab Juni laufen Secure-Boot-Zertifikate ab – was Sie jetzt wissen müssen!

Ab Juni 2026 laufen zentrale Secure-Boot-Zertifikate aus. Unternehmen müssen deshalb jetzt prüfen, ob neue Zertifikate nicht nur importiert, sondern auf Clients und Servern auch wirklich vollständig aktiviert wurden.

Secure Boot gehört zu den Schutzmechanismen, die im Alltag kaum sichtbar und dennoch enorm wichtig sind. Noch bevor Windows oder Linux vollständig startet, prüft die Plattform anhand von Schlüsseln, Zertifikaten und Signaturdatenbanken in der UEFI-Firmware, ob nur vertrauenswürdige Komponenten geladen werden. Genau diese Vertrauenskette sorgt dafür, dass manipulierte Bootloader, kompromittierte Treiber oder andere Angriffe auf den frühen Startprozess deutlich schwerer zum Zug kommen. Microsoft ersetzt deshalb aktuell die älteren, ursprünglich 2011 ausgestellten Secure-Boot-Zertifikate durch neue 2023-Zertifikate, da die bisherigen Zertifikate ab Juni 2026 auslaufen.

Das bedeutet nicht automatisch, dass am Stichtag plötzlich massenhaft Systeme nicht mehr starten. Microsoft beschreibt vielmehr, dass Geräte auch nach dem Ablauf der alten Zertifikate in vielen Fällen weiter normal booten und reguläre Windows-Updates erhalten. Das eigentliche Problem liegt tiefer: Ohne die neuen Zertifikate können betroffene Systeme künftig keine neuen Schutzmechanismen für Secure Boot und den Boot Manager mehr übernehmen. Damit bleiben Geräte zwar lauffähig, geraten aber sicherheitstechnisch in einen veralteten Zustand und verlieren Schutz gegen neu entdeckte Boot-Schwachstellen.

Der kritische Unterschied zwischen gespeichert und aktiv

Genau hier entsteht in vielen Unternehmen ein gefährlicher Irrtum. Sobald neue Secure-Boot-Zertifikate verteilt oder in die Firmware geschrieben wurden, wirkt das Thema oft wie erledigt. In Wirklichkeit ist das häufig aber nur ein Zwischenstand. Denn ein Zertifikat kann bereits vorhanden sein, ohne dass der gesamte Update- und Aktivierungsprozess erfolgreich abgeschlossen wurde.

Für die Praxis ist dieser Unterschied entscheidend. Ein Gerät kann neue Zertifikate empfangen haben, sie sogar im UEFI-Speicher führen und trotzdem noch nicht vollständig bereit sein. Vielleicht fehlt ein Neustart. Vielleicht wurde ein geplanter Task nicht ausgeführt. Vielleicht bleibt die Verarbeitung an einer Zwischenstufe hängen. Und auf manchen Plattformen ist sogar ein zusätzliches BIOS- oder UEFI-Update des Hardware-Herstellers erforderlich, damit die neuen Zertifikate korrekt verarbeitet und tatsächlich für den Boot-Prozess aktiviert werden. Microsoft weist ausdrücklich darauf hin, dass manche Systeme zusätzliche Firmware-Updates benötigen können.

Gerade deshalb reicht die bloße Aussage „Die Zertifikate sind da“ nicht aus. Für Administratoren zählt am Ende nicht, ob ein Eintrag irgendwo sichtbar ist, sondern ob das System nach allen nötigen Schritten wirklich mit der neuen Vertrauenskette arbeitet.

Ein erfolgreiches Update besteht aus mehreren Stufen

Typischerweise beginnt der Prozess damit, dass die Zertifikate in die UEFI-Firmware geschrieben werden. Dabei landen sie in den relevanten Datenbanken der Plattform, also etwa in db für zugelassene Signaturen und dbx für gesperrte oder widerrufene Signaturen. In vielen Umgebungen geschieht das über Windows Update. Microsoft beschreibt dazu einen Update-Mechanismus, bei dem Geräte für die Aktualisierung markiert werden und ein geplanter Task die nötigen Schritte auf dem System ausführt.

Wichtig ist dabei: Das reine Provisioning ist oft noch nicht das Ende des Vorgangs. Microsoft dokumentiert, dass der geplante Task „Secure-Boot-Update“ für die Umsetzung wesentlich ist. Fehlt dieser Task, ist er deaktiviert oder läuft er nicht sauber, kommt der Prozess nicht voran. Genau deshalb kann ein Gerät in einem Zustand bleiben, in dem die Zertifikate zwar vorbereitet oder teilweise übernommen wurden, die eigentliche Aktivierung aber noch aussteht.

Hinzu kommt der Neustart. Erst nach einem Reboot übernimmt die Firmware Änderungen häufig so, dass sie im Boot-Prozess tatsächlich wirksam werden. Wird dieser Neustart aufgeschoben, bleibt ein System schnell in einem halbfertigen Zustand hängen. Und genau diese halbfertigen Zustände sind im Alltag der IT besonders unangenehm, weil sie auf den ersten Blick wie ein Erfolg wirken, technisch aber noch keiner sind. Microsoft verweist in seinen aktuellen Hinweisen ebenfalls darauf, dass solche Statuszustände sichtbar gemacht werden müssen, weil zwischen „Update angestoßen“ und „Update vollständig wirksam“ ein relevanter Unterschied besteht.

Warum große IT-Umgebungen so schnell den Überblick verlieren

Auf einem einzelnen Testgerät lässt sich das meist noch mit vertretbarem Aufwand nachvollziehen. In größeren IT-Landschaften mit hunderten oder tausenden Systemen kippt das Bild schnell. Dort gibt es fast immer Geräte, die noch auf einen Reboot warten, bei denen ein Firmware-Stand nicht passt oder bei denen ein Zwischenschritt fehlgeschlagen ist. Genau dann wird aus einer rein technischen Aufgabe ein operatives Problem.

Windows liefert dazu zwar Hinweise. Microsoft hat den Status rund um Secure-Boot-Zertifikat-Updates inzwischen in der Windows-Sicherheit sichtbarer gemacht. Ab April 2026 zeigt die Windows-Sicherheits-App zusätzliche Informationen zum Zertifikatstatus unter Gerätesicherheit > Sicherer Start an. Für Administratoren ist das hilfreich, ersetzt aber keine Gesamtsübersicht. Einzelne Statusanzeigen und Event-Informationen helfen bei der Analyse, lösen aber nicht das Grundproblem, dass in großen Umgebungen schnell die Gesamtsicht fehlt.

Hinzu kommt, dass Microsoft in seinen Leitfäden ausdrücklich auf Monitoring und Ereignisprotokolle verweist. Der Hersteller macht also selbst deutlich, dass das reine Ausrollen nicht genügt und der Status überwacht werden muss. Genau an dieser Stelle beginnt für viele Unternehmen die eigentliche Herausforderung: Nicht das Verteilen der Zertifikate ist das Problem, sondern die verlässliche Antwort auf die Frage, auf welchen Systemen der Prozess wirklich abgeschlossen ist.

Was das neue Feature in JDisc Discovery sichtbar macht

Genau hier setzt bspw. das neue Feature in JDisc Discovery an. Sein praktischer Wert liegt nicht einfach darin, noch eine weitere technische Detailinformation anzuzeigen. Interessant wird es vielmehr dadurch, dass Administratoren nachvollziehen können, auf welchen Rechnern die Installation der neuen Secure-Boot-Zertifikate erfolgreich war und bei welchen Systemen sie noch nicht oder nicht vollständig abgeschlossen wurde.

Das ist in der Praxis ein großer Unterschied. Denn eine Umgebung wird nicht dadurch sicherer, dass Updates irgendwann angestoßen wurden. Sicherheit entsteht erst dann, wenn sich der tatsächliche Status sauber bewerten lässt. Wer erkennt, welche Systeme bereits vollständig aktualisiert sind und wo Provisioning, Verarbeitung, Reboot oder Firmware-Schritt noch fehlen, kann gezielt nacharbeiten statt im Blindflug zu operieren.

Gerade in großen Umgebungen spart das Zeit und reduziert Risiko. Statt einzelne Geräte manuell zu prüfen oder verstreute Event-Log-Einträge auszuwerten, bekommen Administratoren eine belastbarere Sicht auf den Umsetzungsstand. Und genau diese Transparenz ist bei einem mehrstufigen Prozess wie dem Secure-Boot-Zertifikatswechsel entscheidend.

Nicht nur Clients, sondern auch Server im Blick

Besonders relevant wird das in heterogenen Infrastrukturen. Viele Lösungen konzentrieren sich vor allem auf klassische Windows-Clients, also Laptops und Desktops. Das greift in der Praxis zu kurz. Denn auch Server gehören zur Vertrauenskette des Unternehmens und müssen beim Zertifikatswechsel berücksichtigt werden. Microsoft nennt in seinen Informationen ausdrücklich auch unterstützte Windows-Server-Versionen als betroffen.

Genau deshalb ist es sinnvoll, nicht nur Endgeräte, sondern auch Server sichtbar zu machen. Das gilt besonders dort, wo Server unter Linux laufen und trotzdem Teil derselben Secure-Boot-Strategie sind. Wer nur die Client-Seite betrachtet, erhält schnell ein unvollständiges Bild der eigenen Sicherheitslage. Wer dagegen auch Server in die Bewertung einbezieht, sieht realistischer, wo Zertifikate bereits aktualisiert wurden und wo noch Handlungsbedarf besteht.

Fazit: Entscheidend ist der echte Status

Beim Thema Secure-Boot-Zertifikate ist die wichtigste Erkenntnis am Ende recht schlicht: Importiert heißt noch lange nicht aktiviert. Erst wenn Provisioning, Verarbeitung, möglicher Firmware-Schritt und Reboot erfolgreich abgeschlossen sind, ist ein System wirklich auf dem neuen Stand.

Mit Blick auf Juni 2026 steigt deshalb der Druck, genau diese Transparenz herzustellen. Denn Systeme ohne aktualisierte Zertifikate laufen womöglich weiter, können aber künftige Schutzmechanismen für den frühen Boot-Prozess nicht mehr vollständig übernehmen. Unternehmen brauchen also keine bloße Bestätigung, dass Zertifikate irgendwo gespeichert wurden, sondern Klarheit darüber, welche Geräte und Server tatsächlich bereit sind. Genau darin liegt der Nutzen eines Features, das nicht nur Zertifikate zählt, sondern den echten Umsetzungsstand sichtbar macht.

Über den Autor

Thomas Frietsch ist Senior Softwareentwickler bei der JDisc GmbH. Sein Schwerpunkt liegt auf Softwarelösungen zur automatisierten Netzwerkinventarisierung und -dokumentation. Er verfügt über langjährige Erfahrung in der Entwicklung und Architektur komplexer Systeme für das System- und Netzwerkmanagement.

(ID:50819872)