MFA in Microsoft 365: van basisbeveiliging naar phishingbestendig aanmelden

Een wachtwoord alleen is niet genoeg om Microsoft 365 te beveiligen. Een aanvaller kan een wachtwoord buitmaken via phishing, hergebruik, malware of een datalek bij een andere dienst. Multifactor-authenticatie, meestal MFA genoemd, voegt daarom een tweede controle toe. De gebruiker bewijst niet alleen wat hij weet, maar ook wat hij heeft of wie hij is.

MFA is echter geen vinkje dat ieder aanmeldrisico oplost. Een sms-code kan worden onderschept en een gebruiker kan een onverwachte goedkeuringsmelding alsnog accepteren. Bovendien kan een slecht ingevoerd beleid medewerkers, leveranciers en zelfs beheerders buitensluiten. De beste aanpak combineert brede MFA-dekking met goede herstelprocedures, beperkte uitzonderingen en een plan om gevoelige accounts phishingbestendig te laten aanmelden.

Deze gids helpt MKB-directeuren, office managers en IT-verantwoordelijken om dat als beheersbaar proces in te richten. Wil je weten welke accounts nog onvoldoende beschermd zijn en waar toegangsbeleid gaten bevat? Laat je Microsoft 365-omgeving beoordelen met de IT-scan.

Wat MFA precies controleert

Een aanmelding kan gebruikmaken van drie soorten bewijs:

• iets wat je weet, zoals een wachtwoord of pincode;
• iets wat je hebt, zoals een geregistreerde telefoon of beveiligingssleutel;
• iets wat je bent, zoals een biometrische controle op een vertrouwd apparaat.

Bij gewone MFA combineert Microsoft Entra minimaal twee factoren. Een wachtwoord plus een goedkeuring in Microsoft Authenticator kan bijvoorbeeld voldoen. Een wachtwoord plus een sms-code kan ook voldoen, maar biedt minder weerstand tegen phishing en onderschepping. Niet iedere methode die gebruiksvriendelijk lijkt, biedt dus hetzelfde beschermingsniveau.

Microsoft Entra kent naast de algemene MFA-eis ook authentication strengths. Daarmee bepaal je welke methoden voor een bepaald risico of systeem zijn toegestaan. Microsoft levert drie ingebouwde niveaus:

Authentication strength	Praktische betekenis	Passend gebruik
Multifactor authentication	Meerdere gangbare MFA-combinaties toegestaan	Brede basis voor medewerkers
Passwordless MFA	Aanmelden zonder wachtwoord met toegestane sterke methode	Gebruiksgemak en minder wachtwoordrisico
Phishing-resistant MFA	Alleen methoden met sterke koppeling aan de echte aanmeldomgeving	Beheerders en gevoelige toepassingen

Tot de ingebouwde phishingbestendige methoden behoren volgens Microsoft onder meer FIDO2-beveiligingssleutels en passkeys, Windows Hello for Business en multifactor-certificaatverificatie. Microsoft Authenticator met een pushmelding is nuttige MFA, maar valt niet onder de ingebouwde phishingbestendige sterkte.

Kies eerst je beheermodel

Kleine organisaties komen vaak uit bij een van deze twee routes:

1. Security Defaults biedt een door Microsoft beheerde basis zonder eigen Conditional Access-ontwerp.
2. Conditional Access geeft meer controle over doelgroepen, toepassingen, apparaten, locaties, risico en vereiste verificatiesterkte.

Gebruik deze routes niet als losse lagen boven op elkaar. Microsoft legt uit dat Security Defaults en Conditional Access niet bedoeld zijn om gecombineerd te worden. Zodra je eigen Conditional Access-beleid nodig hebt, moet je de overgang als wijziging plannen: inventariseer de bestaande bescherming, maak noodtoegang gereed, test het vervangende beleid en controleer daarna pas of de oude route uit kan.

Conditional Access vereist Microsoft Entra ID P1 of een licentie waarin dit recht is opgenomen, zoals Microsoft 365 Business Premium. Risicogestuurde voorwaarden op basis van user risk of sign-in risk vragen aanvullende Entra ID P2-functionaliteit. Controleer altijd de actuele licentievoorwaarden voor je definitieve ontwerp.

Maak eerst alle identiteiten zichtbaar

Een beleid voor alle gebruikers werkt alleen wanneer je weet wie en wat zich aanmeldt. Maak daarom vóór de uitrol een inventaris met:

• gewone medewerkers;
• beheerders en tijdelijke beheerders;
• gastgebruikers en leveranciers;
• gedeelde en functionele accounts;
• synchronisatieaccounts;
• serviceaccounts die interactief aanmelden;
• service principals, managed identities en andere workload-identiteiten;
• twee zorgvuldig ingerichte noodtoegangsaccounts.

Menselijke gebruikers, serviceaccounts en workload-identiteiten vragen niet automatisch hetzelfde beleid. Een Conditional Access-regel die op gebruikers is gericht, blokkeert volgens Microsoft niet ineens alle aanroepen van service principals. Voor workload-identiteiten bestaan eigen controls. Vervang waar mogelijk scripts met gebruikersnaam en wachtwoord door managed identities of een andere moderne toepassingsidentiteit.

Gebruik uitzonderingen niet als afvalbak. Iedere uitzondering krijgt een eigenaar, reden, risico, compenserende maatregel en einddatum. Controleer maandelijks of het account nog bestaat en of de uitzondering nog nodig is. Een uitgesloten account met een onveranderlijk wachtwoord kan het hele MFA-programma ondermijnen.

Bouw een minimale beleidsset

Microsoft adviseert als basis een Conditional Access-beleid dat alle gebruikers en alle resources omvat, zonder willekeurige app-uitsluitingen, en MFA vereist. In een beheersbare MKB-inrichting hoort daar meer omheen:

Beleid	Doel	Belangrijke controle
MFA voor alle gebruikers en resources	Brede basisdekking	Alleen gemotiveerde uitzonderingen
Sterkere verificatie voor beheerrollen	Bescherm accounts met veel invloed	Phishingbestendige authentication strength
Blokkeren van legacy authentication	Voorkom protocollen die moderne verificatie omzeilen	Controleer vooraf oude clients en scanners
Bescherming van registratiegegevens	Voorkom dat een aanvaller eigen MFA toevoegt	Sterke verificatie en vertrouwde context
Apparaateis voor gevoelige apps	Beperk toegang tot beheerde of conforme apparaten	Test BYOD- en gastscenario's apart

Houd ieder beleid klein en benoem het op doel, doelgroep en status. Een naam als CA-BASIS-Alle-gebruikers-MFA is later beter te beoordelen dan Nieuw beleid 4. Leg per beleid vast wie eigenaar is, welk risico het afdekt, welke uitzonderingen bestaan en wanneer het voor het laatst is getest.

Maak niet één reusachtig beleid met iedere voorwaarde en iedere toepassing. Kleine beleidsregels zijn eenvoudiger te testen, terug te draaien en uit te leggen. Let wel op de gecombineerde uitkomst: tijdens een aanmelding kunnen meerdere beleidsregels tegelijk van toepassing zijn, waarbij de strengste vereisten samen het resultaat bepalen.

Test zonder medewerkers te blokkeren

Zet een nieuw Conditional Access-beleid eerst in report-only. Microsoft Entra evalueert dan wat het beleid bij echte aanmeldingen zou doen, maar dwingt de grant- en sessiecontrols nog niet af. De uitkomst verschijnt in de aanmeldlogboeken en in de rapportage voor Conditional Access.

Beoordeel niet alleen het totaalaantal successen. Onderzoek per belangrijke gebruikersgroep:

• op welke gebruikers en apps het beleid van toepassing zou zijn;
• welke aanmeldingen zouden mislukken;
• waar een gebruikersactie nodig zou zijn;
• welke accounts onverwacht zijn uitgesloten;
• of oudere clients of apparaten problemen veroorzaken;
• hoe gastgebruikers en leveranciers worden behandeld;
• of andere actieve beleidsregels de uitkomst veranderen.

Microsoft waarschuwt dat een report-only beleid met een compliant-device-eis op macOS, iOS en Android toch certificaatkeuzemeldingen kan veroorzaken, ook al wordt compliance nog niet afgedwongen. Test apparaatbeleid daarom met echte apparaten en niet uitsluitend met een rapport.

Gebruik vervolgens een pilotgroep met verschillende rollen, apparaten en werklocaties. Laat de groep normale taken uitvoeren, waaronder Teams, Outlook, SharePoint, mobiele apps en gevoelige beheerhandelingen. Leg storingen vast met gebruiker, tijdstip, toepassing, clienttype en correlation ID. Die gegevens maken de aanmeldlogboeken bruikbaar voor diagnose.

Regel noodtoegang vóór handhaving

Microsoft adviseert noodtoegangsaccounts, vaak break-glass accounts genoemd, uit te sluiten van beleid dat de hele organisatie kan buitensluiten. Dat betekent niet dat deze accounts onbeveiligd of dagelijks bruikbaar mogen zijn.

Een werkend noodpad heeft minimaal:

• twee cloud-only accounts die niet afhankelijk zijn van dezelfde lokale infrastructuur;
• permanent toegewezen noodzakelijke beheerrechten, beperkt tot dit nooddoel;
• sterke, onafhankelijk bewaarde authenticatiemiddelen;
• directe alarmering bij iedere aanmelding en iedere wijziging;
• geen mailbox, dagelijks gebruik of koppeling aan een persoon als werkaccount;
• een periodieke, gecontroleerde test;
• een incidentprocedure voor ieder werkelijk gebruik.

Controleer tijdens een test niet alleen of aanmelden lukt. Controleer ook of de melding aankomt, wie reageert, of de activiteit in het auditlogboek staat en hoe normale toegang wordt hersteld. Lees voor tijdelijke dagelijkse beheerrechten ook hoe Privileged Identity Management permanente beheertoegang beperkt.

Migreer van zwakke naar sterke methoden

Brede MFA-dekking is de eerste mijlpaal. Daarna verlaag je stapsgewijs de afhankelijkheid van sms, telefonische oproepen en goedkeuringsmeldingen die een gebruiker zonder context kan accepteren.

Een praktische volgorde is:

1. Zorg dat iedere medewerker minimaal twee bruikbare verificatiemethoden heeft.
2. Activeer number matching en relevante context in Microsoft Authenticator waar dat van toepassing is.
3. Geef beheerders een phishingbestendige methode en test die op hun beheerwerkplek.
4. Laat een pilotgroep passkeys, FIDO2-sleutels of Windows Hello for Business gebruiken.
5. Vereis phishingbestendige authentication strength eerst voor beheerrollen en gevoelige apps.
6. Breid de doelgroep uit op basis van risico, ondersteuning en apparaatgereedheid.
7. Schakel zwakkere methoden pas uit nadat registratie, herstel en uitzonderingen aantoonbaar werken.

Let op het verschil tussen een authenticatiemethode toestaan en die methode vereisen. De Authentication methods policy bepaalt welke methoden een doelgroep mag registreren en gebruiken. Conditional Access met authentication strength bepaalt welke van die methoden voor een specifieke resource of situatie voldoende sterk zijn. Beide configuraties moeten dus op elkaar aansluiten.

Een authentication strength wordt pas na de eerste authenticatie beoordeeld. Een gebruiker kan nog steeds een wachtwoord invoeren, maar krijgt geen toegang tot de beschermde resource voordat een toegestane sterke methode is gebruikt. Test ook sessiegedrag. Een eerder opgebouwde claim kan onder bepaalde omstandigheden nog voldoen, waardoor gebruikers niet bij ieder bezoek een nieuwe prompt zien.

Ontwerp registratie en herstel als bedrijfsproces

MFA faalt operationeel wanneer niemand weet wat te doen bij een verloren telefoon, nieuw toestel of vertrekkende medewerker. Leg daarom een herstelproces vast dat identiteitscontrole zwaarder laat wegen dan snelheid.

Een veilige servicedeskprocedure bevat:

• controle van de identiteit via een vooraf afgesproken onafhankelijk kanaal;
• registratie van aanvrager, behandelaar, reden en tijdstip;
• intrekken van verloren of verdachte methoden;
• tijdelijke toegang alleen met beperkte geldigheid;
• controle of de gebruiker zelf een nieuwe methode registreert;
• beoordeling van recente aanmeldingen bij vermoeden van misbruik;
• afronding in een ticket met duidelijke uitkomst.

Gebruik geen openbare persoonsgegevens als enige identiteitsbewijs. Een aanvaller kent mogelijk naam, functie, telefoonnummer en leidinggevende al. Laat een manager bovendien niet zonder verdere controle iedere reset autoriseren. Combineer meerdere signalen en escaleer twijfel.

Microsoft Entra Temporary Access Pass kan helpen om een gebruiker gecontroleerd een nieuwe sterke methode te laten registreren. Beperk de geldigheid en het aantal keer dat de pas bruikbaar is. Deel zo'n code via een passend kanaal en behandel hem als een tijdelijk geheim.

Voor het volledige herstelscenario helpt de gids MFA-app kwijt: herstelprocedure voor medewerkers en beheerders.

Meet dekking en beheerlast

Rapporteer niet alleen dat MFA 'aan' staat. Meet iedere maand:

• percentage actieve medewerkers met geschikte methoden;
• percentage beheerders met phishingbestendige verificatie;
• accounts die door beleid zijn uitgesloten;
• uitzonderingen zonder eigenaar of einddatum;
• mislukte aanmeldingen door Conditional Access;
• herstelverzoeken en gemiddelde oplostijd;
• zwakke methoden die nog worden gebruikt;
• noodtoegangstests en opvolging van bevindingen;
• oude protocollen of clients die moderne verificatie blokkeren.

Koppel iedere afwijking aan een eigenaar en datum. Een dashboard zonder opvolging ontlast de IT-manager niet. Een korte maandelijkse lijst met vijf concrete acties doet dat vaak wel.

Controleer daarnaast wijzigingen via het Microsoft 365-auditlogboek voor incidentonderzoek en bewijs. Aanmeldlogboeken vertellen wat tijdens toegang gebeurde. Auditgegevens helpen reconstrueren wie beleid, methoden of accounts wijzigde. Samen geven ze meer context dan één van beide bronnen afzonderlijk.

Veelgemaakte fouten

MFA alleen voor beheerders activeren. Beheerders zijn belangrijk, maar een gewone mailbox kan toegang geven tot facturen, klantdata en overtuigende interne phishing.

Iedere uitzondering permanent laten bestaan. Tijdelijke technische problemen veranderen zo in blijvende gaten. Geef iedere uitzondering een einddatum.

Een pushmelding als phishingbestendig beschouwen. Authenticator-push is nuttige MFA, maar de ingebouwde phishingbestendige authentication strength accepteert andere, sterker gebonden methoden.

Direct van report-only naar de hele organisatie gaan. Een pilot met echte gebruikers, mobiele apps, gasten en afwijkende apparaten ontdekt problemen die een configuratiecheck mist.

Noodaccounts nooit testen. Een onbekend wachtwoord, verlopen sleutel of ontbrekende alarmering komt dan pas tijdens een storing aan het licht.

Herstel via een snel telefoontje toestaan. De resetprocedure is zelf een aanvalsroute en verdient sterke identiteitscontrole.

Licenties als configuratiebewijs gebruiken. Een Business Premium-licentie maakt Conditional Access beschikbaar, maar bewijst niet dat beleid volledig, actief of getest is.

Veelgestelde vragen

Is Microsoft Authenticator voldoende voor MFA?

Ja, Authenticator kan gewone MFA leveren en is doorgaans sterker dan alleen een wachtwoord. Een pushmelding is volgens de ingebouwde Microsoft-definitie alleen niet phishingbestendig. Gebruik voor beheer en gevoelige resources een passende authentication strength met ondersteunde sterke methoden.

Moet iedere medewerker een zakelijke telefoon hebben?

Niet per se. De passende methode hangt af van werkplek, privacyafspraken, licenties en beheermodel. Windows Hello for Business, passkeys en FIDO2-sleutels kunnen alternatieven zijn. Bied een ondersteunde route die geen ongewenste afhankelijkheid van een privételefoon creëert.

Kunnen we sms direct uitschakelen?

Alleen wanneer alle betrokken gebruikers een werkende vervangende methode hebben en het herstelproces is getest. Begin met inventarisatie, pilot en begeleiding. Schakel de zwakkere methode daarna doelgroep voor doelgroep uit.

Wat gebeurt er met gasten?

Externe gebruikers kunnen MFA in hun eigen tenant uitvoeren of in de resource-tenant een methode gebruiken, afhankelijk van cross-tenant instellingen en vertrouwen. Test belangrijke leveranciers en klanten apart. Neem niet aan dat intern beleid voor gasten identiek uitpakt.

Is report-only volledig zonder gebruikersimpact?

Niet altijd. Microsoft noemt specifiek mogelijke certificaatkeuzemeldingen op macOS, iOS en Android bij report-only apparaatcompliancebeleid. Gebruik daarom echte pilots en lees de aanmeldresultaten zorgvuldig.

Hoe vaak moeten we MFA en Conditional Access controleren?

Beoordeel uitzonderingen en opvallende aanmeldingen minstens maandelijks. Test noodtoegang en belangrijke beleidspaden periodiek, bijvoorbeeld ieder kwartaal, en altijd na grote wijzigingen in licenties, apparaten, identiteiten of applicaties.

Gebruikte Microsoft-bronnen

De productwerking en aanbevelingen zijn op 28 oktober 2026 gecontroleerd tegen deze officiële Microsoft Learn-pagina's. De links bevatten geen trackingparameters:

• What is Conditional Access?
• Require multifactor authentication for all users
• Conditional Access authentication strengths
• Analyze Conditional Access policy impact
• Plan a Conditional Access deployment

Microsoft past documentatie, portalen en licentievoorwaarden regelmatig aan. Controleer daarom de actuele tenantconfiguratie en productvoorwaarden voordat je een beleid afdwingt.

Van MFA-vinkje naar aantoonbaar toegangsbeheer

Een goede MFA-inrichting beschermt alle menselijke accounts, maakt uitzonderingen zichtbaar en heeft een herstelroute die geen nieuwe zwakke plek vormt. Conditional Access voegt gerichte controle toe, maar vraagt noodtoegang, report-only analyse en een echte pilot. Bouw daarna door naar phishingbestendige methoden voor beheerders en gevoelige systemen.

Zo wordt MFA geen verzameling onverwachte meldingen, maar een controleerbaar beheerproces. Medewerkers kunnen doorwerken, de servicedesk weet hoe herstel verloopt en de organisatie kan aantonen welke identiteiten, resources en risico's daadwerkelijk beschermd zijn.