Hoe werken passkeys? Gids voor authenticatiestroom

Hoe werkt een passkey? Het gebruikt FIDO2-public key cryptografie om diefstal van inloggegevens onmogelijk te maken. Leer de authenticatiestroom, platforms en implementatiepraktijken.

Wat is een passkey?

Gestolen inloggegevens waren de oorzaak bij 22% van de bevestigde datalekken, volgens het Verizon 2024 DBIR. Diefstal van inloggegevens, met name via infostealer-malware en phishingcampagnes, blijft de zwakke schakel in traditionele wachtwoordauthenticatie. Dit patroon is zichtbaar in echte incidenten:

• MGM Resorts (2023): Aanvallers gebruikten een social engineering-telefoontje om inloggegevens te verkrijgen en verstoorden uiteindelijk de hotel- en casinoactiviteiten; MGM meldde een impact van $100 miljoen op de aangepaste property EBITDAR in het kwartaal en $10 miljoen aan eenmalige kosten (MGM Resorts 8-K filing).
• Colonial Pipeline (2021): Het DOJ verklaarde dat het incident voortkwam uit een gecompromitteerd account dat werd gebruikt voor externe toegang, wat leidde tot een grote verstoring van de brandstofvoorziening aan de Amerikaanse oostkust (DOJ persbericht).
• Twilio (2022): Een phishingcampagne onderschepte medewerkersgegevens, waardoor toegang tot interne systemen en impact op klanten downstream mogelijk werd (Twilio incidentrapport).

Passkeys elimineren deze kwetsbaarheid door cryptografische authenticatie die is gebonden aan specifieke domeinen, waardoor diefstal en hergebruik van inloggegevens architectonisch onmogelijk wordt.

Een passkey is een cryptografisch authenticatiebewijs gebaseerd op het FIDO2-protocol. In plaats van een gedeeld geheim zoals een wachtwoord dat zowel op je apparaat als op een server wordt opgeslagen, gebruikt een passkey een asymmetrisch publiek-privaat sleutelpaar cryptografie. Je apparaat genereert en bewaart een privésleutel in beveiligde hardware, zoals een Trusted Platform Module (TPM) of secure enclave. De bijbehorende publieke sleutel wordt naar de server gestuurd. Tijdens het inloggen geeft de server een cryptografische uitdaging, je apparaat ondertekent deze met de privésleutel en de server verifieert de handtekening met de publieke sleutel.

De privésleutel verlaat je apparaat nooit. De server bezit nooit een herbruikbaar geheim. Er is niets om te phishen, niets om te hergebruiken en niets om te stelen uit een gecompromitteerde database.

Dat ontwerp heeft directe gevolgen voor hoe organisaties zich verdedigen tegen de meest voorkomende aanvalsvectoren gericht op identiteitsinfrastructuur.

Hoe passkeys zich verhouden tot cybersecurity

Passkeys pakken de dominante categorie van initiële toegang bij bedrijfsdatalekken aan: compromittering van inloggegevens. Het Verizon DBIR constateerde dat gecompromitteerde inloggegevens betrokken waren bij 42% van alle datalekken (Verizon 2024 DBIR). Traditionele MFA-methoden zoals sms-codes en TOTP blijven kwetsbaar voor real-time phishing, waarbij aanvallers codes doorsturen naar legitieme diensten voordat ze verlopen. Passkeys gebruiken cryptografische domeinbinding, wat betekent dat het authenticatiebewijs alleen werkt op het legitieme oorsprongsdomein. Zelfs als een gebruiker interactie heeft met een phishingpagina, kan de passkey niet authenticeren op een nagemaakt domein. Voor een opfrissing van hoe deze aanvallen werken, bekijk de phishing-aanval gids van SentinelOne.

Voor securityteams die identiteitsinfrastructuur beheren, verschuiven passkeys de verdedigingsstrategie van het verkleinen van de kans op diefstal van inloggegevens naar het architectonisch onmogelijk maken ervan. SentinelOne's overzicht van identity security helpt je authenticatieversterking te koppelen aan het bredere identiteitsrisicogebied.

Die context maakt een directe vergelijking mogelijk tussen wat passkeys vervangen en wat ze opleveren.

Passkeys versus wachtwoorden

De onderstaande tabel vat de belangrijkste verschillen tussen passkeys en wachtwoorden samen op de beveiligings- en operationele dimensies die het meest relevant zijn voor verdedigers.

Dimensie	Wachtwoorden	Passkeys
Authenticatiemodel	Gedeeld geheim opgeslagen op zowel client als server	Asymmetrisch sleutelpaar: privésleutel op apparaat, publieke sleutel op server
Phishingrisico	Hoog: gebruikers kunnen inloggegevens invoeren op nagemaakte domeinen	Uitgesloten: cryptografische domeinbinding voorkomt gebruik op ongeldige oorsprong
Serverlek-blootstelling	Wachtwoordhashes kunnen worden geëxfiltreerd en offline gekraakt	Publieke sleutels zijn waardeloos zonder de bijbehorende privésleutel
Hergebruik van inloggegevens	Veelvoorkomend: 52% van de volwassenen gebruikt wachtwoorden opnieuw voor meerdere accounts (Google/Harris Poll)	Onmogelijk: elke passkey is uniek voor één domein en account
MFA-vereiste	Aparte factor vereist (sms, TOTP, push)	Ingebouwd: bezit (apparaat) plus inherentie (biometrie) of kennis (pincode) in één stap
Succespercentage inloggen	~63% gemiddeld bij traditionele methoden	93% voor passkey-inlogpogingen (FIDO Alliance Passkey Index)
Snelheid van inloggen	31,2 seconden gemiddeld met MFA	8,5 seconden gemiddeld, een reductie van 73% (FIDO Alliance Passkey Index)
Helpdeskbelasting	Wachtwoordresets zijn een belangrijke kostenpost voor IT-support	Passkey-gebruikers rapporteren 81% minder helpdeskverzoeken gerelateerd aan inloggen (FIDO Alliance Passkey Index)
Herstelmodel	E-mail of sms-reset (herintroduceert phishable kanalen)	Gesynchroniseerde inloggegevens via platformbeheerders of vooraf geregistreerde back-up passkeys

Deze vergelijking tussen passkey en wachtwoord verklaart waarom de sector snel beweegt. De volgende sectie behandelt de bouwstenen die passkey-authenticatie mogelijk maken.

Kerncomponenten van passkey-authenticatie

Passkey-authenticatie gebruikt een gelaagde stack van protocollen, hardware en platformdiensten die je inloggegevens in elke fase beschermen. Elke component speelt een specifieke rol in het phishing-resistent en cryptografisch gebonden houden van inloggegevens.

1. FIDO2-protocolstack: FIDO2 is het overkoepelende raamwerk dat bestaat uit twee kernspecificaties. WebAuthn, gedefinieerd door de W3C Web Authentication-spec, is de browsergerichte API waarmee relying parties publieke sleutelinloggegevens kunnen aanmaken en verifiëren via JavaScript-aanroepen. CTAP (Client to Authenticator Protocol) regelt de communicatie tussen het clientplatform en de authenticatorhardware via USB, NFC of Bluetooth Low Energy (BLE). Samen overbruggen WebAuthn en CTAP je applicatie, browser en de beveiligde hardware die je privésleutel beschermt.
2. Authenticator-typen: De FIDO Alliance authenticator-specificaties definiëren twee categorieën. Platform (ingebouwde) authenticators zijn direct geïntegreerd in de hardware van het apparaat en slaan privésleutels op in secure enclaves of TPM's. Roaming (cross-platform) authenticators zijn externe hardwareapparaten die werken via USB, NFC of BLE en bieden de sterkste isolatie omdat privésleutels binnen een toegewijde secure element blijven. De keuze van authenticator bepaalt je zekerheidsniveau, herstelplan en gebruikerservaring.
3. Beveiligde hardwarelaag: De beveiliging van elke passkey hangt af van de authenticator die de privésleutel beschermt. Hardwarebeveiligingssleutels bieden de sterkste bescherming via toegewijde secure elements die zijn ontworpen om zowel fysieke als logische extractie-aanvallen te weerstaan.
4. Attestatie: Tijdens registratie van inloggegevens kun je met attestatie verifiëren dat een passkey is aangemaakt op een goedgekeurd authenticator-model (geïdentificeerd door zijn AAGUID) dat voldoet aan je beveiligingseisen, zoals hardwarematige sleutelopslag of FIPS 140-2-certificering.

Deze vier lagen, de FIDO2-protocolstack, authenticator-typen, beveiligde hardware en attestatie, werken samen bij elke passkey-interactie. De volgende sectie laat precies zien hoe ze samenkomen tijdens registratie en inloggen.

Hoe passkey-authenticatie werkt

De levenscyclus van een passkey kent twee ceremonies: registratie (het aanmaken van het authenticatiebewijs) en authenticatie (bewijzen dat je het bezit). Beide volgen een challenge-response-model met publieke-sleutelcryptografie.

Registratie: een passkey aanmaken

1. Server genereert een uitdaging. Wanneer je begint met het instellen van een passkey, genereert de relying party-server een cryptografisch willekeurige uitdaging samen met registratieparameters: de RP-identifier, gebruikersinformatie, ondersteunde algoritmen (meestal ES256) en authenticator-eisen.
2. Je apparaat maakt een sleutelpaar aan. De client roept credentials. create(challenge) aan. Je authenticator genereert een nieuw publiek-privaat sleutelpaar in beveiligde hardware. De privésleutel verlaat deze beschermde omgeving nooit.
3. De reactie wordt ondertekend teruggestuurd. Je apparaat stuurt de publieke sleutel, een credential-ID en de ondertekende uitdaging naar de server. De W3C-specificatie zorgt ervoor dat de volledige oorsprong cryptografisch wordt ondertekend in het attestatieobject, waardoor het authenticatiebewijs aan het legitieme domein wordt gebonden.
4. De server verifieert en slaat op. De server bevestigt de ondertekende uitdaging, valideert de oorsprong, controleert attestatie (voor bedrijfsimplementaties) en slaat de publieke sleutel en credential-ID op die aan je account zijn gekoppeld.

Op dit punt bezit de server je publieke sleutel en credential-ID, maar heeft nooit je privésleutel gezien. Die asymmetrie maakt elke volgende login phishing-resistent.

Authenticatie: inloggen met een passkey

1. Server geeft een nieuwe uitdaging uit. Elke inlogpoging levert een nieuwe cryptografisch willekeurige uitdaging op, waardoor replay-aanvallen worden voorkomen.
2. Je apparaat ondertekent de uitdaging. De client roept credentials.get(challenge) aan. Je authenticator vraagt om gebruikersverificatie (biometrische scan of pincode van het apparaat), haalt de privésleutel op, verhoogt de handtekeningenteller en ondertekent de authenticator-gegevens en client data hash.
3. De server verifieert de handtekening. Met je opgeslagen publieke sleutel verifieert de server de handtekening, waarmee cryptografisch wordt bewezen dat je de privésleutel bezit zonder dat deze ooit je apparaat verlaat.

Onderschepte communicatie bevat niets herbruikbaars omdat elke sessie een unieke uitdaging gebruikt. De privésleutel blijft vergrendeld in hardware. Je biometrische gegevens bereiken de server nooit; verificatie vindt volledig op het apparaat plaats.

Beide ceremonies gaan ervan uit dat de passkey zich bevindt op het apparaat dat je op dat moment gebruikt. In de praktijk werken gebruikers op meerdere apparaten, wat de vraag oproept hoe passkeys tussen apparaten worden verplaatst.

Cross-platform synchronisatie

Passkeys kunnen apparaatgebonden zijn of gesynchroniseerd worden over je apparaatecosysteem.

• Gesynchroniseerde passkeys worden gerepliceerd via platform-credentialmanagers met end-to-end-encryptie. Volgens Apple's iCloud Keychain-documentatie kan Apple de inhoud van de keychain niet lezen, zelfs niet als het cloudaccount is gecompromitteerd. Echter, NIST SP 800-63B vereist niet-exporteerbare privésleutels voor AAL3-compliance, een eis die gesynchroniseerde passkeys schendt omdat privésleutels het oorspronkelijke apparaat moeten verlaten voor synchronisatie.
• Apparaatgebonden passkeys verlaten de authenticatorhardware nooit en voldoen aan de strengste eisen, waaronder NIST SP 800-63B AAL3. Gesynchroniseerde passkeys kwalificeren nog steeds als AAL2-authenticators voor phishing-resistente authenticatie onder federale richtlijnen.

Als je eenmaal het verschil tussen apparaatgebonden en gesynchroniseerd begrijpt, kun je beoordelen waar passkeys al worden ondersteund en waar adoptie naartoe gaat.

Welke diensten en platforms ondersteunen passkeys

Meer dan 15 miljard online accounts ondersteunen nu passkey-authenticatie en 48% van de top 100 websites biedt passkeys als inlogoptie (FIDO Alliance). Adoptie beslaat consumentenplatforms, zakelijke tools en financiële diensten.

• Besturingssystemen en browsers: Apple (iOS, macOS, Safari), Google (Android, Chrome) en Microsoft (Windows, Edge) hebben volledige passkey-ondersteuning geïntegreerd. Meer dan 95% van de iOS- en Android-apparaten is passkey-ready en Windows breidt gesynchroniseerde passkey-ondersteuning uit via Windows Hello (Biometric Update). Cross-device-authenticatie werkt via CTAP over Bluetooth Low Energy (BLE), zodat je kunt inloggen op een laptop met een passkey die is opgeslagen op een nabijgelegen telefoon.
• Consumentenplatforms: Google heeft passkeys ingeschakeld voor meer dan 800 miljoen accounts en rapporteert vier keer meer succesvolle aanmeldingen dan met wachtwoorden. Amazon heeft 175 miljoen klanten met passkeys ingeschakeld. TikTok behaalde een authenticatiesuccespercentage van 97% met passkeys. Andere grote consumentenservices die passkeys ondersteunen zijn onder andere PayPal, eBay, GitHub en Target (FIDO Alliance Passkey Index).
• Zakelijke en workforce-tools: Adoptie in het bedrijfsleven versnelt. HID- en FIDO Alliance-data geven aan dat ongeveer 87% van de bedrijven passkeys heeft geïmplementeerd of actief implementeert. Platforms zoals Okta, HubSpot en Cisco Duo hebben passkey-ondersteuning gelanceerd, waarbij HubSpot een verbetering van 25% in inlogsucces en 4x snellere logins rapporteert ten opzichte van wachtwoorden en tweefactorauthenticatie (Dashlane Passkey Report).
• Financiële diensten en overheid: Banken zoals American Express, Bank of America en Wells Fargo zijn begonnen met het uitrollen van passkey-ondersteuning. Cryptobeurs Gemini werd een van de eerste grote platforms die passkeys verplicht stelde voor alle gebruikers. In de publieke sector heeft de Australische MyGov-dienst passkeys beschikbaar gemaakt voor bijna 30 miljoen mensen en de Europese Unie heeft haar Digital Identity Wallet-framework gelanceerd met passkeys als kerncomponent.

Brede platformondersteuning betekent dat de meeste organisaties vandaag al kunnen beginnen met het testen van passkeys. Dat betekent niet dat implementatie zonder frictie verloopt; de volgende sectie behandelt de operationele uitdagingen waarmee je rekening moet houden.

Uitdagingen bij het implementeren van passkeys

Passkeys lossen het probleem van diefstal van inloggegevens op, maar brengen operationele uitdagingen met zich mee waarmee je vóór implementatie rekening moet houden.

• Het herstelbeveiligingsdilemma: Als een gebruiker zijn enige apparaat met een apparaatgebonden passkey verliest en geen back-up heeft geregistreerd, wordt het account feitelijk onherstelbaar zonder alternatieve mechanismen. Traditionele herstelmethoden via e-mail of sms herintroduceren juist de kwetsbaarheden die passkeys moeten elimineren.
• Compatibiliteit met legacy-systemen: Oudere applicaties missen vaak FIDO2/WebAuthn-ondersteuning. Volgens het FIDO Alliance's enterprise passkeys paper kunnen federatieve omgevingen passkeys op IdP-niveau implementeren, waardoor downstream-ondersteuning mogelijk is zonder individuele aanpassingen. Niet-federatieve omgevingen moeten FIDO per applicatie implementeren of eerst migreren naar een federatief model.
• Organisatorische en cross-platform barrières: Zelfs met sterke beveiligingsvoordelen kan de uitrol van passkeys stagneren door middelen, eigenaarschap en procesverandering. Passkey-gedrag varieert ook per platform en browser, met verschillende registratieflows en synchronisatiegedrag, wat training bemoeilijkt en de supportlast tijdens de uitrol verhoogt.

Geen van deze uitdagingen is een blokkade, maar elk vereist een bewuste keuze tijdens de planning in plaats van een oplossing achteraf. De volgende best practices pakken herstel, compatibiliteit en uitrolfrictie direct aan.

Best practices voor passkey-implementatie in de onderneming

Een succesvolle passkey-uitrol vereist architecturale planning, gelaagde beleidsvoering en gefaseerde uitvoering.

• Stel een tweelaagse credentialstrategie op: Scheid je gebruikersbestand op basis van risicoprofiel en vereiste zekerheidsniveaus. Bevoorrechte accounts (beheerders, financiën, gereguleerde toegang) die AAL3-compliance vereisen, moeten apparaatgebonden passkeys of hardwarebeveiligingssleutels met niet-exporteerbare privésleutels gebruiken. Algemene medewerkers kunnen gesynchroniseerde passkeys gebruiken (voldoen aan AAL2 phishing-resistente eisen) voor betere bruikbaarheid en platformondersteund herstel via hun apparaat-credentialmanager.
• Implementeer in drie fasen: Voer een gestructureerde uitrol uit: begin met een pilot van 50 tot 100 gebruikers op kritieke applicaties (e-mail, VPN, HR-systemen) om levenscyclus- en herstelprocessen vast te stellen. Schaal uit naar meer applicaties en gebruikerssegmenten terwijl je provisioning-, intrekkings- en auditworkflows formaliseert. Maak ten slotte passkeys de standaard authenticatiemethode en verplaats wachtwoordgebaseerde fallback naar alleen-noodgebruik.
• Federeren vóór implementatie: Als je authenticatiearchitectuur niet is gecentraliseerd via een Identity Provider, los dat dan eerst op. Federatieve omgevingen die passkeys op IdP-niveau implementeren, kunnen downstream-applicaties ondersteunen zonder individuele aanpassingen. Niet-federatieve omgevingen hebben een intensiever traject, waarbij passkey-ondersteuning per applicatie vereist is.
• Ontwerp phishing-resistent herstel: Faseer sms- en e-mailherstel uit ten gunste van tijdsgebonden herstelmechanismen en back-up passkeys. Hersteltokens moeten een vervaltermijn van 5 tot 15 minuten hebben, gebonden zijn aan de oorspronkelijke sessie en eenmalig gebruikt kunnen worden. Back-up passkeys geregistreerd op secundaire apparaten bieden de sterkste fallback omdat ze de cryptografische beveiliging van primaire authenticatie behouden.
• Vereis attestatie voor bedrijfsregistraties: Implementeer AAGUID-gebaseerde attestatiefiltering om te waarborgen dat alleen goedgekeurde authenticator-modellen credentials kunnen registreren. Dit voorkomt dat gebruikers passkeys registreren op authenticators die niet aan je hardwarebeveiligingseisen voldoen.
• Investeer in gerichte training: Trainingsprogramma's moeten passkey-registratie op verschillende apparaattype behandelen, herstelprocedures voor verloren apparaten, gebruik van fallback-authenticatie en de beveiligingsredenering achter het beleid. Cross-platform inconsistenties maken praktijktraining effectiever dan alleen documentatie.
• Implementeer auditlogging vanaf dag één: Registreer elk registratie-event, authenticatiepoging, herstelactie en credentialintrekking in je SIEM. Integreer passkey-levenscyclusgebeurtenissen om audittrails te onderhouden die ISO 27001-controle-eisen en SOC 2 CC6 logische toegangsbeveiliging ondersteunen. SentinelOne's SIEM-gids en XDR-overzicht helpen je identiteitsgegevens te koppelen aan endpoint- en cloudsignalen.

Deze operationele fundamenten bereiden je voor om passkeys te vertalen naar auditklare controles, wat relevant is voor compliance en toezichthouders.

Compliance- en regelgevingsdrivers voor passkey-authenticatie

Regelgevende druk versnelt de adoptie van passkeys. CISA dringt er bij elke onderneming op aan om phishing-resistente MFA te implementeren voor e-mail, VPN's en systemen die kritieke infrastructuur raken. CISA en NIST hebben ook een concept interagency-rapport gepubliceerd over het beschermen van authenticatietokens tegen manipulatie, diefstal en replay-aanvallen. NIST SP 800-63B stelt dat AAL2 een phishing-resistente optie vereist, terwijl AAL3 een phishing-resistente authenticator met een niet-exporteerbare privésleutel vereist.

Om passkeys te koppelen aan audits, moet je doorgaans drie zaken aantonen:

• Control mapping: Documenteer hoe passkeys voldoen aan of beter zijn dan bestaande toegangscontrole-eisen (bijvoorbeeld ISO 27001 Annex A toegangscontrole).
• Risicobeoordeling: Leg de risico's vast die je introduceert (apparaatverlies, vendor lock-in, herstelcomplexiteit, downgrade-aanvallen) en je compenserende maatregelen.
• Bewijs en handhaving: Onderhoud implementatiedocumentatie, toon beleidsafdwinging aan en houd audittrails bij van authenticatie- en herstelgebeurtenissen.

Door deze onderdelen samen te voegen, kun je passkeys positioneren als zowel een beveiligingsupgrade als een auditvriendelijke controlemaatregel. Authenticatie is echter slechts één laag van het identity aanvalsoppervlak, en de tooling die je rondom passkeys inzet bepaalt hoe snel je dreigingen detecteert en erop reageert als ze voorbij het inlogscherm komen.

Versterk passkey-authenticatie met SentinelOne

Passkeys elimineren aanvallen op basis van inloggegevens op het authenticatieniveau, maar identity security gaat verder dan het inlogscherm. Diefstal van sessietokens, laterale beweging en identity-based persistentie vinden allemaal downstream van authenticatie plaats. Singularity Identity correleert endpoint- en identity-activiteit voor contextgestuurde detectie en snellere triage wanneer passkeys slechts een deel van het verhaal zijn. Het versterkt Active Directory en cloud identity providers zoals SecureAuth, Ping, Duo, Entra ID en Okta, zet deceptiontechnieken in om indringers vroeg te vangen en detecteert diefstal van inloggegevens en privilege-escalatie in realtime.

Purple AI versnelt het onderzoek van identity-gerelateerde meldingen door natuurlijke taalvragen te vertalen naar cross-domein zoekopdrachten. Organisaties die Purple AI gebruiken rapporteren tot 55% snellere dreigingsoplossing en een reductie van 40-50% in onderzoekstijd (IDC-onderzoek).

SentinelOne genereerde 88% minder meldingen dan het mediane aantal bij alle leveranciers in de onafhankelijke 2024 MITRE ATT&CK Evaluations (MITRE ATT&CK Evaluations resultaten), waardoor je team meer tijd kan besteden aan echte incidenten in plaats van aan meldingsvolume.

Wanneer je passkey-, endpoint- en identity-telemetrie centraliseert, Singularity AI SIEM biedt één plek om genormaliseerde beveiligingsgebeurtenissen snel op te slaan voor snellere hunting en forensisch onderzoek. SentinelOne's cybersecurity 101 hub biedt ondersteunende concepten voor interne runbooks. Vraag een SentinelOne-demo aan om te zien hoe identity-, endpoint- en cloudtelemetrie samenkomen in één platform.

Belangrijkste punten

Wat is een passkey in de kern? Het is een cryptografisch authenticatiebewijs dat gedeelde geheimen vervangt door asymmetrische cryptografie, waarmee het risico op diefstal van inloggegevens achter 22% van de datalekken wordt geëlimineerd (Verizon 2024 DBIR). Implementatie in de onderneming vereist een tweelaagse credentialstrategie: apparaatgebonden passkeys voor AAL3-conforme bevoorrechte accounts en gesynchroniseerde passkeys voor de algemene medewerkers. 

Bouw phishing-resistente herstelworkflows, federateer je authenticatiearchitectuur en rol gefaseerd uit. Regelgevende vereisten van CISA en NIST versnellen de adoptie.

Veelgestelde vragen

Wat is een passkey?

Een passkey is een cryptografisch authenticatiebewijs gebaseerd op het FIDO2-protocol dat wachtwoorden vervangt door asymmetrische cryptografie met een openbaar-privaat sleutelpaar. Uw apparaat genereert en slaat een privésleutel op in beveiligde hardware, terwijl de openbare sleutel naar de server wordt gestuurd. 

Tijdens het inloggen geeft de server een uitdaging, uw apparaat ondertekent deze met de privésleutel en de server verifieert de handtekening. De privésleutel verlaat uw apparaat nooit, waardoor diefstal van inloggegevens en phishing architectonisch onmogelijk worden.

Wat is het verschil tussen een passkey en een wachtwoord?

Het verschil tussen een passkey en een wachtwoord zit in de architectuur. Een wachtwoord is een gedeeld geheim dat zowel op je apparaat als op de server wordt opgeslagen. Als de server wordt gecompromitteerd, wordt het wachtwoord blootgesteld. Een passkey gebruikt asymmetrische cryptografie: je privésleutel blijft in de hardware van het apparaat, en de server bewaart alleen de publieke sleutel. 

Zelfs bij een volledige servercompromittering wordt er geen bruikbare inloggegevens blootgesteld. Passkeys zijn ook cryptografisch gebonden aan het legitieme domein, waardoor phishing onmogelijk is.

Kunnen passkeys worden gefisht of onderschept?

Passkeys zijn phishingbestendig omdat WebAuthn gegevens ondertekent die de legitieme website-oorsprong bevatten (de relying party ID en origin binding). Als je op een lookalike domein terechtkomt, zullen de browser en authenticator geen geldige bewering vrijgeven voor die oorsprong, waardoor de aanmelding mislukt, zelfs als je deze goedkeurt. 

Als een aanvaller verkeer onderschept, krijgt deze alleen een eenmalig ondertekend challenge-antwoord dat aan die sessie is gekoppeld. Dit kan niet worden hergebruikt omdat de challenge uniek is

Wat gebeurt er als ik het apparaat verlies waarop mijn passkey is opgeslagen?

Met gesynchroniseerde passkeys worden uw inloggegevens gerepliceerd over uw apparaat-ecosysteem via diensten zoals iCloud-sleutelhanger, waardoor herstel mogelijk is als u een apparaat verliest. Bij apparaatgebonden passkeys verlaat uw privésleutel het oorspronkelijke apparaat nooit, dus heeft u een vooraf geregistreerde back-up passkey op een apart apparaat of hardware sleutel nodig. 

Enterprise-omgevingen dienen administratieve herstelworkflows te implementeren met tijdsgebonden tokens en identiteitsverificatie, in plaats van te vertrouwen op e-mail- of sms-terugvalopties.

Voldoen passkeys aan compliance-eisen voor ondernemingen zoals SOC 2 en ISO 27001?

Gesynchroniseerde passkeys voldoen aan NIST AAL2-eisen en kwalificeren als phishingbestendige authenticators. Apparaatgebonden passkeys op hardwarebeveiligingssleutels voldoen aan NIST AAL3-eisen. 

Organisaties moeten risicoanalyses uitvoeren waarbij passkey-controls worden gekoppeld aan hun specifieke compliance-raamwerken, waaronder SOC 2 Common Criteria 6 en ISO 27001-doelstellingen voor toegangsbeheer, met correcte auditlogging en gedocumenteerde procedures.

Hoe werken passkeys op verschillende besturingssystemen en browsers?

Elk groot platform biedt een eigen credential manager voor het opslaan van passkeys. Gesynchroniseerde passkeys worden binnen een ecosysteem gerepliceerd met end-to-end-encryptie. Authenticatie tussen apparaten gebruikt CTAP via Bluetooth Low Energy (BLE), zodat je kunt authenticeren op een laptop met een passkey die op een nabijgelegen telefoon is opgeslagen. 

Browsersupport voor WebAuthn is breed beschikbaar, waardoor uitrol meestal gericht is op gebruikersopleiding en herstelontwerp in plaats van browserinschakeling.