MFA geregistreerd, maar niet afgedwongen

Honderd procent MFA-registratie zegt niets over de vraag of MFA ook wordt afgedwongen. Registratie hangt aan een account. Enforcement gebeurt op het moment van de sign-in. In Entra ID lopen die twee uit elkaar zodra Conditional Access bij een deel van de sign-ins niet om de tweede factor vraagt, terwijl elke gebruiker wel een method heeft geregistreerd. Dat verschil staat in de sign-in logs, niet in het registratierapport dat sommige dashboards tonen.

Dit heeft betrekking op iedere organisatie die MFA-dekking rapporteert aan directie, auditor of verzekeraar. Begin met meten: hoeveel geslaagde sign-ins van de afgelopen dertig dagen voldeden aan een MFA-eis, uitgesplitst naar applicatie en accounttype.

Waar zit het gat tussen registratie en enforcement

Registratie en enforcement zijn twee losse mechanismen. Bij registratie legt een gebruiker een method vast met bijvoorbeeld een Authenticator of een FIDO2-key. Bij enforcement bepaalt vervolgens een policy of daar bij een sign-in ook om gevraagd wordt. Daar komt authenticatiesterkte nog bij, die bepaalt welke methods aan die eis mogen voldoen. Een pushmelding en een phishing-resistente passkey zijn allebei MFA, maar bieden niet hetzelfde niveau. Tussen registratie aan de ene kant en enforcement aan de andere kant ontstaat de ruimte waar het misgaat.

Policies blijven vaak in report-only staan omdat weinig beheerders deze scherper willen zetten vanwege gebruiksgemak of vanwege exclusions die gelden voor trusted locations of voor die ene applicatie die het anders niet deed. Accounts zijn tijdens een migratie als uitzondering toegevoegd en staan er sindsdien nog. Legacy authentication kan per definitie geen tweede factor opvragen en omzeilt daarmee alles wat je verder hebt ingericht.

Security Defaults is bedoeld als basisbeveiliging voor tenants zonder eigen Conditional Access-beleid. Het verplicht gebruikers een method te registreren, vraagt MFA aan beheerders, kan MFA voor gebruikers vereisen wanneer Microsoft dat nodig acht en blokkeert verouderde authenticatieprotocollen. Voor nieuwe tenants wordt sinds 1 juli 2026 ook device code flow geblokkeerd. Dat verkleint het risico op veelvoorkomende aanvallen, maar geeft geen sturing per applicatie, gebruikersgroep, locatie, apparaatstatus of method. Wie vooraf wil bepalen waar MFA geldt, uitzonderingen aantoonbaar wil beheren of voor kritieke rollen phishing-resistente authenticatie wil afdwingen, heeft doorgaans Conditional Access nodig. De twee functioneren daarbij niet als twee beleidslagen die gelijktijdig naast elkaar draaien.

Het gaat hier dus niet om een tekortkoming van MFA, en ook niet om een configuratiefout die je met een druk op de knop oplost. Het cijfer waar de meeste CISO's naar kijken meet iets wat eigenlijk niet alles zegt, en daardoor blijft een gat in de dekking onzichtbaar. Ook in omgevingen waar technisch alles aanwezig is om het goed te regelen.

Wat de sign-in logs wel en niet laten zien

De sign-in logs bevatten de informatie waarmee een aanmelding is te reconstrueren: gebruiker, applicatie, resource, client, IP-adres en apparaatstatus, de volgorde van de gebruikte methods, en welke policies zijn geëvalueerd, toegepast, niet toegepast of alleen in report-only actief waren. Dat is de plek waar je de enforcement rate vandaan haalt.

Het veld Authentication requirement is daarbij op zichzelf niet voldoende. Een resource kan een eerder afgegeven MFA-claim accepteren, waardoor de gebruiker geen nieuwe prompt krijgt terwijl de sessie wel op eerdere sterke authenticatie steunt. Omgekeerd kan een aanmelding als single factor worden weergegeven terwijl in de bredere context wel een geldige claim aanwezig was. De oorspronkelijke method, de sessiestatus en de tokenketen moeten daarom samen worden beoordeeld. Kort na een gebeurtenis kunnen de Authentication details bovendien nog onvolledig zijn omdat Microsoft de loggegevens verder verwerkt. Gebruik bij twijfel de uiteindelijke logregistratie en koppel gerelateerde gebeurtenissen via Request ID en Correlation ID.

Hoe ontstaat dit in de praktijk

Wie Entra ID gebruikt, heeft een kans dat dit verschil ook in de eigen omgeving zit. Het is geen fout die met een bepaalde versie of configuratie meekomt, maar een gevolg van hoe organisaties in de loop van de tijd met Conditional Access werken. Controleren is daarom de moeite waard, ook zonder directe aanleiding.

Tijdens forensisch onderzoek onderzocht DeepBlue Security & Intelligence een Microsoft 365-account waarvoor Authenticator was geregistreerd. De tenant gebruikte Security Defaults. Toch bleek toegang met alleen geldige primaire inloggegevens mogelijk. Dat betekent niet automatisch dat Authenticator of Security Defaults technisch is omzeild. Hetzelfde beeld kan ontstaan door een bestaande sessie, een eerder afgegeven claim, de gebruikte applicatie of het protocol waarmee toegang is verkregen. De vraag is dus niet of MFA aan staat, maar welke eis voor die specifieke toegang gold en hoe daaraan is voldaan.

De oorzaak is zelden één grote fout. Meestal gaat het om exclusions die ooit tijdelijk waren bedoeld. Een applicatie die tijdens een migratie niet meewerkte met moderne authenticatie. Een leverancier die vanaf een vast IP-adres moest kunnen werken. Een groep gebruikers die tijdens een uitrol werd overgeslagen om de planning te halen. Stuk voor stuk verdedigbare beslissingen op het moment zelf. Wat vaak ontbreekt is een einddatum en een eigenaar, waardoor niemand er nog naar omkijkt zolang alles blijft werken.

Het probleem komt meestal aan het licht wanneer er iets verandert waar de policy niet op is aangepast: een migratie, een fusie, een nieuwe SaaS-applicatie, of een beheerder die vertrekt. Is zoiets recent gebeurd en is er daarna niet opnieuw gemeten, dan geeft het dashboard waarschijnlijk een ander beeld dan de sign-in logs.

Wat je nu kunt doen

Meet de enforcement rate in de sign-in logs over de laatste dertig dagen, uitgesplitst naar applicatie, accounttype en locatie, en leg die naast het registratiecijfer dat nu bekend is. Het verschil tussen die twee is je eigenlijke bevinding.
Trek elke exclusion in Conditional Access na, inclusief de policies die nog op report-only staan, en leg per exclusion vast wie hem heeft aangevraagd, waarom, en tot wanneer hij geldig is. Wat je niet kunt verantwoorden, gaat eruit.
Blokkeer legacy authentication en meet daarna opnieuw. Inventariseer eerst wat er nog op draait, want hier veroorzaak je een productieprobleem als je te snel schakelt.
Breng service accounts, break-glass accounts en gastaccounts onder expliciet beleid, met per account een vastgelegde compenserende maatregel en monitoring op gebruik. Deze groep valt vaak buiten de scope en heeft doorgaans de zwaarste rechten.
Zet phishing-resistant methods in voor admin accounts. Afgedwongen MFA op basis van push lost de dekking op, maar niet token theft of een AiTM-aanval waarbij de aanvaller tussen gebruiker en dienst zit.

Conclusie

Het aantal geregistreerde gebruikers zegt in deze niets over de MFA dekkingsgraad. De enforcement rate per sign-in beantwoordt wel de vraag die eigenlijk gesteld zou moeten worden. Blijft staan: ook een hoge enforcement rate sluit token theft en session hijacking niet uit, en zegt niets over de weerbaarheid van de gebruikte methods. Begin dus met een duidelijk overzicht, en pak de methods daarna aan.

Bronnen

Verder lezen: pentest, CISO as a Service en gelekte inloggegevens.

Laatst inhoudelijk gecontroleerd: 29 juli 2026.