- De oorspronkelijke Secure Boot-certificaten uit 2011 verlopen in juni 2026 en moeten worden vervangen door de Windows UEFI CA 2023.
- Windows 11 en Windows 10 met ESU ontvangen de update voornamelijk via Windows Update, hoewel sommige computers een BIOS-update vereisen.
- In bedrijfsomgevingen is het essentieel om apparaten te inventariseren, registersleutels en 1801/1808-gebeurtenissen te controleren en MicrosoftUpdateManagedOptIn te configureren.
- Door firmware-updates af te stemmen met OEM's en Secure Boot ingeschakeld te houden, wordt de bescherming tegen malware en boot-aanvallen versterkt.
Als u Windows 10 of Windows 11 gebruikt en Secure Boot hebt ingeschakeld , wordt u direct beïnvloed door de certificaatwijzigingen die Microsoft en pc-fabrikanten tussen nu en juni 2026 zullen doorvoeren. Dit is geen theoretisch probleem: het gaat hier om het onderdeel dat valideert wat er op uw computer mag worden uitgevoerd vanaf het moment dat u de aan/uit-knop indrukt, en waarvan de oorspronkelijke certificaten binnenkort verlopen.
Jarenlang gingen we ervan uit dat het systeem vanaf het opstarten beschermd was, maar nu is het tijd om te controleren of alles klaar is voor de vernieuwing van het Secure Boot-certificaat . Microsoft, OEM's (zoals Acer) en systeembeheerders zijn hier al mee bezig en het is belangrijk om te begrijpen wat er gebeurt, wat de gevolgen zijn van nietsdoen en welke praktische stappen u kunt nemen, of u nu een thuisgebruiker bent of een vloot apparaten beheert binnen een bedrijf.
Waarom verlopen Secure Boot-certificaten en wat betekent dat?
Het op UEFI gebaseerde Secure Boot- mechanisme vertrouwt op digitale certificaten die in de firmware zijn opgeslagen om te bepalen welke code tijdens het opstarten betrouwbaar is: bootloaders, firmwarestuurprogramma's, kritieke componenten van het besturingssysteem, enzovoort. Dit model is ontworpen rond een sleutelhiërarchie die een vertrouwensketen creëert van de firmware tot Windows.
Binnen deze hiërarchie vinden we bijvoorbeeld de Platform Key (PK) , die meestal afkomstig is van de OEM (zoals Acer), de Key Exchange Keys (KEK) van Microsoft en de fabrikant, en twee essentiële databases: de DB (toegestane handtekeningen) en de DBX (ingetrokken handtekeningen). De DB bevat certificaten en handtekeningen die als betrouwbaar worden beschouwd, terwijl de DBX wordt bijgewerkt met elementen die moeten worden geblokkeerd omdat ze onveilig zijn of gecompromitteerd zijn.
De eerste Secure Boot-certificaten die gezamenlijk door Acer en Microsoft zijn uitgegeven, dateren uit 2011 en waren ontworpen met een geschatte levensduur van 15 jaar. Dit betekent dat deze eerste certificaten in juni 2026 verlopen. Als de firmware van uw computer er nog steeds op vertrouwt en niet is bijgewerkt naar de nieuwe certificaten van 2023, zal de opstartbeveiliging niet langer werken.
Met verlopen certificaten kan de computer nog steeds opstarten en Windows normaal uitvoeren, maar het cruciale probleem is dat Microsoft de nieuwe beveiligingsmaatregelen niet correct kan toepassen op de opstartomgeving. Dit omvat bescherming tegen malware die vóór het systeem wordt geladen, pogingen om BitLocker te omzeilen en andere aanvallen op de initiële vertrouwensketen.
Op oudere machines, of op systemen die niet langer worden ondersteund (zoals Windows 10-installaties zonder ESU), bestaat het risico dat je een opstartomgeving krijgt die weliswaar werkt, maar waarvan het aanvalsoppervlak groter wordt omdat deze niet dezelfde beveiligingsupdates ontvangt of misbruik kan maken van moderne DBX-intrekkingen.
Context: einde van de ondersteuning voor Windows 10, opkomst van Windows 11 en afhankelijkheid van Secure Boot
De aankondiging dat Windows 10 niet langer ondersteund zou worden, zorgde ervoor dat miljoenen gebruikers overstapten naar Windows 11 om te voorkomen dat ze beveiligingsupdates zouden missen. Tegenwoordig is het marktaandeel duidelijk verschoven naar Windows 11, met ongeveer 63% tegenover 35% voor Windows 10, grotendeels als gevolg van die druk door het einde van de ondersteuning.
Hoewel sommige Windows 10-installaties nog steeds gebruikmaken van speciale kanalen zoals LTSC of Extended Security Updates (ESU) , is de realiteit dat de meeste gebruikers zullen moeten samenwerken met Windows 11 of, op zijn minst, met Linux-distributies om goed beschermd te blijven. Maar dat betekent niet dat Windows 11 ondoordringbaar is: de geldigheid van Secure Boot-certificaten speelt nu een zeer directe rol.
Voor Windows 11 is Secure Boot geen luxe, maar een vereiste voor installatie in de meeste ondersteunde scenario's. Microsoft staat erop dat het ingeschakeld blijft, niet alleen voor de algemene beveiliging, maar ook omdat veel beveiligingsmaatregelen afhankelijk zijn van deze vertrouwensketen. Zelfs in de gamewereld is het steeds gebruikelijker dat moderne titels (zoals de Battlefield-serie en andere AAA-games) vereisen dat Secure Boot is ingeschakeld om te kunnen draaien.
De nieuwste reeks beveiligingsupdates voor Windows 11 bevat de vernieuwing van Secure Boot-certificaten die in juni 2026 verlopen. Veel gebruikers ontvangen deze certificaten automatisch via Windows Update, zonder dat ze handmatig naar bestanden of pakketten hoeven te zoeken.
Voor desktop- of laptopcomputers die vanaf 2024-2025 zijn aangeschaft, hebben OEM-fabrikanten de UEFI CA 2023-certificaten al rechtstreeks in hun firmware geïntegreerd. Deze computers zijn dus vanuit de fabriek al klaar voor gebruik, en het enige wat u hoeft te doen is Windows up-to-date te houden en Secure Boot niet onnodig uit te schakelen.
Wat gebeurt er als u uw Secure Boot-certificaten niet verlengt?
Een veelgestelde vraag is of de pc stopt met opstarten wanneer de levensduur van de batterij is verstreken. Het antwoord is voor de meeste gebruikers dat de computer gewoon blijft opstarten en functioneren . U kunt uw applicaties openen, internetten en het besturingssysteem gebruiken zoals u dat nu ook doet.
Het werkelijke probleem is subtieler: een computer met verlopen Secure Boot-certificaten ontvangt mogelijk geen updates meer of past deze niet correct toe, updates die deze nieuwe vertrouwensketen vereisen. Sommige cruciale beveiligingsverbeteringen op opstartniveau worden mogelijk niet geïnstalleerd, waardoor kwetsbaarheden ontstaan die aanvallers kunnen misbruiken.
Bovendien zijn deze certificaatvernieuwingen bedoeld om moderne kwetsbaarheden in de pre-besturingssysteemomgeving aan te pakken. Als de certificaatdatabase niet wordt bijgewerkt, kan de pc een gemakkelijker doelwit worden voor bootkit-malware, persistente rootkits of tools die zijn ontworpen om mechanismen zoals BitLocker in de allereerste opstartfase te omzeilen.
Er is nog een ander scenario om te overwegen: sommige applicaties, met name in bedrijfsomgevingen of omgevingen met hoge beveiligingseisen, vereisen mogelijk dat Secure Boot operationeel en up-to-date is . Als interne controles verlopen certificaten detecteren, kunnen deze applicaties weigeren op te starten of beperkte functionaliteit bieden, wat de productiviteit beïnvloedt.
Het advies van Microsoft is daarom duidelijk: houd Secure Boot altijd ingeschakeld en bijgewerkt , installeer de nieuwste Windows 11-updates of, in het geval van Windows 10 met ESU, pas alle beveiligingspatches toe en zorg ervoor dat u voor elke computer de nieuwste firmware-/BIOS-versie beschikbaar hebt.
Hoe controleer ik de status van Secure Boot-certificaten in Windows?
Om te achterhalen of uw computer de nieuwe Secure Boot-certificaten al heeft overgenomen , kunt u een snelle controle uitvoeren met PowerShell. Microsoft biedt een opdracht aan die de inhoud van de Secure Boot-handtekeningdatabase (db) inspecteert en specifiek zoekt naar de aanwezigheid van Windows UEFI CA 2023.
Als je PowerShell met beheerdersrechten opent, kun je iets soortgelijks uitvoeren als:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
Als de opdracht True retourneert , betekent dit dat de computer al het nieuwe UEFI-certificaat uit 2023 gebruikt en beschermd is tegen het verlopen van de oorspronkelijke certificaten uit 2011. In dat geval hoeft u zich geen zorgen te maken, behalve dat u de normale Windows- en firmware-updates kunt blijven installeren zodra deze beschikbaar komen.
Als de expressie daarentegen 'False' retourneert , is de machine nog steeds afhankelijk van certificaten die in juni 2026 verlopen. In dat geval is het raadzaam om eerst te controleren of Secure Boot daadwerkelijk is ingeschakeld in de BIOS/UEFI en vervolgens de benodigde updates te forceren of te faciliteren via Windows Update of via de juiste configuratie in beheerde omgevingen.
Om te controleren of Secure Boot is ingeschakeld, kunt u het hulpprogramma Systeeminformatie gebruiken met de opdracht msinfo32 . Controleer in het venster dat verschijnt het veld 'Status Secure Boot': als er 'Ingeschakeld' staat, werkt de functie; als er 'Uitgeschakeld' of 'Niet ondersteund' staat, moet u de UEFI-instellingen van het moederbord of de laptop openen om deze in te schakelen, mits de hardware dit toelaat.
Als je na het controleren van msinfo32 en de PowerShell-opdracht het certificaat voor 2023 nog steeds niet ziet, is de volgende logische stap Windows Update . Controleer op openstaande updates, met name beveiligings- of firmware-updates. Op veel computers wordt de certificaatvernieuwing automatisch toegepast door deze pakketten te installeren en de computer opnieuw op te starten.
Handmatige update van Secure Boot-certificaten op individuele computers
Er zijn gevallen waarin, ondanks dat Secure Boot is ingeschakeld en Windows Update actief is, de certificaatdatabase-update niet automatisch wordt toegepast. Voor deze situaties beschrijft Microsoft een manier om het updatesignaal via het Windows-register af te dwingen.
De standaardprocedure omvat het aanmaken of wijzigen van de waarde AvailableUpdates in de registertak die is bestemd voor Secure Boot. In PowerShell met beheerdersrechten kan een opdracht zoals de volgende worden gebruikt:
reg add HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Het is belangrijk om te weten dat wanneer u deze opdracht in PowerShell plakt, u de schuine strepen "/" in het registerpad moet vervangen door standaard Windows-backslashes om de opdracht correct te laten werken. Zodra deze waarde is aangemaakt of aangepast, zou Windows moeten detecteren dat er certificaatupdates beschikbaar zijn en deze na de volgende Windows Update-cyclus en herstart moeten toepassen.
Voordat u het register wijzigt, is het raadzaam te controleren of uw systeem aan de basisvereisten voldoet: Secure Boot ingeschakeld in de BIOS, een ondersteunde versie van Windows (voornamelijk Windows 11 of Windows 10 met ESU) en de Windows Update-service actief. Onjuiste wijzigingen in het register kunnen problemen veroorzaken, dus het is verstandig om een back-up of een systeemherstelpunt te hebben.
Zodra het proces is voltooid en na een of meerdere herstarts, kunt u de PowerShell-opdracht opnieuw uitvoeren die zoekt naar "Windows UEFI CA 2023" in de Secure Boot-database. Als het antwoord deze keer True is, werkt de machine nu met de vernieuwde certificaten en kunnen toekomstige opstartbeveiligingsmaatregelen zonder problemen worden toegepast.
Geavanceerde monitoring: gebeurtenissen, logboekregistratie en WMI voor beheerders
In bedrijfsomgevingen raadt Microsoft aan veel verder te gaan dan handmatige verificatie met een paar commando's. Om te begrijpen hoe ver elk team is met betrekking tot updates van Secure Boot-certificaten , is het cruciaal om systeemgebeurtenissen te bekijken en gedetailleerde informatie te verzamelen met behulp van PowerShell, het register en WMI/CIM-query's.
Een eerste stap is het inspecteren van de meest recente Secure Boot-gebeurtenissen , met name de identificatoren 1801 en 1808. Deze gebeurtenissen worden vastgelegd in de logboeken die zijn gekoppeld aan de updates van de Secure Boot-database (db) en de intrekkingsdatabase (DBX). Door de meest recente gebeurtenissen te analyseren, kan worden vastgesteld of er updates in behandeling zijn, toepassingsfouten of succesvolle statussen.
Daarnaast wordt aanbevolen om een gedetailleerde inventarisatie van alle apparaten binnen de organisatie uit te voeren. PowerShell-scripts kunnen worden gebruikt om parameters te verzamelen zoals de machinenaam (bijvoorbeeld HostName, $env:COMPUTERNAME) en de datum en tijd van verzameling (Get-Date), waardoor een duidelijk beeld ontstaat van het apparatenpark op een specifiek moment.
In het register zijn verschillende sleutels bijzonder relevant. Een daarvan is de belangrijkste Secure Boot-sleutel, te vinden op HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot , waar waarden zoals SecureBootEnabled, HighConfidenceOptOut en AvailableUpdates kunnen worden gecontroleerd. Deze gegevens geven aan of Secure Boot actief is, of het apparaat bepaalde vertrouwensbeleidsregels heeft geaccepteerd en of er certificaatupdates beschikbaar zijn.
Aan de andere kant is er de onderhoudstak op HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing , die parameters bevat zoals UEFICA2023Status, WindowsUEFICA2023Capable en UEFICA2023Error. Deze waarden geven aan of het apparaat de nieuwe UEFI CA 2023-certificaten kan gebruiken, of deze zijn toegepast en of er fouten zijn opgetreden tijdens het proces.
De sectie met apparaatkenmerken, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes , is ook nuttig. Deze sectie bevat gegevens zoals OEMManufacturerName, OEMModelSystemFamily, OEMModelNumber, FirmwareVersion, FirmwareReleaseDate, OSArchitecture en CanAttemptUpdateAfter. Deze informatie helpt bij het vergelijken van de firmwarecompatibiliteit met de status van Secure Boot-updates.
Wat betreft gebeurtenislogboeken is het raadzaam om indicatoren te verzamelen zoals de LatestEventId die is gekoppeld aan Secure Boot, de BucketID en het vertrouwensniveau dat is afgeleid van gebeurtenissen 1801/1808, evenals de tellers Event1801Count en Event1808Count. Met deze telemetrie kunnen IT-teams patronen, terugkerende fouten of apparaten die certificaatupdates nooit succesvol voltooien, detecteren.
Ten slotte worden aanvullende systeemdetails verkregen met behulp van WMI/CIM-query's : Windows-versie (Get-CimInstance Win32_OperatingSystem voor OSVersion en LastBootTime), fabrikant en product van het moederbord (Get-CimInstance Win32_BaseBoard), fabrikant en model van de computer (Get-CIMInstance Win32_ComputerSystem.Manufacturer en .Model) en BIOS-gegevens (Get-CIMInstance Win32_BIOS voor beschrijving en releasedatum). Dit alles maakt het mogelijk om firmwareversies, hardware en Secure Boot-status binnen één inventaris te correleren.
Intune-beheerde omgevingen en IT-beheerde apparaten
Voor organisaties die Intune of andere MDM-oplossingen gebruiken om hun Windows-apparaten te beheren, is de belangrijkste vraag of het voldoende is om Windows Update zijn werk te laten doen, of dat er extra stappen nodig zijn in aanloop naar 2026. Microsoft heeft aangegeven dat in beheerde omgevingen, zolang diagnostische gegevens minimaal op het niveau "Vereist" zijn ingeschakeld, de benodigde updates automatisch worden geleverd.
In de praktijk betekent dit dat als uw Intune-beleid al telemetrie toestaat en uw update-opties correct zijn geconfigureerd, u gerust kunt zijn. Toch vragen veel beheerders zich af of ze bepaalde registersleutels, zoals MicrosoftUpdateManagedOptIn, handmatig moeten aanmaken, of dat deze automatisch worden geconfigureerd wanneer het apparaat aan de vereisten voldoet.
Microsoft heeft specifieke documentatie gepubliceerd waarin staat dat de MicrosoftUpdateManagedOptIn- sleutel , te vinden in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot, op 1 moet worden ingesteld op apparaten met door IT beheerde updates, wil automatische certificaatvernieuwing correct werken. In sommige gevallen kan deze sleutel automatisch worden geconfigureerd, maar in andere gevallen kan het nodig zijn om dit via beleidsregels af te dwingen.
De aanbeveling is daarom om het Intune-beleid met betrekking tot diagnostiek en updates te herzien, de werkelijke status van machines te verifiëren met behulp van inventarisatiescripts en, indien nodig, een configuratiebeleid te implementeren dat ervoor zorgt dat MicrosoftUpdateManagedOptIn de juiste waarde heeft en dat Servicing Branches compatibel zijn met UEFI CA 2023.
Het is net zo belangrijk om niet blindelings aan te nemen dat "er in 2026 niets meer hoeft te gebeuren". Hoewel Microsoft een groot deel van het proces automatiseert, heeft elke organisatie zijn eigen unieke kenmerken: apparaten met verouderde firmware, computers die niet regelmatig verbinding maken, restrictief netwerkbeleid of machines met uitgestelde updates. Een proactief validatieplan voorkomt verrassingen op het laatste moment.
De rol van OEM's en BIOS-/firmware-updates
Computer- en moederbordfabrikanten, zoals Acer, spelen een cruciale rol in dit hele proces. Zij beheren de Platform Key (PK) en een deel van de KEK's die in de firmware aanwezig zijn, evenals de BIOS/UEFI-versies die bepalen hoe de Secure Boot DB- en DBX-databases worden geladen en beheerd.
Volgens Acer is het bedrijf van plan om in het eerste kwartaal van 2026 BIOS-updates uit te brengen, specifiek voor de getroffen laptops en desktops. Deze updates bevatten de PK-, KEK- en DB-bestanden met de certificeringen van 2023, zodat de computer na het toepassen van de BIOS-update voldoet aan de nieuwe Secure Boot-vertrouwensketen.
Andere OEM's zullen waarschijnlijk vergelijkbare strategieën volgen, dus IT-beheerders en gevorderde gebruikers moeten de ondersteuningsnotities van hun fabrikanten goed in de gaten houden . In veel gevallen houdt het proces in dat een nieuwe BIOS van de website van de OEM wordt gedownload of via eigen tools (zoals automatische updateprogramma's) wordt ontvangen en dat de update volgens de standaardinstructies wordt toegepast.
Voor computers die in 2024 of 2025 zijn uitgebracht, wordt de BIOS doorgaans vanuit de fabriek geleverd met BIOS-sleutels uit 2023, of ontvangt deze update kort na aankoop. Als u uw pc in die jaren hebt gekocht, beschikt u waarschijnlijk al over de bijgewerkte certificaten ; desalniettemin is een controle met PowerShell altijd een goed idee om dit te bevestigen.
In het geval van gedistribueerde infrastructuren, datacenters of grote laptopvloten kan het nodig zijn om een gefaseerd firmware-implementatieplan met OEM's af te stemmen , om te voorkomen dat kritieke BIOS-updates gelijktijdig op alle apparaten worden toegepast zonder voorafgaande tests. Dit is geïntegreerd in het cryptografische en firmware-levenscyclusbeheer dat veel bedrijven al implementeren.
Cybersecurity-best practices rondom Secure Boot
Het vernieuwen van Secure Boot-certificaten is geen op zichzelf staande gebeurtenis, maar onderdeel van het beheer van de cryptografische levenscyclus van de organisatie . Het plannen van sleutel- en certificaatrotaties, het controleren van wat er daadwerkelijk in de omgeving wordt gebruikt en het handhaven van integriteitscontroles in firmware en TPM verkleinen de kans dat iemand het systeem manipuleert tijdens de eerste opstartfasen.
In dit verband is het raadzaam om opstartcontroles te combineren met andere beveiligingslagen: schijfversleuteling met BitLocker , detectie- en responsystemen (EDR/XDR), monitoring van firmware- en configuratiewijzigingen en regelmatige controles van het Windows-beveiligingsbeleid en de hardware. Dit alles helpt voorkomen dat een enkele fout in één laag het hele systeem in gevaar brengt.
Bedrijven die gespecialiseerd zijn in cybersecurity en penetratietesten kunnen waarde toevoegen door boot chain assessments uit te voeren , aanvallen op de firmware, UEFI en Secure Boot zelf te simuleren en te verifiëren of de beveiligingsmechanismen naar behoren functioneren. Deze diensten omvatten vaak ook aanbevelingen voor het automatiseren en orkestreren van updates.
In organisaties met een sterk gedistribueerde infrastructuur kan het gebruik van cloudservices zoals Azure of AWS voor het opzetten van distributiekanalen en gecentraliseerd updatebeheer de controle over patches, certificaten en firmware vereenvoudigen. Bovendien helpt het gebruik van dashboards in Power BI en telemetrie-analyses bij het prioriteren van apparaten die dringend aandacht nodig hebben.
Het gebruik van tools voor kunstmatige intelligentie en anomaliedetectie gericht op opstartgebeurtenissen en firmwaregedrag wordt steeds gebruikelijker. Deze systemen kunnen ongebruikelijke patronen in Secure Boot-logboeken, afwijkende herstarts of wijzigingen in UEFI-configuraties detecteren die kunnen wijzen op een poging tot aanval of een verkeerde configuratie.
Op operationeel niveau zijn enkele basisaanbevelingen onder andere: periodiek controleren van Windows Update en de beveiligingsstatus in het Windows Beveiligingscentrum, het aanvragen van officiële firmware bij fabrikanten voor machines die niet automatisch worden bijgewerkt, het testen van updates in testomgevingen vóór massale uitrol en het bijhouden van actuele inventarissen en goed geconfigureerde patchbeheersystemen.
Door deze werkwijzen te combineren met de juiste vernieuwing van Secure Boot-certificaten, wordt een sterke beveiligingspositie behouden, worden kwetsbaarheden beperkt en worden toekomstige audits, zowel intern als extern, vergemakkelijkt.
Kortom, het verlopen van Secure Boot-certificaten in juni 2026 maakt het essentieel om te controleren hoe onze systemen geconfigureerd en bijgewerkt worden, zowel thuis als in grote organisaties: ervoor zorgen dat Secure Boot actief is , de aanwezigheid van de Windows UEFI CA 2023 bevestigen via PowerShell, registersleutels en gebeurtenissen valideren, samenwerken met OEM's om recente firmware toe te passen en gebruikmaken van de mogelijkheden van Intune, WSUS, SCCM of MDM-oplossingen om implementaties te automatiseren, maakt het verschil tussen een omgeving die beschermd blijft tegen moderne opstartbedreigingen en een omgeving die, hoewel ogenschijnlijk normaal, stille risico's verzamelt die op het eerste gezicht moeilijk te detecteren zijn.