- Inzicht in de Secure Boot-vertrouwensketen
- Welke Secure Boot-certificaten verlopen in 2026?
- Zullen systemen stoppen met opstarten: wat de verandering nu eigenlijk betekent?
- Wat de transitie PKI-teams leert
- Modernisering van Secure Boot en paraatheid na de kwantumcrisis
- Wat PKI- en infrastructuurteams nu moeten doen
- Veel voorkomende fouten te vermijden
- Best practices voor beveiliging
- Hoe encryptieconsultancy kan helpen
- Conclusie
De overgang naar nieuwe Secure Boot -certificaten is Microsofts plan om in 2026 de oorspronkelijke Secure Boot-vertrouwensankers uit 2011 te vervangen door een nieuwe set certificaten uit 2023. Hierdoor kunnen Windows-apparaten vertrouwde beveiligingsupdates blijven ontvangen voordat ze opstarten. Het is de eerste grote vernieuwing van de Secure Boot-certificaathiërarchie sinds de introductie van deze functie meer dan tien jaar geleden. De wijziging zorgt er niet voor dat apparaten niet meer opstarten, maar systemen die de update missen, verliezen geleidelijk de toegang tot toekomstige Secure Boot-beveiligingen, updates van de vertrouwensdatabase en intrekkingsupdates.
Microsoft is in 2026 een belangrijke vertrouwensverandering in Secure Boot ingegaan. Vanaf juni 2026 bereiken verschillende certificaten die de basis vormen van het Secure Boot-ecosysteem het einde van hun geplande levenscyclus. Microsoft vervangt de oorspronkelijke certificaten uit 2011 door een set die in 2023 is geïntroduceerd.
Voor de meeste organisaties zullen apparaten niet plotseling stoppen met opstarten wanneer de oude certificaten verlopen. Een belangrijker gevolg is dat apparaten die geen bijgewerkte certificaten ontvangen, mogelijk geen toegang meer hebben tot toekomstige Secure Boot-beveiligingen, updates van de vertrouwensdatabase en intrekkingsupdates. Na verloop van tijd kan dit leiden tot beveiligings- en complianceproblemen binnen een bedrijfsnetwerk.
De wijziging vindt plaats binnen het Secure Boot-ecosysteem, maar bevat een bredere les voor teams die zich bezighouden met Public Key Infrastructure ( PKI). Vertrouwensinfrastructuur heeft een levenscyclus. Certificaten verlopen, vertrouwensankers evolueren en de beveiligingsfundamenten moeten continu worden gemoderniseerd. De overgang naar een Secure Boot-certificaat is een duidelijk voorbeeld van een probleem waarmee elk PKI-programma te maken krijgt.
Deze handleiding legt uit wat er verandert, wat dit betekent voor de beveiliging van bedrijven en welke praktische stappen PKI-teams nu moeten nemen.
Inzicht in de Secure Boot-vertrouwensketen
Secure Boot is een beveiligingsfunctie die is ingebouwd in de UEFI-firmware en ervoor zorgt dat alleen vertrouwde software wordt geladen tijdens het opstarten. Voordat Windows begint met laden, valideert de firmware de digitale handtekeningen van opstartcomponenten aan de hand van vertrouwde certificaten in Secure Boot-databases. Als een component niet kan worden geverifieerd, kan Secure Boot deze blokkeren. Dit helpt beschermen tegen bootkits, rootkits en andere malware die voorafgaat aan het besturingssysteem.
Het vertrouwensmodel is een hiërarchie. Het begint met de platformsleutel (PK), die meestal eigendom is van de hardwarefabrikant. Daaronder bevindt zich de sleuteluitwisselingssleutel (KEK), die naast OEM-sleutels ook een Microsoft KEK kan bevatten. Twee databases maken het plaatje compleet: de database met toegestane handtekeningen (DB), die vertrouwde ondertekenaars bevat, en de database met niet-toegestane handtekeningen (DBX), die ingetrokken handtekeningen bevat . Iedere houder van een geldige KEK kan updates van de DB en DBX autoriseren.
Sinds 2011 hebben door Microsoft beheerde certificeringsinstanties Windows-opstartcomponenten, EFI-toepassingen van derden, updates van het Secure Boot-beleid en intrekkingsdatabases binnen dit model ondertekend. Naarmate deze certificaten verlopen, migreert Microsoft apparaten naar een nieuwe 2023-hiërarchie om de integriteit van de keten te waarborgen.
Welke Secure Boot-certificaten verlopen in 2026?
Microsoft vervangt een aantal kerncertificaten gefaseerd, van juni tot en met oktober 2026. De onderstaande tabel koppelt elk verouderd certificaat aan de vervanging in 2023, de functie ervan en de vervaldatum.
| Legacy-certificaat (2011) | 2023 vervanging | Primaire rol | Afloop |
|---|---|---|---|
| Microsoft Corporation KEK CA 2011 | Microsoft Corporation KEK 2K CA 2023 | Autoriseert updates voor de DB- en DBX-databases. | 24 juni 2026 |
| Microsoft Corporation UEFI CA 2011 | Microsoft UEFI CA 2023 | Ondertekent bootloaders en EFI-applicaties van derden. | 27 juni 2026 |
| Microsoft Windows Productie PCA 2011 | Windows UEFI CA 2023 | Ondertekent Windows-opstartcomponenten | October 19, 2026 |
Een detail is het vermelden waard voor PKI-specialisten. Bij de verlenging van het Microsoft Corporation UEFI CA 2011-certificaat splitst Microsoft de functionaliteit op in twee certificaten, zodat het ondertekenen van bootloaders gescheiden is van het ondertekenen van option ROM's. Een systeem dat option ROM's moet vertrouwen, kan het Microsoft Option ROM UEFI CA 2023-certificaat toevoegen zonder ook bootloaders van derden te hoeven vertrouwen. Dit geeft beheerders meer controle over het vertrouwen.
De overgang betreft niet het vervangen van Secure Boot zelf. Het vernieuwt de vertrouwensankers, zodat het platform toekomstige beveiligingsupdates kan blijven ontvangen. De nieuwe certificaten uit 2023 zijn ontworpen om ruim tien jaar geldig te blijven. Nu dit certificatensysteem is vastgesteld, rijst de logische vraag: wat gebeurt er met systemen die deze updates niet ontvangen?
Zullen systemen stoppen met opstarten: wat de verandering nu eigenlijk betekent?
De meest voorkomende misvatting is dat systemen niet meer opstarten wanneer de certificaten van 2011 verlopen. Microsoft geeft echter expliciet aan dat dit niet het geval is. Apparaten die de certificaten van 2023 nog niet hebben ontvangen, blijven normaal opstarten en functioneren, en standaard Windows-updates worden nog steeds geïnstalleerd.
De werkelijke zorg is het geleidelijke verlies van toekomstige vertrouwensinformatie. Naarmate er nieuwe kwetsbaarheden aan het licht komen en kwaadaardige opstartcomponenten worden geïdentificeerd, distribueert Microsoft updates voor de Secure Boot-vertrouwensdatabases en intrekkingslijsten . Een apparaat dat nog steeds in de oude vertrouwenshiërarchie is opgenomen, kan uiteindelijk deze updates niet meer toepassen of nieuwe ondertekende componenten niet meer vertrouwen. Microsoft beschrijft dit als een verslechterde beveiligingsstatus.
Voor een onderneming die duizenden apparaten beheert in datacenters, externe vestigingen en hybride omgevingen, wordt dit een uitdaging op het gebied van vertrouwensbeheer in plaats van een simpele patch-operatie. Een enkel onbeheerd apparaat vormt wellicht weinig direct risico. Honderden of duizenden apparaten die stilletjes achterlopen met de beveiliging op opstartniveau, vormen echter een probleem op het gebied van beveiliging, compliance en operationele zaken. Het risico is bovendien sluimerend, omdat een getroffen apparaat er identiek uitziet als een gezond apparaat totdat een update van de opstartketen de nieuwe certificaten vereist.
Organisaties die Linux of dual-boot-omgevingen gebruiken, worden geconfronteerd met extra complexiteit. De Microsoft UEFI CA 2011, die de shim- bootloader ondertekent waarop belangrijke Linux-distributies zoals RHEL, Ubuntu en Fedora vertrouwen, verloopt op 27 juni 2026. Systemen die de Microsoft UEFI CA 2023 niet in de apparaatfirmware hebben opgenomen, kunnen geen bijgewerkte shim-versies opstarten die zijn ondertekend met het nieuwe certificaat.
Leveranciers van Linux-distributies hebben bijgewerkte shim-pakketten uitgebracht met handtekeningen van zowel de certificaten uit 2011 als uit 2023, maar de CA uit 2023 moet eerst in de firmware worden opgenomen. Enterprise PKI-teams die gemengde omgevingen beheren, moeten controleren of de nieuwe CA is geregistreerd op zowel Windows- als Linux-eindpunten.
Wat de transitie PKI-teams leert
Secure Boot werkt onder het besturingssysteem, maar de overgang weerspiegelt de uitdagingen waar PKI-teams dagelijks mee te maken hebben. Vertrouwensrelaties hebben een levenscyclus, certificaten verlopen, cryptografische standaarden evolueren en verouderde vertrouwensmodellen moeten uiteindelijk worden gemoderniseerd.
Veel organisaties hebben nog steeds geen inzicht in certificaten die zijn ingebed in firmware, besturingssystemen, apparaten en gespecialiseerde hardware. De overgang naar Secure Boot-certificaten benadrukt waarom certificaatinventarisatie, levenscyclusbeheer en beheer van vertrouwensankers strategische beveiligingsfuncties zijn in plaats van administratieve taken. Dezelfde discipline die een gezonde PKI binnen een organisatie in stand houdt, is direct van toepassing op het beheer van vertrouwensankers in Secure Boot. Het contrast tussen de oude en de moderne manier is leerzaam.
| De Omgeving | Legacy-benadering | Moderne benadering | Operationeel voordeel |
|---|---|---|---|
| Secure Boot-vertrouwen | Certificaathiërarchie 2011 | Certificaathiërarchie 2023 | Onbeperkte toegang tot de beveiliging van Secure Boot. |
| Certificaat zichtbaarheid | Handmatige validatie en inventariscontroles | Gecentraliseerde monitoring en rapportage | Snellere identificatie van getroffen systemen |
| PKI-operaties | Reactieve certificaatvervanging | Levenscyclusbeheer en automatisering | Verminderd operationeel risico |
| Cryptografiestrategie | Statische vertrouwensveronderstellingen | Crypto-wendbaarheid en moderniseringsplanning | Snellere aanpassing aan toekomstige bedreigingen |
| Beveiligingsbeheer | Periodieke vertrouwensbeoordelingen | Continue monitoring en nalevingsregistratie | Verbeterde auditbereidheid |
De les die we hieruit kunnen trekken, is dat de modernisering van Secure Boot geen eenmalige certificaatupdate is. Het weerspiegelt een bredere verschuiving naar op de levenscyclus gebaseerd vertrouwensbeheer binnen de gehele PKI-omgeving van de onderneming. Deze verschuiving sluit direct aan op een parallelle ontwikkeling die momenteel gaande is in PKI-platformen voor bedrijven: ondersteuning voor post-kwantumcryptografie.
Modernisering van Secure Boot en paraatheid na de kwantumcrisis
De overgang naar Secure Boot-certificaten gaat hand in hand met een grotere moderniseringsinspanning op het gebied van cryptografie. Active Directory CS op Windows Server 2025 biedt nu ondersteuning voor het uitgeven van post-quantum cryptografiecertificaten met behulp van ML-DSA, de Module-Lattice-Based Digital Signature Standard die door NIST is gestandaardiseerd in FIPS 204. Deze functionaliteit is vanaf mei 2026 algemeen beschikbaar.
AD CS ondersteunt alle drie de ML-DSA-parameterreeksen: ML-DSA-44, ML-DSA-65 en ML-DSA-87. Hierdoor kunnen organisaties de beveiligingssterkte afwegen tegen de grootte van sleutels en handtekeningen. ML-DSA is een algoritme dat alleen handtekeningen genereert en is daarom van toepassing op ondertekeningsscenario's zoals certificeringsinstanties en OCSP-responders (Online Certificate Status Protocol), in plaats van op sleuteluitwisseling of encryptie. Microsoft raadt aan een parallelle ML-DSA-certificeringsinstantiehiërarchie op te bouwen om de uitgifte na de quantumfase te evalueren zonder de bestaande hiërarchie te verstoren.
De ondersteuning voor ML-DSA en de vervanging van het Secure Boot-certificaat zijn afzonderlijke projecten, maar ze wijzen in dezelfde richting: de vertrouwensinfrastructuur moet continu evolueren om veilig te blijven. Organisaties die PKI-modernisering plannen, zouden updates voor Secure Boot, certificaatlevenscyclusbeheer , crypto-flexibiliteit en post-quantum gereedheid moeten beschouwen als onderdelen van één strategie voor vertrouwensmodernisering, in plaats van als losse inspanningen.
Voor organisaties die gebonden zijn aan de eisen van de Amerikaanse overheid, biedt de Commercial National Security Algorithm Suite ( CNSA 2.0 ) van de NSA het duidelijkste migratietijdschema. Voor het ondertekenen van software en firmware is de categorie die het meest relevant is voor Secure Boot CNSA 2.0, die LMS en XMSS verplicht stelt zoals gedefinieerd in NIST SP 800-208. Meer in het algemeen specificeert CNSA 2.0 ML-DSA-87 voor digitale handtekeningen en ML-KEM-1024 voor sleuteluitwisseling. Van nationale veiligheidssystemen wordt verwacht dat ze de CNSA 2.0-algoritmen tegen 2026 ondersteunen en er tegen 2030 volledig op vertrouwen.
Wat PKI- en infrastructuurteams nu moeten doen
De transitie wordt beloond met vroegtijdig en methodisch handelen. De volgende stappen zorgen voor controle voordat vertrouwensrelaties beginnen te verwateren.
- Identificeer de getroffen systemen. Bouw een inventaris van apparaten die gebruikmaken van Secure Boot en bepalen of elk apparaat de certificaatupdates van 2023 heeft ontvangen. Veel apparaten worden automatisch bijgewerkt via Windows Update, terwijl sommige oudere systemen OEM-firmware-updates vereisen.
- Controleer de updatestatus. Gebruik Windows Beveiliging en beheertools om te controleren welke apparaten de nieuwe KEK- en DB-certificaten bevatten en welke nog aandacht nodig hebben.
- Breng vertrouwensafhankelijkheden in kaart. Documenteer waar certificaten zich bevinden in firmware, besturingssystemen, apparaten en applicaties, zodat niets over het hoofd wordt gezien.
- Audit uw huidige PKI-infrastructuur. Voor organisaties die AD C.S.Evalueer de gereedheid van het platform voor post-kwantum cryptografische vereisten. Houd er rekening mee dat bestaande AD CS-certificeringsinstanties niet ter plaatse kunnen worden geüpgraded naar ML-DSA; er moet een parallelle PQC CA-hiërarchie naast de bestaande worden geïmplementeerd. Deze functionaliteit is momenteel beschikbaar op Windows Server 2025 met de cumulatieve update van mei 2026.
- Stel herhaalbare processen in. Beschouw dit als de eerste van vele vertrouwensupdates en implementeer monitoring- en levenscyclusbeheersystemen die de volgende rotatie automatisch afhandelen.
Het is veel gemakkelijker om deze activiteiten proactief aan te pakken dan om te reageren nadat vertrouwensrelaties verlopen of een audit de tekortkoming aan het licht brengt.
Veel voorkomende fouten te vermijden
De meest voorkomende fout is aannemen dat een systeem gezond is, simpelweg omdat het nog opstart. Een apparaat kan normaal functioneren terwijl het stilletjes achterloopt met de updates voor Secure Boot, waardoor een verborgen beveiligingslek ontstaat dat pas aan het licht komt tijdens een kwetsbaarheidsanalyse, een audit of een incidentonderzoek.
Een tweede veelgemaakte fout is het beschouwen van de transitie als een eenmalige lapmiddeloperatie. De blijvende uitdaging is het opzetten van herhaalbare processen die toekomstige vertrouwensupdates, certificaatrotaties en cryptografische migraties ondersteunen. Organisaties die worstelen met Secure Boot-updates ondervinden vaak dezelfde problemen met certificaatlevenscyclusbeheer en PKI-modernisering, omdat alle drie afhankelijk zijn van inzicht, governance, eigenaarschap en levenscyclusbeheer.
Best practices voor beveiliging
De overgang naar een Secure Boot-certificaat vereist dezelfde discipline als die wordt toegepast op PKI-systemen voor bedrijven.
- Zorg voor een nauwkeurige inventaris van certificaten en bewaak de levenscyclus ervan continu.
- Houd afhankelijkheden tussen vertrouwensrelaties bij en wijs duidelijke verantwoordelijkheden toe voor certificaat- en vertrouwensbeheer.
- Zorg ervoor dat PKI-platforms op ondersteunde besturingssystemen en softwareversies draaien.
- Evalueer regelmatig de trust-architecturen om mogelijkheden voor modernisering te identificeren.
- Stel monitoring en rapportage in voor inzicht in de implementatiestatus van certificaten en wijzigingen met betrekking tot vertrouwensrelaties in de gehele omgeving.
- Bescherm de privésleutels van CA in een Hardwarebeveiligingsmodule gevalideerd om FIPS 140-3 — minimaal niveau 2 voor uitgevende CA's, niveau 3 voor root-CA's in de meeste bedrijfsomgevingen; federale en door CMMC gereguleerde omgevingen kunnen niveau 3 of hoger vereisen; sommige offline root-CA's werken op niveau 4.
- Beschouw de infrastructuur voor vertrouwen als een levend systeem dat continu onderhoud vereist, en niet als een statische implementatie.
Hoe encryptieconsultancy kan helpen
De overgang naar Secure Boot-certificaten is in essentie een uitdaging op het gebied van vertrouwenslevenscyclusbeheer. Encryption Consulting (EC) helpt organisaties bij het moderniseren van PKI-omgevingen, het verbeteren van de zichtbaarheid van certificaten, het automatiseren van levenscyclusprocessen en de voorbereiding op cryptografische veranderingen.
Advies over cryptografie na het kwantumtijdperk
De PQC-adviesdiensten van EC helpen organisaties bij het identificeren van cryptografische activa die kwetsbaar zijn voor kwantumaanvallen, het beoordelen van blootstellingsrisico's en het ontwerpen van flexibele migratiestrategieën die aansluiten bij NIST FIPS 204 en CNSA 2.0. Voor teams die zich voorbereiden op de modernisering van Secure Boot in combinatie met de overstap naar post-kwantumalgoritmen, brengt EC de huidige cryptografische afhankelijkheden in kaart en stelt een gefaseerd transitieplan op dat zowel de certificaatvernieuwingen op korte termijn als de bredere algoritmische migratie omvat.
PKI-diensten
Via PKI Services helpt EC organisaties bij het beoordelen, ontwerpen en beheren van PKI-infrastructuur die aansluit op de beveiligings-, compliance- en operationele vereisten, waaronder NIST SP 800-57, WebTrust en toepasselijke wettelijke normen. EC-consultants helpen bij het definiëren van certificaatbeleid en certificeringspraktijkverklaringen, het opzetten van robuuste CA-architecturen, het identificeren van vertrouwensafhankelijkheden, het versterken van governance en het bouwen van certificaatbeheerprocessen die operationele risico's verminderen en de auditbereidheid verbeteren.
CBOM Secure
Voordat u uw bezittingen kunt beheren, moet u eerst weten wat u bezit. CBOM Secure stelt een cryptografische materiaallijst op – een gestructureerde inventaris van cryptografische activa binnen de gehele organisatie, inclusief algoritmen, sleutelgroottes, certificeringsinstanties en afhankelijkheden. Deze inventaris vormt de basis voor het begrijpen van de vertrouwensrelaties binnen Secure Boot, het identificeren van activa die kwetsbaar zijn voor kwantumaanvallen en het plannen van een gefaseerde cryptografische migratie.
CertSecure Manager
CertSecure Manager biedt een gecentraliseerde oplossing voor certificaatdetectie, -monitoring, -rapportage en geautomatiseerd beheer van de levenscyclus. Het helpt teams bij het lokaliseren van verouderde certificaten, het volgen van vertrouwensafhankelijkheden binnen complexe infrastructuren en het behouden van continu inzicht, zodat de volgende rotatie van vertrouwensankers wordt geïdentificeerd en verholpen voordat deze een beveiligingslek creëert.
Naarmate organisaties zich voorbereiden op de modernisering van Secure Boot, crypto-flexibiliteit en de adoptie van technologie na de kwantumcrisis, biedt EC de expertise om veerkrachtige, toekomstbestendige vertrouwensarchitecturen te bouwen.
Conclusie
De overgang van Microsoft naar nieuwe Secure Boot-certificaten is meer dan alleen een vervanging van certificaten. Het is een herinnering dat de vertrouwensinfrastructuur een levenscyclus heeft. Systemen die de certificaten van 2023 niet ontvangen, kunnen blijven functioneren, maar lopen het risico achter te lopen op toekomstige Secure Boot-beveiligingen, intrekkingsupdates en beveiligingsverbeteringen.
De les reikt veel verder dan Secure Boot. Vertrouwenssystemen vereisen continu onderhoud, monitoring en modernisering. Organisaties die deze transitie goed doorstaan, zijn de organisaties die inzicht behouden in hun vertrouwensinfrastructuur, PKI-activiteiten moderniseren, het beheer van de certificaatlevenscyclus automatiseren en zich voorbereiden op cryptografische veranderingen zoals de overstap naar post-kwantumalgoritmen.
Het doel is niet alleen het vervangen van verlopen certificaten. Het gaat erom een veerkrachtigere, flexibelere en toekomstbestendige vertrouwensarchitectuur te bouwen die zowel voldoet aan de huidige beveiligingsvereisten als aan de toekomstige behoeften na de kwantumcomputertijd. Een praktische eerste stap is inzicht: inventariseer alle vertrouwensankers en certificaten waarvan u afhankelijk bent, controleer of de Secure Boot-updates uw systemen hebben bereikt en wijs duidelijke verantwoordelijkheden toe voor de volgende stappen. Neem contact op met het team van Encryption Consulting om uw vertrouwensarchitectuur te beoordelen en de werkzaamheden te plannen.
- Inzicht in de Secure Boot-vertrouwensketen
- Welke Secure Boot-certificaten verlopen in 2026?
- Zullen systemen stoppen met opstarten: wat de verandering nu eigenlijk betekent?
- Wat de transitie PKI-teams leert
- Modernisering van Secure Boot en paraatheid na de kwantumcrisis
- Wat PKI- en infrastructuurteams nu moeten doen
- Veel voorkomende fouten te vermijden
- Best practices voor beveiliging
- Hoe encryptieconsultancy kan helpen
- Conclusie
