Wachtwoorden zijn niet genoeg: waarom MFA nog steeds niet overal staat

Meervoudige authenticatie, kortweg MFA, is het principe dat een gebruiker zich identificeert met meer dan één factor: iets dat je weet, iets dat je hebt, en in sommige gevallen iets wat je bent. Het is geen product en geen vinkje, maar een eigenschap van de manier waarop een organisatie toegang verleent. De factor "iets dat je hebt" zit op een spectrum van zwak naar sterk: een code per sms aan de zwakke kant, een push-melding in het midden, een hardware-gebonden sleutel die alleen op de juiste domeinnaam reageert aan de sterke kant. Die laatste klasse heet phishing-resistant, omdat de factor niet over te zetten is naar een nagebouwde inlogpagina. Wie zegt "wij hebben MFA aanstaan" zegt nog niets over waar op dat spectrum hij zit, en nog minder over waar het wel en niet staat.

Het is precies dat verschil dat in 2026 het pijnlijke gesprek bepaalt. Op papier heeft vrijwel iedere organisatie MFA. In de praktijk staat het op de plekken waar het makkelijk was om aan te zetten, en ontbreekt het op de plekken waar het werkelijk telt. Dat is geen kwestie van onwetendheid bij Operationele teams. Het is een kwestie van architectuur-debt: legacy-systemen die geen moderne authenticatie spreken, service-accounts die nooit zijn ontworpen om een tweede factor te dragen, en koppelingen met derden waar de afspraken stammen uit een tijd dat een wachtwoord nog volstond. Wie MFA "overal" wil hebben staan, ontdekt dat hij geen knop heeft die het overal aanzet. Hij heeft een volgorde nodig.

Waarom staat MFA nog steeds niet overal?

Het korte antwoord is dat MFA in de gangbare bedrijfsomgeving op drie soorten harde randen stuit, en dat elk van die randen om een andere oplossing vraagt dan "de toggle omzetten".

De eerste rand is legacy. Een deel van het applicatielandschap praat protocollen die uit een ander tijdperk komen. Oude mailclients, file-shares, sommige industriële beheerinterfaces, on-premise applicaties die nooit een federatie-koppeling hebben gekregen. Die systemen accepteren een wachtwoord en niets anders. Een tweede factor erop laten landen vraagt of een vervangende client, of een gateway ervoor, of een ontkoppeling van het netwerk waarop het systeem hangt. Dat zijn ingrepen in de architectuur, geen instelling in een beheerportaal. Zolang die ingreep niet wordt gepland, blijft de rand bestaan, en met de rand een pad dat een aanvaller na een wachtwoordlek probleemloos volgt.

De tweede rand is service-accounts en machine-naar-machine-verkeer. Een service-account is een account dat niet door een mens wordt gebruikt maar door een proces: een batch-job, een koppeling tussen twee systemen, een agent die telemetrie ophaalt. Een tweede factor in de zin van "iets dat je hebt" past niet vanzelf op iets dat geen mens is. De moderne uitvoering hiervan zijn certificaat-gebonden of identiteitsgebonden machine-credentials met korte levensduur, gecontroleerd door een centraal beleid. Maar het bestaande landschap hangt vaak nog van lange, vaste service-accountwachtwoorden aan elkaar, soms gedeeld tussen omgevingen, soms gedocumenteerd in een spreadsheet waarvan niemand de eigenaar nog kent. Voor die accounts geldt iets wat NIST in SP 800-63B vastlegt en wat ook NCSC in zijn richtlijnen herhaalt: een tweede factor heeft alleen zin als er een identiteit is waaraan je hem kunt verbinden. Bij een naamloos gedeeld service-account is de eerste stap niet MFA, maar de identiteit op orde brengen.

De derde rand is third-party-koppelingen. De boekhouder die in jouw financiële systeem werkt, de leverancier die op jouw beheerportaal moet, de vendor die remote support levert. Hier is jouw MFA-beleid niet de enige variabele. De andere partij heeft een eigen toegangsmodel, een eigen identity-provider, en een eigen verzameling beperkingen. Een organisatie die hier alleen op "wij eisen MFA" leunt, ontdekt dat de afdwinging zwakker is dan hij denkt: een gedeeld account aan de andere kant, een uitzondering die ooit "tijdelijk" was, een koppeling via een API-sleutel die geen tweede factor kent. Phishing-resistance op de eigen werkplek levert weinig op als de toegangsweg via een derde partij wel kwetsbaar blijft.

Wat betekent phishing-resistance in de praktijk?

Niet elke MFA-implementatie biedt dezelfde bescherming, en dat is het verschil dat de gangbare communicatie over "MFA aan" verbergt. De factor die je toevoegt heeft een eigen kwetsbaarheid. Een code per sms is af te vangen via simswap of via een nagebouwde inlogpagina die de gebruiker zelf de code laat overtypen. Een push-melding is gevoelig voor zogenoemde push-bombing: de aanvaller hamert op de knop tot de gebruiker uit ergernis goedkeurt. De sterkste klasse, hardware-gebonden sleutels die het oorspronkelijke FIDO-protocol volgen, is door het FIDO Alliance-ontwerp gebonden aan het domein waar de gebruiker mee paart. Een nagebouwde pagina op een andere domeinnaam krijgt geen geldige respons, hoe overtuigend de pagina ook lijkt.

Voor Operationele teams betekent dit dat "MFA" zonder vermelding van het type een betekenisloze status is. Een organisatie kan rapporteren dat 100 procent van haar accounts MFA heeft, en tegelijk vrijwel volledig vatbaar zijn voor moderne aanvallen omdat de toegevoegde factor op het zwakke deel van het spectrum zit. CISA wijst hier in haar publicaties consequent op: voor de meest gerichte aanvallen op hooggeplaatste of bevoorrechte accounts is alleen phishing-resistance een serieus antwoord, voor de rest van de organisatie is iedere niet-sms-vorm al een grote stap vooruit. De praktische lijn is daarmee niet "alles op het sterkste niveau", maar "het sterkste niveau eerst daar waar de schade het grootst zou zijn".

Welke volgorde werkt in de praktijk?

Hier komt de architectuurkeuze terug. Een MFA-roll-out die alles tegelijk wil doen, loopt vast op het zwakste punt: de legacy-rand die niet meedoet, het service-account dat niet kan, de externe koppeling die ergens anders woont. Een roll-out die fase voor fase werkt, levert risicoreductie op die per stap zichtbaar is en uitlegbaar blijft. Drie prioriteiten in deze volgorde maken het werkbaar.

Bevoorrechte accounts eerst. Domeinbeheerders, cloud-administrators, accounts met toegang tot de identity-provider zelf, accounts die andere accounts kunnen aanmaken of resetten. Hier hoort phishing-resistance, niet omdat alle medewerkers dat morgen ook hebben, maar omdat het verlies van één van deze accounts onmiddellijk het hele model ondergraaft. Wie hier sms of een eenvoudige push laat staan, geeft een aanvaller na één geslaagde phishing een hefboom over de rest van de omgeving.

Externe toegang als tweede. Elke route waarlangs iemand van buiten naar binnen komt: VPN, remote desktop, remote-beheer voor leveranciers, federatieve toegang voor externe partijen, beheer van publieke applicaties. Dit is de rand waar aanvallers het eerst proberen, omdat ze de buitenkant van je netwerk kunnen zien. Hier hoort tenminste een phishing-resistent of vergelijkbaar sterk niveau, en hier horen ook de afspraken met derden expliciet te worden vastgelegd: welke factor, op welk domein, met welke uitzonderingen, en wat er gebeurt als de andere partij die uitzondering laat verlopen.

Interne kritieke applicaties als derde. Financieel kernsysteem, klantdatabase, broncode-omgeving, productie-besturing in een industriële omgeving. Hier kan de roll-out gefaseerd, omdat de aanvalsweg langer is en de tussenliggende controles meetellen. Maar de fasering moet eindigen, en dat einde hoort vastgelegd te worden voordat de volgende prioriteit begint, anders blijft de roll-out hangen op tachtig procent zoals dat in praktijk regelmatig gebeurt.

Wat opvalt aan deze volgorde is wat erin ontbreekt. Niet de gewone werknemers-mailbox eerst, niet de algemene desktop-login. Die zijn niet onbelangrijk, maar ze zijn niet de plek waar één gelekt account het hele model omver duwt. De volgorde is gebouwd op impactradius: waar zou een aanvaller de meeste schaal krijgen na één succesvolle stap. Dat is een ander criterium dan "waar zit het grootste aantal accounts", en het is precies het criterium dat de discussie verschuift van "MFA als feature" naar "MFA als architectuurmaatregel".

Wat dit betekent voor de uitvoering

De praktische gevolgen voor Operationele teams zijn nuchter. Voor elke prioriteit hoort vooraf vastgelegd wat het sterkste haalbare niveau is in jullie omgeving, welke uitzonderingen je accepteert en met welke vervaldatum, en wie de eigenaar is van de uitfasering van de uitzonderingen. Zonder eigenaar wordt elke uitzondering permanent. Voor service-accounts geldt dat de eerste stap een inventarisatie is, geen tweede factor: welke accounts bestaan er, wie gebruikt ze, wat is hun werkelijke functie, en welke daarvan kunnen worden vervangen door identiteitsgebonden machine-credentials met korte levensduur. Pas daarna komt de vraag of er nog een tweede factor nodig is, en in welke vorm.

Voor de gebruikersbeleving geldt iets vergelijkbaars met wat in andere security-trajecten al zichtbaar is: hoe sterker de factor, hoe lager de wrijving in de dagelijkse routine, mits goed uitgerold. Een hardware-gebonden sleutel die op de werkplek ligt aangesloten, vraagt minder van de gebruiker dan de optelsom van wachtwoord, sms, push-melding en periodieke wachtwoordwijziging die nu vaak nog naast elkaar bestaan. De winst zit niet alleen in security, maar ook in het opruimen van een laag aan controles die historisch op elkaar zijn gestapeld zonder dat iemand er ooit nog kritisch op heeft gewerkt.

De logische volgende stap

MFA staat niet overal omdat de toggle nooit het probleem was. Het probleem is de volgorde, de uitzonderingen die niemand sluit, en de aanname dat een vinkje aan de identity-provider hetzelfde betekent als bescherming aan de rand waar het telt. Wie de volgorde in eigen hand neemt, bevoorrechte accounts eerst op phishing-resistance, externe toegang als tweede, interne kritieke applicaties als derde, en service-accounts onder een eigen regime, krijgt een roll-out die navolgbaar is en blijft staan. Wie wacht tot een audit hem de volgorde voorschrijft, krijgt een plan dat klopt op papier en blijft hangen waar de architectuur het lastig maakt.

Een goede vervolgstap is die volgorde concreet maken naast iemand die de architectuur en de uitvoering allebei kan wegen, zonder een product te hoeven verkopen. Dan blijft de keuze van jou, en blijft hij uitlegbaar aan wie hem moet goedkeuren.