Multi-factor-authenticatie is al jaren de meest effectieve maatregel tegen accountmisbruik, maar juist omdat organisaties er volledig op vertrouwen, vormt het menselijke element een kwetsbaar aanvalsoppervlak. Steeds vaker combineren aanvallers credential harvesting met een stroom aan pushmeldingen in Microsoft Entra ID of andere MFA-apps. Zodra een gebruiker die meldingen klakkeloos goedkeurt, valt de hele identiteitsketen stil en staat een aanvaller binnen. De tactiek wordt MFA-fatigue genoemd omdat zij inspeelt op vermoeidheid, verwarring en tijdsdruk.
In recente onderzoekscijfers van het NCSC en Microsoft blijkt dat ruim twintig procent van de onderzochte incidenten in de publieke sector was terug te leiden tot pushbombing. Nederlandse ministeries en uitvoeringsorganisaties lopen extra risico omdat zij 24/7 werken, veel externe leveranciers op hun tenants aansluiten en vaak legacy-applicaties ondersteunen waarin Conditional Access-afdwinging complex is. Bovendien vragen toezichthouders vanuit de Nederlandse Baseline voor Veilige Cloud, de BIO en de NIS2-richtlijn om aantoonbaar inzicht in authenticatie-incidenten. Een enkele foutieve goedkeuring kan daardoor niet meer als gebruikersfout worden beschouwd; het wordt een governance-issue.
Deze gids verdiept zich in de psychologie en modus operandi achter MFA-fatigue, laat zien hoe je Microsoft 365-signalen koppelt aan risicomodellen, en beschrijft welke preventieve en detectieve maatregelen nodig zijn om de keten van credentialdiefstal tot laterale beweging te doorbreken. We koppelen elk onderdeel aan de eisen van Nederlandse toezichthouders, zodat security- en identiteitsarchitecten direct weten welke evidence zij moeten verzamelen en hoe zij de aanpak in beleid, procedures en rapportages verankeren.
Je leert hoe pushbombing zich ontwikkelt van credentialdiefstal tot volledige tenantcompromittering, hoe je Microsoft Entra ID, Defender en Purview-signalen combineert tot een detectieketen, welke beleidskeuzes de Nederlandse Baseline voor Veilige Cloud verwacht en hoe je eindgebruikers én leveranciers meeneemt in een duurzaam weerbaarheidsprogramma.
Activeer nummermatching en contextbewuste meldingen in Microsoft Authenticator, maar koppel deze wijziging altijd aan een begeleid communicatie- en testplan. Laat servicedesks oefenen met lokale debugtenants en verstuur pas productiewijzigingen nadat gebruikers het nieuwe proces hebben bevestigd, zodat je geen stroom incidenttickets krijgt en direct kunt aantonen dat de wijziging gecontroleerd is uitgerold.
Wat is een MFA Fatigue Attack?
Een MFA-fatigueaanval is in essentie een psychologische aanval op het vertrouwen dat organisaties stellen in pushmeldingen. Zodra een aanvaller via phishing, token diefstal of een credential dump toegang heeft tot gebruikersnaam en wachtwoord, probeert hij zich aan te melden bij Microsoft 365, vaak via het reguliere aanmeldportaal zodat de activiteit niet direct verdacht lijkt. Elke mislukte poging genereert een nieuwe MFA-melding op het toestel van de medewerker. Waar securityteams vaak kijken naar technische indicatoren, speelt de echte kwetsbaarheid zich af in het hoofd van de gebruiker, die gewend is om meldingen zonder nadenken goed te keuren om productief te blijven.
De tactiek wordt versterkt door timing en context. Aanvallers plannen pogingen in de vroege ochtend, tijdens drukke bestuursvergaderingen of juist in de avond wanneer iemand ontspannen tv kijkt. Door tientallen meldingen achter elkaar te sturen ontstaat vermoeidheid en het gevoel "misschien is dit toch een legitieme aanmelding van mijn andere apparaat". In Nederlandse overheidsomgevingen is de druk hoger omdat medewerkers vaak in piketdiensten zitten of thuis met virtuele werkplekken werken; het onderscheid tussen legitieme en malafide prompts vervaagt wanneer mensen voortdurend tussen systemen wisselen.
Bekende casussen, zoals de Uber- en Cisco-incidenten uit 2022, laten zien hoe effectief de tactiek is. In beide gevallen werd een contractor doelbewust bestookt met meldingen, waarna de aanvaller telefonisch contact opnam en zich voordeed als helpdeskmedewerker. Deze combinatie van digitale en telefonische social engineering maakte het slachtoffer onzeker en leidde tot uiteindelijk goedkeuring. Ook in Nederland zagen SOC’s vergelijkbare scenario’s bij onderwijs- en zorginstellingen, waar aanvallers via openbaar beschikbare contactgegevens een geloofwaardig verhaal konden ophangen over een urgent certificaatprobleem.
MFA-fatigue moet daarom niet worden gezien als een fout van een onoplettende medewerker, maar als een aanvalsroute die onderdeel is van geavanceerde campagnes. Dezelfde groepen die phishingkits en ransomware inzetten, automatiseren pushbombing met scripts die honderden pogingen doen, IP-adressen roteren via residentiële proxy’s en zelfs de taal van de meldingen nabootsen. Een enkel incident kan uitgroeien tot een supply-chainrisico wanneer een leverancier met gedelegeerde administratieve rechten wordt geraakt en zo toegang krijgt tot meerdere tenants binnen het Rijk.
Het onderscheidende kenmerk van MFA-fatigue is dat traditionele logica van "meer prompts betekent veiliger" niet meer opgaat. Waar MFA ooit bedoeld was om gebruikers actief te betrekken, zorgt de lawine aan meldingen nu voor gewenning. Mensen die dagelijks tientallen authenticatorpop-ups zien, keuren ze net zo automatisch goed als cookie-banners. Dit vraagt om een herijking van bewustwording en techniek: medewerkers moeten opnieuw leren dat elke melding een potentiële aanval is, terwijl technologie moet zorgen voor extra context zoals nummermatching en locatieweergave zodat legitieme verzoeken eenvoudig herkenbaar zijn.
Vanuit governanceperspectief hoort MFA-fatigue in het risicoregister naast phishing en credential stuffing. De Nederlandse Baseline voor Veilige Cloud en de BIO vereisen dat organisaties aantonen dat zij authentisatieprocessen periodiek evalueren, inclusief de menselijke component. Dat betekent dat CISO’s moeten rapporteren over het aantal pushbombingpogingen, de effectiviteit van mitigerende maatregelen en de lessons learned. Door het fenomeen als volwaardige dreiging te behandelen, ontstaat de juiste urgentie om tooling, processen en cultuur aan te passen voordat een aanvaller er misbruik van maakt.
Anatomie van een MFA Fatigue Attack
Een typische MFA-fatigueaanval verloopt in vier opeenvolgende fases die elkaar versterken en die je alleen kunt stoppen wanneer je het hele patroon begrijpt. In de eerste fase staat credentialdiefstal centraal. Aanvallers gebruiken phishingkits die Microsoft 365-loginpagina’s perfect nabootsen, sturen sms-berichten naar BYOD-toestellen of benutten bestaande datalekken. Binnen publieke organisaties zien we ook dat combinaties van open bronnen, LinkedIn-profielen en leverancierslijsten worden misbruikt om hoogwaardigheidsbekleders of functioneel beheerders gericht te benaderen. Zodra de inloggegevens op straat liggen, verplaatsen de criminelen zich naar geautomatiseerde scripts die voortdurend authenticatiepogingen uitvoeren.
De tweede fase kenmerkt zich door het bombarderen van de gebruiker. Scripts proberen om de dertig seconden verbinding te maken, vanuit verschillende regioknooppunten die via een botnet worden aangestuurd. Sommige aanvallers registreren zelfs applicaties in Entra ID om via OAuth-consent extra prompts te genereren. Daarmee omzeilen zij throttling-limieten en kunnen zij urenlang druk houden op dezelfde identiteit. Het effect is niet alleen technisch, maar ook organisatorisch: servicedesks krijgen meldingen over stokkende authenticator-apps en proberen gebruikers te helpen, waardoor de aanvaller onverwachte steun krijgt.
In fase drie schakelen criminelen over op social engineering. Ze bellen, sturen WhatsApp-berichten of sturen een ogenschijnlijk officiële e-mail vanuit een domein dat lijkt op dat van de organisatie. De boodschap is steeds hetzelfde: er is een urgent probleem en het slachtoffer moet een MFA-melding accepteren om weer toegang te krijgen. Omdat veel organisaties hun medewerkers hebben geleerd dat security altijd voorrang heeft, volgt men instructies van vermeende securitymedewerkers vaak zonder verificatie. Zeker bij organisaties met complexe hiërarchieën durft men zelden een "security officer" tegen te spreken, wat de druk nog verder opvoert.
Zodra de gebruiker toegeeft, start fase vier waarin de aanvaller volledige sessies overneemt. Ze registreren nieuwe MFA-methoden, creëren SMTP-forwarders in Exchange Online, exporteren SharePoint-sites en zoeken naar privilege-escalatie. Vaak activeren ze ook een eigen Azure AD- of Azure-subscription-applicatie om langetermijntoegang te behouden. Als het SOC de initiële waarschuwing mist, kan de aanvaller dagenlang ongestoord rondkijken, data exfiltreren of ransomware voorbereiden. In hybride omgevingen is de dreiging nog groter omdat aanvallers via het cloudtoken on-premises resources kunnen benaderen middels application proxy’s of synchronisatieaccounts.
Deze anatomie laat zien dat het niet volstaat om enkel meer MFA-meldingen te sturen. Je moet de volledige keten analyseren: hoe worden credentials buitgemaakt, welke patronen zien we in de timing van prompts, hoe reageren gebruikers en hoe snel kan het SOC ingrijpen. Door per fase detectieregels en maatregelen te definiëren, creëer je meerdere stopmomenten. Denk aan real-time phishingfilters, brute-force detectie, waarschuwingen bij abnormaal veel MFA-verzoeken en automatische sessierevokes zodra nummermatching faalt. Elke fase die je afsnijdt, verkleint de kans dat fase vier ooit wordt bereikt.
Voor Nederlandse overheden is het bovendien cruciaal om deze fases vast te leggen in het informatiebeveiligingsbeleid en het dreigingsbeeld dat richting bestuurders en toezichthouders gaat. Door aantoonbaar te kunnen uitleggen hoe de organisatie iedere fase monitort, voldoe je aan de bewijsverplichting uit de BIO en de Nederlandse Baseline voor Veilige Cloud. Ook leveranciers moeten in dit verhaal worden meegenomen: vraag tijdens contract- en DPIA-trajecten welke maatregelen zij hebben ingericht tegen pushbombing en leg vast hoe zij incidenten binnen 24 uur melden.
Beschermingsmaatregelen
Bescherming tegen MFA-fatigue begint bij het ontwerpen van een identiteitsarchitectuur waarin elke stap verifieerbaar is. Nummermatching en contextinformatie in Microsoft Authenticator maken een wereld van verschil omdat gebruikers een numerieke code moeten overnemen vanuit het aanmeldscherm en direct zien vanaf welk apparaat, IP-bereik en applicatie de aanvraag komt. Voer deze wijziging gefaseerd in: test in een aparte tenant, laat pilots draaien bij het SOC en de servicedesk, en communiceer met duidelijke screenshots zodat medewerkers weten welke schermen zij voortaan zien. Documenteer in het CAB-dossier welke risico’s worden gemitigeerd en hoe je fallbackaccounts hebt geregeld, zodat auditors zien dat het besluit zorgvuldig is genomen.
Conditional Access is de tweede verdedigingslijn. Bouw beleidssets op maat van de organisatie: dwing meervoudige authenticatie af voor alle cloudapplicaties, vereis compliant devices voor beheerders en blokkeer aanmeldingen vanaf landen waar je geen medewerkers hebt. Gebruik named locations voor Rijksdatacenters, provinciale netwerken en VPN-uitgangen en combineer deze met risicosignalen uit Microsoft Entra ID Protection. Wanneer een aanmelding buiten het verwachte patroon valt, kan het systeem automatisch sessies beëindigen of een aanvullende controle eisen. Leg deze policies vast in het security baselinedocument zodat ze onderdeel worden van de reguliere controlecyclus.
Parallel hieraan is het verstandig om te investeren in phishing-resistente authenticatiemiddelen. FIDO2-sleutels, Windows Hello for Business en certificaatgebaseerde authenticatie zorgen ervoor dat een aanvaller niets heeft aan gestolen wachtwoorden. Hoewel een volledige migratie tijd kost, kun je beginnen met hoog-risicodoelgroepen zoals beheerders, beleidsmakers met staatsgeheime toegang en leveranciers met elevated rechten. Beschrijf in het Identity Roadmap-document welke doelgroepen per kwartaal overstappen en welke KPI’s je hanteert, bijvoorbeeld het percentage accounts met FIDO2 ingeschakeld. Zo toon je richting bestuurders aan dat MFA-hardening een meerjarig programma is.
Microsoft Purview Data Loss Prevention en Defender for Cloud Apps spelen vervolgens een rol in het beperken van schade wanneer een insider of aanvaller toch binnenkomt. Door gevoelige documenten te labelen, downloadlimieten op te leggen en activiteiten op niet-goedgekeurde SaaS-diensten te blokkeren, voorkom je dat een aanvaller moeiteloos data exfiltreert nadat hij MFA heeft omzeild. Combineer deze policies met auditlogboeken zodat je altijd kunt herleiden welke bestanden zijn aangeraakt. Voeg de regels toe aan het register van verwerkingen, zodat de Functionaris Gegevensbescherming kan aantonen dat privacy-by-design is toegepast.
Bewustwording blijft essentieel, maar geef het programma meer inhoud dan een jaarlijkse e-learning. Simuleer MFA-fatigue in gecontroleerde campagnes: verstuur binnen een oefening meerdere pushmeldingen en kijk of medewerkers deze rapporteren via het SOC. Analyseer vervolgens de respons en pas scripts aan. Koppel trainingen aan HR-processen, bijvoorbeeld bij onboarding van nieuwe medewerkers of tijdens promoties naar vertrouwensfuncties. Leg in policies vast dat gebruikers nooit telefonische instructies mogen volgen zonder terug te bellen via een bekend nummer, zodat social engineering minder kans krijgt.
Tot slot moet elke maatregel worden ondersteund door monitoring en rapportage. Gebruik dashboards in Microsoft Entra om te laten zien hoeveel authenticator-meldingen worden geweigerd, hoeveel nummermatchingpogingen mislukken en welk percentage accounts op FIDO2 draait. Rapporteer deze cijfers per kwartaal aan de CIO en de Chief Privacy Officer. Wanneer bestuurders zien dat de organisatie proactief bijstuurt, ontstaat draagvlak voor verdere investeringen, bijvoorbeeld in hardwaretokens of aanvullende licenties. Bovendien voldoet de organisatie zo aan de verplichting uit de Nederlandse Baseline voor Veilige Cloud om controles aantoonbaar te beheren.
Detectie en Response
Detectie begint bij het inrichten van een telemetriestroom waarin MFA-signalen niet verloren gaan tussen andere events. Verzamel in Microsoft Sentinel de Entra ID-sign-inlogs, Identity Protection alerts en Microsoft Authenticator diagnostiek. Richt queries in die zoeken naar meer dan tien MFA-aanvragen binnen vijftien minuten, meldingen buiten de gebruikelijke werktijden of aanmeldingen vanuit onverwachte netwerken. Combineer deze patronen met impossible-traveldetectie en device-compliance-informatie zodat een alert direct aangeeft welke context relevant is. Door een watchlist bij te houden met kritieke functies, zoals accounts met toegang tot staatsgeheime dossiers, kun je alerts prioriteren en sneller reageren.
SOCs die veel alerts verwerken, hebben baat bij geautomatiseerde triage. Gebruik Playbooks in Sentinel of Logic Apps om bij een verdacht patroon automatisch sessies te beëindigen via de Graph API, een wachtwoordreset te forceren en een case in Microsoft Purview te openen. Koppel deze automatisering aan goedgekeurde runbooks zodat securityanalisten precies weten wanneer ingrijpen verplicht is en wanneer escalatie naar de CISO of Functionaris Gegevensbescherming noodzakelijk is. Leg ook vast hoe het SOC onderscheid maakt tussen een echte aanval en een gebruiker die tijdens een internationale dienstreis legitiem veel meldingen ontvangt.
Een volwassen responsproces omvat multidisciplinaire communicatie. Zodra een incident wordt vermoed, informeert het SOC de lijnmanager alleen over het feit dat er een onderzoek loopt, terwijl HR bekijkt of er relevante context is zoals een lopend verbetertraject of een vertrekregeling. Juridische Zaken beoordeelt of de gegevensverwerking proportioneel is en of melding aan de Autoriteit Persoonsgegevens of het NCSC noodzakelijk kan zijn. Deze samenhang voorkomt dat technische teams in isolement beslissingen nemen die later niet verdedigbaar blijken.
Parallel daaraan loopt het forensisch onderzoek. Analisten reconstrueren de tijdlijn: wanneer werden de eerste credentials buitgemaakt, welke IP-adressen waren betrokken, welke applicaties zijn aangeroepen en is er sprake geweest van privilege-escalatie? Microsoft 365 Audit logs, Defender for Cloud Apps en Purview-activiteitslogboeken leveren het bewijs. Zorg dat deze logbestanden minimaal 180 dagen beschikbaar zijn en exporteer kritieke cases naar een immutable opslag, zodat bewijslast intact blijft voor audits of juridische procedures.
Een goed incidentresponseplan bevat ook duidelijke herstelacties. Denk aan het opnieuw registreren van MFA-methoden, het intrekken van OAuth-consent voor verdachte applicaties, het controleren van regels in Exchange Online en het reviewen van SharePoint-sitepermissies. Zorg dat elke actie traceerbaar is in het ticketingsysteem en koppel lessons learned aan het verbeteringsteam. Misschien blijkt dat een bepaald team geen nummermatching gebruikte of dat een leverancier onvoldoende logging aanleverde. Deze bevindingen moeten terug naar het risicoregister en leiden tot concrete verbeterprojecten.
Tot slot hoort testen bij het detectie- en response-onderdeel. Plan minimaal twee keer per jaar een oefening waarin je een pushbombingaanval simuleert, inclusief escalaties, communicatie naar bestuurders en rapportage naar toezichthouders. Documenteer hoe lang het duurde voordat de eerste alert werd opgepakt, welke automatiseringen correct werkten en waar handmatige stappen nodig waren. Door deze oefeningen te koppelen aan het bredere continuïteitsprogramma voldoe je aan de eisen uit de Nederlandse Baseline voor Veilige Cloud en bewijs je dat MFA-fatigue geen theoretische dreiging is maar een scenario waarvoor je aantoonbaar klaarstaat. Leg na elke oefening vast welke controles binnen de overeengekomen RTO’s functioneerden en welke investeringen noodzakelijk zijn, zodat besluitvormers concrete verbeterpaden kunnen aftekenen.
MFA-fatigueaanvallen illustreren dat identiteitsbeveiliging een continu spel blijft tussen techniek, menselijk gedrag en governance. Organisaties die alleen vertrouwen op traditionele pushmeldingen, accepteren impliciet dat vermoeide of afgeleide medewerkers het laatste verdedigingspunt vormen. Door nummermatching, Conditional Access, phishing-resistente authenticatie, Purview- en Sentinel-detectie, multidisciplinaire runbooks en realistische oefeningen te combineren, verandert MFA in een volledig gecontroleerd proces. Je voldoet niet alleen aan de Nederlandse Baseline voor Veilige Cloud en de BIO, maar creëert ook vertrouwen bij bestuurders en burgers dat toegang tot overheidsdiensten robuust is ingericht. Maak daarom van MFA-hardening een vast onderdeel van je jaarplan, rapporteer de voortgang en gebruik incidentgegevens om beleid, techniek en awareness voortdurend te verbeteren.