Im Juni 2026 laufen UEFI Secure Boot-Zertifikate für Windows ab. Im Oktober 2026 trifft es dann das nächste ablaufende UEFI-Zertifikat für den Secure Boot. Microsoft versucht seit geraumer Zeit, diese Secure Boot-Zertifikat im UEFI auszutauschen. In einem Beitrag im Windows-Blog hat Microsoft sich zum 10. Februar 2026 darüber ausgelassen, was bei abgelaufenen Zertifikaten passiert.
Ablaufende UEFI Secure Boot-Zertifikate
Die vor 15 Jahren erstmals (für Windows 8-Maschinen) ausgestellten und im UEFI von Geräten ausgerollten Secure Boot-Zertifikate laufen im Juni 2026 ab. Microsoft hat im Techcommunity-Beitrag Act now: Secure Boot certificates expire in June 2026 folgende Tabelle mit der Liste der ablaufenden Zertifikate veröffentlicht.
Seit Jahren versucht Microsoft diese ablaufenden Zertifikate mittels Updates zu aktualisieren – aber mit mäßigem Erfolg. Fehlgeschlagene Installationen oder nicht mehr bootende Systeme waren die Folge. Bei manchen Mainboards muss das UEFI vom Hersteller aktualisiert werden, bei anderen kann es per Windows Update erfolgen.
Microsoft hat in den Supportdokumenten zu den Windows Sicherheitsupdates für Windows vom 13. Januar 2026, z.B. für KB5074109 für Windows 11 24H2-25H2, erneut an die in diesem Jahr ablaufenden UEFI-Zertifikate erinnert. Im Januar und Februar 2026 hat Microsoft die nächste Welle an Secure Boot-Zertifikats-Updates gestartet. Im Februar 2026 sollen die aktualisierten Zertifikate breiter ausgerollt werden, nachdem im Januar eine erste Welle für "kompatible Maschinen" bereitgestellt wurde.
Und es rumpelt an allen Ecken und Enden. Zum 3. Februar 2026 ist mir obiger Post auf X von Microsofts Mitarbeiterin ariaupdated untergekommen. Der verweist auf den Microsoft-Beitrag Secure Boot status report in Windows Autopatch und kündigt an, dass Secure Boot Status-Reports in Windows Autopatch verfügbar seien. Ich habe beim Schreiben des Beitrags mal kurz auf die Seite geschaut und folgende Botschaft gefunden.
Important
The Secure Boot status report is temporarily unavailable in Windows Autopatch. This documentation remains published for reference and will be updated when the report becomes available.
Die Halbwertszeit für solche Ankündigungen sinken spürbar, ich tippe auf Probleme – und der Einwurf von MVP Rudy Ooms signalisiert dies ebenfalls.
Was passiert im Juni 2026 bei veralteten Zertifikaten?
Zum 10. Februar 2026 hat Microsoft den Beitrag Refreshing the root of trust: industry collaboration on Secure Boot certificate updates im Windows-Blog veröffentlicht. Dort wird nochmals erwähnt, dass das 2011 vorgestellte Secure Boot eine grundlegende Sicherheitsfunktion von Windows und Windows Server sei, die bereits ab dem Einschalten des Geräts greift. Es trage dazu bei, dass nur vertrauenswürdige, digital signierte Software ausgeführt werden kann. Durch das Blockieren von nicht vertrauenswürdigem Code in der frühesten Phase des Startvorgangs hilft Secure Boot dabei, sich gegen komplexe Bedrohungen zu schützen, die später nur schwer zu erkennen sind, schreibt Microsoft.
Aber was ist, wenn das ablaufende Secure Boot-Zertifikat im UEFI nicht aktualisiert werden kann oder vom Benutzer nicht aktualisiert wird? Bleibt der Rechner nach dem Einschalten mit einer Warnung stehen? Für meine Wenigkeit und viele Leser und Leserinnen war unklar, was genau passiert. Vermutung war: Es passiert nichts, die Systeme booten weiterhin, auch wenn das Secure Boot-Zertifikat abgelaufen ist.
Genau das stellt Microsoft jetzt klar: Hat ein Gerät die neuen Secure Boot-Zertifikate nicht vor Ablauf der 2011-Zertifikate erhalten, passiert nichts. Das System funktioniert weiterhin normal, bootet und die vorhandene Software läuft weiter. Aber es gibt eine Einschränkung:
- Das Gerät wechselt laut Microsoft in einen eingeschränkten Sicherheitszustand, der seine Fähigkeit zum Empfang künftiger Schutzmaßnahmen auf Boot-Ebene einschränkt.
- Im Laufe der Zeit könne dies auch zu Kompatibilitätsproblemen führen, da neuere Betriebssysteme, Firmware, Hardware oder Secure Boot-abhängige Software möglicherweise nicht mehr geladen werden können.
Nun ja, so mancher Nutzer hat Secure Boot auf seinen Rechnern deaktiviert – bei Linux muss man sich derzeit auch keine Gedanken um Secure Boot-Zertifikate machen. Und Windows 10-Systeme werden auch mit Secure Boot ohne Zertifikatsupdates weiter laufen. Lediglich neue Windows-Versionen werden möglicherweise auf solchen Maschinen Probleme bereiten. Wobei ich das eher als "theoretische" Möglichkeit sehe, denn neue Windows 11-Versionen werden eh immer mehr Hardware-Anforderungen stellen, so dass ein Secure Boot-Zertifikat das geringere Übel darstellt. Und neuere Geräte sollten bereits mit den 2023er Secure Boot-Zertifikaten ausgeliefert werden. Weitere Details sind im Microsoft-Beitrag Refreshing the root of trust: industry collaboration on Secure Boot certificate updates nachzulesen.
Ähnliche Artikel:
Microsofts UEFI Secure Boot-Zertifikat läuft im Juni 2026 ab
Achtung: Microsofts UEFI Zertifikat läuft am 19. Okt. 2026 aus – Secure Boot betroffen
Frage: BlackLotus-Schwachstelle und ablaufendes UEFI-Zertifikat – was droht uns?
Windows 10/11 KB5053484: Neues PS-Script für Zertifikate in Boot-Medien
Windows 10: Chaos beim Austausch neuer Secure Boot-Keys?
FAQ und Script zur Secure Boot-Absicherung gegen CVE-2023-24932 (Black Lotus)
Windows Januar 2026 Update tauscht Secure Boot Zertifikat
MVP: 2013 – 2016
Von einem seriösen Lieferanten würde man ja erwarten, dass er ein Programm (oder Äpp) bereitstellt, das der normale Benutzer einfach starten kann und welches den Status der betreffenden Zertifikate anzeigt (grün=OK, rot=Handlungsbedarf).
Als besonderen Luxus könnte so ein Programm dann sogar anbieten, nicht aktuelle Zertifikate direkt auszutauschen.
Ich weiß, ich bin ein Träumer …
Träumer in der Tat! Vergleiche doch mal "whynotwin11" von einem Drittanbieter (schnelle, klare, einfache Auflistung, warum auf einem PC kein Win11 läuft – in einer simplen .exe ohne Installation) mit der "Lösung", die MS dafür angeboten hat. Einfach und clever kann man dort nicht, macht sich statt dessen vermutlich ewig Gedanken über die "User experience".
Mein einer Rechner hat mit den Februarupdates die Zertifikate aktualisiert bekommen. Asus-Board 650 irgendwas für AMD. Nach dem BIOS Update Stand 12/25 waren die noch nicht da.
Ein kleines Prüftool wäre aber schon schön, das die Powershell-Funktion etwas einrahmt
Gibt es Infos zu virtuellen Maschinen? Wer kümmert sich da?
so als Einstieg:
if(!(Get-Module -ListAvailable -Name 'UEFIv2')){
Install-Module 'UEFIv2' -scope CurrentUser -Force -Confirm:$false
}
Import-Module -Name UEFIv2
und dann schauen ob die neuen verfügbar sind:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
Ergebnis ist true oder false, wenn noch nichts da ist. Ich hatte noch diesen Registry-Eintrag gemacht:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x200 /f
Das Hyper-V Team will im März ein Update veröffentlichen wo die Zertifikate für 2023 eingebaut werden.
https://github[.]com/microsoft/secureboot_objects/issues/318
Wir ignorieren das Thema erstmal und warten ab. Mit Einschränkungen rechnen wir nicht.
Ich verweise mal auf die Deskmodder-Seite – dort wird von einem Script gesprochen, mit dem man den Status der Zertifikate prüfen können soll:
httpx://www.deskmodder.de/blog/2026/02/10/was-passiert-wenn-die-secure-boot-zertifikate-unter-windows-11-und-windows-10-ablaufen/
Wenn sich die Zertifikate so einfach austauschen lassen, dann müsste das auch für Malware möglich sein.
Und darüber kann dann die ganze Secure Boot Funktion ausgehebelt werden.
Um das zu verhindern müssten die Zertifikate schreibgeschütz sein und sich nur per BIOS-Update austauschen lassen.
Wobei man die Zertifikate gar nicht austauschen müsste, wenn die gleich eine entsprechend lange Laufzeit hätten.
Z.B. anstatt 15 Jahre 30 Jahre.
| Wobei man die Zertifikate gar nicht austauschen müsste, wenn die gleich eine
| entsprechend lange Laufzeit hätten.
Das ist ein Trugschluss. Das würde nur funktionieren, wenn beim Rechnererwerb jeweils ein neues 30 Jahre gültiges Zertifikat erzeugt und installiert wird. Wird ein Rechner aber ~ 18 Monate vor Ablauf des aktuell noch gültigen Zertifikats gekauft, muss dieses halt innerhalb der nächsten 18 Monate ausgetauscht werden, wenn man die Funktionalität darüber hinaus nutzen möchte.
Das ist ein Trugschluss:
Heutige Rechner halten gar nicht so lange. Mein PC ist mit Baujahr 2011 (i7-2600) schon ein Methusalem, aber 30 Jahre Nutzungsdauer wage ich zu bezweifeln …
Wobei das nicht zwangsläufig am Versagen der Hardware liegt, sondern an den Einsatzzwecken, die von Jahr zu Jahr immer höhere Leistung einfordern. Selbst das Surfen im WWW lässt 10 Jahre alte CPUs doch arg ins Schwitzen kommen, es sei denn, sie fielen beim Kauf in oder in die Nähe der High-End-Kategorie. Dann geht da durchaus noch was.
das Zertifikat müsste natürlich auf lange bevor es abläuft für neue Geräte ausgetauscht werden, z.B.: 10 Jahre vor Ablauf.
For those who want to update Certs on the Firmware level but leave Windows untouched a short guide.
=============================================================
SECURE BOOT KEK/DB/DBX ENROLLMENT — LINUX LIVE GUIDE
=============================================================
SAFETY NOTES:
– Boot in UEFI mode with Secure Boot ENABLED in BIOS
– This updates your UEFI firmware NVRAM — Windows OS is untouched
– Existing keys are preserved unless you explicitly remove them
– Manual download URLs are official Microsoft sources
– If a dry-run lists keys for removal, use the manual add-only path
————————————————————-
1. Boot Linux Live (Fedora or Mint)
————————————————————-
# Fedora:
# Boot Fedora Live USB in UEFI mode → "Try Fedora"
sudo -i
# Linux Mint:
# Boot Mint Live USB in UEFI mode → "Try Linux Mint"
sudo -i
————————————————————-
2. Install sbctl
————————————————————-
# Fedora:
dnf update -y
dnf install sbctl -y
# Linux Mint / Ubuntu:
apt update
apt install git make gcc -y
git clone https://github.com/f-secure-foundry/sbctl.git
cd sbctl
make
make install
————————————————————-
3. Optional: Export current firmware keys (backup)
————————————————————-
mkdir /tmp/secureboot_backup
sbctl export-keys –directory /tmp/secureboot_backup
# Saves PK.cer, KEK.cer, DB.cer, DBX.cer
————————————————————-
4. Inspect current Secure Boot state
————————————————————-
sbctl status
# Records existing key hashes/sizes for comparison
————————————————————-
5. DRY-RUN: simulate automatic enrollment
————————————————————-
sbctl enroll-keys –microsoft –dry-run
Check the output:
– Keys listed under "To be added:" should include:
* Microsoft Corporation KEK 2K CA 2023
* Windows UEFI CA 2023
* (Optionally) Microsoft UEFI CA 2023
– There should be no unexpected keys under "To be removed:"
– If no removals and adds look correct, it is safe to proceed
– If any existing critical keys are going to be removed, stop and use manual add-only path
————————————————————-
6. PATH A — Automatic (if dry-run looks clean)
————————————————————-
sbctl enroll-keys –microsoft
# Downloads latest Microsoft keys and enrolls them
————————————————————-
7. PATH B — Manual add-only (if dry-run shows removals)
————————————————————-
7.1 Download certificates manually:
– Microsoft KEK 2K CA 2023 (KEK):
https://go.microsoft.com/fwlink/?linkid=2239775
– Windows UEFI CA 2023 (DB):
https://go.microsoft.com/fwlink/?LinkId=2239776
– Microsoft UEFI CA 2023 (DB):
https://go.microsoft.com/fwlink/?linkid=2239872
– Microsoft Option ROM UEFI CA 2023 (DB):
https://go.microsoft.com/fwlink/?linkid=2284009
# Save these files into /tmp/ms_keys/
7.2 Dry-run manual add
sbctl enroll-keys –manual /tmp/ms_keys –dry-run
# Verify no removals appear in output
7.3 Apply manual add-only
sbctl enroll-keys –manual /tmp/ms_keys
————————————————————-
8. Verify enrollment
————————————————————-
sbctl status
# KEK, DB, DBX should show new 2023 cert hashes
# Old keys still present
————————————————————-
9. Reboot back to Windows
————————————————————-
– Remove Live USB
– Boot normally
– Optional PowerShell verification:
Confirm-SecureBootUEFI → True
Get-SecureBootUEFI -Name KEK
Get-SecureBootUEFI -Name db
Get-SecureBootUEFI -Name dbx
————————————————————-
Relevant Official Information
————————————————————-
– Microsoft guidance on Secure Boot certificate expiry and new 2023 CAs:
https://support.microsoft.com/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e
– Microsoft Secure Boot certificate binaries repository:
https://github.com/microsoft/secureboot_objects/releases
– Microsoft KEK/CA download links:
KEK 2K CA 2023: https://go.microsoft.com/fwlink/?linkid=2239775
Windows UEFI CA 2023: https://go.microsoft.com/fwlink/?LinkId=2239776
Microsoft UEFI CA 2023: https://go.microsoft.com/fwlink/?linkid=2239872
Microsoft Option ROM UEFI CA 2023: https://go.microsoft.com/fwlink/?linkid=2284009
————————————————————-
Safety Recap
————————————————————-
– Dry-run first and inspect output
– Use manual add-only if removals are flagged
– Export existing keys as a backup
– No cleanup needed — keys persist across reboots
– Updates firmware only; Windows remains untouched
=============================================================
Danke :-)
Das seht ja fast so einfach aus wie die kursierenden Powershell-Lösungen :-D
Mal sehen, welche Methode mein Schwiegervater bevorzugen wird.
Ich las mal (finde den Link gerade nicht, kann ihn aber, wenn gewünscht, nachreichen), das man nach solchen Verrenkungen sein UEFI nicht mehr updaten kann, sollte es vom Boardhersteller später noch Updates geben. Daher wäre so etwas eher für "end of life/out-of-support"-Hardware geeignet. Stimmt das?
Ich würde etwas widersprechen, dass man sich bei Linux keine Gedanken machen muss. Wenn man eine Distribution wie Ubuntu oder Fedora nutzt, bieten diese einen von Microsoft signierten shim loader, der derzeit von der "Microsoft UEFI CA 2011" signiert ist. Man kann also prinzipiell mit meist vorinstallierten Standardzertifikaten Secure Boot aktiv haben.
Wenn diese Distributionen aber mal einen neuen shim loader verteilen müssen, der dann wieder von Microsoft signiert ist, wird (nach meinem Verständnis) dieser von der neuen "Microsoft UEFI CA 2023" signiert sein, da die alte CA ausläuft.
Vertraut das UEFI dieser CA noch nicht, wird es da auch Probleme geben, bzw. man muss Secure Boot dann abschalten, damit das OS doch starten kann.
Du hast insofern Recht, wenn man bei Linux auf Secure Boot setzt. Ich habe auf meinem Mint-Notebook Secure Boot im UEFI deaktiviert, um ggf. mit Virtualbox arbeiten zu können.
Das verstehe ich nicht:
Zitat 1:
"Hat ein Gerät die neuen Secure Boot-Zertifikate nicht vor Ablauf der 2011-Zertifikate erhalten, passiert nichts. Das System funktioniert weiterhin normal, bootet und die vorhandene Software läuft weiter."
—
Sobald die 2011-Zertifikate abgelaufen sind und es die 2023-Zertifikate im UEFI nicht gibt, dann verweigert die Secure-Boot-Funktion im UEFI das Starten des Bootloaders.
Würde es trotzdem funktionieren, dann wäre Secure-Boot völlig sinnlos.
Zitat 2:
"Das Gerät wechselt laut Microsoft in einen eingeschränkten Sicherheitszustand"
—
Ist das eine Umschreibung dafür, dass Secure-Boot einfach abgeschaltet wird?
Darauf deutet Zitat 3 hin:
"Secure Boot-abhängige Software möglicherweise nicht mehr geladen werden können."
—
Klar, wenn Secure-Boot deaktiviert ist, dann funktionieren Anti-Cheat Kernel-Module und davon abhängige Spiele nicht mehr.
Das "möglicherweise" kann man getrost streichen.
Es funktioniert garantiert nicht mehr.
Microsoft hätte auch Klartext reden können:
Wenn das neue Zertifikat nicht da ist, dann schalten wird Secure-Boot ab, kurz bevor das alte Zertifikat abgelaufen ist.
Wenn Windows die Secure-Boot-Funktion im UEFI abschalten kann, dann ist dieser Schutz sinnlos.
Sowas dürfte normalerweise nur ein Admin selber direkt im UEFI machen dürfen.
Die Tatsache, dass Anti-Cheat Kernel-Module von Windows geladen werden, konterkariert Secure-Boot ebenfalls, denn das bedeutet, dass Microsoft potentielle Rootkits mit einem Secure-Boot-Zertifikat zertifiziert. Microsoft wird nämlich nicht den Quellcode von jeder Version dieser Anti-Cheat-Module analysieren.
Meine Lesart ist etwas anders – ob ich unrecht habe, wird sich dann ab Juni 2026 zeigen. Solange ein signiertes Microsoft UEFI Secure Boot-Zertifikat vorhanden ist, startet das bestehende System – auch wenn das Zertifikat abgelaufen ist. Es war ja seit 2011 gültig. Erst wenn dieses Zertifikat fehlt oder manipuliert wurde, streikt der Boot-Lader.
Microsoft könnte – so interpretiere ich den Hinweis – irgendwann künftig in neuen Windows-Versionen (oder Builds) den Boot-Loader so modifizieren, dass dieser ein abgelaufenes Secure Boot-Zertifikat wie ein fehlendes oder manipuliertes Zertifikat behandelt.
Ich hatte angenommen, dass das UEFI auch das Ablaufdatum eines Zertifikats berücksichtigt, das Zertifikat bei Überschreitung des Ende-Datums als "fehlend" oder "ungültig" wertet und nicht mehr bootet.
Falls das nicht der Fall sein sollte, dann ist der ganze Aufstand mit dem Zertifikattausch unnötig, weil er auch bei ungültigem Zertifikat bootet.
Eventuell gibt es auch Unterschiede zwischen den Mainbordherstellern, wie sie die Zertifikate bewerten.
Vielleicht bootet es auf MSI, aber nicht auf ASUS oder Gigabyte?
NAJA….:
– Die Systeme grundsätzlich auch weiterhin booten, da die Gültigkeit (Ablaufdatum) der Zertifikate offensichtlich beim Bootvorgang nicht überprüft werden. Das läst sich auch leicht nachstellen/ausprobieren.
Aber
– Die meisten Admins machen wahrschleinlich die Prozesskette 5944, welche die Schritte 80 (CA 2011 in die DBX) und 200 (SVN) nicht enthalten. Sonst sieht die Sache etwas anders aus.
– Außerdem ist auch denkbar, dass die hersteller irgendwann Bios-Updates bringen, bei denen CA 2011 bereits in der DBX ist.
Es gibt schon Konstellationen, bei denen Systeme nicht mehr booten würden
Es wird auch Probleme mit DRM-geschützten Medien geben, denn die werden nur auf einer "trustet Platform" abgespielt und diese verlangt Secure-Boot.
Wird Netflix etc noch funktionieren, wenn das Secure-Boot-Zertifikat im UEFI abgelaufen ist?
Für Intune war der Artikel recht hilfreich > https://www.tbone.se/2026/01/09/update-secure-boot-certificate-by-using-intune-remediation/
Endlich werden die Rechner mit Secure Boot sicher, wenn sich nach Ablauf der Certs dann kein Windows mehr booten. Mit Sicherheit hat Secure Boot nichts zu tun. Es ist typische Scheinsicherheit von Microsoft. Ein Bootloader ist mit einem Zertifikat signiert, dem die jeweilige Hardwareplatfrom vertraut, was der Bootloader dann wirklich bootet spielt ja keine Rolle. Oder wie nochmal unterbindet MS jetzt das einer verseuchte Windows Installationsmedien in die Welt bringt?
Eher ist das wieder so eine Blase, die den Hardwareherstellern neue Verkäufe bringt. Denn wer sein Bios nicht Updated mangels fehlender Updates bzw. es so Verbaut, dass MS es nicht Updaten kann, der sorgt zwangsläufig dafür, dass mit Secure Boot dann ab Oktober neue Hardware benötigt wird.
Musste MS nicht schon mal vor Jahren was machen, weil ihre Secure Boot doch nicht so Secure war?
Tolle Abhängigkeiten die da wieder geschaffen werden für ein System, das so ziemlich nichts mit Security am Hut hat.
Edit: Weil hier immer nur von Client OS die Rede ist, was ist mit den ganzen Server Systemen ab Windows Server 2012 R2 mit ESU bzw. generell 2016, 2019 und höher. Da machen die besagten Updates wohl nichts. ich hab noch nie erlebt, dass am Patchday der Server 2019 je ein Winre Update gemacht hätte. Das haben wir nun händisch aktualisiert bei den Servern bei uns mit Secure Boot.
Wie immer Microsoft erzwingt irgendwas und lässt dann die Kundschaft dumm im Regen stehen.