Waarom dit voor mission-critical software extra weegt
Wij bouwen software voor klanten waar uitval van beschikbaarheid geen optie is. Een incident management-platform voor de Nederlandse snelwegen. Een digitale betaaloplossing. Een community-app met honderdduizenden actieve gebruikers wereldwijd.
Een concreet voorbeeld uit ons werkgebied: operators die buiten werken en op gedeelde tablets moeten inloggen, vaak onder tijdsdruk. In zo’n situatie werkt een traditioneel wachtwoord simpelweg niet. Niemand wil langs de weg met koude handen een ingewikkeld wachtwoord invoeren. Daarom koppelen moderne applicaties een gebruiker veilig aan een vertrouwd toestel en controleren ze continu of de situatie klopt. Logt iemand in vanaf het juiste apparaat, op de juiste locatie en op het gebruikelijke moment, dan gaat toegang snel en soepel. Wijkt er iets af, bijvoorbeeld een ander toestel of een onverwachte locatie? Dan vraagt het systeem automatisch om extra verificatie. Goede beveiliging staat daarbij niet los van gebruiksgemak. Het ís onderdeel van de gebruikerservaring.
Bij moderne software draait authenticatie meestal om drie dingen:
Veiligheid: spreekt voor zich. In kritische applicaties kan een gecompromitteerd account grote operationele en juridische gevolgen hebben. Regelgeving zoals NIS2 stelt daarom steeds strengere eisen aan authenticatie.
Gebruiksgemak: de login-ervaring bepaalt voor een groot deel hoe prettig software werkt. Hoe vaker gebruikers vastlopen op wachtwoorden of resets, hoe groter de kans dat ze afhaken. Iedereen kent het: wachtwoord vergeten, mail openen, resetlink aanvragen, opnieuw inloggen. Dat voelt niet als beveiliging, maar als frictie.
Beheer: wie zelf een wachtwoordsysteem bouwt, blijft verantwoordelijk voor beveiliging, resets en updates. Door te werken met passkeys of een identity provider verschuift dat beheer naar partijen die daar volledig in gespecialiseerd zijn.
Account recovery: het onderwerp dat altijd wordt overgeslagen
De eerlijke kanttekening bij elk passwordless-verhaal: account recovery is moeilijker dan een e-mail-flow met een herstellink. Verliest een gebruiker zijn telefoon, dan moet er iets anders bestaan om hem terug binnen te krijgen zonder dat dát alternatieve pad zelf de zwakste schakel wordt.
In de praktijk betekent dat drie dingen.
Passkeys synchroniseren over devices via de keychain van de gebruiker, zodat het verlies van één toestel geen lock-out is.
Voor zakelijke contexten een tweede vertrouwd device of een hardware-key als backup.
Voor de uitzonderingsgevallen een bewuste, vertraagde recovery-flow met identiteitsverificatie en niet een simpele e-maillink, want dan ben je terug bij waar je vandaan kwam.
Wie passwordless invoert zonder een doordachte recovery-strategie levert geen veiliger systeem op, alleen een systeem dat meer ergernis en frustratie oplevert.
Drie belangrijke vragen over authenticatie bij een nieuwe oplossing
Voor we ook maar één regel code voor de authenticatie schrijven:
Hebben we hier eigenlijk een wachtwoord voor nodig? In de meeste gevallen is het antwoord nee, of niet als primair pad.
Welke context bepaalt het risico? Een veldwerker op een gedeelde tablet heeft een ander auth-pad nodig dan een back-officemedewerker met een persoonlijke laptop. Adaptive auth zonder die context is alleen maar duur.
Wat gebeurt er over vijf jaar? Wat we vandaag opleveren draait over 10 jaar nog steeds. De auth-laag moet meebewegen met passkey-adoptie, nieuwe regelgeving en device-types die vandaag nog niet bestaan.
AI-agents vragen om een nieuwe vorm van authenticatie
De volgende stap in authenticatie draait niet meer alleen om mensen, maar ook om AI-agents. Denk aan een AI die namens een gebruiker e-mails leest, agenda’s beheert of acties uitvoert. Zo’n agent logt niet in met een wachtwoord of passkey, maar krijgt gecontroleerd toegang tot specifieke onderdelen van een systeem.
Dat vraagt om een andere aanpak van beveiliging. AI-agents moeten alleen toegang krijgen tot wat strikt nodig is, voor een beperkte tijd en met volledige controle achteraf. Daarom ontwerpen we moderne platformen met aparte rechten, audit-trails en extra goedkeuring voor gevoelige acties.
Wat vandaag nog uitzonderlijk lijkt, wordt snel de standaard: steeds meer verkeer binnen applicaties is straks afkomstig van software die namens gebruikers handelt.
Tot slot
World Password Day blijft een nuttige aanleiding, niet om een sterker wachtwoord te bedenken, maar om je af te vragen of een wachtwoord in jouw applicatie überhaupt nog bestaansrecht heeft. Elke applicatie die in 2026 wordt opgeleverd zonder serieus over passwordless authenticatie te zijn nagedacht, levert vandaag al de technical debt van morgen op.
Benieuwd naar de mogelijkheden voor jouw organisatie?
