Wie in 2024 nog zonder MFA in de Azure-portal kon, merkt inmiddels dat Microsoft dat niet langer accepteert. Sinds maart 2025 is multifactorauthenticatie verplicht voor iedereen die inlogt op de Azure-portal, het Entra-beheercentrum en het Intune-beheercentrum. In februari 2026 volgde het Microsoft 365-beheercentrum. En sinds 1 oktober 2025 rolt fase twee uit: MFA voor alles wat Azure-resources aanmaakt, wijzigt of verwijdert via Azure CLI, PowerShell, de REST API of Infrastructure-as-Code-tooling. Wie uitstel had aangevraagd, kon dat rekken tot 1 juli 2026. Dat uitstel is voorbij.
Waarom Microsoft dit afdwingt
Het argument is simpel en klopt: veruit de meeste gekaapte accounts hadden geen MFA. Microsoft ziet in zijn eigen data dat MFA meer dan 99 procent van de pogingen tot accountovername blokkeert. Dat het bedrijf de maatregel nu afdwingt in plaats van aanbeveelt, zegt iets over hoe vaak de aanbeveling werd genegeerd. Beheerdersaccounts zonder tweede factor waren tot voor kort geen uitzondering, ook bij organisaties die verder alles netjes op orde hadden.
Als jouw organisatie MFA al via Conditional Access afdwingt, of als beheerders inloggen met passkeys of Windows Hello for Business, verandert er in de praktijk niets. De verplichting van Microsoft ligt onder je eigen beleid, niet erbovenop. Het wordt pas interessant waar je beleid gaten had.
Waar het nu misgaat
Drie plekken waar we de afgelopen maanden problemen zagen ontstaan:
- Serviceaccounts die eigenlijk gebruikersaccounts zijn. Een account "svc-backup" dat via Entra Connect is gesynchroniseerd en 's nachts een script draait dat resources aanpast, is voor Microsoft gewoon een gebruiker. Zonder MFA faalt het script. Met MFA kan het niet onbeheerd draaien. De enige goede oplossing is de automatisering omzetten naar een workload-identiteit: een managed identity of een service principal. Die vallen buiten de MFA-verplichting, omdat ze op certificaten of federatie draaien en niet op een wachtwoord.
- Oude authenticatiestromen. Scripts die gebruikersnaam en wachtwoord meegeven (de zogenoemde ROPC-flow) werken niet meer. Datzelfde geldt voor oudere versies van de Azure-modules die op wachtwoorden leunen. Dat is geen bug, het is de bedoeling.
- Break-glass-accounts. Het noodaccount dat je gebruikt als Conditional Access zichzelf buitensluit, moet ook aan MFA voldoen. De juiste inrichting is een FIDO2-sleutel in een kluis, geen wachtwoord op een briefje. Wie dat nog niet zo heeft, ontdekt het op het verkeerde moment.
Wat "MFA" hier precies betekent
De verplichting van Microsoft stelt geen eisen aan de kwaliteit van de tweede factor. Een sms-code telt. Dat is jammer, want juist voor beheerders is een sms of een pushmelding niet genoeg: een aanvaller met een nagemaakte inlogpagina stuurt die gewoon door. Voor accounts met rechten op je omgeving is phishing-resistant MFA de norm die je zelf moet zetten: FIDO2-sleutels, passkeys of Windows Hello for Business, afgedwongen via een authentication strength in Conditional Access. De verplichting van Microsoft is het minimum. Je beleid hoort daar ruim boven te liggen.
Zo pak je het aan
- Inventariseer welke identiteiten Azure-resources beheren. Niet alleen mensen, ook scripts, pipelines en koppelingen. Het sign-in-log van Entra ID laat zien welke accounts met wachtwoord inloggen op beheer-endpoints.
- Zet automatisering om naar managed identities of service principals met certificaat. Geen client secrets die over een jaar verlopen op een moment dat niemand het verwacht.
- Dwing voor alle beheerdersrollen phishing-resistant MFA af, en beperk permanente rechten met Privileged Identity Management: rechten activeer je als je ze nodig hebt, met goedkeuring en een tijdslimiet.
- Test het break-glass-account met een collega die er nooit eerder mee heeft ingelogd. Als het niet lukt, is het geen noodaccount.
De verplichting van Microsoft is een goed moment om dit in één keer goed te doen. Twijfel je of je omgeving al klopt, dan is een Digital Defense Review de snelste manier om dat zeker te weten.