,
,
,
Context: Multi-factor authentication is geen slecht idee. Integendeel: een tweede factor kan voorkomen dat een gestolen wachtwoord direct toegang geeft tot uw account.
Dit artikel gaat daarom niet over de vraag of MFA nuttig is. Het gaat over de privacyvraag erachter: welke extra gegevens worden verzameld, waarom precies, hoe lang blijven die bewaard, en worden zij echt alleen gebruikt voor beveiliging?
Feit: MFA verhoogt de beveiliging, vooral wanneer de tweede factor bestand is tegen phishing. Ook feit: beveiligingsgegevens kunnen commercieel of analytisch aantrekkelijk worden zodra zij in databases terechtkomen.
Niet bewezen: dat elk bedrijf MFA invoert om profielen groter te maken. Wel redelijk om te vragen: waarom sommige diensten voor "veiligheid" meer gegevens willen dan technisch noodzakelijk is.
Multi-factor authentication klinkt heerlijk verstandig. Eerst een wachtwoord, daarna nog iets extra's: een code, app, sleutel, vingerafdruk, telefoonmelding of passkey. Alsof uw voordeur niet alleen een slot heeft, maar ook even vraagt of u werkelijk u bent.
Dat is vaak precies wat we willen. Wachtwoorden lekken, worden hergebruikt, worden geraden, worden onderschept en worden soms opgeslagen alsof de stagiair met een spreadsheet de hoofdarchitect was. Een tweede factor kan dan veel schade voorkomen.
Maar de beveiligingsvraag is niet de enige vraag. Want zodra een dienst zegt "voor uw veiligheid hebben wij nog even uw telefoonnummer, apparaat-ID, herstelmail, app-installatie, push-notificatie, locatiecontext en gedragssignalen nodig", schuift het onderwerp van beveiliging naar gegevensverzameling.
En daar begint de privacyvraag: wanneer beschermt MFA de gebruiker, en wanneer wordt MFA een keurige voordeur voor een grotere profielkast?
Laat dat eerst helder zijn: MFA is in de basis goed. Een account met alleen een wachtwoord is kwetsbaar, zeker wanneer hetzelfde wachtwoord op meerdere plaatsen is gebruikt. Een tweede factor maakt misbruik moeilijker.
Niet elke tweede factor is even sterk. Een hardware security key of passkey is meestal beter bestand tegen phishing dan een losse SMS-code. Een authenticator-app is vaak beter dan alleen e-mail. SMS kan nog steeds beter zijn dan niets, maar het telefoonnetwerk en het telefoonnummer zijn geen magische beveiligingslaag.
Dat onderscheid is belangrijk. Wie kritiek heeft op privacy-onvriendelijke MFA, zegt niet: "laat iedereen terug naar wachtwoord123." Dat zou geen privacystrategie zijn, maar digitale zelfkastijding met hoofdletters.
De betere stelling is eenvoudiger: gebruik MFA, maar ontwerp het sober. Verzamel niet meer gegevens dan nodig. Gebruik beveiligingsgegevens niet voor marketing, profilering of accountkoppeling. En bied gebruikers waar mogelijk privacyvriendelijke opties.
De kern van deze discussie vraagt om een nette scheiding.
Feit: MFA helpt tegen veel vormen van accountmisbruik. Dat is de reden waarom beveiligingsorganisaties MFA blijven adviseren. Vooral phishingbestendige methoden, zoals FIDO2-beveiligingssleutels en goed ontworpen passkeys, verminderen afhankelijkheid van gedeelde codes die een aanvaller kan overnemen.
Feit: telefoonnummer, herstelmail, apparaatkenmerken, IP-adres, tijdstip, appgebruik en push-reacties kunnen persoonsgegevens of in elk geval herleidbare metadata zijn. Zij vertellen niet altijd wat iemand doet, maar vaak wel genoeg om accounts, apparaten en patronen aan elkaar te knopen.
Feit: gegevens die voor beveiliging zijn verzameld, kunnen later voor andere doelen worden gebruikt wanneer regels, techniek of interne prikkels dat toelaten. De FTC-zaak tegen Twitter is een duidelijk voorbeeld: telefoonnummer- en e-mailgegevens die voor accountbeveiliging waren opgegeven, werden volgens de toezichthouder ook gebruikt voor gerichte advertenties.
Niet bewezen: dat MFA als concept een verkapte datagraaier is. Een goed ontworpen tweede factor kan juist privacyvriendelijk zijn, zeker wanneer biometrie lokaal blijft, elke website een eigen cryptografische sleutel krijgt en de aanbieder niet onnodig extra profielinformatie opslaat.
Wel aannemelijk: dat grotere databases aantrekkelijker worden. Niet alleen voor aanvallers, maar ook voor interne analyses, risicomodellen, advertentiedoelen, fraudedetectie, klantbinding en "personalisatie". Een veld dat vandaag "security_phone" heet, kan morgen voor iemand in een dashboard ineens "useful_customer_identifier" worden. De database bloost daar niet van.
Het telefoonnummer is praktisch. Veel mensen hebben er één, het is relatief stabiel en het werkt buiten de app om. Daarom gebruiken diensten het graag voor herstel en verificatie.
Maar juist die eigenschappen maken het telefoonnummer privacygevoelig. Een telefoonnummer kan accounts aan elkaar koppelen, contactenboeken ontsluiten, SIM-swaprisico's introduceren, spam mogelijk maken en een persoon herkenbaar maken over diensten heen.
Wanneer een dienst SMS-MFA verplicht stelt zonder alternatief, vraagt zij niet alleen om een tweede factor. Zij vraagt om een identifier die vaak dichter bij de echte persoon staat dan een gebruikersnaam. Voor sommige gebruikers is dat geen detail, maar een veiligheids- of privacyrisico.
Daarom is "geef ons uw telefoonnummer voor uw veiligheid" niet automatisch fout, maar ook niet automatisch onschuldig. De juiste vervolgvraag is: kan dezelfde beveiliging met minder persoonlijke gegevens?
Bedrijven voegen graag lagen toe: herstelvragen, extra e-mailadressen, telefoonnummerverificatie, device fingerprinting, locatiecontrole, push-apps, risicoscores en verdachte-loginmodellen. Sommige daarvan zijn nuttig. Sommige zijn vooral een manier om onzekerheid te verplaatsen naar een grotere berg data.
Beveiliging is geen wedstrijd wie de meeste velden in een formulier krijgt. Een geheime vraag als "wat is de naam van uw eerste huisdier?" is niet ineens veilig omdat het in een nette beveiligingsflow staat. Veel antwoorden zijn te raden, te vinden of door datalekken herbruikbaar geworden.
Ook gedragsanalyse en apparaatprofilering kunnen nuttig zijn bij fraudedetectie, maar zij moeten proportioneel blijven. Als een simpele nieuwsbriefinschrijving dezelfde apparaat- en locatiehonger krijgt als online bankieren, is er iets scheef gaan staan.
Dat is het gebied waar "veiligheid" soms verandert in security theatre: er gebeurt veel, het ziet er serieus uit, maar de gebruiker krijgt niet altijd duidelijk betere bescherming. Wel ontstaat er een rijkere database.
Onder Europese privacyregels zijn doelbinding en dataminimalisatie geen hoffelijke suggesties. Persoonsgegevens moeten voor duidelijke doelen worden verzameld en beperkt blijven tot wat nodig is voor die doelen.
Dat principe past bijzonder goed bij MFA. Als een telefoonnummer, herstelmail of apparaatregistratie nodig is voor accountbeveiliging, gebruik die gegevens dan voor accountbeveiliging. Niet voor advertentiedoelen. Niet voor algemene profilering. Niet voor stille koppelingen met andere diensten omdat het technisch zo gezellig kan.
Het probleem is niet dat een beveiligingsteam risico's wil inschatten. Het probleem ontstaat wanneer de organisatie geen stevige grens trekt tussen beveiligingsdata en klantprofieldata.
Voor gebruikers voelt dat verschil vaak onzichtbaar. U ziet een scherm dat om extra beveiliging vraagt. Achter dat scherm kunnen echter opslag, analytics, advertentietechniek, klantenservice, fraudedetectie en identity-management allemaal iets met dezelfde gegevens willen. Dat vraagt governance, niet alleen een privacyverklaring die niemand leest zonder cafeine en karakter.
Gelukkig is dit geen keuze tussen zwakke wachtwoorden en datagraaierij. Er bestaan betere vormen van MFA.
Hardware security keys en passkeys op basis van FIDO/WebAuthn werken met publieke-sleutelcryptografie. De dienst krijgt geen gedeelde code die later opnieuw kan worden onderschept. De sleutel is bovendien per dienst verschillend, waardoor websites elkaar niet zomaar via dezelfde sleutel kunnen volgen.
Biometrie kan daarbij verwarrend klinken. Bij goed ontworpen passkeys verlaat uw vingerafdruk of gezichtsherkenning het apparaat niet als wachtwoordvervanger richting de website. De biometrie ontgrendelt lokaal een sleutel. Dat is een wezenlijk verschil met een centrale database vol biometrische profielen.
Ook authenticator-apps kunnen redelijk privacyvriendelijk zijn wanneer zij offline codes genereren en geen account, tracking of cloudkoppeling afdwingen. De kleine code in de app is saai, maar soms is saai precies wat beveiliging nodig heeft.
Een privacyvriendelijk MFA-beleid begint met keuzevrijheid. Bied meerdere sterke opties aan: passkeys, hardware keys, authenticator-apps en waar nodig SMS als fallback, niet als enige toegangspoort.
Maak daarna een harde scheiding in doelgebruik. Gegevens die voor beveiliging worden gevraagd, horen niet in marketingprofielen te verdwijnen. Wie een telefoonnummer afgeeft om niet gehackt te worden, heeft daarmee geen stil akkoord gegeven voor betere advertentiedoelgroepen.
Beperk bewaartermijnen. Leg uit welke gegevens worden opgeslagen. Toon welke herstelopties actief zijn. Laat gebruikers oude apparaten en telefoonnummers verwijderen. Maak export en correctie mogelijk waar dat wettelijk hoort. En gebruik geen donkere patronen waarbij "later instellen" verstopt zit alsof het een morele tekortkoming is.
Voor organisaties is dit ook eigenbelang. Elke extra databasekolom moet worden beveiligd, uitgelegd, beheerd, gecontroleerd en uiteindelijk verdedigd wanneer zij uitlekt. Minder data is niet alleen beter voor privacy; het is ook minder rommel om om drie uur 's nachts incidentrapporten over te schrijven.
Gebruikers hoeven geen cryptografen te worden om betere keuzes te maken. Een paar vragen helpen al.
Voor belangrijke accounts is sterke MFA verstandig. Voor gevoelige situaties kan een hardware key of passkey beter zijn dan een telefoonnummer. Voor minder belangrijke diensten mag u best kritisch zijn wanneer zij doen alsof een sokkenwebshop hetzelfde risicoprofiel heeft als een bank.
Het eerlijke antwoord is dus dubbel. Ja, MFA is belangrijk. Nee, dat betekent niet dat elke MFA-flow automatisch privacyvriendelijk is.
Beveiliging mag geen excuus worden om een steeds groter profiel van de gebruiker op te bouwen. Het doel is niet dat bedrijven meer over u weten. Het doel is dat iemand anders niet als u kan inloggen.
De juiste richting is daarom sober en sterk: phishingbestendige MFA waar mogelijk, minimale gegevensverzameling, duidelijke doelbinding, echte verwijdermogelijkheden en geen hergebruik van beveiligingsdata voor commerciële profiling.
MFA moet een extra slot zijn op uw account, geen extra plank in het dossier over u. Zodra beveiliging die grens respecteert, wordt zij sterker voor de gebruiker in plaats van waardevoller voor de database.
| CISA | Multi-factor authentication | More than a Password: multi-factor authentication guidance |
| CISA | Phishing-resistant MFA | Implementing phishing-resistant MFA |
| NIST | Digital Identity Guidelines | SP 800-63B: Authentication and authenticator management |
| FTC | Twitter enforcement | FTC charges Twitter with deceptively using account security data to sell targeted ads |
| EUR-Lex | GDPR | Regulation (EU) 2016/679: purpose limitation and data minimisation |
| EDPB | Privacy by design | Guidelines on Data Protection by Design and by Default |
| FIDO Alliance | Passkeys | Passkeys and phishing-resistant authentication |
Copyright © 2026, ASK-Solutions
