Gerelateerde artikelen
De Windows‑update van 13 januari 2026 heeft wereldwijd voor verstoringen gezorgd. Remote Desktop‑verbindingen vielen massaal uit en talloze pc’s en servers konden niet meer in slaapstand of hibernatie. Microsoft moest vervolgens, halsoverkop, een noodupdate uitbrengen om de schade te beperken.
Dereguliere Patch Dinsdag update van 13 januari 2026 introduceerde twee ernstige onbedoelde fouten in Windows 11 en diverse Windows Server‑versies. Binnen enkele dagen stroomden meldingen binnen van organisaties die geen Remote Desktop‑sessies meer konden opzetten en tevens van systemen die niet meer konden afsluiten of in slaapstand gingen. Microsoft bevestigde de problemen en bracht op 17 januari 2026 een reeks out‑of‑band (OOB) noodupdates uit om de fouten te herstellen.
1. Remote Desktop valt massaal uit
Wat ging er mis?
- Na installatie van de januari‑update faalden RDP‑authenticaties direct bij het inlogscherm.
- Verbindingen zoals met Azure Virtual Desktop, Windows 365 Cloud PC en traditionele RDP‑servers braken af tijdens de handshake.
- Het probleem zat aan de clientzijde, waardoor zowel cloud‑ als tevens on‑premises‑omgevingen getroffen werden.
Impact
- Organisaties die sterk leunen op hybride of remote werk zagen medewerkers plotseling buitengesloten.
- Beheerders konden in sommige gevallen zelfs hun eigen servers niet meer bereiken.
- In grote IT‑omgevingen leidde dit tot acute verstoringen van bedrijfsprocessen.
Microsofts reactie
- De fout werd erkend en er werd een OOB‑update uitgebracht die tevens de authenticatiestroom herstelt.
- Voor enterprise‑omgevingen werd ook Known Issue Rollback (KIR) ingezet om de impact te beperken.
2. Slaapstand en afsluiten werken niet meer
De fout: systemen herstarten in plaats van uit te gaan
Een tweede, volledig losstaand probleem, trof vooral Windows 11 systemen met System Guard Secure Launch ingeschakeld.
- Pc’s en laptops herstartten zodra gebruikers probeerden af te sluiten of te hibernaten.
- In plaats van uit te schakelen keerde het systeem terug naar het inlogscherm.
Wie werd getroffen?
- Vooral Windows 11 23H2 systemen in enterprise‑omgevingen.
- Secure Launch is vooral actief in zakelijke en IoT‑images, waardoor consumenten minder last hadden.
Operationele gevolgen
- Laptops die ’s nachts zouden hibernaten bleven aanstaan en liepen leeg.
- Automatische onderhoudstaken en imaging‑processen faalden.
- Helpdesks zagen vervolgens een piek in meldingen van apparaten die niet meer uit willen.
3. De noodupdate: Microsoft grijpt in
Op zaterdag 17 januari 2026 bracht Microsoft meerdere OOB‑updates uit, waaronder KB5077744 en KB5077797, die beide onbedoelde fout moesten oplossen.
Waarom een OOB‑update?
Out‑of‑band updates worden alleen gebruikt wanneer:
- De fout bedrijfskritische functionaliteit raakt;
- De impact onmiddellijk en breed is;
- Wachten op de volgende Patch Dinsdag onacceptabel is.
Dat Microsoft deze route koos, benadrukt de ernst van de problemen.
Andere verbindingen op afstand en gerelateerde applicaties kunnen op soortgelijke wijze geraakt zijn.
Alsdus Microsoft op haar release-health-website.
4. Hoe kon dit gebeuren?
De onbedoelde fouten ontstonden door complexe interacties tussen:
- de nieuwe beveiligingscomponenten in de januari‑update;
- de vroege‑bootbeveiliging van System Guard Secure Launch;
- authenticatie‑mechanismen van Remote Desktop.
Volgens Microsoft ging het om edge‑case‑interacties die tijdens testen niet waren opgevallen, maar in de praktijk grote gevolgen hadden.
5. Wat moeten organisaties nu doen?
Directe acties
- Controleren of de OOB‑updates zijn geïnstalleerd.
- In enterprise‑omgevingen: valideren of KIR‑policies correct zijn toegepast.
- Voor servers: nagaan of RDP‑connectiviteit volledig is hersteld.
Lessen voor IT‑teams
- Kritieke updates eerst testen in een staging‑omgeving.
- Power‑management en Secure Launch‑configuraties expliciet meenemen in testscenario’s.
- Monitoring instellen op RDP‑authenticatie en power‑state‑events.
Secure Launch vs. Secure Boot
Wat is Secure Boot
- Controleert UEFI‑bootloaders en drivers voordat Windows start.
- Voorkomt dat niet‑vertrouwde of gemanipuleerde bootloaders worden geladen.
- Is onderdeel van de firmware/UEFI‑laag.
Secure Launch of System Guard Secure Launch
- Komt ná Secure Boot in actie.
- Start Windows in een hardware‑geïsoleerde omgeving zoals: via TPM + CPU‑virtualisatie).
- Controleert of de hypervisor en kernel niet zijn gemanipuleerd voordat ze worden geladen.
- Beschermt tegen geavanceerde aanvallen zoals bootkits, hypervisor‑rootkits en manipulatie van de kernel tijdens het opstarten.
Dit is een extra beveiligingslaag bovenop Secure Boot:
Secure Boot: Is de bootloader betrouwbaar?
Ja, als Secure Boot is ingeschakeld en correct geconfigureerd, dan wordt alleen een digitale gesigneerde en vertrouwde bootloader geladen. Dit voorkomt tevens dat malware of ongeautoriseerde software zich nestelt in het opstartproces.
Secure Launch: “Is de hypervisor en kernel betrouwbaar én niet aangetast?”
Ja, als Secure Launch of System Guard Secure Launch actief is, dan start Windows in een hardware‑geïsoleerde omgeving. Hierbij wordt de hypervisor en kernel gecontroleerd op integriteit vóór ze worden geladen. Dit beschermt tegen bootkits, rootkits en manipulatie van het geheugen tijdens het opstarten.
Waarom dit relevant is voor de Windows‑update‑bug
De recente updateproblemen met slaapstand en afsluiten traden vooral op bij systemen waar Secure Launch actief was, niet bij systemen met alleen Secure Boot. Dat komt doordat de fout zat in de interactie tussen Secure Launch en bepaalde power‑states.
Conclusie
De januari‑update van 2026 laat zien hoe kwetsbaar moderne IT‑omgevingen zijn voor onbedoelde fouten in beveiligingspatches. Een enkele fout in de authenticatiestroom voor het power‑management kan wereldwijd duizenden organisaties ontregelen. De snelle OOB‑update van Microsoft beperkte de schade, maar het incident benadrukt opnieuw de noodzaak van zorgvuldige update‑strategieën en robuuste testprocessen.
