NIS2 MFA-eisen: waarom "wij hebben MFA" een audit niet meer doorstaat
NIS2 MFA-eisen: waarom "wij hebben MFA" een audit niet meer doorstaat
Een klant zegt dat hun authenticatie op orde is. Iedereen gebruikt Microsoft Authenticator, push-goedkeuring is afgedwongen, klaar. Dan opent een auditor de technische richtlijn van ENISA en stelt één vraag: is de MFA op jullie geprivilegieerde accounts phishing-bestendig? En opeens is het antwoord nee.
Dit is het gat dat de meeste organisaties niet zien aankomen. NIS2 noemt multifactorauthenticatie met zoveel woorden, maar de consensus onder toezichthouders is allang voorbij basis-MFA. Adviseer je Europese entiteiten over NIS2-naleving, dan is het MFA-gesprek van achttien maanden geleden achterhaald.
Artikel 21(2)(j) noemt MFA — maar definieert niet "goed genoeg"
NIS2 Artikel 21(2)(j) vereist "het gebruik van multifactorauthenticatie of continue authenticatieoplossingen, beveiligde spraak-, video- en tekstcommunicatie en beveiligde noodcommunicatiesystemen binnen de entiteit, waar passend."
Twee zinsdelen brengen mensen in de war. Het eerste is "waar passend." Dit is geen vrijblijvendheid. Het betekent dat de entiteit een gedocumenteerde, risicogebaseerde beslissing moet nemen over waar MFA van toepassing is. Een auditor die geprivilegieerde accounts zonder MFA aantreft en geen risicobeoordeling die het weglaten verklaart, behandelt dat als een bevinding, niet als een afweging.
Het tweede probleem is wat de richtlijn niet zegt. Artikel 21 noemt MFA maar definieert nooit welke factoren kwalificeren. Dat detail staat in Uitvoeringsverordening (EU) 2024/2690 van de Commissie van 17 oktober 2024, die de technische en methodologische eisen voor de risicobeheermaatregelen vastlegt. De Richtlijn zegt dat je MFA nodig hebt. De Uitvoeringsverordening, en de richtlijn die daarop voortbouwt, zegt welke soort.
ENISA heeft de lat al op phishing-bestendig gelegd
In juni 2025 publiceerde ENISA versie 1.0 van zijn Technical Implementation Guidance bij Uitvoeringsverordening 2024/2690. Dit is het document waar toezichthouders op leunen wanneer ze beoordelen of jouw maatregelen de norm daadwerkelijk halen.
De richtlijn is duidelijk: kies een authenticatiemethode waarvan het zekerheidsniveau aansluit bij de classificatie van de data en systemen die ze beschermt, en gebruik phishing-bestendige opties "waar mogelijk." Het noemt FIDO2-beveiligingssleutels en passkeys, gebouwd op de FIDO- en W3C WebAuthn-standaarden, als de sterkste beschikbare methode — vóór wachtwoorden, sms-codes en app-gebaseerde eenmalige wachtwoorden.
De redenering is technisch, geen mode. Pushmeldingen, OTP-codes en sms berusten allemaal op een gedeeld geheim of een goedkeuring die de gebruiker kan worden afgetroggeld. Aanvallers verslaan ze dagelijks met MFA-fatigue-prompts, adversary-in-the-middle-proxies en SIM-swaps. Passkeys en FIDO2-sleutels zijn per ontwerp domeingebonden: de credential geeft zich simpelweg niet vrij tegen een vervalst domein. Er is geen code om te phishen en geen prompt om te vermoeien.
Voor een essentiële entiteit is dit financieel én technisch van belang. Niet-naleving stelt essentiële entiteiten bloot aan boetes tot 10 miljoen euro of 2% van de wereldwijde jaaromzet. "Wij hadden MFA" is een zwak verweer wanneer het eigen agentschap van de toezichthouder heeft gedocumenteerd dat de MFA die je inzette de zwakke soort was.
Artikel 21 — 10 NIS2 Cybersecuritymaatregelen
Artikel 21
10 Cybersecuritymaatregelen
Governance & Strategie
1Risicoanalyse & informatiebeveiligingsbeleid6Effectiviteitsbeoordeling van beveiligingsmaatregelenIncidenten & Continuïteit
2Incidentafhandeling & melding3Bedrijfscontinuïteit & disaster recoveryToeleveringsketen & Systemen
4Beveiliging van de toeleveringsketen5Beveiliging bij de ontwikkeling van netwerk- en informatiesystemenTechnische Beheersing
8Cryptografie & versleuteling10Multi-factor authenticatie & veilige communicatieMensen & Middelen
7Cyberhygiëne & training9HR-beveiliging & toegangscontrole
Niet elk account heeft dezelfde factor nodig
De praktische fout in de andere richting is phishing-bestendige MFA als alles-of-niets-uitrol behandelen en blijven hangen omdat hardwaresleutels voor 4.000 medewerkers duur lijken. De richtlijn is risicogetierd, en jouw advies hoort dat ook te zijn.
Geprivilegieerde en impactvolle toegang is waar phishing-bestendige MFA feitelijk niet onderhandelbaar is: domeinbeheerders, cloud-tenantbeheerders, hypervisor- en back-upconsoletoegang, en elk account dat beveiligingsmaatregelen kan uitschakelen. Wordt zo'n account gecompromitteerd, dan is het incident voorbij voordat het begint. Zet hier eerst FIDO2-sleutels of platform-passkeys in.
Externe toegang en internetgerichte identiteiten komen daarna — VPN, RDP-gateways en elk systeem dat vanaf internet bereikbaar is. Dit is de voordeur waar aanvallers daadwerkelijk aankloppen, dus het zekerheidsniveau moet hoog zijn.
Standaard werknemersaccounts kunnen op een gepland tijdpad naar phishing-bestendige MFA, maar de richting moet helder zijn in je documentatie. Een auditor wil zien dat je weet waar de zwakke MFA nog zit en een gedateerd plan hebt om die uit te faseren, niet dat je alles van de ene op de andere dag hebt opgelost.
Deze tiering is ook hoe je budgetgesprekken beheersbaar houdt. Een consultant die binnenstapt en 200.000 euro aan hardwaresleutels eist, verliest de zaal. Een consultant die zegt "dertig FIDO2-sleutels voor jullie vijftien geprivilegieerde beheerders dit kwartaal, passkeys voor de rest volgend kwartaal" krijgt een handtekening.
Hoe je dit auditbaar maakt, niet alleen uitgerold
Uitrollen is de helft van het werk. De helft die een audit overleeft, is het papierwerk dat bewijst dat de uitrol een bewuste, risicogebaseerde beslissing onder Artikel 21 was.
Drie artefacten dragen het meeste gewicht. Ten eerste een toegangsclassificatie die accounttypen koppelt aan vereiste zekerheidsniveaus — dit is het document dat "waar passend" operationeel maakt. Ten tweede bewijs van afdwinging, oftewel conditional-access- of gelijkwaardige beleidsregels die niet-conforme aanmeldingen daadwerkelijk blokkeren in plaats van MFA slechts aan te bevelen. Een beleid in "report-only"-modus is geen maatregel. Ten derde een uitzonderingsregister: elk account dat nog geen phishing-bestendige MFA kan gebruiken, waarom, de compenserende maatregel en de hersteldatum.
Krijg je die drie goed, dan wordt het MFA-deel van een audit kort. Sla je ze over, dan ziet zelfs een technisch sterke uitrol eruit als geluk in plaats van governance.
Is NIS2 van toepassing op uw organisatie?
1Is uw organisatie actief in een essentiële of belangrijke sector (energie, transport, zorg, digitale infrastructuur, enz.)?
Ja▼Nee▼2Heeft uw organisatie 50 of meer werknemers, of een jaarlijkse omzet van meer dan €10 miljoen?
✗NIS2 is niet rechtstreeks van toepassing op uw organisatie.
Ja▼Nee▼✓NIS2 is van toepassing op uw organisatie als essentiële of belangrijke entiteit.
3Is uw organisatie een aanbieder van kritieke infrastructuur of een gekwalificeerde vertrouwensdienstverlener?
Ja▼!NIS2 kan van toepassing zijn op uw organisatie — raadpleeg juridisch advies om uw status te bevestigen.
1Is uw organisatie actief in een essentiële of belangrijke sector (energie, transport, zorg, digitale infrastructuur, enz.)?
Ja ↓Nee →2Heeft uw organisatie 50 of meer werknemers, of een jaarlijkse omzet van meer dan €10 miljoen?
Ja ↓Nee →3Is uw organisatie een aanbieder van kritieke infrastructuur of een gekwalificeerde vertrouwensdienstverlener?
Ja ↓Nee →✗NIS2 is niet rechtstreeks van toepassing op uw organisatie.
✓NIS2 is van toepassing op uw organisatie als essentiële of belangrijke entiteit.
!NIS2 kan van toepassing zijn op uw organisatie — raadpleeg juridisch advies om uw status te bevestigen.
Van toepassingMogelijk van toepassingNiet van toepassing
Wat dit betekent voor MSP's die meerdere tenants beheren
Beheer je identiteit voor meerdere klanten, dan is de overstap naar phishing-bestendig een operationeel programma, geen fix per klant. De klanten die het lastig krijgen, zijn degenen die over de hele linie nog op legacy-MFA zitten, en dat zijn doorgaans je kleinere opdrachten waar de budgetweerstand het hoogst is.
Standaardiseer nu. Kies een phishing-bestendige methode die je op schaal kunt uitrollen en ondersteunen — platform-passkeys plus een hardwaresleutel-fallback voor beheerders is een verdedigbare standaard — en maak die je basislijn voor elke tenant. Bouw de toegangsclassificatie één keer als sjabloon en pas die per klant aan in plaats van hem elke opdracht opnieuw uit te vinden. En zet het uitzonderingsregister in je normale rapportagecadans zodat hersteldata niet stilletjes langs een auditdeadline glippen.
De kosten van dit fout doen zijn niet gelijk verdeeld. Belandt een inbreuk bij een beheerde klant en is de oorzaak phishbare MFA op een beheerdersaccount, dan trekken de toeleveringsketenbepalingen van NIS2 het gesprek naar jouw contract, niet alleen dat van hen.
NIS2-sanctie-escalatie — Voorbij de boete
!Aanleiding
Non-compliance gedetecteerd of incident treedt op
Een toezichthouder identificeert een compliance-hiaat of een organisatie voldoet niet aan de NIS2-vereisten
Toezichthouders kunnen opleggen▼Niet-financiële sancties1Nalevingsbevelen met bindende deadlines
2Verplichte security-audits op eigen kosten
3Publieke bekendmaking van overtredingen
4Bindende instructies over specifieke beveiligingsmaatregelen
Escaleert naar▼Operationele en persoonlijke gevolgen1Opschorting van certificeringen of vergunningen
2Tijdelijk verbod op bestuursfuncties voor personen
3Publieke benoeming van verantwoordelijke natuurlijke personen
AanleidingNiet-financieelOperationeel / persoonlijk
De zet om dit kwartaal te maken
Stop met MFA behandelen als een vinkje dat al gezet is. De vraag die er onder NIS2 toe doet, is niet langer "hebben we MFA" maar "is onze MFA phishing-bestendig waar het ertoe doet, en kunnen we bewijzen dat de beslissing bewust was."
Begin met geprivilegieerde accounts, documenteer de risicotiers, dwing af in blokkeermodus en houd een eerlijk uitzonderingsregister bij. Dat is het verschil tussen een schone authenticatiebevinding en een dure.
Weet je niet zeker waar de MFA van je klanten daadwerkelijk staat ten opzichte van de ENISA-richtlijn, dan brengt een gestructureerde readiness assessment de gaten in beeld vóórdat een auditor dat doet. Doe een gratis NIS2 quick scan om te zien waar authenticatie en de rest van de Artikel 21-maatregelen vandaag staan.
Voor het bredere plaatje van wat Artikel 21 eist, zie onze uitleg van de tien Artikel 21-maatregelen. Wil je je algehele postuur toetsen, werk dan onze stapsgewijze gap-analysegids door.