Waarom MFA niet afdwingt terwijl het wel zou moeten in Microsoft-omgevingen

By Mirko Peters · 2026-04-22

Multi-factor authentication (MFA) hoort je vangnet te zijn in Microsoft 365 en Azure, zodat aanvallers worden tegengehouden, zelfs als ze een wachtwoord stelen. Maar wat gebeurt er als dat vangnet er simpelweg niet is, terwijl het er wel zou moeten zijn…

Automatically translated with AI from the original post. Read the English original

Multi-factor authentication (MFA) hoort je vangnet te zijn in Microsoft 365 en Azure, zodat aanvallers worden tegengehouden, zelfs als ze een wachtwoord stelen. Maar wat gebeurt er als dat vangnet er simpelweg niet is, terwijl het er wel zou moeten zijn? ‘Zou moeten’ gaat over die kritieke momenten: risicovolle aanmeldingen, aanmeldingen van beheerdersaccounts of toegang van buiten je gebruikelijke locaties. Als MFA op die momenten niet afgaat, heb je een blootstelling, punt uit.

Die hiaten sluipen er vaak in door een mix van technische problemen, verwarrende beleidsinstellingen en soms zelfs workarounds van eindgebruikers. Soms komt het door verouderde verificatie in apps, zwakke voorwaardelijke toegangsbeleidsregels of onvolledige dekking van gebruikers. Hoe het ook gebeurt: ontbrekende MFA op de plekken waar het het meest telt, opent de deur voor aanvallers en levert echte beveiligingsproblemen op.

Deze gaten in de afdwinging begrijpen en vooral dichtzetten is essentieel om je gegevens goed af te schermen. Wil je een praktijkvoorbeeld zien van hoe aanvallers deze scheuren misbruiken met tokendiefstal en OAuth-gedoe, dan laat deze Microsoft 365-inbreukanalyse precies zien wat er op het spel staat.

Waar MFA niet afgaat en waarom

MFA is alleen zo sterk als het beleid en de technologie eromheen. Het frustrerende is dat er, zelfs als je zeker weet dat alles goed is ingesteld, nog steeds veel scenario's zijn waarin MFA stilletjes uitblijft, ook voor kritieke gebruikers of bij risicovolle aanmeldingen.

Een veelvoorkomende boosdoener is verkeerd geconfigureerd voorwaardelijk toegangsbeleid. Misschien wordt een VIP-gebruiker om ‘gemak’ uitgesloten, of blijven testaccounts met brede machtigingen en zonder MFA-vereiste bestaan. Dit soort uitsluitingen lijkt tijdens de inrichting onschuldig, maar ze kunnen zomaar gaten in je verdediging slaan. Als je beleid niet regelmatig wordt doorgelopen, kun je met onzichtbare beveiligingslekken blijven zitten waar geen dashboard je voor waarschuwt.

Verouderde apps zijn een ander verraderlijk probleem. Tools zoals Exchange ActiveSync of bepaalde desktop-mailclients gebruiken vaak verouderde verificatie en omzeilen zo standaard moderne MFA. Deze niet-browserapps vertrouwen op basisverificatie, wat niet compatibel is met je gloednieuwe MFA-opzet. Gevolg: aanmeldingen gebeuren volledig buiten jouw controle.

En vergeet het gedrag van gebruikers niet. Sommige gebruikers maken ‘app-wachtwoorden’ aan om oudere apps te koppelen, en die omzeilen MFA volledig. Anderen verlenen per ongeluk OAuth-machtigingen aan apps van derden via riskante toestemmingsvragen, waarmee ze aanvallers een achterdeur geven die nooit om MFA wordt gevraagd. Hier komt governance om de hoek kijken, want gebruikers kunnen MFA omzeilen zonder het risico ook maar door te hebben.

Voor organisaties met hybride of multi-cloudomgevingen worden deze gaten nog talrijker. Als je niet systematisch controleert wie en wat MFA afgedwongen krijgt, mis je mogelijk kritieke blootstellingen. Alleen door de identiteitsdashboards van alle platformen door te nemen, krijg je een echt beeld van je dekking. Weten waar MFA faalt, legt de basis om je controles aan te scherpen en elke aanmelding te beveiligen, ongeacht hoe of waar die plaatsvindt.

MFA-methoden implementeren die bestand zijn tegen phishing voor veilige authenticatie

Standaard MFA is goed, totdat aanvallers uitvinden hoe ze gebruikers kunnen misleiden met pushvermoeidheid, phishingprompts of tokendiefstal. Daarom is overstappen naar phishingbestendige MFA echt belangrijk als je moderne aanvallen de deur wilt wijzen.

Nummerafstemming in authenticator-apps is een solide verbetering. In plaats van een generieke push goed te keuren, krijgen gebruikers een code die ze moeten invoeren. Daardoor is het bijna onmogelijk voor een aanvaller om iemand via prompt bombing te misleiden. Microsoft en anderen duwen hier sterk op en zetten het standaard aan voor nieuwe MFA-opzetten. Het pakt direct de hinderlijke prompt-bombing-trucs aan die in recente, bekende inbreuken zijn gebruikt.

Fysieke beveiligingssleutels zoals YubiKey en FIDO2-tokens gaan nog een stap verder. Deze sleutels kunnen niet worden gephisht en vertrouwen niet op gedeelde geheimen. In zeer gevoelige omgevingen, of voor beheerders en directieleden, komt dit neer op ‘lockdown-modus’: hardwaregebaseerde authenticatie die de meeste echte aanvalstechnieken direct blokkeert.

Je hoeft ook niet in te leveren op gebruiksgemak. Met moderne wachtwoordloze aanmeldopties en een sterke integratie met platformen als Microsoft 365 en Defender kun je phishing-resistente MFA rechtstreeks in je bestaande werkprocessen inbouwen. Voor praktijkvoorbeelden van het integreren van voorwaardelijke toegang met geavanceerde dreigingsbescherming en een gebruiksvriendelijke ervaring, bekijk je deze gids over ijzersterke M365-beveiligingsinstellingen. Overstappen op phishing-resistente MFA is niet langer ‘een leuke extra’—het wordt snel de nieuwe basisnorm om je te beschermen tegen geavanceerde aanvallers.

MFA implementeren zonder kosten voor kleine bedrijven met Microsoft Entra ID

Als je een klein bedrijf runt, heb je geen enorm budget of dure licenties nodig om krachtige MFA in te richten. Microsoft Entra ID (voorheen Azure AD) biedt beveiligingsstandaarden, die elk bedrijf met een paar klikken kan activeren.

Schakel beveiligingsstandaarden in via het Entra-beheercentrum. Hiermee wordt MFA meteen afgedwongen voor alle gebruikers—zonder ingewikkeld beleid op te bouwen of extra licenties aan te schaffen. Het mooiste is nog dat deze vooraf geconfigureerde instellingen direct werken en standaardbescherming bieden tegen het compromitteren van accounts, en verouderde verificatieprotocollen standaard blokkeren.

Een soepele uitrol is belangrijk. Waarschuw je gebruikers vooraf, zodat niemand onverwacht wordt overvallen door nieuwe prompts. Ondersteun mensen die minder bekend zijn met MFA-tools of authenticator-apps. Test de opzet indien mogelijk eerst met een pilotgroep, zodat er geen verrassingen zijn met kritieke werk-apps of serviceaccounts.

Het belangrijkste is dat je niet blind vertrouwt op ‘instellen en vergeten’. Controleer regelmatig wie onder beveiligingsstandaarden valt en zoek naar accounts die er mogelijk tussendoor glippen. Als je later behoefte krijgt aan fijnmaziger beheer, overweeg dan voorwaardelijke toegang in fasen toe te voegen—maar begin eenvoudig en veilig. Voor een veilig uitrolplan en ideeën om onzichtbare gaten te dichten, behandelt deze praktische gids over voorwaardelijke toegang de valkuilen en strategieën die je wilt kennen.

MFA voor bedrijven: best practices voor het afdwingen van beleid en het beperken van risico’s

1. Pas MFA universeel toe—geen uitzonderingen uit gemak. Zorg dat alle gebruikersaccounts (niet alleen beheerders) onder het MFA-beleid vallen, inclusief accounts voor tijdelijk personeel, leveranciers en directieleden. Uitzonderingen moeten zeldzaam zijn, altijd in tijd beperkt, en met een sterke zakelijke onderbouwing.
2. Beveilig service- en niet-menselijke accounts met moderne oplossingen. Traditionele serviceaccounts kunnen grote MFA-gaten vormen. Moderniseer ze met tools zoals Entra Workload Identities voor beheerde authenticatie, zodat je levenscyclusbeheer en controleerbaarheid krijgt. Meer over deze aanpak lees je in deze uitleg over risico’s bij niet-menselijke accounts.
3. Begeleid gebruikers met de juiste training en ondersteuning. Help gebruikers bij het instellen van authenticator-apps of fysieke tokens en leg uit waarom MFA belangrijk is. Zorg tijdens de uitrol voor helpdeskondersteuning, vooral voor gebruikers die niet bekend zijn met nieuwe MFA-prompts zoals getalsovereenkomst.
4. Houd pogingen om MFA te omzeilen en afwijkende aanmeldingen in de gaten. Stel waarschuwingen en logs in om te detecteren wanneer MFA ontbreekt in verwachte scenario’s met hoog risico, of wanneer verouderde protocollen er toch doorheen glippen. Automatiseer waar mogelijk de incidentrespons—denk aan het resetten van wachtwoorden of het afdwingen van extra MFA-verificatie bij riskante aanmeldingen.
5. Controleer MFA-dekking en naleving van beleid regelmatig. Ga er niet van uit dat de dekking ‘wel goed zit’. Gebruik identiteitsdashboards en rapportages, zowel in Microsoft 365 als op andere platformen als je multi-cloud werkt. Vertaal bevindingen naar duidelijke rapporten, zodat IT en management kunnen zien waar nog risico’s bestaan. Effectief bestuur gaat verder dan knopjes en schakelaars; voor meer inzicht kun je deze lessen uit mislukte M365-governance bekijken.

Door deze checklist te volgen verklein je het risico aanzienlijk dat aanvallers langs MFA glippen, hoe slim de techniek ook is. Consistentie, duidelijk beleid en regelmatige controles houden de bescherming sterk en de gaten dicht.