Laatst gecontroleerd: 12 juli 2026
Kort antwoord
Een klant vraagt meestal niet alleen óf MFA ergens is ingeschakeld. De klant wil weten voor welke accounts en systemen MFA geldt, hoe de verplichting technisch wordt afgedwongen, welke uitzonderingen bestaan en wanneer dit voor het laatst is gecontroleerd.
Sterk MFA-bewijs bestaat daarom meestal uit een combinatie van:
- een duidelijke scope;
- een policy- of configuratiesamenvatting;
- geanonimiseerd visueel of geëxporteerd bewijs;
- een controle- of rapportagedatum;
- uitleg over uitzonderingen;
- bewijs van periodieke controle;
- een open punt en roadmap wanneer de uitrol nog niet compleet is.
Een screenshot kan onderdeel zijn van de onderbouwing, maar is op zichzelf niet automatisch voldoende. Een afbeelding zonder scope, datum en uitleg kan bijvoorbeeld wel tonen dat één instelling bestaat, maar niet dat MFA voor alle bedoelde gebruikers, applicaties en toegangswegen wordt afgedwongen.
Krijg je deze vraag in een concrete klantuitvraag? Bekijk dan ook welke bewijsstukken je bij een securityvragenlijst kunt meesturen of laat de securityvragenlijst inhoudelijk beoordelen.
Wat bedoelt de klant precies met “MFA ingericht”?
Dezelfde korte vraag kan verschillende verwachtingen bevatten.
| Vraag van de klant | Mogelijke betekenis | Wat je eerst moet vaststellen |
|---|---|---|
| Is MFA beschikbaar? | De techniek kan worden gebruikt | Beschikbaarheid is niet hetzelfde als verplicht gebruik |
| Is MFA verplicht? | Een policy dwingt MFA af | Voor welke gebruikers, apps en situaties? |
| Geldt MFA voor alle gebruikers? | Brede personeels- of accountscope | Tellen gasten, serviceaccounts en uitzonderingsgroepen mee? |
| Geldt MFA voor beheerders? | Bescherming van privileged accounts | Welke beheerrollen en noodaccounts vallen in scope? |
| Geldt MFA voor externe toegang? | VPN, cloud, portalen of remote beheer | Welke toegangsroute bedoelt de klant? |
| Wordt MFA periodiek gecontroleerd? | Niet alleen inrichting, maar beheer | Welke rapportage, review of steekproef bestaat? |
| Zijn uitzonderingen toegestaan? | Er kan een bypass of technische uitzondering zijn | Wie keurt uitzonderingen goed en hoe lang gelden ze? |
Vraag bij een te brede formulering om verduidelijking. Een antwoord op “Do you enforce MFA for all users?” kan anders worden geïnterpreteerd als MFA voor ieder account, iedere applicatie, iedere externe toegang en iedere uitzonderingssituatie.
Bepaal eerst de scope
Schrijf vóór het verzamelen van bewijs één zin op die de scope afbakent. Bijvoorbeeld:
Dit bewijs geldt voor medewerkers en beheerders die toegang hebben tot Microsoft 365 en de klantgerelateerde cloudapplicaties. Technische serviceaccounts en twee gecontroleerde noodaccounts vallen buiten de normale interactieve MFA-policy en worden afzonderlijk beheerd.
Controleer minimaal deze onderdelen:
- medewerkers;
- beheerders en andere privileged accounts;
- externe of gastgebruikers;
- serviceaccounts en technische koppelingen;
- cloudapplicaties;
- VPN of andere remote access;
- kritieke systemen;
- accounts met toegang tot klantgegevens;
- nood- of break-glassaccounts;
- legacy protocollen of oude applicaties die geen moderne authenticatie ondersteunen.
“MFA is ingeschakeld” zonder deze scope is meestal te vaag. Het kan feitelijk waar zijn voor één platform, maar onjuist worden gelezen als organisatiebrede afdwinging.
Welke soorten MFA-bewijs kunnen bruikbaar zijn?
Gebruik alleen bewijs dat past bij de echte inrichting. Combineer liever twee beperkte, goed uitgelegde bewijzen dan één grote ongeredigeerde export.
| Bewijstype | Wat het kan aantonen | Wat het niet automatisch aantoont | Benodigde context |
|---|---|---|---|
| Geanonimiseerde policyweergave | Dat een MFA-policy bestaat en aan staat | Dat alle relevante gebruikers en apps eronder vallen | Policynaam, status, scope en controledatum |
| Conditional Access-overzicht | Welke groepen, applicaties en voorwaarden aan MFA zijn gekoppeld | Dat iedere aanmelding daadwerkelijk met een nieuwe prompt eindigt | Inclusies, uitsluitingen, grant controls en uitzonderingen |
| Registratie- of adoptierapport | Welke accounts een methode hebben geregistreerd | Dat MFA ook technisch wordt afgedwongen | Populatie, uitgesloten accounts en meetdatum |
| Sign-inrapportage | Dat MFA bij aanmeldingen is toegepast of voldaan | Dat de policy voor alle denkbare scenario’s compleet is | Periode, logdekking en interpretatie van claims |
| Beleidsfragment | Welke organisatorische afspraak geldt | Dat de technische configuratie overeenkomt met beleid | Versie, eigenaar en ingangsdatum |
| Controleverslag of steekproef | Dat iemand de werking en scope heeft beoordeeld | Dat alle toekomstige wijzigingen automatisch correct blijven | Datum, beoordelaar, bevindingen en opvolging |
| Change- of implementatierecord | Dat een wijziging gepland en uitgevoerd is | Dat de huidige productieconfiguratie nog gelijk is | Implementatiedatum en nacontrole |
| Uitzonderingsregister | Welke accounts bewust afwijken | Dat de uitzondering veilig is | Reden, eigenaar, einddatum en compenserende maatregel |
Microsoft Entra-sign-inlogs kunnen inzicht geven in MFA-gebruik, toegepaste Conditional Access-policies en gebruikte authenticatiemethoden. Microsoft waarschuwt daarbij dat je niet op één logveld moet vertrouwen, omdat een eerder verkregen MFA-claim kan worden hergebruikt. Beschrijf dus wat je rapport daadwerkelijk meet en trek geen bredere conclusie dan de gegevens toelaten.
Conditional Access aantonen zonder een volledige tenantexport
Bij Microsoft Entra kan een klant vragen om bewijs van Conditional Access. Een veilige onderbouwing hoeft geen volledige export van alle policies te zijn.
Een compacte klantversie kan bijvoorbeeld bevatten:
- de naam of zakelijke omschrijving van de relevante policy;
- de status: ingeschakeld of alleen rapportagemodus;
- de doelgroepen of rollen;
- de applicaties of toegangssituaties;
- de vereiste grant control, zoals MFA;
- relevante uitsluitingen;
- de datum van controle;
- een korte toelichting op noodaccounts of technische uitzonderingen.
Het Conditional Access-rapport kan laten zien welke impact een policy over een gekozen periode had. Dat is nuttig als aanvullende onderbouwing, maar alleen wanneer duidelijk is welke periode, gebruikers en applicaties zijn geselecteerd.
Wat moet je niet delen?
Deel nooit meer dan nodig is om de klantvraag te beantwoorden. Scherm minimaal af:
- MFA-herstelcodes;
- QR-codes voor registratie;
- secrets, tokens en API-sleutels;
- volledige gebruikerslijsten;
- privénummers en privé-e-mailadressen;
- volledige zakelijke e-mailadressen als namen niet nodig zijn;
- sessie- en tokeninformatie;
- tenant-ID’s en interne identifiers zonder noodzaak;
- beheercredentials;
- details van noodaccounts;
- onnodige IP-adressen en locatiegegevens;
- screenshots met openstaande securitymeldingen die niets met de vraag te maken hebben;
- bestandsnamen of documentmetadata met klantnamen, gebruikersnamen of interne projectinformatie.
Anonimiseren betekent niet alleen zwarte vlakken over een screenshot zetten. Controleer ook uitsneden, hoverteksten, downloadnamen, verborgen tabbladen en documenteigenschappen.
Checklist voor een veilig screenshot
Loop deze punten na voordat je een screenshot deelt:
- Is dit de juiste productieomgeving en de juiste policy?
- Is de relevante scope zichtbaar of apart toegelicht?
- Staat de controledatum in de begeleidende tekst?
- Zijn gebruikersnamen, e-mailadressen en identifiers afgeschermd?
- Zijn herstelcodes, QR-codes, tokens en secrets volledig buiten beeld?
- Zijn uitzonderingsgroepen uitgelegd zonder gevoelige accountdetails?
- Is duidelijk wat de afbeelding wel en niet bewijst?
- Is een versie-, review- of exportdatum toegevoegd?
- Bevat de bestandsnaam geen gevoelige informatie?
- Zijn documentmetadata en verborgen lagen gecontroleerd?
- Kan een reviewer het bewijs begrijpen zonder toegang tot het beheerportaal?
Voeg bij ieder screenshot een korte begeleidende notitie toe. Bijvoorbeeld:
Geanonimiseerde weergave van de actieve MFA-policy voor medewerkers en beheerders binnen Microsoft 365, gecontroleerd op 10 juli 2026. Twee beheerde noodaccounts zijn buiten de normale policy geplaatst en vallen onder een afzonderlijke procedure.
Gebruik dit alleen wanneer de beschrijving feitelijk klopt.
Wat als MFA maar gedeeltelijk is uitgerold?
Een gedeeltelijke uitrol is geen reden om “ja, MFA is overal actief” te antwoorden. Benoem de status zo dat een klant het verschil tussen huidige werking en geplande uitbreiding begrijpt.
Gebruik deze structuur:
| Onderdeel | Wat je beschrijft |
|---|---|
| Huidige status | Waar MFA technisch actief of verplicht is |
| Scope | Welke gebruikers, rollen, apps en toegangswegen |
| Uitzondering | Wat nog buiten de policy valt en waarom |
| Risico | Welk risico de uitzondering veroorzaakt |
| Tijdelijke maatregel | Welke beperking of extra controle nu geldt |
| Actie | Welke concrete verandering wordt uitgevoerd |
| Eigenaar | Wie verantwoordelijk is |
| Streefdatum | Een realistische datum of eerstvolgende besluitmoment |
| Toekomstig bewijs | Welk rapport of controlemoment daarna beschikbaar komt |
Voorbeeld: alleen beheerders beschermd
MFA wordt afgedwongen voor beheerders en accounts met verhoogde rechten. Voor gewone gebruikers is registratie grotendeels voltooid, maar organisatiebrede technische afdwinging is nog niet afgerond. De resterende uitrol wordt uitgevoerd door de IT-verantwoordelijke. Na afronding wordt een nieuwe scope- en registratierapportage vastgelegd.
Voorbeeld: uitzonderingsgroep aanwezig
MFA geldt voor de reguliere medewerkers- en beheerdersgroepen. Een beperkte uitzonderingsgroep bestaat voor een oudere applicatie die moderne authenticatie nog niet ondersteunt. De groep wordt afzonderlijk beheerd, periodiek beoordeeld en staat op de migratieroadmap. Wij claimen daarom niet dat MFA zonder uitzondering voor alle applicaties geldt.
Voorbeeld: legacy authentication nog mogelijk
MFA is ingericht voor moderne cloudtoegang. Een resterend legacy protocol kan de normale MFA-route niet volledig gebruiken. De toegang is beperkt tot de noodzakelijke scope en wordt uitgefaseerd. Tot afronding wordt deze beperking als open punt gerapporteerd.
Lees voor dit soort antwoorden ook hoe je gedeeltelijk antwoordt zonder te overclaimen.
Voorbeeld van een volledig maar voorzichtig klantantwoord
MFA wordt technisch afgedwongen voor medewerkers en beheerders die toegang hebben tot Microsoft 365 en de in scope opgenomen cloudapplicaties. De huidige onderbouwing bestaat uit een geanonimiseerde policiesamenvatting, een registratieoverzicht en een controle van recente sign-ininformatie. In de meegeleverde klantversie zijn gebruikersgegevens en technische identifiers afgeschermd. Twee gecontroleerde noodaccounts vallen buiten de normale interactieve policy en worden volgens een afzonderlijke procedure beheerd. De scope en uitzonderingen zijn gecontroleerd op [datum].
Voorbeeld wanneer het bewijs nog niet compleet is
MFA is actief voor beheerders en voor gebruikers met toegang tot Microsoft 365. De technische afdwinging voor enkele overige applicaties wordt nog uitgebreid. We kunnen bewijs leveren voor de huidige scope en benoemen de resterende applicaties als open punt met eigenaar en planning. We verklaren daarom niet dat MFA al voor alle accounts en systemen organisatiebreed wordt afgedwongen.
Praktische controlelijst vóór verzending
- De exacte klantvraag is letterlijk vastgelegd.
- Beschikbaarheid, registratie en afdwinging zijn niet door elkaar gehaald.
- De scope bevat gebruikers, beheerders, apps en externe toegang.
- Serviceaccounts en noodaccounts zijn afzonderlijk beoordeeld.
- Het bewijs heeft een datum en een eigenaar.
- Uitsluitingen zijn uitgelegd.
- Een screenshot is voorzien van context.
- Gevoelige waarden en persoonsgegevens zijn verwijderd.
- De formulering is niet breder dan de technische inrichting.
- Open punten hebben een concrete vervolgstap.
- De definitieve klantversie is intern gecontroleerd.
Wanneer is technische of juridische hulp nodig?
Schakel je IT-beheerder of securityspecialist in wanneer je niet betrouwbaar kunt vaststellen welke policies actief zijn, welke accounts buiten scope vallen of wat de rapportage precies aantoont.
Laat een contract- of aanbestedingseis apart beoordelen wanneer de klant een formele garantie, specifieke certificering, aansprakelijkheid of harde termijn verlangt. Een technisch screenshot bepaalt niet automatisch de juridische betekenis van je antwoord.
Bronnen en actuele informatie
Geraadpleegd op 12 juli 2026:
- Microsoft Learn — Use the sign-in logs to review Microsoft Entra multifactor authentication events: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-reporting
- Microsoft Learn — Conditional Access insights and reporting: https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-insights-reporting
- NCSC — Verdiepende maatregelen voor toeleveranciers: https://www.ncsc.nl/cyberbeveiligingswet-nis2/verdiepende-maatregelen-voor-toeleveranciers
- NCSC — Toeleveranciers van Cbw-organisaties: https://www.ncsc.nl/cyberbeveiligingswet-nis2/toeleveranciers-van-cbw-organisaties
Hulp nodig bij het onderbouwen van MFA?
Gebruik de primaire actie onder dit artikel om het bewijs binnen een concrete securityvragenlijst te laten beoordelen. Keren dezelfde bewijsverzoeken bij meerdere klanten terug, dan kan een Cybersecurity Bewijsmap een secundaire vervolgstap zijn.
