Secure Boot-problemen en de gevolgen voor je pc: wat je nu moet weten

In de praktijk blijkt echter dat dit beveiligingsmechanisme op veel computers juist tot problemen leidt, omdat Secure Boot de pc niet meer tegen schadelijke code beschermt, maar jou als gebruiker actief hindert. Je vertrouwde herstelmedia voor back-ups starten niet meer op, het installeren van nieuwe besturingssystemen mislukt, en mogelijk lukt het zelfs niet meer om je Linux- of Windows-installatie vanaf de SSD op te starten.

In dit artikel leggen we uit wat Secure Boot eigenlijk is.

Alle Windows- en Linux-pc’s waarop Secure Boot actief is, hebben hier last van. Of jouw pc hiertoe behoort, kun je onder Windows zien via het programma Systeeminformatie. Druk op de Windows-toets, typ msinfo32 letter voor letter in totdat het zoekresultaat met dezelfde naam verschijnt, en druk op Enter. De regel Status beveiligd opstarten geeft aan of Secure Boot is ingeschakeld. Als daar Uitgeschakeld staat, is Secure Boot een probleem voor andere computers.

Dat betekent echter niet dat je er helemaal geen last van hebt. Dat geldt alleen als bij alle andere computers die je gebruikt of beheert – zowel thuis als op het werk – ook Uitgeschakeld staat.

Bij Windows-computers staat daar in veel gevallen waarschijnlijk Ingeschakeld, want Microsoft heeft secure Boot tot een systeemvereiste voor Windows 11 verklaard. Om aan deze eis te voldoen, hoeft de functie echter alleen maar aanwezig te zijn. Of hij is ingeschakeld of niet, maakt niet uit. Als je een computer koopt waarop Windows 11 al door de pc-fabrikant is voorgeïnstalleerd, is de functie vaak toch al ingeschakeld (dat bepaalt de fabrikant).

Is Secure Boot ingeschakeld? Dan heeft dit gevolgen voor jou, maar wat betekent dat precies?

De uitleg begint eigenlijk bij het opstartproces, maar als trouwe c’t-lezer heb je daarover al in eerdere artikelen kunnen lezen. In [1] hebben we uitgelegd hoe Windows opstart op een UEFI-computer; er is ook een FAQ over [2]. De bestanden die daarbij een rol spelen op je SSD, staan allemaal op een speciaal logisch station, de EFI System Partition (ESP). De details van de partitie-indeling worden in [3] uitgelegd; ook hierover is er weer een FAQ [4]. In [5] laten we ten slotte een script zien waarmee je de inhoud van de ESP veilig kunt bekijken. Daarnaast geven we uitleg over welk bestand waarvoor dient.

Hier daarom alleen de korte versie. De UEFI-firmware draagt de controle over aan één enkel bestand, waarin de bootmanager van het besturingssysteem zit. De bestandsnaam wordt bepaald door de UEFI-specificatie. Deze luidt, afhankelijk van de architectuur, zowel bij Windows als bij Linux op 64-bits x86-computers bootx64.efi en op 64-bits ARM-computers bootaa64.efi. De naam mag ook anders zijn, maar dan moet de firmware dat van tevoren weten. Dat regelt meestal het installatieprogramma tijdens het installeren van het besturingssysteem. Bij Windows heet het bestand dan altijd bootmgfw.efi.

Als Secure Boot is ingeschakeld, moet het bootmanager-bestand digitaal ondertekend zijn. Dit betekent dat een producent met een certificaat bevestigt dat het bestand echt van hem afkomstig is.

Technisch gezien gaat het, sterk vereenvoudigd, om een vergelijking van checksums. In de handtekening (signatuur) van het bootmanager-bestand zit onder andere de checksum ervan, en de UEFI-firmware berekent volgens hetzelfde algoritme ook een checksum voor het bestand.

Als die twee verschillen, gaat de firmware ervan uit dat het bestand is gemanipuleerd en weigert het uit te voeren. Zijn de checksums daarentegen identiek, dan controleert de firmware ook van wie het bestand afkomstig is. Het certificaat in het bestand dient hierbij als identiteitsbewijs van de producent. De firmware vergelijkt dit certificaat met een eigen lijst van betrouwbare uitgevers.

Dat werkt als een gastenlijst: alleen wie daarop staat, krijgt toegang. Als de bootmanager erbij staat, geeft de firmware de controle aan hem door; anders wordt hij geweigerd en gaat het ofwel verder met de volgende bootmanager (volgens de opstartvolgorde), ofwel eindigt het opstartproces met een foutmelding.

Het addertje onder het gras: het certificaat zou afkomstig kunnen zijn van een willekeurige uitgever die zich bijvoorbeeld ten onrechte voordoet als Microsoft of Canonical.

Om dat te kunnen herkennen, is het certificaat zelf ondertekend, en dan niet door de producent zelf, maar door een hogere instantie, een certificeringsinstantie (Certificate Authority, kortweg CA). Deze bevestigt met haar handtekening: “Ja, het certificaat hoort echt bij deze producent.”

Maar dat verplaatst het probleem alleen maar naar het volgende niveau, want waarom zou deze CA vertrouwen verdienen? Je raadt het al: ook hun certificaat is op zijn beurt weer ondertekend door een hogere instantie; het geheel vormt een certificaatketen. Die loopt door tot aan een root-certificeringsinstantie (Root-CA).

Hier houdt de controle op, dan rest alleen nog vertrouwen. De Root-CA ondertekent haar root-certificaat namelijk zelf. Dit certificaat wordt daarom de “root of trust” genoemd. Het vertrouwen in alle certificaten die lager in de keten staan, hangt af van de reputatie van deze certificeringsinstantie.

Als het om Secure Boot gaat, zit aan het einde van de keten in de meeste gevallen altijd hetzelfde bedrijf: Microsoft. De vertrouwensketens van alle Windows- en de meeste Linux-bootmanagers eindigen momenteel bij rootcertificaten van Microsoft. Het beheren van de benodigde infrastructuur kost namelijk geld, en daarom zijn alle producenten dankbaar dat Microsoft dat op zich neemt.

Zoals gezegd heeft de firmware een eigen lijst met betrouwbare certificaten. Daarin staan echter niet de certificaten van alle fabrikanten van betrouwbare bootmanagers, maar slechts een paar van Microsoft. Daarnaast zijn er vaak, maar niet altijd, certificaten van de hardwarefabrikanten en andere besturingssystemen.

Voor de huidige Secure Boot-problemen zijn alleen die van Microsoft relevant. Dat zijn tussencertificaten (intermediate) die niet worden gebruikt om de bestanden van de bootmanager te ondertekenen, maar om de certificaten te ondertekenen van degene van wie de bootmanager afkomstig is (“Ja, de fabrikant is betrouwbaar.”).

Microsoft gebruikte er in het verleden twee. De ene heet Microsoft Windows Production PCA 2011 en wordt gebruikt voor alle bootmanagers die van Microsoft zelf komen. De andere, met de naam Microsoft Corporation UEFI CA 2011, dient hetzelfde doel, maar dan voor alle niet-Microsoft-bootmanagers, zoals bijvoorbeeld voor Linux. Een tip om de twee, toch wel erg op elkaar lijkende namen makkelijker uit elkaar te houden: let erop of het woord Windows in de naam voorkomt.

Uiteindelijk gaat het dus maar om twee certificaten, waarmee een veel groter aantal producentcertificaten wordt gewaarborgd. En om afzonderlijke bestanden die met een van de twee certificaten ondertekend moeten zijn. Dat klinkt misschien alsof er niet zo veel mis kan gaan, maar helaas is dat niet zo.

Axel Vahldiek en Marco den Teuling

[1] Axel Vahldiek en Noud van Kruysbergen, Zo start Windows via UEFI, c’t 8-9/2026, p. 114

[2] Axel Vahldiek en Noud van Kruysbergen, FAQ: Zo start Windows via UEFI, c’t 8-9/2026, p. 120

[3] Axel Vahldiek en Noud van Kruysbergen, Partitionering in kaart gebracht, c’t 7/2026, p. 84

[4] Axel Vahldiek en Noud van Kruysbergen, Partitionering onder Windows, c’t 7/2026, p. 90

[5] Axel Vahldiek en Noud van Kruysbergen, Een overzicht van de EFI-systeempartitie, c’t 8-9/2026, p. 113