Secure Boot Certificate expiration date June 2026

[TheTeek]

Microsoft heeft dit jaar aangekondigd dat oudere Secure boot certificaten gaan verlopen op June 2026.

Voor die tijd moeten systemen die afhankelijk zijn van Secure Boot, zoals Windows 11, voorzien zijn van up to date certificaten. Het lijkt erop dat MS deze aanbied via een Windows update;

Frequently asked questions about the Secure Boot update process - Microsoft S...

Maar er worden ook UEFI Bios van verschillende hardware leveranciers uitgerold.
Wat is de relatie van die Windows update vs een UEFI update?
Start een systeem niet meer op als Windows wel up to date is, maar mijn bios niet?

De gevolgen van het niet "up to date" hebben van die systemen kunnen best groot zijn. Systemen starten mogelijk niet meer op.

Ik heb het idee dat er maar weinig bekendheid is, op Tweakers kon ik er iig niets over vinden.

Of overdrijf ik nu.. -> een beetje wel, feit is dat er mogelijk actie nodig is voor jou systeem om na Juni 2026 nog een functionerende Windows te hebben.

Meer info;
Windows Secure Boot certificate expiration and CA updates - Microsoft Support
en;
https://learn.microsoft.c...ture-databases-db-and-dbx

Een overzicht van DELL laptops met de minimaal benodigde BIOS;
https://www.dell.com/supp...1-secure-boot-certificaat

HPe;
https://support.hp.com/us.../ish_13070353-13070429-16

[ Voor 52% gewijzigd door TheTeek op 31-10-2025 22:55 . Reden: nuance toegevoegd ]

[Hero of Time]

Ik snap niet helemaal waarom je er een enorm probleem van maakt. MS heeft maanden geleden al updates uitgebracht dat een geplande taak heeft gemaakt om de nieuwe certificaten te installeren. Het is niet verplicht om je BIOS bij te werken, de secure boot certificaten is in een losstaand register. Dit is heel fijn, want Linux gebruikers hebben niet altijd toegang tot de MS signing keys en zijn hierdoor in staat hun eigen key te importeren en zo alsnog fatsoenlijk secure boot te hebben met hun eigen kernel.

[TheTeek]

Volgens mij vraag ik ook letterlijk af of ik overdrijf, maar bedankt voor je antwoord.

Volgens MS;

If your device is managed by Microsoft, and sharing diagnostic data with Microsoft, then Microsoft will attempt to update the Secure Boot certificates automatically in most cases. While Microsoft will do their best to update Secure Boot, there will be some situations where the update is not guaranteed to apply and will need Customer action. The customer is ultimately responsible for updating the Secure Boot Certificates.

bron; Frequently asked questions about the Secure Boot update process - Microsoft S...

Als ik geen diagnostic data naar MS stuur krijg ik de update niet?
Toch nog veel vragen en weinig duidelijkheid van MS zelf.

[eheijnen]

TheTeek schreef op vrijdag 31 oktober 2025 @ 22:19:
Volgens mij vraag ik ook letterlijk af of ik overdrijf, maar bedankt voor je antwoord.

Volgens MS;

[...]


bron; Frequently asked questions about the Secure Boot update process - Microsoft S...

Als ik geen diagnostic data naar MS stuur krijg ik de update niet?
Toch nog veel vragen en weinig duidelijkheid van MS zelf.

Kun je dit niets eens in een test setup doen die de update niet zal verwerken omdat er geen data wordt gedeeld of niet gekoppeld aan het internet.
En dan de datum vooruit te zetten waarmee de certificaten verlopen.

[computerjunky]

Ik zag dit tipic en was benieuwd of ik al up to date was (laatste update gedaan op 7 juli) en dat blijkt het geval.

Hoe bekijk je dit:

Start powershell als administrator en paste het volgende :

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’

Vervolgens rolt er true of valse uit.

[Hero of Time]

TheTeek schreef op vrijdag 31 oktober 2025 @ 22:19:

Volgens MS;

[...]

bron; Frequently asked questions about the Secure Boot update process - Microsoft S...

Als ik geen diagnostic data naar MS stuur krijg ik de update niet?
Toch nog veel vragen en weinig duidelijkheid van MS zelf.

Je moet heel wat moeite doen om helemaal geen data naar MS te sturen. Standaard is het laagste niveau 'verplicht' en het andere niveau is 'extended'. Er is 1 ding waar ik wel moeite mee heb in het antwoord dat je van MS quote:

The customer is ultimately responsible for updating the Secure Boot Certificates.

Dit is wel heel erg kort door de bocht en verantwoordelijkheid afschuiven. Want het zijn juist MS' certificaten en keys die gaan verlopen. MS verplicht het tevens voor het OS. En dan is de gebruiker verantwoordelijk voor het updaten hiervan? Iets waar bijna niemand iets van af weet, laat staan hoe dat zou moeten. En als dan blijkt dat de update van MS niet z'n werk heeft gedaan is het lekker makkelijk wijzen naar de gebruiker, want die had het moeten uitvoeren/moet het oplossen.

[Dennism]

Hero of Time schreef op zaterdag 1 november 2025 @ 14:04:


Dit is wel heel erg kort door de bocht en verantwoordelijkheid afschuiven. Want het zijn juist MS' certificaten en keys die gaan verlopen. MS verplicht het tevens voor het OS. En dan is de gebruiker verantwoordelijk voor het updaten hiervan? Iets waar bijna niemand iets van af weet, laat staan hoe dat zou moeten. En als dan blijkt dat de update van MS niet z'n werk heeft gedaan is het lekker makkelijk wijzen naar de gebruiker, want die had het moeten uitvoeren/moet het oplossen.

Eigenlijk is dat natuurlijk volkomen logisch, MS levert tijdig wat het moet doen, namelijk de benodigde update en de instructies hoe deze te installeren.

Echter blijft het natuurlijk uiteindelijk de eindverantwoordelijkheid van de gebruiker om de updates tijdig te installeren. Dat is met deze update niet anders dan met andere (maandelijkse) updates. Er zijn immers ook hele volkstammen die het installeren van updates uitzetten (en zelfs het systeem 'slopen' om dat voor elkaar te krijgen omdat ze denken dat dit beter is.

[Hero of Time]

@Dennism, gaat mij er voornamelijk om dat een gemiddelde gebruiker, Henk en Greet op de hoek, al niet eens weten hoe de computer an sich werkt, wat SB überhaupt is en ze gewoon FB willen kunnen gebruiken om foto's van de (klein)kinderen te delen/bekijken. Als er dan problemen ontstaan met Secure Boot, wijst MS naar de gebruiker van "jij bent verantwoordelijk, zoek het maar lekker uit".

Die gebruikers hebben niet direct om Windows gevraagd, het kwam met het systeem voorgeïnstalleerd. MS heeft zelf als eis dat SB aan moet staan, is een van de bedrijven die er het meest aan heeft bijgedragen om het in de hardware te krijgen, hun keys en certificaten staan er standaard in. Hoe kan het dan dat ze er geen enkele verantwoordelijkheid over nemen nu?

Als jij een auto koopt en er blijkt een mankement mee te zijn door een productiefout, verwacht je toch ook dat de fabrikant dit voor je oplost, ipv dat je zelf aan de auto moet gaan sleutelen? Want ook de meeste eigenaren van een auto hebben er weinig verstand van. Ze kunnen het besturen, maar mechanische problemen oplossen of een APK uitvoeren doen we niet.

[Sissors]

Nou geen enkele verantwoordelijkheid? Normaal zorgen ze toch gewoon dat het automatisch allemaal werkt? Als ze wel de verantwoordelijkheid hebben, dan moeten ze ook gewoon de updates forceren. Geen optie om de update af te wijzen of te blokkeren, je moet hem installeren.

Dit lijkt mij ook niet te vergelijken met een productiefout. Meer iets wat up to date gehouden moet worden. Waarbij er genoeg dingen zijn bij een auto die ermee kappen als je dat niet doet.

[Dennism]

@Hero of Time

Ik denk niet dat deze auto vergelijking heel correct is. Ik zie security updates en dus ook updates als deze eerder als noodzakelijk onderhoud, en als je dan een auto vergelijking wil maken, kan je dat afhankelijk van de auto en je eigen kennis prima (soms) zelf doen, en als je dat niet kan, omdat je er niet de kennis of kunde voor hebt, of omdat je er simpelweg geen zin in hebt, laat je het doen door een ander, bijvoorbeeld de dealer of een andere garage of door bijvoorbeeld een bevriende monteur. Maar je blijft zelf verantwoordelijk om onderhoud uit te voeren (of uit te laten voeren) bij een auto in eigendom. Ik ken mensen die hele auto's uit elkaar halen, maar ook mensen die zelfs het bijvullen de olie uitbesteden omdat.

En zo werkt het bij PC's ook, ook als je zelf die kennis niet hebt, ben je zelf verantwoordelijk voor het up-to-date houden van de PC. En als er dan een keer wat mis gaat los je dat op, of laat je het oplossen door een 3de partij. Het is geen schade om iets niet zelf te kunnen bij PC onderhoud, net als dat het geen schande is als je niet je eigen auto gaat onderhouden maar dat uitbesteed. Daar hebben ze nu juist ITérs voor uitgevonden

[Hero of Time]

@Sissors, ik heb al aangegeven dat de gemiddelde gebruiker niks met updates verandert. Toch kan er iets falen, want software blijft door de mens gemaakt en is niet perfect. Je kan de update zelf hebben, maar er kan iets zijn waardoor de werkelijke taak voor het installeren van de nieuwe certificaten mislukt. Daar moet MS gewoon verantwoordelijkheid voor nemen en niet afschuiven op de gebruiker.

@Dennism, zoals de tekst in de FAQ staat, zou een jurist er gehakt van maken. Dit is echt iets dat MS niet kan afschuiven op een gebruiker die de kennis en kunde niet heeft. Zoals ik hier direct boven al noem, wanneer het proces van MS faalt, moet MS hier verantwoordelijkheid voor nemen en met juist die ene zin die ik quote schuiven ze dat van zich af. En juist dát mogen ze in dit geval niet. MS is in de eerste plaats verantwoordelijk voor Secure Boot. Heeft zo veel gelobbyd dat het in elk systeem aanwezig is, vereist het dat het aan staat en gebruikt wordt met W11. Als dan van de ene op de andere dag het systeem niet meer start omdat SB is verlopen, kunnen ze niet hun kop in het zand steken als hun proces heeft gefaald dit te voorkomen.

[dcm360]

Eerder dit jaar heb ik over dit onderwerp al meerdere posts zien langskomen, waarvan dit artikel¹ denk ik de beste uitleg geeft.

De TL;DR is: er is geen betrouwbare clock op dat punt van het bootproces, dus de geldigheidsdatum van certificaten wordt niet gecontroleerd.

Wat dat artikel ook nog aanstipt, is dat dit niet enkel gaat om software (het laden van het OS), maar ook om hardware. Alle hardware waar de UEFI interactie mee heeft tijdens het bootproces (GPU, netwerkkaart, etc) maar niet echt 'built-in' is bevat signatures. Strikt controleren op de geldigheidsdatum van die certificaten zou er toe leiden dat hardware van de ene op de andere dag ineens niet meer zou werken.

1: gevonden via HN

[ Voor 6% gewijzigd door dcm360 op 02-11-2025 10:22 ]

[Nopheros]

Hero of Time schreef op vrijdag 31 oktober 2025 @ 19:43:
Ik snap niet helemaal waarom je er een enorm probleem van maakt. MS heeft maanden geleden al updates uitgebracht dat een geplande taak heeft gemaakt om de nieuwe certificaten te installeren. Het is niet verplicht om je BIOS bij te werken, de secure boot certificaten is in een losstaand register. Dit is heel fijn, want Linux gebruikers hebben niet altijd toegang tot de MS signing keys en zijn hierdoor in staat hun eigen key te importeren en zo alsnog fatsoenlijk secure boot te hebben met hun eigen kernel.

Heb je enige idee wanneer die scheduled task afgetrapt wordt dan? We hebben hier namelijk +/- 600 HP probooks, W11 apparaten, allemaal 0 tot max 5 jaar oud en het lijkt erop dat er nog geen enkele is geupdate terwijl alle updates automatisch gedraaid worden, incl. BIOS/Firmware updates.

Intune heeft een rapport maar geeft niets aan

Dus ja het begint nu wel wat problematisch te worden.

[EDIT]
Zie onder scheduled tasks wel iets dat heet 'Client cert checker", status: "Proces is onverwachts beëindigd"..

[ Voor 7% gewijzigd door Nopheros op 21-04-2026 10:19 ]

[ZwarteIJsvogel]

Nopheros schreef op dinsdag 21 april 2026 @ 09:58:
Heb je enige idee wanneer die scheduled task afgetrapt wordt dan?

Als een systeem er volgens Microsoft klaar voor is. Wat de status daarvan is, kun je zien in de Windows eventlog. Zoek het meest recente TPM-WMI event 1801 en kijk daarin wat het BucketConfidenceLevel is. Als dat High Confidence is, zal Windows de nieuwe certificaten in de UEFI NVRAM schrijven. Een tijdje later wordt de boot loader bijgewerkt met een versie die ondertekend is met een nieuw certificaat ('Windows UEFI CA 2023' om precies te zijn).

Windows maakt van elk systeem een fingerprint, het BucketId (dat staat ook in het event). Dit wordt opgezocht in een database (C:\Windows\System32\SecureBootUpdates\BucketConfidenceData.cab). De data die daarin staat, is samengesteld op basis van telemetriedata. De database wordt bijgewerkt door Windows Update.

We hebben hier namelijk +/- 600 HP probooks, W11 apparaten, allemaal 0 tot max 5 jaar oud en het lijkt erop dat er nog geen enkele is geupdate terwijl alle updates automatisch gedraaid worden, incl. BIOS/Firmware updates.

Ik weet niet wat allemaal wordt meegenomen in het BucketId, maar ik heb wel gezien dat het BucketId wijzigt bij een UEFI BIOS update. BIOS updates zou ik mede daarom voorlopig even niet automatisch uitrollen.

Intune heeft een rapport maar geeft niets aan

Dus ja het begint nu wel wat problematisch te worden.

Valt wel mee (voor zover ik weet).

De Secure Boot certificaten verlopen weliswaar dit jaar, maar de signatures die ermee zijn gemaakt blijven geldig. Hiervoor is elke signature voorzien van een counter-signature van een vertrouwde timestamp service (in dit geval die van Microsoft). Bij het controleren van een signature wordt gekeken naar het tijdstip waarop die is gegenereerd. Als op dat moment de certificaten van de signature en van de counter-signature beide geldig waren, is de signature gewoon geldig. Het moment waarop de signature wordt gecontroleerd doet er niet toe (het proces werkt dus onafhankelijk van time of day). Ik heb in het verleden software geschreven waarvan het code signing certificaat inmiddels ruimschoots is verlopen, maar Windows zegt nog steeds dat de signature OK is.

Waarom is het updaten van die certificaten dan toch belangrijk? Zonder de nieuwe certificaten kun je geen software draaien waarvan de boot loader met het nieuwe certificaat is ondertekend. Daardoor kun je bv. een boot loader update niet installeren die een belangrijk security issue patcht. Of Windows opnieuw installeren vanaf een vers gedownload image. Of een ander OS (bv. Linux). Secure Boot uitschakelen is dan de workaround, maar dat wil je liever niet.

Zie onder scheduled tasks wel iets dat heet 'Client cert checker", status: "Proces is onverwachts beëindigd"..

Die task is van Intune, niet van Windows.

Hier vind je wat handige scripts om de Secure Boot update status op een systeem te controleren: https://github.com/cjee21/Check-UEFISecureBootVariables. Met de Check scripts kun je de stand van zaken zien, met de Apply scripts kun je o.a. het installeren van de nieuwe certificaten forceren. Mijn advies is om dat NIET te doen, tenzij het noodzakelijk is en je EXACT weet wat je aan het doen bent. Laat het over aan Windows.

[Nopheros]

ZwarteIJsvogel schreef op dinsdag 21 april 2026 @ 11:46:
[...]

Als een systeem er volgens Microsoft klaar voor is. Wat de status daarvan is, kun je zien in de Windows eventlog. Zoek het meest recente TPM-WMI event 1801 en kijk daarin wat het BucketConfidenceLevel is. Als dat High Confidence is, zal Windows de nieuwe certificaten in de UEFI NVRAM schrijven. Een tijdje later wordt de boot loader bijgewerkt met een versie die ondertekend is met een nieuw certificaat ('Windows UEFI CA 2023' om precies te zijn).

Windows maakt van elk systeem een fingerprint, het BucketId (dat staat ook in het event). Dit wordt opgezocht in een database (C:\Windows\System32\SecureBootUpdates\BucketConfidenceData.cab). De data die daarin staat, is samengesteld op basis van telemetriedata. De database wordt bijgewerkt door Windows Update.


[...]

Ik weet niet wat allemaal wordt meegenomen in het BucketId, maar ik heb wel gezien dat het BucketId wijzigt bij een UEFI BIOS update. BIOS updates zou ik mede daarom voorlopig even niet automatisch uitrollen.


[...]

Valt wel mee (voor zover ik weet).

De Secure Boot certificaten verlopen weliswaar dit jaar, maar de signatures die ermee zijn gemaakt blijven geldig. Hiervoor is elke signature voorzien van een counter-signature van een vertrouwde timestamp service (in dit geval die van Microsoft). Bij het controleren van een signature wordt gekeken naar het tijdstip waarop die is gegenereerd. Als op dat moment de certificaten van de signature en van de counter-signature beide geldig waren, is de signature gewoon geldig. Het moment waarop de signature wordt gecontroleerd doet er niet toe (het proces werkt dus onafhankelijk van time of day). Ik heb in het verleden software geschreven waarvan het code signing certificaat inmiddels ruimschoots is verlopen, maar Windows zegt nog steeds dat de signature OK is.

Waarom is het updaten van die certificaten dan toch belangrijk? Zonder de nieuwe certificaten kun je geen software draaien waarvan de boot loader met het nieuwe certificaat is ondertekend. Daardoor kun je bv. een boot loader update niet installeren die een belangrijk security issue patcht. Of Windows opnieuw installeren vanaf een vers gedownload image. Of een ander OS (bv. Linux). Secure Boot uitschakelen is dan de workaround, maar dat wil je liever niet.


[...]

Die task is van Intune, niet van Windows.

Hier vind je wat handige scripts om de Secure Boot update status op een systeem te controleren: https://github.com/cjee21/Check-UEFISecureBootVariables. Met de Check scripts kun je de stand van zaken zien, met de Apply scripts kun je o.a. het installeren van de nieuwe certificaten forceren. Mijn advies is om dat NIET te doen, tenzij het noodzakelijk is en je EXACT weet wat je aan het doen bent. Laat het over aan Windows.

Event ID 1801 is idd handig mocht je nog op de oude certificaat zitten, 1808 zou je te zien moeten krijgen als het voltooid is en 1795 bij een fout.

Onze confidence level zit op 'more data needed'. Vandaar ook de zoektocht hoe ik het een handje kan helpen. Er is veel info beschikbaar maar weinig over de daadwerkelijk te zetten stappen wanneer het niet werkt.

Wij gebruiken daarnaast Intune met compliancy policies, uiteraard is 1 van de gecontroleerde zaken 'secure boot' dus ik zou het eigenlijk wel gefixed willen hebben voor het vervallen. Mocht het echt niet werken dan kan ik die optie uiteraard tijdelijk uitschakelen in de policy maar dat is niet gewenst.

Als ik je tekst goed begrijp, en het klopt ook, dan blijft secure boot ook na het verlopen van het certificaat gewoon actief, dat zou mooi zijn als dat inderdaad het geval is.

[ZwarteIJsvogel]

Nopheros schreef op dinsdag 21 april 2026 @ 13:05:
Event ID 1801 is idd handig mocht je nog op de oude certificaat zitten, 1808 zou je te zien moeten krijgen als het voltooid is en 1795 bij een fout.

Onze confidence level zit op 'more data needed'. Vandaar ook de zoektocht hoe ik het een handje kan helpen. Er is veel info beschikbaar maar weinig over de daadwerkelijk te zetten stappen wanneer het niet werkt.

Mijn PC (zelfbouw met een GigaByte moederbord) zat na de patchrondes van februari en maart nog op het niveau 'Under Observation - More Data Needed'. Bij de patchronde van deze maand werd dat 'High Confidence' en werden geüpdatete bootbestanden geïnstalleerd. Gisteren verscheen event 1808 (die check draait denk ik maar 1x per week).

Maar als je een BIOS update uitrolt, val je helemaal terug in het assessmentproces ('No Data Observed - Action Required') omdat het systeem een nieuw BucketId krijgt. Dan is het weer wachten tot Microsoft voldoende data heeft verzameld. Vandaar mijn advies om mede hierom BIOS updates niet automatisch uit te rollen.

Maar er is meer. De certificaten worden opgeslagen in UEFI variabelen in NVRAM. Bij mij worden die variabelen gewist bij een BIOS update (en dat lijkt 'by design' te zijn). Als de nieuwe BIOS het certificaat 'Windows UEFI CA 2023' default aan boord heeft, is er geen probleem. BIOS updates die nu uitkomen zullen dat certificaat aan boord hebben.

Maar stel dat je een oud systeem hebt dat al de certificaatupdates heeft gehad en ook een geüpdatete bootloader, en dat je daarop nog even de laatste BIOS wilt installeren die al een paar jaar oud is, dan kan het zomaar gebeuren dat het systeem niet meer start omdat de BIOS het nieuwe certificaat niet default heeft.

BIOS updates kunnen tricky zijn.

Event 1795 zou eigenlijk niet moeten optreden als het bucket confidence level 'High Confidence' is. Ik denk dat het vooral optreedt als je de updates probeert te forceren op een systeem dat (nog) niet geschikt is. Datzelfde geldt voor sommige van de andere failure events.

Wij gebruiken daarnaast Intune met compliancy policies, uiteraard is 1 van de gecontroleerde zaken 'secure boot' dus ik zou het eigenlijk wel gefixed willen hebben voor het vervallen. Mocht het echt niet werken dan kan ik die optie uiteraard tijdelijk uitschakelen in de policy maar dat is niet gewenst.

Als ik je tekst goed begrijp, en het klopt ook, dan blijft secure boot ook na het verlopen van het certificaat gewoon actief, dat zou mooi zijn als dat inderdaad het geval is.

Voor zover ik weet is dat het geval (wel zeker eigenlijk, maar ik hou graag een slag om de arm). Anders zouden heel wat systemen plotseling niet booten (denk bv. aan Windows 7/8, daar zijn er nog miljoenen van in de wereld).

[Nopheros]

ZwarteIJsvogel schreef op dinsdag 21 april 2026 @ 14:38:
[...]

Mijn PC (zelfbouw met een GigaByte moederbord) zat na de patchrondes van februari en maart nog op het niveau 'Under Observation - More Data Needed'. Bij de patchronde van deze maand werd dat 'High Confidence' en werden geüpdatete bootbestanden geïnstalleerd. Gisteren verscheen event 1808 (die check draait denk ik maar 1x per week).

Maar als je een BIOS update uitrolt, val je helemaal terug in het assessmentproces ('No Data Observed - Action Required') omdat het systeem een nieuw BucketId krijgt. Dan is het weer wachten tot Microsoft voldoende data heeft verzameld. Vandaar mijn advies om mede hierom BIOS updates niet automatisch uit te rollen.

Maar er is meer. De certificaten worden opgeslagen in UEFI variabelen in NVRAM. Bij mij worden die variabelen gewist bij een BIOS update (en dat lijkt 'by design' te zijn). Als de nieuwe BIOS het certificaat 'Windows UEFI CA 2023' default aan boord heeft, is er geen probleem. BIOS updates die nu uitkomen zullen dat certificaat aan boord hebben.

Maar stel dat je een oud systeem hebt dat al de certificaatupdates heeft gehad en ook een geüpdatete bootloader, en dat je daarop nog even de laatste BIOS wilt installeren die al een paar jaar oud is, dan kan het zomaar gebeuren dat het systeem niet meer start omdat de BIOS het nieuwe certificaat niet default heeft.

BIOS updates kunnen tricky zijn.

Event 1795 zou eigenlijk niet moeten optreden als het bucket confidence level 'High Confidence' is. Ik denk dat het vooral optreedt als je de updates probeert te forceren op een systeem dat (nog) niet geschikt is. Datzelfde geldt voor sommige van de andere failure events.

[...]

Voor zover ik weet is dat het geval (wel zeker eigenlijk, maar ik hou graag een slag om de arm). Anders zouden heel wat systemen plotseling niet booten (denk bv. aan Windows 7/8, daar zijn er nog miljoenen van in de wereld).

Bedankt voor de info en lekker dan @ bios update. Die worden hier automatisch uitgevoerd, laatste was een paar weken terug. Misschien maar even de driver updates tijdelijk stil leggen dan (alhoewel het waarschijnlijk dus weinig effect heeft, het verlopen van de certificaten).

[Hero of Time]

Nopheros schreef op dinsdag 21 april 2026 @ 09:58:
[...]


Heb je enige idee wanneer die scheduled task afgetrapt wordt dan? We hebben hier namelijk +/- 600 HP probooks, W11 apparaten, allemaal 0 tot max 5 jaar oud en het lijkt erop dat er nog geen enkele is geupdate terwijl alle updates automatisch gedraaid worden, incl. BIOS/Firmware updates.

Intune heeft een rapport maar geeft niets aan

Dus ja het begint nu wel wat problematisch te worden.

Je hebt Intune, kijk daarom even naar Microsoft Intune ervaringentopic of een paar pagina's terug erin. Je moet tevens diagnostic data naar MS sturen en in je tenant de verwerking aanzetten, dan krijg je de status rapportage te zien. Daarnaast is er een Settings Catalog optie om de boel te laten updaten als dat kan. Werkt bij ons prima.

We hebben een aantal oudere systemen (Core i 9e generatie) die geen BIOS updates meer krijgen en hier heb ik geprobeerd een SB update op uit te laten voeren. Dat lukte niet omdat er 1 onderdeel, de KEK meen ik, niet bij te werken is want het OEM gedeelte is niet bij MS bekend en daardoor niet ondertekend. Dit ene dingetje zorgt er voor dat het updaten niet afgerond kan worden. Enige optie hiervoor? SB uitzetten.

[Nopheros]

Hero of Time schreef op dinsdag 21 april 2026 @ 20:11:
[...]

Je hebt Intune, kijk daarom even naar Microsoft Intune ervaringentopic of een paar pagina's terug erin. Je moet tevens diagnostic data naar MS sturen en in je tenant de verwerking aanzetten, dan krijg je de status rapportage te zien. Daarnaast is er een Settings Catalog optie om de boel te laten updaten als dat kan. Werkt bij ons prima.

We hebben een aantal oudere systemen (Core i 9e generatie) die geen BIOS updates meer krijgen en hier heb ik geprobeerd een SB update op uit te laten voeren. Dat lukte niet omdat er 1 onderdeel, de KEK meen ik, niet bij te werken is want het OEM gedeelte is niet bij MS bekend en daardoor niet ondertekend. Dit ene dingetje zorgt er voor dat het updaten niet afgerond kan worden. Enige optie hiervoor? SB uitzetten.

De settings catalog optie staat hier al een tijdje aan en diagnostic info sturen we in principe ook maar zal het topic idd nog even doornemen dan.

[Hero of Time]

Nopheros schreef op dinsdag 21 april 2026 @ 20:21:
[...]

De settings catalog optie staat hier al een tijdje aan en diagnostic info sturen we in principe ook maar zal het topic idd nog even doornemen dan.

Ik kreeg eerst ook geen info te zien in Intune, de rapportage bleef maar op 'not applicable' staan (geen info ontvangen dus). Met de paar posts van degene die in dat topic voor zichzelf aan de praat had en wat extra zoeken had ik het ook werken. Wanneer het allemaal goed staat, zal je de dag erna resultaten moeten zien.