Am 24. Juni 2026 laufen die ersten Secure Boot-Zertifikate für Windows-Systeme (und für Linux-Systeme, sofern die Secure Boot nutzen) ab. Microsoft versucht seit Monaten, mithilfe der IT-Administratoren, die Systeme mit neuen Secure Boot-Zertifikaten zu aktualisieren. Scheint aber nicht immer einfach – heute noch ein kurzer Blick auf die Gemengelage.
Ablauf der Secure Boot-Zertifikate zum 24.6.2026
Zum 24. Juni 2026 laufen die ersten Secure Boot-Zertifikate, die vor 15 Jahren (2011) für Windows 8-Maschinen ausgestellt wurden, 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.
Ich hatte hier im Blog seit geraumer Zeit auf diesen Umstand hingewiesen (siehe Links am Artikelende). Betroffene Windows-Maschinen werden auch nach dem Ablauf der Secure Boot-Zertifikate starten – sagt zumindest Microsoft. Aber diese Maschinen bekommen dann keine Sicherheitsfixes mehr, die sich auf den Secure Boot-Vorgang beziehen.
Microsoft versucht seit vielen Monaten die ablaufenden Zertifikate per Windows Update zu aktualisieren. Das ist aber nicht immer erfolgreich, wie diverse Rückmeldungen aus der Leserschaft ergeben haben.
Lesererfahrung HP Workstation Update
Blog-Leser Dr. Josef Z. hat mich vorige Woche per Mail kontaktiert und seine Erfahrungen mit dem HP-Support für das Secure Boot 2023-Update geschildert. Ich stelle die Information mal hier im Blog ein.
Der Leser nutzt seit April 2022 u.a. eine HP Workstation Z4G4 (HP Commercial Plattform, Typ:1JP11AV9 mit einem Intel Xeon W2225 Prozessor). Nun stand der Leser vor dem Problem, diese HP Workstation mit dem Secure Boot 2023-Update zu aktualisieren.
Zur Vorbereitung auf die Installation neuer Secure Boot-Zertifikate von Windows erwies sich laut Leser (vermeintlich) eine HP Veröffentlichung HP Business PC – Vorbereitung auf neue Secure Boot-Zertifikate von Windows zu diesem Thema als informativ. Diese Veröffentlichung wurde mehrfach revidiert (derzeit in 5. Revision). Meine Workstation (Bios Version HP P61 V02.75 vom 28.09.2021, dürfte das Produktionsdatum sein) hat nach der Veröffentlichung ihre EOL noch nicht erreicht und erhält BIOS-Updates (Firmware Updates). Wegen diverser Probleme bei HP dürften viele Nutzer (so auch der Leser), soweit möglich BIOS-Updates meiden. Der Leser hat daher Firmware-/Treiber-Updates durch Microsoft deaktiviert.
BIOS-Version als Voraussetzung für Secure Boot-Update
Spannend wurde es laut Leser durch die Ausführungen im Abschnitt "Installieren und Verwalten neuer Secure Boot-Zertifikate" im Absatz 1 "Aktualisieren des System-BIOS" der HP-Anleitung.
Dort wird gefordert, dass bei unterstützten HP PCs mit BIOS in einer Mindestversion neue Secure Boot-Zertifikate nur dann installiert werden können, wenn das Versionsfeld SMBIOS Type1 die Teilzeichenfolge SBKPFV3 enthält. Diese Teilzeichenfolge ermöglicht kumulativen Windows-Updates die neuen Secure Boot-Zertifikate dem aktiven UEFI-KEK und der Datenbank im Laufe des Jahres 2026 hinzuzufügen.
Ist im Versionsfeld SMBIOS Type1 die Teilzeichenfolge SBKPFV3 nicht enthalten, benötigt das System ein HP BIOS-Update mit definierter Mindestversion, um diese neuen Zertifikate vorzubereiten. Die Prüfung kann durch Ausführen des folgenden Befehls in der Powershell erfolgen:
(Get-CimInstance -ClassName Win32_ComputerSystemProduct).Version
Mit SBKPFV3 markiert HP offenbar BIOS-Versionen, welche den Schutzmechanismus von HP Sure Start (HP Produkt neben Secure Boot) ändern, um Updates der UEFI Zertifikate zu ermöglichen, nimmt der Leser an. Er hat dazu nur diese Information gefunden.
HP hat dazu in oben verlinkter Veröffentlichung eine Liste mit unterstützten HP Commercial Plattformen und BIOS-Mindestversionen integriert, welche, bis zur 4. Revision, für die HP Z4 G4 Workstation (Xeon W) (Abschnitt Desktop Workstations) die Bios Version HP P61 02.97 Rev.A vom 13.08.2025 (sp161764) als Mindestversion festlegte.
Ab Revision 5 dieser Veröffentlichung änderte sich dies grundlegend, indem für alle Workstations der Generation 4 (…G4) und der BIOS-Familie P… keine BIOS-Mindestversionen, SoftPaq-Nr und SoftPaq-Links definiert werden ("n.v."), dafür aber jeweils folgender Verweis (Stern) erfolgt:
Anmerkung: * Bei diesem System unterstützt Microsoft neue Secure Boot-Zertifikate ohne die Teilzeichenfolge „SBKPFV3". Halten Sie Ihr System mit Microsoft Update auf dem neuesten Stand, um die neuen Zertifikate zu erhalten.
Der Leser schrieb: Demnach scheinen (wenn ich es positiv interpretiere) HP und M$ offenbar eine Möglichkeit gefunden zu haben, ohne BIOS-Updates und damit eventuell ohne die Teilzeichenfolge "SBKPFV3" , die Zertifikate via Windows Update zu installieren. Glaubhaft ist dies für mich bei diesen Firmen nicht und mein Verdacht sollte sich auch als zutreffend erweisen!
Neue HP BIOS-System-Firmware Version 03.00 Rev A
Der Leser schrieb dazu, dass HP seit dem 22.05.2026 dann eine BIOS-System-Firmware Version 03.00 Rev A (sp173140) für die HP Z4-G4 Xeon Workstation im Angebot habe, welche u.a. neu "support for updated UEFI Certificate Authority (CA) 2023 keys" erwähnt.
Der neue Support für die Keys ist im HP-Artikel Alle HP Commercial- und Workstation-Computer – Computer bleibt nach einer Aktualisierung des BIOS in der BitLocker Wiederherstellungsschleife hängen zu sehen, auf den in der HP-Veröffentlichung im Abschnitt "Bekannte Probleme" verwiesen wird (Bitlocker Loop).
Bemerkenswert sei es in diesem Zusammenhang auch, schrieb der Leser, dass in der Liste der unterstützten Plattformen für Updates der BIOS-Zertifikate, die neue BIOS-Version 03.00 Rev A nicht als Mindest-Biosversion für die HP Z4G4 einfügt wurde. Das heißt, neue Secure Boot-Zertifikate wären demnach weiterhin (mittels Microsoft-Updates) ohne die Teilzeichenfolge "SBKPFV3" zu installieren.
Erfahrungen zu Microsofts Vorgehen beim Zertifikate-Update
Der Leser hat nach diesen HP-Empfehlungen kein BIOS -Update vorgenommen (n.v.) und die monatlichen Updates von Microsoft verfolgt. Die automatischen Updates der Zertiikate starteten (definitionsgemäß auch ohne Teilzeichenfolge SBKPFV3), jedoch wurden in einer ersten Phase (etwa 3 Monate) Daten gesammelt.
Dann hat Microsoft (ab etwa April 2026) die Zertifikatsupdates für den sicheren Start für bestimmte Gerätekonfigurationen vorübergehend angehalten, während ein bekanntes Kompatibilitätsproblem von Microsoft und seinen Partnern untersucht wird. Das Update soll automatisch fortgesetzt werden, sobald das Problem behoben wurde. Letzteres bedeutet, nach den Recherchen des Lesers, dass ein Firmware Update seitens des OEMs benötigt wird.
Das umfangreiche Juni 2026-Update hat der Leser, vorausschauend, 5 Wochen pausiert. Das hat aber nichts genutzt, denn Microsoft startete das Update, so der Leser, knapp nach dem Juni-Patchday, ungefragt im Hintergrund samt dem Secure Boot-Update. Das Secure Boot-Update missglückte mit der Meldung, dass das automatische Update des Zertifikats für sicheres Starten aufgrund von Hardware- und Firmwar-Einschränkungen vom Gerät nicht unterstützt wird. Der Administrator solle sich an den Gerätehersteller wenden um Unterstützung zu erhalten.
Ereignisanzeige zeigt Fehler 1802, 1797
In der Ereignisanzeige werden dazu, so der Leser, für UEFI CA 2023 (DB), Option ROM CA 2023 (DB), 3P UEFI CA 2023 (DB), KEK 2023 bekannte Firmwareprobleme angegeben, wodurch das Update blockiert wird (ConfidenceLevel: High Confidence; Errors 1802, 1797; SkipReason: KI_7 )
Nach den Einträgen in der Registry wurde das Update mit der Bitmask 0x5944 in bekannter Weise getriggert (ergänzte der Leser). Nach dem UEFI CA 2023-Status: InProgress ist das Update noch aktiv und das System daher wohl in einem undefinierbaren Zustand.
Auf der patchmanagement.org-Mailing-Liste ist mir die Diskussion For Secureboot certificate installation is anyone seeing repeated 1801 events? untergekommen. Dort erwähnen Teilnehmer ebenfalls Einträge in der Ereignisanzeige, die in Verbindung mit dem Secure Boot-Zertifikat und dessen Update stehen. Dort geht es auch um Dell-Systeme und es heißt, viele Systeme benötigten BIOS-Updates, um die Zertifikate aktualisieren zu können.
Was bedeutet SkipReason: KI_7?
Der Leser hat dann nachgeschaut, was SkipReason KI_7 bei der HP-Firmware bedeutet und ist auf folgende Definition gestoßen:
Dieses HP-Gerät hat ein bekanntes Kompatibilitätsproblem bei Updates für den sicheren Start. Updates für betroffene Modelle werden übersprungen, um Probleme zu vermeiden, die auftreten können, wenn das erforderliche Firmwareupdate fehlt. Kunden können bei HP überprüfen, ob aktualisierte Firmware verfügbar ist, die dieses Problem behebt und das Update für den sicheren Start ermöglicht. Weitere Informationen finden Sie unter HP-PCs – Vorbereiten auf neue Windows Secure Boot-Zertifikate | HP-Support".
Der Leser schreibt dazu: "Letzterer Verweis auf die HP-Veröffentlichung führt wieder zum Anfang dieses Schreibens und zur "SBKPFV3"- Problematik". Sprich: HP weiß selbst nicht, was man da tut. Der Leser fragt: "Was nützt das Pausieren von Updates, um bekannte Kompatibilitätsprobleme angeblich zu lösen und die Updates (ohne Lösung) doch zu starten und das System zu gefährden?
Der Leser ist dann auf reddit.com auf den Thread HP lügt offensichtlich über Secure Boot 2023 CA-Unterstützung gestoßen. Die sehr informative Diskussion auf Reddit trifft auf den Problemfall des Lesers (HP, G4-Modelle, Bios, etc.) weitgehend zu. Beim Studium der Beiträge in dieser Diskussion wurde dem Leser bewusst, dass die (leeren) Einträge "n.v." in der HP-Liste und das Ausklammern der Teilzeichenfolge "SBKPFV3" so zu interpretieren sind, dass HP für die Installation kein BIOS-Update zur Verfügung stellen kann und damit dem Vorwurf der Lüge ausweicht. Die Verantwortung wird auf die Updates von Microsoft verlagert, welche aber ohne angepasstes BIOS offensichtlich nicht funktionieren.
Wenn die Katze sich in den Schwanz beißt
Der Leser merkt an, dass die (neue) BIOS-System-Firmware Version 03.00 Rev A als Mindestversion die Kompatibilitätsprobleme offensichtlich auch nicht zu lösen scheint. Über das weitere Vorgehen zeigt sich der Leser unschlüssig. Zudem hegt er große Bedenken, ob der PC nach einem BIOS-Update, während einem unterbrochenen aber noch aktiven Update-Vorgangs, noch bootet (Zustand von Sure Start nach Bios-Update zudem ungewiss). Der Leser schrieb: "Ich habe dabei kein Zutrauen zu HP (vgl. Bitlocker Loop, etc.). Bliebe das Abschalten von SecureBoot oder der Umstieg auf Linux (funktioniert auf dieser Workstation).
Dass die automatische Installation von Zertifikaten bei älteren PCs (Windows 11, ohne Bitlocker, ohne Microsoft-Konto) bei Windows Updates völlig problemfrei funktioniert, hat der Leser bei seiner Dell Workstation T5820 aus dem Jahr 2018 erlebt (lediglich ein außerplanmäßiger Neustart zum Umbenennen von neuen Zertifikaten war erforderlich).
Der Leser schrieb, dass er HP-Geräte sicherlich nicht mehr kaufen werde, er will diesen Ärger und die vielen damit verbundenen Recherchen nicht mehr haben.
Nächster Ärger vorprogrammiert?
Der Leser merkt an, dass die nächsten Probleme mit den Windows-Start-Manager-Sperrungen für Änderungen und deren Verwaltung bereits warten und verweist auf den Microsoft-Supportabschnitt Aktualisieren der Windows-Installationsmedien.
In einer weiteren Nachtrags-Mail ergänzt der Leser, dass sein Verdacht, dass das in der HP Workstation integrierte System HP Sure Start (Hard- und Software) zur Laufzeit UEFI Secure Boot Zertifikate und deren Abspeicherung in der Firmware überwacht und gegebenenfalls auch sperrt (db,dbx, KEK, KEK) u.a. auf Seite 12 der HP Veröffentlichung "HP Sure Start Whitepaper"- Abschnitt "Secure boot keys protection" ausführlicher beschrieben ist.
Dieser Schutzmechanismus ist standardmäßig aktiviert (vgl Seite 20, "HP Sure Start provides superb firmware protection" ), habe aber in dem umfangreichen White Paper keinen Hinweis gefunden wie dieser Mechanismus deaktiviert werden kann (vgl. Seite 18 "HP Sure Start provides superb firmware protection").
HP Sure Start ist laut Leser bei Microsoft-Updates bereits unangenehm aufgefallen. Der Leser hat die Webseiten Computers stuck in startup-loop "Protected by HP Sure Start" after installing June 14, 2022—KB5014699 und HP Business Produkte – Bei kommerziellen Produkten (2017 – 2023) mit Sure Start tritt nach der kumulativen monatlichen Betriebssystemaktualisierung von Microsoft beim Systemstart möglicherweise eine Fehlermeldung von Secure Boot (Sicherer Systemstart) auf als belegt verlinkt.
Der Leser wird für die HP Workstation Z4G4 Sure Start/ Secure Boot beide deaktivieren. Bei administrator.de bin ich die Tage über diese Diskussion zur Zertifikatsaktualisierung beim HP Elitedesk 400 G6 (Desktop Mini PC) gestoßen. Hört sich alles nicht nach einem Easy Going an. Wie sind die Erfahrungen in der Leserschaft diesbezüglich?
Ä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
Windows 10: Chaos beim Austausch neuer Secure Boot-Keys?
Windows Januar 2026 Update tauscht Secure Boot Zertifikate
FAQ und Script zur Secure Boot-Absicherung gegen CVE-2023-24932 (Black Lotus)
Windows und das (BlackLotus) Secure Boot-Desaster: Wie ist bei euch der Status?
Was passiert, wenn im Juni 2026 Windows Secure Boot-Zertifikate auslaufen?
Windows Server für Secure Boot-Zertifikat-Updates vorbereiten
Windows Secure Boot und der Zertifikatswechsel: Microsoft Video-Session
Secure Boot-Zertifikatswechsel: Ein Playbook von Microsoft – Teil 1
Secure Boot-Zertifikatswechsel: Es gibt Hürden beim Austausch – Teil 2
Windows Secure Boot News-Splitter (Mai 2026): Sample Secure Boot E2E Automation Guide
Microsoft-Hinweise zu Secure Boot-Zertifikate-Updates für Linux- und Azure-VMs
MVP: 2013 – 2016
Für einen imo minimalen Gewinn an Sicherheit ein riesiger Berg Arbeit und Ärger.
Als alter Knochen habe ich ein anderes Verständnis von sinnvoller Technik und bin froh, dass ich auf Windows 11 nicht angewiesen bin.
Gruß
R.G.
Treffend gesagt. Irgendwie auch praktisch, wenn man neuen Konsum anschieben kann, in dem man alte Rechner ins Abseits schiesst. So ein ganz klein wenig drängt sich mir da der Gedanke an geplante Obsoleszenz auf.
Aktuell gehen etliche Rechner mit Bootschleifen ausser Betrieb, die nur eine 100MB Startpartition haben. Diese Rechner werden dann gleich meist erneuert. Oftmals Rechner aus der Win10-Zeit, die auf Win11 hochgezogen wurden.
früher™ war das alles kein Problem, da waren BIOS Chips gesockelt, im Ernstfall hast du einfach vom Hersteller ein gefixten neuen Chip bekommen… Gibt auch heute noch einige Modelle wo gesockelt sind, aber da muss man suchen (die Hersteller geben das auch nicht unbedingt an, muss man tiefer recherchieren)…
Gigabyte und Asus Boards problemlos alle bereits "upgegraded" (auch wenn ich kein W11 und SecureBoot / TPM nutze)
Firma: Rigs werden alle 3 bis 4 Jahre ersetzt, ist erst passiert: alle aktuelle Zertifikate…
Geht bei vielen Gaming Boards auch.
Autarkes Subsystem flasht auf Knopfdruck Bios von USB-Stick.
Geht sogar ohne Speicher und CPU.
Für Gamer die gerne mit dubiosen Bios Mods das letzte an "Leistung" rauskitzeln.
Funktioniert aber nicht wenn der BIOS Baustein kaputt ist!
Fehler beim flashen ja das bügelt der wieder hin wenn der Baustein aber harwareseite hinüber ist, ist nix mehr mit flashen, da hilft nur ein Bausteintausch, was bei verlöteten Teilen doch nicht jedermanns Sache ist!
Ein aktuelles SPI NOR Flash lässt sich mindestens 100.000 mal löschen und neu beschreiben und das auch noch doppelt, da es fast immer zwei getrennt lösch- und programmierbare Speicherbereiche für den Fall gibt, wenn etwas schief geht.
Die Zeiten wo sich sowas nur 10 bis 100 neu programmieren hat lassen waren im letzten Jahrtausend. Lang lang ist's her.
Anders ist das heute nur noch, wenn µC oder SoC direkt programmiert werden.
Die werden aber auch nur ein- bis ganz wenige mal mit einem kurzen Bootloader geflasht. Oder genau einmal als OTP.
Ist richtig. Damit kann man auch problemlos das UEFI Downgraden.
Zusätzlich ist noch ein Pfostenstecker in der Nähe des UEFI Chips aufgelötet beim ASUS Rog Crosshair Hero VI. Der ist im Handbuch nicht weiter dokumentiert.
Im Kundenumfeld bin ich gespannt, was mich auf der Arbeit hier erwarten wird. Privat war es kein großes Problem. Mein moderneres Framework Notebook hat das gemütlich von der Linux Konsole aus installiert. Bei allen anderen älteren Geräten habe ich einfach Secure-Boot ausgeschaltet – Problem gelöst. :-)
Treffend gesagt. Irgendwie auch praktisch, wenn man neuen Konsum anschieben kann, in dem man alte Rechner ins Abseits schiesst. So ein ganz klein wenig drängt sich mir da der Gedanke an geplante Obsoleszenz auf.
Aktuell gehen etliche Rechner mit Bootschleifen ausser Betrieb, die nur eine 100MB Startpartition haben. Diese Rechner werden dann gleich meist erneuert. Oftmals Rechner aus der Win10-Zeit, die auf Win11 hochgezogen wurden.
Grundsätzlich sollte man immer ein aktuelles Bios drauf haben. Denn resettet man später aus irgendeinem Grund daie SecureBoot-Keys im Bios und das Bios ist zu alt, ist erstmal ende mit booten. Denn wenn die neuen Zertifikate nicht im Standardspeicher/Backupspeicher drin sind, werden sie beim Reset aus dem Bootspeicher gelöscht. (Und der Bootspeicher kann NUR vom Bios-Hersteller per Bios-Update geschrieben werden, weil für Windows read-only.
Lenovo ist auch nicht besser.
Erst bringen die BIOS Updates Fehlermeldungen wenn die CoreIsolation/Vulnerable Driver Blocklist aktiviert ist
https://support.lenovo.com/us/en/solutions/ht517407
und jetzt bringen die BIOS Updates für ein Modell L13 Gen3 die Geräte in den automatischen Windows Repair Mode. Wenn man dann im BIOS die Security Einstellungen resettet und neu setzt funktioniert es wieder.
Bin seit Wochen mit dem Support in Kontakt :-(
Tja auch wenn es "nur" mein privater Rechner war, war er doch hochkomplex eingerichtet mit jeder Menge Fachapplikationen. War ein Eigenbau mit ASUS Mainboard, Ryzen CPU, GTX Grafikkarte und und und.. Das letzte Update hat dann meinen Rechner gekillt. Wie ich diesen Scheissdrecksverein mittlerweile verachte.. Achso.. in Bios komme ich nicht, weil die Grakatreiber nicht geladen werden.
Das ist ja wohl eher Anglerlatein. Grafikkarten besitzen eine grundlegende Firmware direkt auf der Karte selbst (das Video-BIOS oder VBIOS). Beim Einschalten des PCs kommuniziert das Mainboard-BIOS über standardisierte Protokolle (wie VESA oder UEFI GOP) mit der Grafikkarte. Dadurch kann die Karte sofort ein einfaches Bild (meist in niedriger Auflösung wie 640×480 oder 1024×768 Pixel) ausgeben, noch bevor irgendein Treiber geladen werden muss.
Wenn du kein Bild siehst, dann ist entweder die GraKa hinüber, das Kabel defekt, der Monitor kaputt, das Mainboard hinüber, oder oder oder…
Jedenfalls ist nicht MS daran Schuld und auch SecureBoot nicht.
Das ist so nicht ganz richtig, secure boot spielt eine Rolle/ kann eine Rolle spielen.
Die (separate) Grafikkarte hat eine separate Firmware, die zum Booten / zum Zeigen eines Bildes beim Booten benötigt wird, gleiches Prinzip wie zum Beispiel ein bootfähiger Festplattencontroller.
Diese Firmware muss bei aktivem secure boot eben mit den entsprechenden Zertifikaten signiert sein, um erlaubt und geladen zu werden. Früher war das das Microsoft UEFI CA 2011, jetzt wäre es das Microsoft Option ROM UEFI CA 2023.
Wenn die Firmware (das "Bios") der Grafikkarte nicht entsprechend signiert ist, wird die Firmware der Grafikkarte nicht geladen. Abhängig von Hersteller verweigert der PC dann ganz das Booten oder er bootet ohne Schirmausgabe durch, bis ein anderer Grafiktreiber (z.B. der Windows Grafiktreiber) übernimmt…
Wenn das Betriebssystem nicht "durchbootet", kann man
– secure boot ausschalten, wenn man die Tastenabfolge auswendig kennt und blind eintippt
– die Grafikkarte temporär entfernen und die integrierte Grafik nutzen (so vorhanden- deren Firmware ist Teil des Mainboard Bios und damit signiert)
– die Grafikkarte in einen anderen Rechner stecken und dort deren Firmware- Update aufspielen (so vorhanden)
– oder eine Grafikkarte kaufen, die bereits das entsprechende Zertifikat in der Firmware hat…
(Nicht alle Hersteller handhaben die Validierung der Grafikkarten- Firmware gleich, es soll auch Hauptplatinen geben, die das einfach "übersehen")
Hmmm…. Wenn NVIDIA die Firmware (das GOP) deiner Grafikkarte erstellt und von Microsoft signieren lässt, wird dieser Signatur ein sogenannter Zeitstempel (Timestamp) hinzugefügt.
Für Secure Boot bedeutet das: Das Mainboard-BIOS prüft beim Starten nicht, ob das Zertifikat heute am heutigen Tag noch gültig ist. Es prüft stattdessen: War das Zertifikat zu dem Zeitpunkt gültig, als NVIDIA die Firmware signiert hat? Da die Firmware in der Vergangenheit (z. B. 2018 oder 2021) signiert wurde – also mitten in der Gültigkeitsphase des Microsoft UEFI CA 2011 Zertifikats –, stuft das BIOS die Grafikkarte dauerhaft als sicher und gültig ein. Die Signatur läuft für diese spezifische Firmware niemals ab.
Der beschriebene "ich sehe nix" kann dann höchstens durch ein Update des VBIOS der GraKa auf eine mit dem neuen Schlüssel zertifizierten Version passieren, wenn auf dem BIOS/UEFI des MB das neue Zertifikat noch nicht hinterlegt ist.
Oder verrenne ich mich gedanklich gerade?
Das würde ja dem secure- boot process widersperechen, der eine sicheren Kette zum Bios- Aufruf des Bootmanagers garantieren soll (Die Firmware der Hauptplatine selbst gehört da nicht dazu und hat ggf. andere Mechanismen)
Dazu gehört auch die Sicherung anderer Bootloader / Bootmanager und ggf. beim Start ladbarer / benötigter Firmware.
Ein Bootmanager wird ja auch bei jedem Start gegen das entsprechende Zertifikat geprüft, das gleiche trifft für boot- relevante Firmware zu.
Ich kann das soweit reproduzieren, dass ein Dell Precision 3630 (C246) Board mit nicht upgedateten Zerifikaten im Bios mit einer alten NVidia GT640 bootet, mit upgedateten Zertifikaten aber eine secure boot Fehlermeldung kommt.
"Ich kann das soweit reproduzieren, dass ein Dell Precision 3630 (C246) Board mit nicht upgedateten Zerifikaten im Bios mit einer alten NVidia GT640 bootet, mit upgedateten Zertifikaten aber eine secure boot Fehlermeldung kommt."
Das würde ja bedeuten, dass alle GraKas ebenfalls upgedated werden müssen in ihrer Firmware/VBIOS… :-O
Das kann doch irgendwie nicht sein?
Bei den Kunden-Servern(!) ist mir da ein gewisses Muster aufgefallen: 90% aller "eher simplen" bzw. kostengünstigen Systeme mit z. B. ASUS-Boards haben die SecureBoot-Updates einfach so verdaut. Auch Supermicro stellte kein Problem dar, selbst bei Boards, die schon etliche Jahre auf dem Buckel haben.
Die einzigen Server, die sich beharrlich weigerten, trotz manuellem Firmware-Update vor Ort, waren die besonders "edlen" Systeme mit Intel-Board (konkret: S2600STBR).
Ist natürlich nur anekdotische Evidenz, aber mich beschleicht schon länger der Verdacht: Mit all den selbst geklöppelten, tollen Sonderlösungen und Spezialfunktionen von HP, DELL, Intel und Co. schießt man sich am Ende selbst in den Fuß. Insbesondere Intel ist auch maximal hemdsärmlig, wenn es um Support-Ende geht. War seinerzeit gut zu beobachten am SATA-SSD-Debakel. Erst starben die Dinger wie die Fliegen, dann wurde sogar das SSD-Tool von der Webseite entfernt, so dass man kein Firmware-Update mehr machen konnte.
Manchmal ist weniger mehr. Ich halte zukünftig Abstand von Intel-Serverboards.
Also wir verwalten eine Flotte von 3000 HP Laptops und Standrechner und das Secure Boot Update ging inkl. des teilweise benötigter BIOS Updates größtenteils ohne Probleme durch.
Für eine Modellreihe, die wir mit einem "Beta BIOS" von HP betreiben müssen, wurde das Update Mitte März seitens MS pausiert. Mal schauen was da noch passiert.
Und G1A stürzten nach dem Ruhezustand ab, wenn man unter Windows 11 23H2 das aktuelle Zertifikat hat. Ist aber mit Windows Versionen ab 24H2 nicht mehr der Fall.
Also alles in allem klappte bei uns alles sehr gut.
In der c't 13 gibt es 2 Tools, mit denen man den aktuellen Stand des Rechners diesbezüglich ermitteln kann. Da sieht man sehr übersichtlich, was bis wann noch läuft.
Zu HP: Mein HP EliteBook hat das BIOS-Updates überstanden, da Bitlocker nicht verwendet wird, habe ich das "riskiert".
Da sollte man doch eigentlich meinen, wenn man schon so eine sündhaft teure HP Xeon Workstation hat, dass sich da HP alle Beine ausreißt, um dieses essentielle Update zum Laufen zu bringen. Aber wer weiß, vielleicht ist auch einfach der Fehler, da einzugreifen und Updates zu verzögern oder gar abzustellen, und so in den von HP und Microsoft organisierten Zyklus einzugreifen.
Mein HP Notebook mit Core i5 8gen jedenfalls scheint gerüstet zu sein, in der Systemsteuerung in der Gerätesicherheit und in msinfo32 werden die erwarteten Statis angezeigt, bei mir scheint alles für den Zertifikateschwenk gerüstet zu sein. Und wenn nicht, dann wird halt Secureboot ausgeschaltet, bis es eine Lösung gibt.
Ich verstehe nicht warum es da keine standardisierte Lösung gibt, es kann doch nicht sein das da jeder Hersteller Fuchswild was anderes definiert. Die Zertifikate gehören unter Windows einfach per Powershell im BIOS geupdatet, ohne Blockierung der Hersteller. Der Zugriff auf das BIOS über Powershell ist ja möglich und es ist NUR ein Zertifikat, keine Raketenwissenschaft.
Ich hoffe man lernt aus dem Desaster und definiert da eine einheitliche Lösung für die Zukunft.
> Ich hoffe man lernt aus dem Desaster und definiert da eine einheitliche Lösung für die Zukunft.
Das hoffe ich ebenfalls, denn die jetzt ausgerollten Zertifikate halten ja auch nicht ewig… Und ich habe noch deutlich mehr als 10 Jahre bis zur Rente. ;)
weils dann hackbar ist und open source geeignet.
Ein vor einem Vierteljahr erworbenes Elitebook 8 G1i hatte bei Auslieferung schon die aktuellen Zertifikate, ein ca. 4 Jahre altes Probook 450 G8 hat die aktuellen Zertifikate erst nach BIOS-Update Version 01.24.03 Rev.A vom 26.5.2026 geladen.
Mich beschleicht das Gefühl, dass nicht Windows 11 sondern die neuen Zertifikate meine Hardware unbrauchbar machen, für meinen HP ProDesk gibt es wohl kein notwendiges BIOS-Update :-(
Bei den nicht ganz neuen Medion-Laptops muss ich noch schauen …
Ergänzung: Ist ein G3-Modell, Bj. 2015
Man kann die Zertifikate auch selbst einspielen, habe ich bei einem HP Elitebook 850 G5 gemacht, weil das kein BIOS Update mehr bekommt.
https://h30434.www3.hp.com/t5/Business-Notebooks/Enabling-new-UEFI-2023-CA-certificates-in-pre-2018-HP/td-p/9628370
Das einzige, was anders war als in der Anleitung:
Man muss auf der verlinkten Github Seite weiter nach unten scrollen, zu den Assets unter 1.6.3, und dort dann die edk2-x64-secureboot-binaries.zip
herunterladen.
Ich habe aktuell ca. 40 HP Laptops inkl. Bitlocker und Intune Verwaltung umgestellt. Bei allen habe ich den HP Support Assistent verwendet. Jedes hat ein Bios update erhalten. Die Geräte sind von ganz neu bis hin zu Geräten aus 2021.
Zudem ca. 120 nicht HP PCs, Mini-PCs, andere Laptop-Hersteller.
Ausfälle oder Probleme bisher: 0
Mal sehen, ob das am Freitag auch so ist :)
Wir haben hier in der Firma noch ein paar Restbestände von den im Blogartikel erwähnten Z4 G4 Xeon Workstations in Einsatz. Hier sind alle Zertifikate installiert. Das KEK und MS CA wurde über das kumulative Update installiert. Die restlichen Zertifikate über das erwähnte BIOS Update 3.00. Seit dem BIOS-Update sind alle Zertifikate installiert. Einzig die DBX Einträge scheinen nicht komplett platz im Speicher zu finden. Auf diesen Geräten ist allerdings kein Bitlocker aktiv und die Geräte hängen in einer Domäne und werden über einen eigenen Server / Service (nicht Microsoft) mit Updates versorgt.
Ein etwas älteres HP ZBook, welches hier noch herumgeistert und bis jetzt kein aktuelles BIOS-Update erhalten hat (und wahrscheinlich auch nicht mehr erhalten wird), weigert sich bis jetzt irgendwelche neuen Zertifikate aufzunehmen.
In meiner Win11-VirtualBox hatte Microsoft in den Settings bis und mit Mai-Update noch sinngemäß behauptet, dass man dabei sei, die Situation zu evaluieren.
Mit (a) einem Upgrade auf VB 7.1.18 und (b) den in diesem Artikel: https://www.borncity.com/blog/2025/11/20/windows-10-chaos-beim-austausch-neuer-secure-boot-keys/#more-318401
vorhandenen Informationen (danke dafür) ging es dann, anscheinend ohne weitere Probleme.
Wie jemand, der von diesem Computer-Zeugs keine Ahnung hat, sondern diese komischen Kisten einfach nur zum Surfen und Emailen nutzt, mit der Situation hätte umgehen sollen — sofern er/sie überhaupt mitbekommen hätte, dass es eine „Situation" gibt — bleibt mir schleierhaft.
SecureBoot ist und bleibt in jeder Hinsicht „broken by design".
Auf meinem 2017er ALDI-Laptop mit (nachgerüstetem) W11Pro und Bitlocker scheint es einfach automatisch installiert worden zu sein. Ich denke (hoffe), das wird auf viele "Ahnungslose" zutreffen, wenn sie halbwegs aktuelle Standard-HW haben …
die meisten Otto Normalos weren da gar nix mitkriegen und auch keine Problem haben da die alles auf standard haben. Probleme gibt es meistens bei den "optimierten" Geräten… weil da halt doch eine nötige Komponente "wegoptimiert" wurde und sich der User das nicht bewusst war.
Kann man ja alles machen, muss sich aber stets bewussts ein was man tut… und das ist halt nicht immer gegeben.
Na ja, aber wenn ein Firmware-Update Voraussetzung ist: Das installiert sich normalerweise ja nicht von allein, oder? Also auf meinem PC (Dell aus 2019) muss ich das schon selbst anstoßen. Was ja auch gut und richtig so ist.
Das kommt ein bisschen auf den Hersteller an. ASUS und Lenovo spielen bei halbwegs aktuellen Geräten UEFI/Firmware Updates über Windows Update ein, zumindest habe ich das bei NUCs und diversen Lenovo Notebooks schon mehrfach gesehen. Sieht man dann beim nächsten Neustart sehr schön, weil dann da was von "Es wird ein Systemupdate installiert, bitte warten" steht. D.h. in gewissen Situationen kann das durchaus automatisch gehen. Kommt aber wie gesagt auf Hersteller und Alter an.
Ergänzung: Sofern man der Aussage in der "Device Security" trauen kann, hat die Installation der Juni-Updates in der Win11-VM anscheinend die *alte* Zertifikats-Konfiguration wiederhergestellt?!?
"Secure Boot is on, but your device is using an older boot trust configuration that should be updated. There is not yet enough data to classify your device for automatic update."
In der Win10-VM ist es auch nach Installation der Juni-Updates bei "alles in Ordnung" geblieben.
Ich glaube, ich gebe es jetzt doch endgültig auf, mich weiter mit dem Microsoft-Kram zu beschäftigen…
Die HP Z4 Workstations G4 und G5, gekauft ab 03/2021, konnte Windows Anfangs Monat automatisch aktualisieren, nachdem das aktuellste BIOS installiert wurde.
HP ProBook x360 440 G1 Notebooks, gekauft 11/2019, bekamen kein BIOS-Update spendiert und verweigerten sich bisher mit den im Artikel beschriebenen Fehlermeldungen 1802, 1797; SkipReason: KI_7 jeglicher Update-Versuche.
Bin dann heute über den Kommentar von Markus vom 20. Mai 2026 gestolpert. Damit liess sich, wie Markus vermutet hatte, auch beim HP ProBook x360 440 G1 die neuen Windows Secure Boot-Zertifikate installieren. Es musste nur "Update-UEFI.bat" ausgeführt werden. Ausschalten der HP-SureStart-Funktion war nicht notwendig, weil in diesem Modell noch nicht vorhanden. Es war auch kein Eingriff in die Registry notwendig. Das könnte aber daran gelegen haben, dass dort von uns bei früheren Versuchen schon Werte angepasst wurden.
https://borncity.com/blog/2026/02/06/secure-boot-zertifikatswechsel-es-gibt-huerden-beim-austausch-teil-2/#comment-256001
Danke, Markus!
Vielleicht ein letzter Versuch für Alle, welche bisher mit HP-Geräten mit älteren BIOS-Versionen gescheitert sind. Vorher immer sicherstellen, dass der BitLocker-Wiederherstellungsschlüssel greifbar ist. Hier wurde er nicht benötigt, aber nachher suchen und nicht finden kann für den Festplatteninhalt fatal enden.
Ich denke es wird auch nach dem 24. Juni 2026 vorerst nichts passieren, da die Zeitstempel der UEFI-Zertifikate nicht geprüft werden. Erst wenn Microsoft einen mit 2023-Zertifikat signierten Bootloader erzwingt, wird es keinen Secure Boot Vorgang mehr für ältere Geräte ohne aktuelle Zertifikate geben.
Habe gerade einen HP Probook 470 G3 (Core i7-6500U, WIN11 25H2 26200.8655) mit BIOS N78 01.62 vom 03.04.2024 per Update-UEFI.bat auf die CA 2023 in DB hochgezogen (gilt bis 13.06.2035).
Das ist eine Spielkiste!
Danke an Euch Markus und ChristophH
*********************************
Hier wurde er nicht benötigt, aber nachher suchen und nicht finden kann für den Festplatteninhalt fatal enden.
*********************************
Dafür hat man Backups seiner Daten! da kann dann gar nix fatal enden.
VMware und Linux Systeme ist super nervig, zwar wurde mit 8.0 U3j dafür gesorgt das bei einem shutdown+start einer VM der Plattform Key aktualisiert wird (geprüft, geht), die dbx ist aber trotzdem noch alt und enthält weder das Windows 2023 UEFI noch das Microsoft 2023 UEFI. Windows kann das scheinbar updaten, bei Linux geht es nicht weil bei VMware aus Linux kein DBX Update möglich sind (fwupd sagt nein).
Jetzt darf man bei jeder Linux VM in den Settings einstellen, das man an die Secure Boot Settings kommt umd dann händisch auf einer ISO liegenden UEFI Certificate per UEFI zu importieren.
Bei Promox gibt es ein Menüpunkt dafür, klick und fertig ist die laube.
Für ältere HP-Computer (gefunden via Deskmodder):
https://h30434.www3.hp.com/t5/Business-Notebooks/Enabling-new-UEFI-2023-CA-certificates-in-pre-2018-HP/td-p/9628370
Habe aber aus Zeitgründen noch nicht probiert, ob es auf meinem 2015er ProDesk 400 auch funktioniert.
Das Microsoft Zertifikats wirwar ist nicht mehr nachvollziehbar.
Bei einem Fujitsu A3511 (UEFI Version 1.09) ist die Samsung PM991a mit 512 GB im Betrieb ausgefallen. (Soweit eigentlich nichts dramatisches.) Der Laptop wurde regelmäßig über die Windows eigne Funktion "Sichern und wiederherstellen" über die Systemsteuerung als "Systemabbild" gesichert.
Beim Wiederherstellungsvorgang gab es dann aber verschiedene Probleme.
– Da der Laptop schon das UEFI CA 2023 über Windows Update installiert hatte, startete er von keinem im Schrank liegenden Startmedium.
– Ein mit dem "Media Creation Tool" neu erstellter USB Stick, ging auch nicht, da hier auch das aktuelle Zertifikat fehlt.
– Auch ohne Secure Boot, brachte der USB Stick keinen nutzen für den Vorgang. Die WinRE Funktionalität fehlt einfach. Der Hyperlink ist allerdings im Setup vorhanden.
– Also nochmal das komplette Windows 11 25H2 ISO heruntergeladen. Die "Install.wim" gesplittet und anschließend auf einem Bootfähigen USB Stick kopiert.
– Laptop startete darauf hin, vom USB Stick
– Wiederherstellung scheiterte mit einem Parameterfehler.
Also erst mal Windows neu installiert.
– Die *.vhdx aus dem Backup Verzeichnis mit "Ventoy" in einer VM gestartet.
– Windows 11 25H2 lief fehlerfrei hoch
– mit Hasleo Backup Suite Free auf die externe Festplatte exportiert.
– anschließend in eine VM wiederhergestellt
– Bootloader neu schreiben lassen.
– Win RE Partition neu angelegt und aktiviert
Der letzte Schritt kommt nächstes Wochenende. Da werde ich versuchen, das System aus der VM wieder auf Interne M2 SSD des Laptops zu spiegeln.
——————————————
Ob das fehlschlagen der Wiederherstellung aus der Windows Abbildsicherung nun an dem UEFI Zertifikaten liegt, kann ich nicht abschließend klären.
Unter Windows 8.1 x64 hat die Funktion "Sichern und Wiederherstellen" immer anstandslos funktioniert. Man musste einen Bootfähigen USB Stick als Startmedium erstellen. Dieser bot sogar USB 3.0 Unterstützung.
Das ganze zeigt, wie kaputt doch das Microsoft Ökosystem und Windows 11 ist.
Ist das "Sichern und Wiederherstellen" nicht seit Windows 10 deprecated? Ich meine mich zu erinnern, dass das zwar noch vorhanden ist, aber MS selbst meinte, man soll das nicht mehr benutzen. Deswegen steht da in der Systemsteuerung bei Windows 10/11 auch "Sichern und Wiederherstellen (Windows 7)".
Für vollständige Abbilder der Systempartition verwende ich seit einer gefühlten Ewigkeit CloneZilla und hatte damit bisher noch nie Schwierigkeiten.
Es ist bereits seit Windows 8 deprecated. Deshalb das (Windows 7) hinter der Funktion.
Nadella und AI waschen hier ihre Hände also ausnahmsweise mal in Unschuld. Der Ballmer war's.
Will man das mit Windows 11 Bordmitteln reparieren muss man ein aktuelles Windows 11 zuerst auf eine SSD komplett neu installieren, wo System und Recovery-Partition mindestens so groß wie auf der Ausgefallenen ist.
Dann in das WinRE auf der neuen SSD booten. Dort unter Problembehandlung, Weitere Wiederherstellungsoptionen anzeigen, Systemimage-Wiederherstellung die gesicherten NTFS Images wieder einspielen lassen.
Dann mit bcdboot ggf. noch die ESP Partition manuell anpassen.
Das alles am Einfachsten mit ausgeschaltetem SecureBoot und abgeschalteter Geräte-/Bitlocker-Laufwerksverschlüsselung.
Booten aus Ventoy kann die VHDX wenn es dumm gelaufen ist so verändert haben, dass sie danach nicht mehr richtig läuft.
Wenn im UEFI mit dem alten Zertifikat nicht mehr im Secureboot gestartet werden kann hat der User oder Fujitsu da etwas verändert. MSFT sperrt es derzeit noch nicht.
Künftig wie bereits seit 2012 von MSFT empfohlen besser ein externes Backup Programm verwenden, das alle Partitionen sichert und nicht nur die mit NTFS, also mit GPT System, Recovery und ggf. noch eine weitere von Fujitsu. Die ESP ist hier mit FAT32 formatiert und wurde deshalb nicht mitgesichert.
Komplett tut es der olle Win 7 Imager nur wenn mit MBR partitioniert wurde. Dann wird auch die mit NTFS formatierte Boot-Partition mitgesichert und wieder hergestellt.
Künftig die Datensicherung mit einem vernünftigen externen Disk Imager machen der das komplett auch mit GPT und Bitlocker kann.
Auch bei einer erforderlichen kompletten Neuinstallation.
Unter Windows 8.1, war es sicherlich noch nicht deprecated. Die Information, das es aus Windows 7 stammt, ist mir das erste mal unter Windows 11 unter gekommen. Windows 10 habe ich privat nie genutzt.
Meine Windows wechsel waren:
Windows XP –> Windows 8.0 –> Windows 8.1 (bis Anfang 2023) –> Windows 11
"Wenn im UEFI mit dem alten Zertifikat nicht mehr im Secureboot gestartet werden kann hat der User oder Fujitsu da etwas verändert. MSFT sperrt es derzeit noch nicht. "
Da hat wahrscheinlich niemand was dran geändert. Das einzige, was ich damals mit dem Laptop nach dem Kauf gemacht habe, ist Windows 11 neu Installiert. Die Vorinstallierte Version von Fujitsu, lief einfach nicht gescheit. (Windows 11 21H2) Das Ding verlor permanent die W-Lan Verbindung. Des weiteren, gab es ein kuddelmuddel aus Deutsch und Englisch im System. Die SSD wurde damals mittels Secure erase im UEFI gelöscht. Anschließend im UEFI die Optimal defaults geladen. Im UEFI danach Quiet Fan Funktion deaktiviert.
Danach von einem über das Media Creation Tool erstellten USB Stick Windows 11 22H2 neu Installiert. Dabei habe ich bewusst alle Fujitsu Service Tools weggelassen. Treiber hat er sich damals alle automatisch über Windows Update geladen. Zuletzt den Modern Standby abgeschaltet.
In dem Zustand lief der Laptop fast problemlos. Er hat alle Windows 11 Versionsaktualisierungen bis Windows 11 25H2 problemlos mitgemacht. Einzig der Intel Arc Grafikkarten Treiber musste mal von Hand aktualisiert werden. Teilweise gab es nach dem Standby blackscreens.
das nachfolgende steht bei unseren Maschinen drin.
also auch der KI_7 Fehler mit SBKPF Fehler.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing]
"WindowsUEFICA2023Capable"=dword:00000000
"UEFICA2023Status"="InProgress"
"UEFICA2023Error"=dword:80004005
"BucketHash"="hashwerte :-)"
"ConfidenceLevel"="Temporarily Paused"
"UEFICA2023ErrorEvent"=dword:0000070a
"LastParsedBucketDataVersion"=dword:0000000f
"ConfidenceUpdateType"=dword:00000000
"DBLastUpdateError"=dword:80004005
"DBLastUpdateErrorReason"="Firmware_KI_7"
"DB3POROMLastUpdateError"=dword:80004005
"DB3POROMLastUpdateErrorReason"="Firmware_KI_7"
"DB3PUEFILastUpdateError"=dword:80004005
"DB3PUEFILastUpdateErrorReason"="Firmware_KI_7"
"KEKLastUpdateError"=dword:80004005
"KEKLastUpdateErrorReason"="Firmware_KI_7"
"BootMgrLastUpdateError"=dword:80004005
"BootMgrLastUpdateErrorReason"="PCA2023NotFoundInDB"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes]
"CanAttemptUpdateAfter"=hex:60,66,19,b8,53,63,dc,01
"OEMManufacturerName"="HP"
"OEMModelSystemVersion"="SBKPF"
"BaseBoardManufacturer"="HP"
"FirmwareManufacturer"="HP"
"OEMModelBaseBoard"="8715"
"FirmwareVersion"="S22 Ver. 02.23.00"
"OEMModelNumber"="HP ProDesk 600 G6 Desktop Mini PC"
"OEMModelSystemFamily"="103C_53307F HP ProDesk"
"OEMName"="HP"
"OSArchitecture"="AMD64"
"OEMModelSKU"="21L18EA#ABD"
"FirmwareReleaseDate"="07/07/2025"
"OEMModelBaseBoardVersion"="KBC Version 09.08.26"
"StateAttributes"="06D52AC7DB04010C107F-0-0-1-0-ER–BR–OR—RBR–0-0-78240D81B367B272572D8AE609A8B60B0CCF9588-6468–85AF1A08554B93E6AAF377AA0E1D98448339FE7A"
"LastUploadFailed"=dword:00000001
Ich habe auch eine Z4G4, und ich habe leider mit jedem Bios-Update "Forderungen nach Lüftern", die bereits verbaut sind. ;) Ich habe sogar Updates zurückgenommen. Voraussichtlich lese ich hier noch etwas mit und deaktiviere dann SecureBoot.
So … first (read readme, there is extra for HP)
https://github.com/garlin-cant-code/SecureBoot-CA-2023-Updates/releases/tag/v2026.06.14
Works with Elitebook 840G5 without any bios update (latest is from 03-2025). Script downloads certs from MS github section, so connectivity need.
And ….
1) tun this crap off
2) if you have (any, not only HP) functional bios, you can import any cert for secureboot (even own selfsigned). This is howto you can import certs from MS (this is how that script works)
3) there is (theoretically) just one shortcoming of not doing anything. If bootloader will have bug, you cant update it.
4) practically, I think that sooner or later someone (ms) will overwrite the bootloader and the system won't boot.