Kernpunt: Artikel 21(2)(j) is de enige maatregel binnen artikel 21 die een specifieke control noemt. Toezichthouders zijn er dol op, want het is binair. MFA staat aan of uit, en het dekkingsrapport is een screenshot. Dat maakt het de makkelijkste maatregel om te auditen en de meest voorkomende bron van vroege NIS2-bevindingen. De meeste organisaties hebben MFA. Weinigen kunnen een schoon dekkingsrapport met gedocumenteerde uitzonderingen laten zien.
Artikel 21(2)(j) is de enige maatregel in artikel 21 die meervoudige authenticatie met naam noemt, en daarmee de enige plek waar NIS2 MFA feitelijk verplicht stelt. Overal daarbuiten blijft het best practice die je zelf onderbouwt. Als er één maatregel uit artikel 21 is die een toezichthouder binnen 10 minuten na aanvang controleert, is het meervoudige authenticatie. De vraag is simpel: "Laat je MFA-dekkingsrapport zien, en de lijst met accounts die niet zijn gedekt." Het antwoord is bijna altijd rommeliger dan het zou moeten zijn.
Dit artikel loopt door wat artikel 21(2)(j) werkelijk vereist, waar MFA in de praktijk verplicht is, waar het nog best practice is, en de uitrolvalkuilen waardoor organisaties tekortschieten, zelfs met een MFA-programma. Het sluit af met een praktische readinesschecklist.
Wat zegt artikel 21(2)(j) precies?
De tekst noemt drie dingen: meervoudige authenticatie of continue-authenticatieoplossingen, beveiligde spraak-, video- en tekstcommunicatie, en beveiligde noodcommunicatiesystemen binnen de entiteit. Alle drie worden gekwalificeerd door de zinsnede "waar passend". Daar zit het grootste juridische gewicht.
"Waar passend" betekent niet "waar je zin in hebt". In de handhavingsrichtlijnen van begin 2026 komen ENISA en meerdere nationale bevoegde autoriteiten uit op een simpele toets: heeft een account toegang tot systemen die de levering van essentiële of belangrijke diensten van de entiteit ondersteunen, of tot gevoelige data, dan is MFA passend. Die toets vangt bijna elk account in een typische onderneming.
Continue authenticatie als alternatief: De richtlijn noemt MFA of continue-authenticatieoplossingen. Gedragsgebaseerde continue authenticatie kan in beperkte gevallen klassieke MFA vervangen, doorgaans bij interne systemen met hoge doorvoer waar meervoudige-authenticatieprompts de bedrijfsvoering zouden verstoren. Het moet aantoonbaar minstens even sterk zijn, en vastgelegd worden in het cryptografie- en toegangsbeleid.
Waar is MFA feitelijk verplicht?
Toezichthouders trekken een duidelijke grens rond accounts waarvoor MFA niet langer optioneel is. In elke tot nu toe in 2026 gepubliceerde toezichtszaak telde ontbrekende MFA op een van deze accountklassen als bevinding.
1. Alle naar buiten gerichte authenticatie
E-mail (M365, Google Workspace), VPN en zero-trust netwerktoegang, remote desktop, SaaS-consoles, klantgerichte beheerportalen, en elke identity provider die hiermee federeert. MFA moet worden afgedwongen bij de identity provider, niet als instelling per applicatie die gebruikers kunnen overslaan.
2. Alle bevoorrechte accounts
Domeinbeheerders, cloudbeheerders (AWS-, Azure-, GCP-rootrollen en bevoorrechte rollen), databasebeheerders, firewall- en netwerkengineers, SaaS-tenantbeheerders, en service desk-accounts met gedelegeerde beheerrechten. Toezichthouders verwachten steeds vaker phishingbestendige MFA (FIDO2-beveiligingssleutels, smartcards, of platformauthenticators met TPM) voor deze accounts, geen app-based push.
3. Accounts met toegang tot gevoelige data
Financiën, HR, juridische zaken, R&D, en elke rol met permanente toegang tot persoonsgegevens op grote schaal of tot de meest gevoelige operationele technologie van de entiteit. De invulling is sectorspecifiek: de beheerders van klinische systemen van een ziekenhuis, SCADA-gebruikers bij een energiebedrijf, klantenservice van een cloudprovider met toegang tot tenantdata.
4. Toegang van derde partijen en leveranciers
Elke externe leverancier met een account in je omgeving heeft MFA nodig. De incidenten in de keten van 2024 en 2025 begonnen bijna allemaal met een onbeschermd leveranciersaccount. Artikel 21(2)(d) (keten) en (j) (MFA) werken hier samen: contractclausules moeten de leverancier verplichten MFA te gebruiken, maar de handhaving vindt echt plaats bij de identity provider.
Waar is MFA nog best practice en nog niet verplicht?
Een beperkte groep accounts blijft in een grijs gebied. MFA wordt aangeraden, maar een gedocumenteerd risicogebaseerd besluit kan alternatieve maatregelen rechtvaardigen. Dit zijn de gevallen waar je goed over moet nadenken.
- Serviceaccounts. Niet-interactieve accounts die applicaties gebruiken kunnen geen klassieke MFA uitvoeren. Toezichthouders verwachten compenserende maatregelen: door een vault beheerde credentials, kortlevende tokens, restricties per host, en systematische rotatie van secrets. "Serviceaccount, dus geen MFA" is een geldige uitspraak. "Serviceaccount, dus geen control" niet.
- Break-glass-accounts. Noodaccounts worden doorgaans beschermd door een fysieke kluis, verzegelde credentials, en split knowledge. Dit wordt geaccepteerd, maar vereist een schriftelijk proces, een logboek van elk gebruik, en een jaarlijkse oefening.
- Legacy OT en embedded systemen. Sommige operationele technologie kan geen moderne MFA aan. Compenserende maatregelen zijn netwerksegmentatie, jump servers die MFA wel afdwingen, en een gedocumenteerde migratieroadmap met data.
- Klantgerichte eindgebruikersaccounts. Heeft de dienst van de entiteit klantlogins, dan wordt MFA voor die klanten sterk aangeraden, maar is het nog niet universeel verplicht onder artikel 21. Sectorspecifieke regelgeving (financiële diensten, digitale identiteit) voegt vaak eigen MFA-eisen toe.
Welke uitrolvalkuilen leiden tot bevindingen?
Bij pre-enforcement reviews en vroege toezichtsbesluiten komen acht implementatiefouten steeds terug. Elk is te vermijden met een gestructureerde uitrol en een dekkingsrapport dat aansluit op de gebruikersdirectory.
- MFA bestaat, maar is optioneel. Het beleid is gepubliceerd, gebruikers kunnen zich aanmelden, maar afdwinging staat niet aan. Wie zich nooit aanmeldt logt nog steeds in met alleen een wachtwoord. Afdwinging moet aanstaan bij de identity provider.
- Legacy authenticatieprotocollen staan nog aan. IMAP, POP3, SMTP AUTH, en oudere NTLM-paden omzeilen MFA stilzwijgend. Legacy authenticatie uitschakelen is de meest waardevolle hardeningsstap na het afdwingen van MFA zelf.
- Stille uitzonderingen. Een handjevol gebruikers is uitgesloten van de MFA-beleidsgroep omdat "het niet werkte". De uitsluitingen hebben geen vervaldatum en geen vastgelegde risicoacceptatie.
- Conditional access-omzeilingen. Beleid voor vertrouwde netwerken of vertrouwde apparaten is toegevoegd om frictie te verminderen, en groeide uit tot brede uitzonderingen. Een kantoor-IP-adres mag onder artikel 21 nooit MFA overslaan.
- Push fatigue en MFA-bombing. App-based push alleen is onveilig tegen aanvallen met herhaalde prompts. Number matching, of beter nog FIDO2 voor bevoorrechte gebruikers, is de huidige standaard.
- SMS-OTP als enige factor. SIM-swapaanvallen tegen individuele bestuurders en beheerders komen vaak voor. SMS blijft geaccepteerd als aanvullende factor, maar niet als enige optie voor bevoorrechte gebruikers.
- Geen dekkingsrapportage. MFA is afgedwongen, maar er is geen rapport dat laat zien welk percentage accounts is aangemeld, welke zijn uitgezonderd, en wie de eigenaar is van elke uitzondering. Het dekkingsrapport is het belangrijkste bewijsstuk.
- MFA voor gebruikers, niet voor beheerconsoles. Beheerconsoles voor identity, cloud en SaaS-tenants vallen soms buiten het hoofd-MFA-beleid. Aanvallers richten zich hier als eerste op. Ze horen onder het strengste beschikbare beleid te vallen.
Een praktische readinesschecklist voor artikel 21(2)(j)
Gebruik deze korte checklist om jezelf te beoordelen voordat de toezichthouder langskomt. Kun je een item niet beantwoorden met een document of screenshot, dan is dat een gat om te dichten.
MFA-readinesschecklist
- Een schriftelijk MFA-beleid, goedgekeurd door het management, dat vastlegt welke accounts binnen scope vallen en welke factortypen zijn toegestaan.
- Afdwinging bij de identity provider voor alle naar buiten gerichte authenticatie, met legacy protocollen uitgeschakeld.
- Phishingbestendige MFA (FIDO2 of smartcard) voor alle bevoorrechte accounts.
- Een maandelijks dekkingsrapport met aanmeldpercentage, verdeling van factortypen, en de lijst met uitzonderingen.
- Gedocumenteerde uitzonderingen met een genoemde risico-eigenaar, compenserende maatregelen, en een evaluatiedatum.
- Contractuele MFA-eisen voor toegang door derden, afgedwongen op je identity provider.
- Number matching ingeschakeld bij push-based MFA; SMS alleen als fallback, niet als primaire factor voor bevoorrechte gebruikers.
- Beveiligd noodcommunicatiekanaal geïdentificeerd, getest, en gedocumenteerd (onderdeel van dezelfde maatregel).
De helft van maatregel 10 over beveiligde communicatie
Artikel 21(2)(j) stopt niet bij MFA. Het vereist ook beveiligde spraak-, video- en tekstcommunicatie en beveiligde noodcommunicatiesystemen binnen de entiteit, waar passend. Dit wordt vaak over het hoofd gezien, en is in 2026 een veelgestelde vraag bij toezicht.
In de praktijk betekent dit twee dingen. Ten eerste hoort gevoelige samenwerking (incident response-bridges, bestuurscommunicatie, gesprekken onder legal hold) plaats te vinden via end-to-end versleutelde kanalen. Enterprise messaging suites, versleutelde voice-bridges, of specifieke tools zoals Signal for Business of Wickr Enterprise worden geaccepteerd. Onversleutelde spraak en SMS voor gevoelige gesprekken niet. Ten tweede moet het incident response plan een communicatiekanaal buiten de band vastleggen dat werkt als primaire systemen zijn gecompromitteerd.
Veelgestelde vragen
Maakt NIS2 MFA verplicht?
In de praktijk wel. Artikel 21(2)(j) vereist het gebruik van MFA of continue-authenticatieoplossingen 'waar passend'. Voor naar buiten gerichte, administratieve en accounts met gevoelige data dekt 'waar passend' vrijwel al deze accounts. Toezichthouders beschouwen ontbrekende MFA op deze klassen als een bevinding.
Welke typen MFA accepteert NIS2?
De richtlijn is technologieneutraal. Elke combinatie van factoren voldoet. In de praktijk verwachten toezichthouders phishingbestendige MFA zoals FIDO2, smartcards, of platformauthenticators met TPM voor bevoorrechte accounts, app-based push met number matching als minimum voor algemene gebruikers, en SMS alleen als fallback.
Is SMS-gebaseerde MFA acceptabel onder NIS2?
Het is niet verboden, maar wordt gezien als de zwakste gangbare factor en is doelwit van SIM-swapaanvallen. Toezichthouders accepteren het als tussenoplossing voor algemene gebruikers en verwachten een gedocumenteerde roadmap naar sterkere factoren, zeker voor beheerders en bevoorrechte toegang op afstand.
Moeten MFA-uitzonderingen worden gedocumenteerd?
Ja. Elk account zonder MFA heeft een schriftelijke onderbouwing nodig, een genoemde risico-eigenaar, compenserende maatregelen, en een evaluatiedatum. De meest voorkomende MFA-bevinding bij inspecties in 2026 is een cluster stille uitzonderingen, meestal serviceaccounts of legacy applicaties, zonder vastgelegde risicoacceptatie.
Welk bewijs vraagt een toezichthouder voor MFA-dekking?
Een door het management goedgekeurd MFA-beleid, een screenshot van de afdwingingsconfiguratie bij de identity provider, een dekkingsrapport met aanmeldpercentage per gebruikersklasse, en de lijst met gedocumenteerde uitzonderingen met eigenaren en evaluatiedata. Het dekkingsrapport wordt meestal als eerste opgevraagd.
Vereist NIS2 MFA voor toegang door derden en leveranciers?
Ja. Artikel 21(2)(d) over ketenveiligheid gecombineerd met maatregel (j) betekent dat elke leverancier of managed service provider met toegang tot systemen binnen scope moet authenticeren met MFA. Dit wordt meestal afgedwongen via contractclausules en gecontroleerd tijdens leveranciersbeoordelingen.
Dekt artikel 21(2)(j) van NIS2 ook beveiligde communicatie?
Ja. Maatregel (j) combineert MFA met beveiligde spraak-, video- en tekstcommunicatie en noodcommunicatiesystemen. Incident response-bridges, bestuurscommunicatie, en kanalen buiten de band moeten draaien op versleutelde tooling. Onversleutelde spraak of SMS voor gevoelige gesprekken wordt niet geaccepteerd.
Een schoon MFA-dekkingsrapport nodig voor je volgende audit?
We helpen organisaties het gat te dichten tussen "MFA uitgerold" en "MFA audit-ready": dekkingsrapportage, uitzonderingsbeheer, phishingbestendige uitrol voor bevoorrechte accounts, en afdwinging bij leveranciers.
Plan een MFA-readinessreview