Wat is WebAuthn? Definitie, voorbeelden & best practices

WebAuthn is de W3C-standaard voor wachtwoordloze, phishingbestendige authenticatie. Lees hoe het werkt, veelvoorkomende implementatiefouten en best practices voor ondernemingen.

Wat is WebAuthn?

Wachtwoorden falen. Ze worden gephisht, gestufft, gesprayd en gedumpt. Verizon’s 2026 Data Breach Investigations Report (DBIR) vond misbruik van inloggegevens terug in 39% van alle datalekken, de meest voorkomende techniek in de dataset. Daarom geven verdedigers prioriteit aan maatregelen die wachtwoorden uit het inlogpad verwijderen. WebAuthn is de standaard van het World Wide Web Consortium (W3C) die precies daarvoor is ontwikkeld.

WebAuthn, kort voor Web Authentication, is een W3C-webstandaard die een browser-API definieert voor het aanmaken en gebruiken van sterke, op publieke sleutels gebaseerde inloggegevens om gebruikers te authenticeren bij webapplicaties. In plaats van gedeelde geheimen zoals wachtwoorden uit te wisselen, gebruikt WebAuthn asymmetrische cryptografie: uw authenticator genereert per site een uniek sleutelpaar, bewaart de privésleutel vergrendeld in beveiligde hardware en deelt alleen de publieke sleutel met de server.

De W3C-specificatie definieert het formeel als "een API die het aanmaken en gebruiken mogelijk maakt van sterke, geattesteerde, afgebakende, op publieke sleutels gebaseerde inloggegevens door webapplicaties, met als doel gebruikers sterk te authenticeren." In de praktijk betekent dit dat u kunt inloggen op webapplicaties met een vingerafdrukscan, gezichtsontgrendeling of een fysieke beveiligingssleutel, en dat de server nooit iets ontvangt dat een aanvaller opnieuw zou kunnen gebruiken.

WebAuthn is een kerncomponent van het FIDO2-project, ontwikkeld in coördinatie met de Fast Identity Online (FIDO) Alliance. FIDO2 koppelt WebAuthn (de browser-API-laag) aan CTAP (Client to Authenticator Protocol), dat de communicatie afhandelt tussen uw authenticatorapparaat en de browser via USB, near-field communication (NFC) of Bluetooth Low Energy (BLE). Samen vormen ze de basis voor wachtwoordloze en phishingbestendige authenticatie op het web.

Twee incidenten laten zien wat het wachtwoordmodel op schaal kost. In 2021 kregen aanvallers toegang tot Colonial Pipeline via een verouderd virtual private network (VPN)-profiel dat niet bedoeld was om in gebruik te zijn, zoals de CEO van het bedrijf tegen de U.S. Senate zei. Colonial legde de pijpleiding stil om de aanval in te dammen en betaalde $4,4 miljoen losgeld aan een DarkSide-filiaal, de ransomware-operatie die werd behandeld in een CISA-advies. Het Department of Justice nam later $2,3 miljoen daarvan in beslag. In 2023 meldde MGM Resorts een geschatte negatieve financiële impact van $100 miljoen door een cyberincident dat begon met social engineering tegen identiteitsworkflows, volgens een 8-K uit oktober 2023. Beide incidenten draaiden om een herbruikbaar geheim. WebAuthn verwijdert dat uit het inlogpad.

WebAuthn versus traditionele authenticatie

Traditionele authenticatie vertrouwt op gedeelde geheimen. Wachtwoorden, eenmalige codes en push-goedkeuringen verzenden allemaal gegevens die een aanvaller kan onderscheppen, herhalen of in realtime kan phishen. WebAuthn verandert het model door gedeelde geheimen te vervangen door publieke-sleutel-cryptografie, waarbij de privésleutel uw authenticatorhardware nooit verlaat en er niets herbruikbaars over het netwerk gaat.

De verschillen zijn het belangrijkst op de punten waar traditionele methoden tekortschieten:

• Phishingbestendigheid. Authenticatie op basis van wachtwoorden en OTP’s kan worden onderschept door realtime phishingproxy’s. WebAuthn-inloggegevens zijn cryptografisch gebonden aan het oorsprongsdomein, dus een inloggegeven dat is geregistreerd op login.example.com zal niet authenticeren tegen login-example.com of een ander lookalike-domein. De browser dwingt dit af op protocolniveau, onafhankelijk van het oordeel van de gebruiker.
• Server-side blootstelling. Traditionele systemen slaan wachtwoordhashes of gedeelde geheimen op die waardevolle doelwitten worden bij datalekken in databases. WebAuthn slaat alleen publieke sleutels op. Een volledige servercompromittering geeft een aanvaller niets waarmee die zich als een gebruiker kan voordoen.
• Hergebruik van inloggegevens. Gebruikers hergebruiken wachtwoorden over verschillende diensten heen, wat credential stuffing op schaal effectief maakt. WebAuthn genereert per relying party een uniek sleutelpaar, waardoor een gecompromitteerd inloggegeven bij de ene dienst geen enkele waarde heeft bij een andere.
• Afweging tussen gebruikersfrictie en beveiliging. Langere wachtwoorden en frequente rotatie verbeteren op papier de beveiliging, maar verslechteren de bruikbaarheid. WebAuthn neemt die afweging weg: een vingerafdrukscan of gezichtsontgrendeling biedt sterkere authenticatiegarantie dan welk wachtwoordbeleid dan ook, met minder frictie voor de gebruiker.

Het netto-effect is dat WebAuthn de drie vectoren elimineert die verantwoordelijk zijn voor de meeste inbreuken op basis van inloggegevens: phishing, diefstal aan serverzijde en hergebruik tussen sites. Inzicht in deze verschillen legt de basis voor hoe de componenten van het protocol deze eigenschappen afdwingen.

Belangrijke componenten van WebAuthn

WebAuthn werkt op basis van een architectuur met drie partijen, gedefinieerd door de W3C-specificatie.

Authenticator: Dit is de cryptografische entiteit die sleutelparen genereert en authenticatie-asserties ondertekent. Authenticators vallen in twee categorieën:

• Platformauthenticators zijn ingebouwd in het besturingssysteem van uw apparaat: Windows Hello, Touch ID, Face ID. Ze worden met vrijwel geen frictie geregistreerd, maar gaan verloren als het apparaat verloren gaat.
• Roaming (cross-platform) authenticators zijn draagbare hardwareapparaten zoals YubiKeys en FIDO-beveiligingssleutels. Ze werken op meerdere apparaten, maar vereisen fysieke distributie en voorraadbeheer.

Welk type u ook kiest, het beveiligingsmodel blijft hetzelfde: de authenticator maakt per relying party een uniek sleutelpaar aan en de privésleutel verlaat nooit de beveiligde grens van de authenticator.

Relying Party (RP): Dit is uw webapplicatie: client-side JavaScript dat de WebAuthn-API aanroept plus een server-side component die opslag en verificatie van inloggegevens afhandelt. De RP slaat alleen de publieke sleutel op. De RP ID, doorgaans uw domeinnaam, dient als cryptografisch anker voor origin binding.

User Agent (browser): De browser bemiddelt bij alle interacties tussen authenticators en relying parties. Hij dwingt origin-beleid af, voorkomt misbruik van inloggegevens over domeinen heen en beschermt de privacy van gebruikers: inloggegevens die bij één origin zijn geregistreerd, kunnen niet door een andere worden gebruikt, en dat is wat phishing op protocolniveau stopt.

WebAuthn definieert ook een attestation framework waarmee authenticators tijdens registratie cryptografisch hun authenticiteit kunnen bewijzen. Uw organisatie kan dan verifiëren dat inloggegevens afkomstig zijn van vertrouwde, door IT goedgekeurde authenticatormodellen in plaats van onbekende of consumentgerichte apparaten. De FIDO Metadata Service biedt een live mechanisme voor intrekking en advisering voor authenticatormodellen.

Zodra u de actoren en vertrouwensgrenzen kent, kunt u de twee ceremonies in kaart brengen en precies zien waar verificatie kan mislukken.

Hoe WebAuthn werkt

WebAuthn definieert twee cryptografische ceremonies: registratie (aanmaken van inloggegevens) en authenticatie (verificatie van asserties). Beide volgen een challenge-responseprotocol.

1. Registratie (aanmaken van inloggegevens): Uw server genereert een cryptografisch willekeurige challenge en stuurt die naar de client samen met informatie over de relying party, gebruikersaccountgegevens en acceptabele cryptografische algoritmen. De client roept navigator.credentials.create() aan. De authenticator vraagt om expliciete toestemming van de gebruiker, genereert een nieuw asymmetrisch sleutelpaar en retourneert een attestation-object met daarin de publieke sleutel, ondertekende challenge, credential ID en (optioneel) een attestation-certificaatketen. Uw server verifieert de attestation, valideert de handtekening, bevestigt dat de publieke sleutel overeenkomt met de gevraagde algoritmen en slaat de publieke sleutel van het inloggegeven, de credential ID en de handtekeningsteller op. Kritieke beveiliging: zelfs met identieke parameters genereert navigator.credentials.create() bij elke aanroep een nieuw inloggegeven. U moet de excludeCredentials-parameter gebruiken om dubbele registraties te voorkomen.
2. Authenticatie (verificatie van asserties): Uw server genereert een nieuwe challenge en stuurt die naar de client met een lijst van toegestane credential ID’s. De client roept navigator.credentials.get() aan. De authenticator verifieert de aanwezigheid of identiteit van de gebruiker (afhankelijk van uw beleid) en ondertekent vervolgens de challenge met de opgeslagen privésleutel. Uw server haalt de opgeslagen publieke sleutel op, verifieert de handtekening van de assertie, valideert de overeenkomst van de challenge, controleert de vlaggen voor gebruikersaanwezigheid/-verificatie, bevestigt dat de origin en RP ID overeenkomen en verifieert dat de handtekeningsteller is verhoogd.

De verificatie van de handtekeningsteller is uw verdediging tegen gekloonde authenticators. Als de teller niet toeneemt zoals verwacht, hebt u bewijs van duplicatie van inloggegevens.

Voor AAL2-naleving moet u User Verification (UV) afdwingen, niet alleen User Presence (UP). Volgens de richtlijnen voor syncbare authenticators moeten verifiers aangeven dat UV de voorkeur heeft en reacties inspecteren om te bevestigen dat de UV-vlag is ingesteld.

Hoe organisaties WebAuthn implementeren

Zien waar WebAuthn in productie draait, beantwoordt de vraag die de meeste beoordelaars daadwerkelijk stellen: is dit op schaal bewezen?

• Google Accounts is de duidelijkste benchmark. Google begon in mei 2023 met de uitrol van passkeys en maakte ze de standaard voor persoonlijke accounts in oktober 2023. Binnen een jaar na de lancering waren passkeys meer dan één miljard keer gebruikt op meer dan 400 miljoen accounts, en Google meldde dat passkeys dagelijks al vaker voor authenticatie werden gebruikt dan SMS OTP en authenticator-apps samen.
• GitHub noemde WebAuthn de sterkste beschikbare 2FA-optie toen het 2FA in 2023 verplicht stelde voor alle bijdragers, en noemde fysieke beveiligingssleutels en platformauthenticators zoals Windows Hello en Face ID de methoden die het minst kwetsbaar zijn voor phishing.
• Commerciële platforms zijn gevolgd: Amazon, PayPal, Shopify, DocuSign en Kayak, dat de gemiddelde tijd voor aanmelden en inloggen met 50% verminderde, hebben allemaal inloggen ondersteund door WebAuthn uitgerold. Deze implementaties bevestigen dat WebAuthn presteert op consumentenschaal, herstelworkflows afhandelt en integreert met standaardarchitecturen van identity providers.

Nu de ceremonies en implementaties in de praktijk duidelijk zijn, is de volgende beslissing welk type authenticator bij uw omgeving past.

Typen WebAuthn-authenticators

Uw keuze voor een authenticator bepaalt het niveau van beveiligingsgarantie, de gebruikerservaring en de operationele overhead van uw WebAuthn-implementatie. Elk type brengt specifieke afwegingen met zich mee die belangrijk zijn voor enterpriseplanning.

1. Platformauthenticators zijn ingebed in het besturingssysteem en de hardware van het apparaat. Windows Hello gebruikt een door Trusted Platform Module (TPM) ondersteunde pincode, gezichtsherkenning of vingerafdruk. Apple-apparaten gebruiken Touch ID of Face ID ondersteund door de Secure Enclave. Android-apparaten gebruiken vingerafdruk of gezichtsontgrendeling via Google Play Services. Platformauthenticators 1carry de laagste registratiefictie omdat gebruikers de hardware al hebben, en biometrische verificatie voldoet aan de vereisten voor user verification (UV) voor AAL2-naleving zonder extra stappen. De beperking is dat inloggegevens aan het apparaat zijn gekoppeld. Als een gebruiker zijn laptop of telefoon verliest, zijn die inloggegevens weg, tenzij u gesynchroniseerde passkeys gebruikt.
2. Roaming (cross-platform) authenticators zijn draagbare hardwaretokens, zoals YubiKeys, Feitian BioPass-sleutels of andere FIDO2-beveiligingssleutels, die verbinding maken via USB, NFC of BLE. Ze werken op meerdere apparaten en besturingssystemen, waardoor ze de standaardkeuze zijn voor bevoorrechte toegang, omgevingen met gedeelde werkstations en use cases met hoge zekerheid. De afweging zit in de distributielogistiek: u moet fysieke apparaten inkopen, verzenden, inventariseren en beheren, en gebruikers moeten ze bij zich dragen.
3. Gesynchroniseerde passkeys zijn een nieuwere categorie waarbij WebAuthn-inloggegevens synchroniseren via een platformwachtwoordmanager (iCloud Keychain, Google Password Manager of een externe manager zoals 1Password). Gesynchroniseerde passkeys verminderen het herstelprobleem bij verlies van een apparaat omdat het inloggegeven beschikbaar blijft op elk apparaat dat met hetzelfde account is verbonden. Voor de meeste enterprisegebruikers neemt dit het grootste frictiepunt weg bij de adoptie van WebAuthn. De afweging is dat de beveiliging van uw authenticatie nu gedeeltelijk afhangt van de beveiliging van het platformaccount dat het gesynchroniseerde inloggegeven host. Voor omgevingen met hoge zekerheid blijven apparaatgebonden inloggegevens met door IT beheerde back-upsleutels de sterkere keuze.

De meeste enterprise-implementaties gebruiken een combinatie: platformauthenticators voor dagelijks gebruik, een roaming-sleutel als geregistreerde back-up en gesynchroniseerde passkeys waar het risicoprofiel dat toelaat. Het kiezen van de juiste mix hangt af van uw assurance-eisen, uw gebruikerspopulatie en hoeveel operationele overhead u kunt opvangen.

De keuze voor de authenticator beïnvloedt direct welke beveiligingseigenschappen u krijgt, en dat is wat de volgende sectie behandelt.

Beveiligingsvoordelen van WebAuthn

WebAuthn levert concrete beveiligingsvoordelen op het gebied van phishingbestendigheid, server-side blootstelling, naleving van regelgeving en preventie van cross-site-aanvallen:

• Phishingbestendigheid op protocolniveau. WebAuthn bindt inloggegevens cryptografisch aan de origin. De FIDO Alliance NIST-opmerking waarschuwde dat aanvallers AAL2-authenticators die niet phishingbestendig zijn inmiddels hebben ingehaald. WebAuthn dicht dat gat.
• Geen gedeelde geheimen op de server.Het publieke-sleutelcryptografiemodel van FIDO2 neemt de noodzaak weg om geheimen te delen tussen de identity provider en de authenticator, wat NIST SP 800-63B-4 verifier compromise resistance noemt. Een volledig datalek in een database levert niets op dat een aanvaller kan herhalen.
• Afstemming op regelgeving. WebAuthn voldoet aan de phishingbestendige vereisten van NIST SP 800-63B-4 AAL2. Het Memorandum M-22-09 van het Office of Management and Budget (OMB) van de Amerikaanse overheid noemt de W3C Web Authentication-standaard expliciet als phishingbestendige aanpak voor federale instanties. Gereguleerde organisaties krijgen een duidelijk, controleerbaar nalevingspad.
• Eliminatie van aanvallen op de menselijke factor. De 2026 Verizon DBIR   plaatste de menselijke factor in 62% van de datalekken. WebAuthn verwijdert twee kritieke menselijke aanvalsvlakken: zwakke wachtwoordkeuze en vatbaarheid voor phishing. Gebruikers kunnen geen slechte wachtwoorden kiezen als er geen wachtwoorden zijn.
• Preventie van cross-site credential stuffing. Elk inloggegeven is cryptografisch afgebakend tot een specifiek domein, waardoor credential stuffing tussen diensten veel minder effectief wordt.

Die beveiligingseigenschappen zijn niet theoretisch. Organisaties die WebAuthn op schaal hebben geïmplementeerd, hebben ze al in productie gevalideerd, en de use cases bestrijken vrijwel elke branche.

Veelvoorkomende use cases voor WebAuthn

De adoptie van WebAuthn is geconcentreerd in scenario’s waarin aanvallen op basis van inloggegevens de grootste zakelijke impact hebben. Dit zijn de implementatiepatronen die het vaakst voorkomen in productieomgevingen.

• Bevoorrechte toegang en admin consoles. VPN-portalen, cloudbeheerconsoles en infrastructuurbeheerpanelen zijn de meest waardevolle doelwitten voor diefstal van inloggegevens. Het implementeren van WebAuthn als verplichte tweede factor, of als primaire wachtwoordloze methode, voor deze toegangspunten verwijdert het aanvalsvlak dat phishingkits en credential dumps het agressiefst uitbuiten. Dit is doorgaans de eerste fase in elke enterprise-uitrol.
• Klantgerichte login voor financiële dienstverlening en gezondheidszorg. Gereguleerde sectoren waar compromittering van inloggegevens leidt tot meldingen van datalekken, boetes van toezichthouders en direct financieel verlies, adopteren passkeys voor klantauthenticatie. Bankapplicaties, patiëntenportalen en verzekeringsplatforms gebruiken WebAuthn om zowel aan nalevingseisen (PCI DSS, HIPAA-toegangscontroles) te voldoen als aan het operationele doel om fraude door accountovernames te verminderen.
• Omgevingen met gedeelde werkstations en kiosken. Ziekenhuizen, productievloeren en retailactiviteiten gebruiken gedeelde terminals waar inloggen met wachtwoorden traag is en gevoelig voor meekijken over de schouder. Roaming authenticators (NFC-geschikte beveiligingssleutels of badge-tap-oplossingen) authenticeren gebruikers in seconden zonder dat er inloggegevens op een gedeeld apparaat worden ingevoerd.
• Single sign-on (SSO) voor medewerkers. Het implementeren van WebAuthn op het niveau van de identity provider (IdP), via platforms zoals Okta, Azure AD of Ping Identity, beschermt elke onderliggende applicatie in een gefedereerde omgeving met één enkele registratie. Dit is de meest efficiënte route naar brede dekking, omdat u WebAuthn één keer bij de IdP implementeert en elke relying party voor Security Assertion Markup Language (SAML) of OpenID Connect (OIDC) de phishingbestendige authenticatie erft.

Elk van deze use cases versterkt hetzelfde principe: hoe dichter u bij het elimineren van herbruikbare geheimen uit uw authenticatiestroom komt, hoe minder aanvalspaden op basis van inloggegevens open blijven. Dat gezegd hebbende, brengt het implementeren van WebAuthn op schaal operationele complexiteit met zich mee waarvoor teams moeten plannen.

Uitdagingen en beperkingen van WebAuthn

Het beveiligingsmodel van WebAuthn is solide, maar enterprise-implementaties brengen operationele complexiteit aan het licht die teams consequent onderschatten:

• Beheer van de levenscyclus van inloggegevens. De primaire faalmodus in enterprise WebAuthn-implementaties is operationeel, niet cryptografisch. U hebt gedocumenteerde processen nodig voor distributie van authenticators, intrekking van inloggegevens bij verlies van apparaten, vernieuwingsbeleid en gebruikersondersteuning bij authenticatiefouten. De FIDO-richtlijnen voor levenscyclusbeheer behandelen registratie-, herstel- en intrekkingsfasen in detail.
• Selectie van het authenticatortype. U staat voor een strategische keuze tussen platformauthenticators (geen distributiekosten, verloren met het apparaat), roaming authenticators (draagbaar maar fysieke distributie vereist) en hybride benaderingen. Elk brengt verschillende assurance-niveaus, herstelvereisten en operationele overhead met zich mee.
• Integratie met legacyapplicaties. Niet elke applicatie in uw omgeving ondersteunt WebAuthn van nature. U moet integratie aanpakken met federatieprotocollen zoals SAML, OAuth en OpenID Connect. Dit is een aanzienlijke uitdaging voor organisaties met complexe topologieën voor identiteitsfederatie.
• Architectuurbeslissingen voor FIDO-servers. U moet kiezen tussen het integreren van een FIDO-server in uw bestaande identity provider, het implementeren van een zelfstandige FIDO-server of het gebruik van een FIDO-server-as-a-service-model. Elk heeft invloed op de architectuur voor opslag van inloggegevens, procedures voor disaster recovery en de omvang van de uitrol. De implementatiegids voor FIDO-servers behandelt de afwegingen in detail.
• De afweging van gesynchroniseerde inloggegevens. Synchronisatie van passkeys via grote platformwachtwoordmanagers vermindert gebruikersfrictie drastisch, maar verplaatst een deel van de authenticatiebeveiliging naar de beveiliging van het platformaccount. Waar assurance-eisen het hoogst zijn, blijven apparaatgebonden inloggegevens met door IT beheerde back-upsleutels de sterkere keuze.

Naast operationele complexiteit creëren specifieke implementatiebeslissingen langdurigere blootstelling:

• Alle MFA behandelen als phishingbestendig. Dit is de fout met de grootste impact. Het implementeren van TOTP, SMS OTP of pushnotificatie-MFA en vervolgens claimen dat u phishingbestendige naleving hebt, laat u blootgesteld. Realtime phishingproxy’s onderscheppen en herhalen beide factoren in deze benaderingen. Alleen WebAuthn met verifier name binding of channel binding bereikt echte phishingbestendigheid.
• Niet-geauthenticeerde registratie van inloggegevens toestaan. CVE-2021-3632 liet dit zien in Keycloak, waar iedereen een nieuw beveiligingsapparaat kon registreren wanneer er geen apparaat bestond voor een gebruikersaccount. Registratie moet plaatsvinden binnen een reeds geauthenticeerde sessie of via geverifieerde out-of-band-processen.
• Slecht ontwerp van de registratiestroom. Omslachtige registratie creëert weerstand bij gebruikers en verhoogt het aantal supporttickets. Uw registratieportaal moet gebruikers door de registratie leiden binnen een geauthenticeerde sessie, duidelijke instructies geven over acceptabele authenticators en uitleggen waarom specifieke apparaten zijn afgewezen.
• Ontbrekende fallback- en herstelmechanismen. Het implementeren van WebAuthn zonder gedocumenteerde fallbackprocedures voor verlies van apparaten, hardwarestoringen of biometrische problemen creëert lock-outscenario’s. U hebt vooraf geregistreerde back-upauthenticators, noodtoegangscodes voor IT-beheerders en processen voor verificatie in persoon nodig.
• WebAuthn geïsoleerd van uw securitystack implementeren. WebAuthn is geen op zichzelf staande oplossing. Volgens NIST SP 1800-35 moet het integreren met continue evaluatie van authenticatie, verificatie van apparaatstatus, contextbewuste toegangsbeleidsregels en uw endpoint security-infrastructuur. In een zero trust-architectuur wordt WebAuthn een van de sterkste signalen die u kunt meenemen in toegangsbeslissingen.

Deze uitdagingen zijn oplosbaar met de juiste planning. De volgende praktijken behandelen de belangrijkste beslissingen die een productieklare implementatie onderscheiden van een proof of concept.

Best practices voor het implementeren van WebAuthn

De volgende praktijken behandelen de belangrijkste beslissingen die een productieklare WebAuthn-implementatie onderscheiden van een proof of concept.

Dwing user verification af voor AAL2. Stel userVerification: "required" in voor zowel registratie- als authenticatieceremonies en valideer de UV-vlag aan serverzijde. Vertrouw niet op "preferred" voor implementaties binnen een nalevingsscope.

Gebruik attestation om authenticatiebeleid af te dwingen. Controleer attestations tijdens registratie en sta alleen authenticators toe die aan uw beveiligingseisen voldoen (bijvoorbeeld FIDO L1+-certificering). Gebruik op AAGUID (identificatie van authenticatormodel) gebaseerde allowlists en integreer met de FIDO Metadata Service voor live statuscontroles van authenticators.

Implementeer gefaseerd. De aanbeveling voor gefaseerde FIDO-uitrol is een stapsgewijze aanpak:

1. WebAuthn als tweede factor voor applicaties met hoog risico (VPN, bevoorrechte toegang, beheerconsoles)
2. Platformbrede uitrol van WebAuthn als tweede factor terwijl operationele ondersteuning wordt opgebouwd
3. Discoverable credentials en wachtwoordloze stromen voor volwassen gebruikerspopulaties
4. Volledig wachtwoordloos, waarbij legacy-authenticatie voor geregistreerde gebruikers is uitgefaseerd

Met deze aanpak kunt u beleid, ondersteuning en herstelworkflows valideren voordat u WebAuthn de standaard maakt.

Implementeer een herstelstrategie met meerdere authenticators. Registreer ten minste twee authenticators per gebruiker: een primaire (bijvoorbeeld platformauthenticator voor dagelijks gebruik) en een back-up (bijvoorbeeld een veilig opgeslagen beveiligingssleutel). Toon geregistreerde herstelinloggegevens duidelijk in de accountinstellingen van de gebruiker.

Verifieer handtekeningstellers. Controleer dat de handtekeningsteller bij elke authenticatie monotoon toeneemt. Een teller die niet toeneemt, duidt op een mogelijk gekloonde authenticator.

Scheid verwachte van onverwachte fouten. Houd WebAuthn-fouten expliciet bij. Groepeer NotAllowedError, AbortError en passkey-fouten van Credential Manager als afzonderlijke signalen, zodat u gebruikersfrictie kunt onderscheiden van beveiligingsafwijkingen.

Door deze praktijken te volgen, brengt u uw WebAuthn-implementatie naar een productieklare staat. Maar zelfs een correct geconfigureerde WebAuthn-uitrol is geen volledige identiteitsverdediging. De aanvallen die WebAuthn volledig omzeilen, vereisen maatregelen die verder gaan dan de inlogceremonie: sessiekaping, laterale beweging na authenticatie en social engineering via de helpdesk.

Hoe SentinelOne identiteitsbeveiliging versterkt

WebAuthn vermindert het herhalen van inloggegevens, maar stopt niet elke aanval op het identiteitspad die u in productie zult zien. U moet nog steeds omgaan met diefstal van sessietokens, compromittering van apparaten, social engineering via de helpdesk en laterale beweging na authenticatie.

Het Singularity™ Platform dicht dat gat door identiteit- en endpointcontext te correleren:

• Singularity Identity vindt verdacht identiteitsgedrag en reageert wanneer tegenstanders directory services en SSO-workflows aanvallen. Het dekt de identiteitsinfrastructuur die WebAuthn nooit raakt.
• Singularity Endpoint voert gedrags- en statische AI-modellen uit op het apparaat om malware voor diefstal van inloggegevens en hands-on-keyboard-activiteit te stoppen die inlogcontroles volledig omzeilt. Het markeert kwaadaardige patronen in realtime zonder menselijke tussenkomst, wat belangrijk is wanneer aanvallers sessies aanvallen in plaats van wachtwoorden.
• Purple AI™ redeneert over uw beveiligingsgegevens heen om onderzoeken te begeleiden en volgende acties aan te bevelen. Een 2025 IDC Snapshot liet zien dat klanten bedreigingen 63% sneller identificeren, wat belangrijk is wanneer u moet bepalen of een mislukte WebAuthn-login gebruikersfrictie was of een actieve phishingcampagne.

Samen houden ze het identiteitsaanvalspad aan beide kanten van de login onder controle.

Als u WebAuthn behandelt als één sterk signaal binnen uw bredere phishingverdedigingsprogramma en incidentresponsworkflow, kunt u zowel het risico op accountovernames als de tijd die u besteedt aan het bewijzen van wat er is gebeurd verminderen.

Vraag een demo aan om te zien hoe SentinelOne de kloof dicht tussen authenticatie en volledige identiteitsverdediging.

Bekijk de rondleiding

Krijg realtime identiteitsbescherming en end-to-end zichtbaarheid in hybride omgevingen om blootstellingen te detecteren, misbruik van inloggegevens te stoppen en identiteitsrisico te verminderen.

Belangrijkste punten

WebAuthn is de W3C-standaard voor wachtwoordloze, phishingbestendige webauthenticatie met publieke-sleutelcryptografie. Het bindt inloggegevens cryptografisch aan specifieke domeinen, waardoor het herhalen van inloggegevens architectonisch onmogelijk wordt. 

Succesvolle enterprise-implementatie vereist een gefaseerde uitrol, op attestation gebaseerd authenticatiebeleid, herstelstrategieën voor meerdere apparaten en integratie met uw bredere securitystack.

Veelgestelde vragen

Wat is WebAuthn in cybersecurity?

WebAuthn, kort voor Web Authentication, is een W3C-webstandaard die een browser-API definieert voor het maken en gebruiken van sterke, op publieke sleutels gebaseerde inloggegevens om gebruikers te authenticeren bij webapplicaties. 

In plaats van wachtwoorden gebruikt het asymmetrische cryptografie: uw authenticator genereert een uniek sleutelpaar per site, bewaart de privésleutel in beveiligde hardware en deelt alleen de publieke sleutel met de server. Dit maakt diefstal van inloggegevens en phishingaanvallen veel moeilijker om uit te voeren.

Welke aanvallen voorkomt WebAuthn?

De primaire beveiligingseigenschap van WebAuthn is phishingbestendigheid via cryptografische domeinbinding. Wanneer u een referentie registreert, wordt deze gebonden aan de exacte oorsprong van de relying party. Wanneer u zich authenticeert, neemt de browser die oorsprong cryptografisch op in het ondertekende antwoord, zodat een aanvaller op een domein dat erop lijkt uw referentie niet kan hergebruiken. 

Naast phishing elimineert WebAuthn diefstal van referenties aan de serverzijde omdat alleen openbare sleutels worden opgeslagen, en het stopt credential stuffing omdat elke referentie is beperkt tot één enkel domein.

Is WebAuthn hetzelfde als FIDO2?

WebAuthn en FIDO2 zijn verwant, maar niet identiek. FIDO2 is het bredere project, ontwikkeld door de FIDO Alliance in samenwerking met het W3C, dat twee specificaties combineert: WebAuthn (de browser-API voor het aanmaken en verifiëren van public-keyreferenties) en CTAP (Client to Authenticator Protocol, dat de communicatie afhandelt tussen uw authenticator en de browser via USB, NFC of BLE). 

WebAuthn is de webgerichte helft van FIDO2. U implementeert WebAuthn in uw applicatie. CTAP draait tussen de authenticatiehardware en de browser.

Hoe ondersteunt WebAuthn Zero Trust-beveiliging?

WebAuthn biedt een van de sterkste authenticatiesignalen in een zero trust architecture. Volgens NIST SP 1800-35 integreert het met continue evaluatie van authenticatie, verificatie van apparaatstatus en contextbewuste toegangsbeleidsregels. Omdat WebAuthn-inloggegevens phishingbestendig en domeingebonden zijn, dienen ze als een identiteitsverificatiestap met hoge zekerheid die input levert voor bredere toegangsbeslissingen. 

In de praktijk geeft het combineren van WebAuthn met endpointtelemetrie en gedragsanalyse uw beleidsengine een betrouwbaarder authenticatiesignaal dan welk wachtwoord of welke verouderde MFA-methode dan ook.

Welke browsers en platforms ondersteunen WebAuthn?

Volgens Can I Use is WebAuthn beschikbaar in ongeveer 95% van de wereldwijde browsers. Alle evergreen desktopbrowsers ondersteunen het: Chrome (v67+), Firefox (v60+), Safari (v14+) en Edge (v18+). Op mobiel ondersteunen Chrome voor Android, Safari op iOS en Samsung Internet allemaal WebAuthn. 

Voor platformauthenticators wordt Windows Hello (gezichtsherkenning, vingerafdruk, pincode via TPM) meegeleverd met Windows 10+, ondersteunt macOS/iOS 16+ Touch ID en Face ID met iCloud Keychain-synchronisatie voor passkeys, en biedt Android 9+ vingerafdruk- en gezichtsontgrendeling via Google Play Services. Er blijven hiaten bestaan in oudere OS-versies en sommige vergrendelde browserconfiguraties in ondernemingen.

Wat is het verschil tussen WebAuthn en passkeys?

WebAuthn is de W3C-API-specificatie die browsers implementeren voor het maken van inloggegevens met publieke sleutels en voor authenticatie. Passkeys is een gebruikersgerichte term voor WebAuthn-inloggegevens, vaak specifiek verwijzend naar gesynchroniseerde (cloud-ondersteunde) inloggegevens die via platformproviders op uw apparaten worden gesynchroniseerd. 

Alle passkeys gebruiken WebAuthn onder de motorkap, maar niet alle WebAuthn-inloggegevens zijn gesynchroniseerde passkeys. Apparaatgebonden WebAuthn-inloggegevens blijven gekoppeld aan specifieke hardware.

Kan WebAuthn alle vormen van MFA vervangen?

WebAuthn kan functioneren als single-factor (bezit van de authenticator), two-factor (bezit plus biometrie of pincode), of multi-factor-authenticatie, afhankelijk van uw configuratie. 

Voor AAL2-naleving moet u gebruikersverificatie (biometrie of pincode) afdwingen en de UV-vlag server-side valideren. WebAuthn vervangt verouderde MFA-methoden zoals TOTP en SMS OTP en biedt daarbij sterkere phishingbestendigheid dan elk van deze methoden.

Wat gebeurt er als een gebruiker zijn of haar WebAuthn-authenticator verliest?

Zonder herstelplan worden ze buitengesloten. Een best practice is om ten minste twee authenticators per gebruiker te registreren: een primair apparaat voor dagelijks gebruik en een back-up die veilig wordt opgeslagen. 

Uw accountherstelproces moet ook noodtoegangscodes voor IT-beheerders bevatten en een pad voor persoonlijke verificatie voor omgevingen met hoge zekerheid waar back-upauthenticators niet beschikbaar zijn.

Werkt WebAuthn met federatieve identiteitssystemen?

Ja, maar integratie vereist planning. WebAuthn werkt op het niveau van de identity provider (IdP) in federatieve omgevingen die SAML, OAuth of OpenID Connect gebruiken. Uw IdP verwerkt de WebAuthn-ceremonie en geeft vervolgens federatietokens uit aan downstream applicaties. 

Dit betekent dat u WebAuthn implementeert bij de IdP in plaats van bij elke afzonderlijke applicatie, wat de uitrol over federatieve services vereenvoudigt.

Hoe beschermt WebAuthn tegen man-in-the-middle-aanvallen?

De browser neemt de origin (het domein) cryptografisch op in de gegevens die door de authenticator worden ondertekend tijdens elke authenticatieceremonie. Een man-in-the-middle-aanvaller kan een authenticatieassertie niet doorsturen naar een ander domein, omdat de handtekening niet geldig zal zijn voor een andere origin dan die waarop het inloggegeven is geregistreerd. 

Deze bescherming werkt op protocolniveau, onafhankelijk van TLS of gebruikersbewustzijn.