Inloggen hoort in 2026 niet meer aan te voelen als een noodzakelijk kwaad. Toch vertrouwen veel webapps en digitale diensten nog steeds op wachtwoorden, sms-codes en pushmeldingen — precies de mechanismen waar moderne phishingaanvallen het vaakst op mikken. De verschuiving naar phishing-resistente authenticatie is daarom geen hype, maar een logische stap richting een veiliger én gebruiksvriendelijker internet.
Waarom traditionele MFA niet meer genoeg is
Multi-factor authenticatie was jarenlang de aanbevolen stap bovenop wachtwoorden. En terecht: een extra factor maakt een aanval meteen een stuk moeilijker. Maar in de praktijk blijkt dat niet elke vorm van MFA dezelfde bescherming biedt.
Code-gebaseerde methoden zoals sms, e-mailcodes of authenticator-apps zijn nog steeds kwetsbaar voor phishing. Een gebruiker kan een code zelf invoeren op een nepsite, waarna een aanvaller die code direct benut. Ook push-based MFA heeft een zwak punt: MFA-fatigue of prompt bombing, waarbij aanvallers een gebruiker blijven bestoken met inlogverzoeken tot die uit gewoonte of frustratie goedkeurt. CISA waarschuwt hier expliciet voor en stelt dat organisaties moeten overstappen op phishing-resistant MFA als ze echt een hoger beschermingsniveau willen bereiken:
https://www.cisa.gov/resources-tools/resources/implementing-phishing-resistant-mfa
https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-074a
Daar komt bij dat de dreiging zelf slimmer is geworden. Moderne adversary-in-the-middle-phishingkits kunnen niet alleen inloggegevens onderscheppen, maar ook sessiecookies kapen. Microsoft beschreef hoe dit soort aanvallen traditionele MFA kan omzeilen door de sessie na succesvolle login over te nemen:
https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bypass-phishing-evolving-threats-and-cookie-theft/
De harde realiteit is dus: traditionele MFA is beter dan alleen een wachtwoord, maar het is niet meer automatisch “goed genoeg”. Microsoft stelde al jaren geleden dat meer dan 99,9% van de gecompromitteerde accounts geen MFA had ingeschakeld:
https://www.microsoft.com/en-us/security/blog/2019/12/18/password-doesnt-matter/
Die statistiek blijft relevant, maar in 2026 verschuift de vraag van “moeten we MFA gebruiken?” naar “welke MFA is nog veilig genoeg?”
Wat phishing-resistente authenticatie precies betekent
Phishing-resistente authenticatie is ontworpen om een fundamentele eigenschap van klassieke phishing weg te nemen: het moeten delen van een geheim dat ook op een nepwebsite werkt. In plaats van een code of wachtwoord dat door een gebruiker kan worden overgetikt, gebruikt deze aanpak cryptografie die gekoppeld is aan het echte domein.
Dat is precies waarom standaarden en instanties steeds nadrukkelijker in deze richting bewegen. NIST, W3C en de FIDO Alliance positioneren cryptografische authenticatie als de moderne standaard voor sterke loginflows:
https://pages.nist.gov/800-63-3/sp800-63b.html
https://www.w3.org/TR/webauthn-2/
https://fidoalliance.org/
De kern van phishing-resistentie is eenvoudig: een aanvaller moet niet alleen weten wat de gebruiker intypt, maar moet ook toegang krijgen tot een private key die nooit de dienst verlaat en alleen werkt voor het juiste domein. Daardoor valt een hele aanvalsklasse weg in plaats van alleen een deel van de risico’s te verkleinen.
Dat maakt phishing-resistente authenticatie interessant voor meer dan alleen security-teams. Het is ook een strategische keuze voor productteams, UX-designers en developers die minder accountovernames, minder supporttickets en minder loginfrictie willen.
Passkeys uitgelegd: hoe ze werken en waarom ze veiliger zijn
Passkeys zijn in feite de gebruiksvriendelijke vorm van moderne, cryptografische authenticatie. De gebruiker hoeft geen wachtwoord meer te onthouden; het device regelt de login op basis van een sleutelpaar.
De belangrijkste eigenschap: de private key blijft veilig op het apparaat of in een beveiligde omgeving zoals een secure enclave of TPM, terwijl de server alleen de publieke sleutel opslaat. Tijdens het inloggen bewijst het device dat het de private key bezit, zonder die ooit prijs te geven. Volgens de WebAuthn-standaard zijn credentials bovendien origin-bound: een passkey voor een echt domein kan niet zomaar worden gebruikt op een phishingdomein.
https://www.w3.org/TR/webauthn-2/
https://fidoalliance.org/passkeys/
Dat verschil is groot. Bij een wachtwoord of OTP kan een gebruiker iets overtypen op een nepwebsite. Bij passkeys gebeurt dat niet op dezelfde manier: de authenticatie is gekoppeld aan de legitieme site, niet aan de kopie ervan. Daardoor wordt phishing niet alleen moeilijker, maar vaak gewoon ineffectief.
Een tweede voordeel is gebruiksgemak. Moderne passkeys zijn meestal multi-device credentials. Dat betekent dat ze niet beperkt zijn tot één fysieke sleutel, maar veilig kunnen synchroniseren tussen apparaten binnen ecosystemen van bijvoorbeeld Apple, Google of Microsoft. Dat vergroot de adoptie aanzienlijk, al vraagt het wel om goede recovery- en lifecycleprocessen:
https://developer.apple.com/passkeys/
https://developers.google.com/identity/passkeys
Passkeys zijn dus niet alleen “veiliger wachtwoorden”. Ze vertegenwoordigen een andere manier van authenticeren: zonder gedeeld geheim, met minder foutgevoeligheid en meer gemak voor de gebruiker.
FIDO2 en WebAuthn: de technische basis voor moderne login
Als passkeys de ervaring zijn, dan zijn FIDO2 en WebAuthn de technische fundering eronder.
WebAuthn is de webstandaard waarmee browsers en websites publieke-sleutel-authenticatie kunnen gebruiken. FIDO2 is het bredere ecosysteem van standaarden en specificaties dat deze aanpak mogelijk maakt. Samen vormen ze de basis voor phishing-resistente login in moderne webapps.
Technisch gezien werkt het als volgt:
- de server vraagt een credential aan;
- het device genereert of gebruikt een public-private key pair;
- de private key blijft lokaal;
- de publieke key gaat naar de server;
- bij een login challenge tekent het device de challenge;
- de server verifieert de handtekening.
Omdat de private key nooit wordt gedeeld, is er niets dat een aanvaller gemakkelijk kan stelen via een phishingpagina. En omdat de credential aan het domein is gebonden, helpt zelfs een overtuigende kloonwebsite niet.
Voor developers is dit belangrijk om goed te begrijpen: WebAuthn is niet slechts “een nieuwe login-API”, maar een compleet ander beveiligingsmodel. Dat betekent ook dat ontwerpkeuzes anders zijn. Recovery, account linking, enrollment, device replacement en fallback moeten vanaf het begin mee worden ontworpen — niet achteraf.
Voor een bredere uitleg en normatieve context zijn deze bronnen het meest relevant:
https://www.w3.org/TR/webauthn-2/
https://pages.nist.gov/800-63-3/sp800-63b.html
https://fidoalliance.org/
Biometrie in 2026: kansen, grenzen en privacyvragen
Biometrie roept vaak sterke reacties op. Voor de één voelt het futuristisch en prettig, voor de ander juist privacygevoelig. In de context van passkeys is het belangrijk om een nuance goed te begrijpen: biometrie wordt meestal niet gebruikt als centrale identificatiemethode, maar als lokale ontgrendeling van de private key op het device.
Dat betekent dat een vingerafdruk of gezichtsscan in veel implementaties niet naar de dienstverlener gaat. De biometrie bevestigt vooral: de eigenaar van dit apparaat wil de sleutel gebruiken. Dat is privacytechnisch een groot verschil met systemen waarbij biometrische templates centraal worden opgeslagen of verwerkt. Apple, Google en de FIDO Alliance leggen dat model expliciet uit in hun passkey-documentatie:
https://developer.apple.com/passkeys/
https://developers.google.com/identity/passkeys
https://fidoalliance.org/passkeys/
Toch is biometrie niet foutloos. Er zijn altijd foutmarges, vaak uitgedrukt als FAR en FRR: False Accept Rate en False Reject Rate. Apple meldt bijvoorbeeld dat Face ID een geschatte kans van ongeveer 1 op 1.000.000 heeft op een willekeurige match, tegenover ongeveer 1 op 50.000 voor Touch ID, met bekende uitzonderingen zoals identieke tweelingen en kinderen:
https://support.apple.com/en-us/102381
De belangrijkste conclusie is niet dat biometrie perfect is, maar dat het in passkey-flows vooral dient als een snelle, lokale en gebruiksvriendelijke ontgrendelmethode. Voor privacy is dat vaak beter dan een centrale biometrische database. Tegelijk vraagt het om heldere communicatie: gebruikers moeten begrijpen dat hun biometrie meestal niet naar jouw app wordt gestuurd, maar op hun apparaat blijft.
Daar zit ook een juridische laag aan. Onder de AVG geldt biometrische data die wordt gebruikt voor unieke identificatie als een bijzondere categorie persoonsgegevens:
https://gdpr-info.eu/art-9-gdpr/
Als jouw organisatie biometrische gegevens zelf verwerkt, komen daar dus strengere eisen bij kijken. In veel passkey-scenario’s voorkom je juist dat risico door de biometrie op het device te houden.
Implementatie in webapps: stappen voor developers en teams
Een veilige en bruikbare uitrol van passkeys vraagt meer dan alleen een technische integratie. Het is een combinatie van authenticatie-architectuur, productbeslissingen en goede UX.
De praktische volgorde ziet er vaak zo uit:
- Begin met een duidelijke adoptiestrategie. Bied passkeys aan als voorkeursoptie, maar forceer een harde breuk met bestaande loginmethoden niet te snel.
- Implementeer WebAuthn correct. Gebruik de officiële standaarden en test op meerdere browsers en platformen.
- Ontwerp recovery als first-class feature. Een sterke primaire login is pas waardevol als accountherstel niet de zwakke schakel wordt.
- Voorkom onveilige fallbackpaden. Een sterke passkey-flow helpt weinig als users via een kwetsbare helpdeskroute alsnog eenvoudig worden overgenomen.
- Zorg voor account linking en device replacement. Mensen wisselen apparaten; jouw systeem moet daar zonder frictie en zonder beveiligingslekken mee om kunnen gaan.
- Test op edge cases. Denk aan nieuwe apparaten, gedeelde devices, passkey-sync, verloren telefoons en organisaties met meerdere rollen of trust levels.
OWASP benadrukt al langer dat juist de recovery- en lifecyclekant veel organisaties in de problemen brengt:
https://cheatsheetseries.owasp.org/cheatsheets/AuthenticationCheatSheet.html
NIST is eveneens duidelijk dat sms geen voorkeursoptie meer is voor sterkere assurance-scenario’s:
https://pages.nist.gov/800-63-3/sp800-63b.html
Een goede implementatie is dus niet alleen: “We ondersteunen passkeys.”
Een goede implementatie is: “We hebben een complete identiteitservaring gebouwd waarin login, herstel, devicewissel en support allemaal veilig samen werken.”
Gebruikerspsychologie: veiligheid zonder extra frictie
Authenticatie is niet alleen techniek. Het is ook psychologie. Mensen willen zekerheid, maar niet ten koste van eindeloze stappen, code-invoer of verwarrende recoveryschermen.
Dat is een belangrijke reden waarom passkeys zo’n sterke kans maken. Ze combineren vaak twee dingen waar gebruikers van nature goed op reageren:
- minder frictie
- meer duidelijkheid
Onderzoek rondom checkout- en accountflows laat al jaren zien dat extra frictie direct leidt tot afhaken. Baymard publiceert al lang data over cart abandonment en wijst erop dat frictie in account- en checkoutflows een grote rol speelt:
https://baymard.com/lists/cart-abandonment-rate
De FIDO Alliance laat daarnaast herhaaldelijk zien dat gebruikers wachtwoorden ervaren als frustrerend: ze vergeten ze, hergebruiken ze en zien inloggen als een obstakel in plaats van een neutrale stap:
https://fidoalliance.org/tag/online-authentication-barometer/
Psychologisch werkt een simpele login vaak beter omdat de gebruiker minder mentale belasting ervaart. Er is minder twijfel, minder codezoekwerk, minder kans op fouten. De flow voelt moderner en gecontroleerder. Dat kan zelfs het veiligheidsgevoel verhogen, zolang de communicatie helder is. Als gebruikers begrijpen dat een passkey hun apparaat gebruikt als veilige sleutel, ontstaat vertrouwen in plaats van weerstand.
Voor teams betekent dit: schrijf geen security-copy die technisch indrukwekkend klinkt maar onduidelijk blijft. Leg in gewone taal uit wat er gebeurt, waarom het veiliger is en wat de gebruiker kan verwachten. Frictieloos betekent niet onzichtbaar; het betekent voorspelbaar, kort en begrijpelijk.
Veelgemaakte fouten en best practices voor een soepele uitrol
De meeste problemen rond moderne authenticatie ontstaan niet in de cryptografie zelf, maar in de implementatie en de randprocessen eromheen.
Veelgemaakte fouten zijn onder andere:
- Alle focus op de primaire login, weinig aandacht voor recovery
- Te agressief uitfaseren van bestaande loginmethoden
- Fallbacks die via e-mail of helpdesk alsnog makkelijk te misbruiken zijn
- Onduidelijke UX rond passkeys, waardoor gebruikers niet snappen wat er gebeurt
- Geen goede support voor multi-device scenario’s
- Te weinig testen op browser- en platformverschillen
- Biometrie presenteren alsof het centrale identificatie is, terwijl het vaak alleen een lokale unlock is
- Sms of OTP blijven zien als gelijkwaardig aan phishing-resistente authenticatie
De best practices zijn in grote lijnen simpel:
- Maak passkeys de standaardoptie, maar behoud een veilige migratieperiode.
- Behandel recovery als een beveiligingsfunctie, niet als supportdetail.
- Zorg voor heldere, korte en geruststellende UX-copy.
- Gebruik phishing-resistente authenticatie waar mogelijk als primaire route.
- Documenteer welk fallbackpad wanneer mag worden gebruikt.
- Meet adoptie, herstelacties en supportcases, zodat je kunt bijsturen.
- Houd rekening met privacy- en AVG-implicaties zodra biometrie of recoverydata centraal wordt verwerkt.
Een soepele uitrol is uiteindelijk een combinatie van vertrouwen, goede techniek en realistische operationalisatie. Het doel is niet alleen dat mensen kunnen inloggen, maar dat ze dat veilig, snel en zonder frustratie kunnen doen.
Conclusie
De toekomst van authenticatie draait niet alleen om sterkere beveiliging, maar om betere beveiliging die gebruikers daadwerkelijk willen gebruiken. Traditionele MFA blijft nuttig, maar is in 2026 niet meer voldoende tegen moderne phishing, AiTM-aanvallen en MFA-fatigue. Phishing-resistente authenticatie, met passkeys, FIDO2 en WebAuthn als kern, biedt een veel robuustere basis.
Biometrie speelt daarin een belangrijke rol, zolang je het begrijpt als lokale ontgrendeling in plaats van centrale identificatie. Voor ontwikkelaars ligt de uitdaging in een veilige end-to-end implementatie, inclusief recovery en lifecycle management. En voor productteams is de les misschien nog belangrijker: eenvoud en veiligheid hoeven elkaar niet in de weg te zitten. Sterker nog, als je het goed ontwerpt, versterken ze elkaar.
Wie in 2026 een serieuze digitale dienst bouwt, kan authenticatie niet langer zien als een bijzaak. Het is een kernonderdeel van security, UX, vertrouwen en conversie.