Die Frist klingt nach einem harten Schnitt: Ab dem 24. Juni 2026 laufen zentrale kryptografische Zertifikate aus, die in der Secure-Boot-Kette von Windows- und Linux-Systemen eine wichtige Rolle spielen. In manchen Darstellungen wird daraus ein nahender Ausfalltag für PCs. Das ist zu grob. Die größere Gefahr liegt nicht darin, dass Millionen Rechner an einem Morgen geschlossen stehen bleiben. Sie liegt darin, dass ein Teil der installierten Hardware nach und nach aus einer Sicherheitskette herausfällt, die kaum jemand sieht, aber sehr früh im Startprozess entscheidet, was ein Rechner überhaupt laden darf.
Secure Boot ist keine Funktion, die Nutzer im Alltag bemerken. Sie sitzt im UEFI, also in der Firmware unterhalb des Betriebssystems, und prüft digitale Signaturen von Komponenten, die beim Start geladen werden. Dazu gehören Bootloader, Firmwarebestandteile und andere frühe Bausteine. Der Zweck ist nüchtern: Code, der nicht aus einer vertrauenswürdigen Quelle stammt, soll gar nicht erst vor Windows, Linux oder Sicherheitssoftware starten können.
Genau dort setzen Bootkits an. Sie sind nicht deshalb gefährlich, weil sie besonders laut auftreten, sondern weil sie vor dem Betriebssystem aktiv werden können. Malware wie BlackLotus oder Angriffe rund um die BootHole-Schwachstelle CVE-2020-10713 zeigen, weshalb diese frühe Vertrauenskette mehr ist als ein technisches Detail für Firmware-Entwickler. Wer den Bootprozess kontrolliert, sitzt tiefer im System als klassische Schadsoftware.
Das Datum ist real, die Panik ist es nicht
Betroffen sind drei von Microsoft signierte Secure-Boot-Zertifikate. Vor allem die Microsoft Corporation KEK CA 2011 und die Microsoft UEFI CA 2011 laufen am 24. beziehungsweise 27. Juni 2026 aus, ein weiteres Zertifikat folgt am 19. Oktober 2026. Diese Zertifikate stammen aus einer älteren Vertrauenskette, die über Jahre hinweg in sehr vielen Windows- und Linux-Systemen genutzt wurde.
Dass Zertifikate auslaufen, ist kein Unfall. Kryptografische Vertrauensanker haben Lebenszyklen. Sie müssen ersetzt werden, bevor sie veraltet oder organisatorisch nicht mehr tragfähig sind. Das Problem entsteht, weil diese Rotation nicht nur eine Datei auf einem Server betrifft, sondern eine weit verteilte Mischung aus Firmware, Betriebssystem, Bootloader, Distributionspaketen und Herstellersupport.
Microsoft hat Updates über Windows Update für Windows 10 und Windows 11 bereitgestellt. Große Linux-Distributionen wie Ubuntu, Fedora und Debian haben ihre Shim-Pakete und den GRUB-Bootloader aktualisiert. Für viele gepflegte Systeme wird die Umstellung daher unspektakulär bleiben. Wer Updates installiert, automatische Aktualisierungen nicht blockiert und keine ungewöhnliche Boot-Konfiguration betreibt, wird vermutlich wenig davon merken.
Das ist die beruhigende Hälfte der Geschichte. Die andere Hälfte betrifft Geräte, die zwar noch genutzt werden, aber nicht mehr sauber in diese Update-Mechanik passen.
Die Schwachstelle heißt nicht Windows oder Linux, sondern Altbestand
Das eigentliche Risiko liegt bei älteren PCs, besonders bei Geräten, die vor Ende 2024 hergestellt wurden oder keine verlässlichen Firmware-Updates mehr bekommen. Solche Systeme können äußerlich völlig normal wirken. Sie starten, sie bekommen vielleicht noch Betriebssystem-Patches, sie stehen in Büros, Werkstätten, Laboren oder Privathaushalten. Trotzdem kann der untere Teil der Sicherheitsarchitektur veralten.
Für Unternehmen ist das unangenehm, weil diese Ebene selten im normalen Patch-Reporting sichtbar ist. Betriebssystemstände lassen sich zentral auslesen. Browser-Versionen ebenfalls. Bei Firmware, Secure-Boot-Datenbanken, KEK-Zertifikaten und dbx-Einträgen wird es schnell heterogener. Unterschiedliche Hersteller, verschiedene Geräteserien, Sonderimages, Dual-Boot-Konfigurationen und lange Nutzungszyklen machen aus einer geplanten Zertifikatsrotation eine operative Prüfung.
Gerade die dbx ist dabei wichtig. Sie enthält gesperrte Signaturen und dient dazu, bekannte unsichere Boot-Komponenten nicht mehr zu akzeptieren. Wenn ein System künftige Sperrlisten-Updates nicht mehr korrekt verarbeitet, wird es nicht zwangsläufig sofort unsicher im sichtbaren Sinn. Es verliert eher die Fähigkeit, auf neue Erkenntnisse zu reagieren. Das ist eine leisere Form von Risiko: Der Rechner funktioniert weiter, aber seine Abwehr auf Boot-Ebene bleibt stehen.
In der Praxis ist genau diese Art von Verfall schwer zu vermitteln. Ein System, das nicht mehr startet, erzeugt ein Ticket. Ein System, das startet, aber keine saubere Secure-Boot-Kette mehr pflegt, erzeugt oft keines. Sicherheit verschlechtert sich hier nicht als Ereignis, sondern als Zustand.
Linux trifft es anders als Windows
Windows-Systeme haben in diesem Fall einen Vorteil: Microsoft kontrolliert einen großen Teil der Verteilung über Windows Update und die eigene Rolle in der Secure-Boot-Infrastruktur. Das macht die Lage nicht trivial, aber zentraler steuerbar. Für Standardgeräte mit unterstützter Windows-Version ist der Weg vergleichsweise klar.
Linux ist komplizierter, nicht weil Linux grundsätzlich unsicherer wäre, sondern weil das Ökosystem anders gebaut ist. Viele Distributionen nutzen den signierten Shim als Brücke zwischen Microsofts Secure-Boot-Vertrauen und dem eigenen Bootloader. Dazu kommt GRUB, dazu kommen Distributionspakete, dazu kommen Gerätefirmwares, die nicht von den Distributionen kontrolliert werden. Ubuntu, Fedora und Debian haben Updates veröffentlicht, aber damit ist nicht jede reale Installation automatisch abgedeckt.
Besonders empfindlich sind Systeme mit Dual Boot, angepassten Bootloadern oder manuellen Secure-Boot-Einstellungen. Dort kann die Grenze zwischen notwendiger Härtung und unerwartetem Startproblem schmal werden. Wer Secure Boot aus Bequemlichkeit deaktiviert, löst zwar manche Kompatibilitätsfrage, gibt aber genau den Schutz auf, um den es geht. Wer es aktiviert lässt, muss dafür sorgen, dass die Vertrauenskette tatsächlich erneuert wird.
Das ist keine elegante Lage. Sie zeigt, wie stark moderne PC-Sicherheit von einer Infrastruktur abhängt, die quer durch Hersteller, Betriebssysteme und Open-Source-Projekte verläuft. Secure Boot sieht für Nutzer wie ein Schalter im BIOS-Menü aus. Tatsächlich ist es ein Vertrag zwischen vielen Beteiligten, und dieser Vertrag muss gepflegt werden.
Gewinner sind die, die den Lebenszyklus kontrollieren
Von solchen Übergängen profitieren vor allem Akteure, die Updatepfade kontrollieren oder Ersatz anbieten können. Microsoft kann seine Plattform über Windows Update absichern und zugleich die zentrale Rolle seiner Signaturen in der PC-Welt bestätigen. Sicherheitsdienstleister bekommen ein weiteres Feld für Audits, Bestandsanalysen und Härtung. Hardwareanbieter haben ein naheliegendes Argument, alte Geräte zu ersetzen, wenn Firmwarepflege unsicher wird.
Die Verlierer sind weniger spektakulär: Nutzer älterer PCs, kleine Unternehmen ohne saubere Geräteinventur, Organisationen mit Sonderhardware und Open-Source-Anwender, die ihre Boot-Konfiguration einmal eingerichtet und dann jahrelang nicht mehr angerührt haben. Für sie ist die Frist kein einzelner Stichtag, sondern ein Test darauf, ob ihr System noch Teil einer gepflegten Sicherheitskette ist.
Das macht die Sache ernster als die üblichen Alarmzeilen, aber auch weniger dramatisch. Es geht nicht darum, dass Windows oder Linux am 24. Juni 2026 plötzlich unbrauchbar werden. Es geht darum, dass Boot-Sicherheit Wartung braucht. Wer sie nicht betreibt, merkt den Schaden womöglich erst dann, wenn ein Angriff genau dort ansetzt, wo Betriebssystem und Virenschutz noch gar nicht laufen.
Die richtige Reaktion ist daher trocken: Updates einspielen, Firmwarestände prüfen, ältere Hardware inventarisieren, Linux-Shim und GRUB aktuell halten, Sonderkonfigurationen testen. Für private Nutzer klingt das nach lästiger Systempflege. Für Unternehmen ist es Bestandsmanagement. In beiden Fällen gilt: Die Frist ist weniger ein Countdown zur Katastrophe als ein Hinweis darauf, welche Rechner im eigenen Umfeld noch gepflegt werden und welche nur noch weiterlaufen.
