Passkey versus Security Key: Verschillen & Hoe te Kiezen

Passkeys versus security keys: vergelijk FIDO2-credentialtypen op basis van assurantieniveau, attestatie, herstel en enterprise-implementatiemodellen. Ontdek welke het beste past bij uw stack.

Wat zijn passkeys en security keys?

In 2021 herleidde Colonial Pipeline een ransomware-incident tot een gecompromitteerd VPN-wachtwoord, en het bedrijf betaalde volgens een DOJ-persbericht ongeveer $4,4 miljoen losgeld. Dat is de operationele realiteit van initiële toegang op basis van inloggegevens: aanvallers hebben geen zero-days nodig als ze kunnen phishen, hergebruiken of credential stuffing kunnen uitvoeren tegen wachtwoordgebaseerde authenticatie.

Zowel passkeys als fysieke security keys bestaan om dat gat te dichten. Ze gebruiken dezelfde cryptografische basis, maar het verschil in hoe ze inloggegevens opslaan en beheren is van belang bij het beschermen van een organisatie.

Een passkey is een FIDO-authenticatie-inloggegeven dat wachtwoorden vervangt door cryptografische sleutelpaaren. Volgens de FIDO Alliance kunnen gebruikers met passkeys inloggen op apps en websites via hetzelfde proces als waarmee ze hun apparaat ontgrendelen: biometrie, een pincode of een patroon. Passkeys zijn er in twee vormen:

• Gesynchroniseerde passkeys slaan inloggegevens op in een cloudgebaseerde credential manager en synchroniseren deze over je apparaten.
• Apparaatgebonden passkeys vergrendelen de privésleutel aan één apparaat. Deze verlaat nooit die hardware.

In de praktijk bepaalt het opslagmodel de meeste afwegingen voor je organisatie.

Een hardware security key (ook wel roaming authenticator genoemd) is een extern hardwareapparaat dat communiceert met browsers en besturingssystemen via USB, NFC of Bluetooth met behulp van het FIDO2 CTAP (Client-to-Authenticator Protocol). Denk aan YubiKeys, smartcards en vergelijkbare tokens. Deze zijn per definitie apparaatgebonden: de privésleutel wordt opgeslagen in een hardware security module en kan niet worden geëxporteerd of gekopieerd.

Beide technologieën delen dezelfde cryptografische basis. Elke inloggegeven is uniek, gebonden aan een specifiek servicedomein en gebaseerd op standaard public key cryptografie. Biometrische gegevens verlaten je apparaat nooit. De server slaat alleen de publieke sleutel op. Dat gedeelde ontwerp maakt beide opties relevant voor hetzelfde kernbeveiligingsprobleem.

Hoe passkeys en security keys zich verhouden tot cybersecurity

Het 2025 Verizon DBIR meldt dat misbruik van inloggegevens een groot aandeel heeft in initiële toegang: 22% van de datalekken betreft misbruik van inloggegevens als initiële toegangsmethode, volgens het Verizon DBIR. Dat komt overeen met wat je in de praktijk ziet: zodra een aanvaller geldige inloggegevens heeft, bestrijd je je eigen toegangswegen.

Zowel passkeys als security keys zijn van nature bestand tegen phishing. Zoals de WebAuthn-specificatie definieert, is elke authenticatieverklaring gekoppeld aan een specifiek website-domein, zodat een phishing-site op een ander domein geen geldige verklaring kan verkrijgen. Dit stopt credential phishing, credential stuffing en adversary-in-the-middle-aanvallen op protocolniveau, wat de reden is dat overheidsinstanties en gereguleerde sectoren aandringen op phishing-resistente MFA.

Daarom verplicht OMB M-22-09 nu dat federale instanties uitsluitend phishing-resistente authenticatie gebruiken. De vraag voor jouw organisatie is niet of je FIDO2-authenticatie moet invoeren, maar welk implementatiemodel past bij je risicoprofiel. De onderstaande tabel zet de belangrijkste verschillen naast elkaar.

Passkey vs. Security Key in één oogopslag

Kenmerk	Passkey (gesynchroniseerd)	Fysieke security key
Opslag van inloggegevens	Cloud credential manager (Apple Keychain, Google Password Manager)	Hardware security module op fysiek token
Exporteerbaarheid van sleutel	Gesynchroniseerd over apparaten via cloud-infrastructuur	Niet exporteerbaar; vergrendeld aan hardware
NIST Assurance Level	AAL2	AAL3
Phishing-resistentie	Ja (FIDO2 domeinbinding)	Ja (FIDO2 domeinbinding)
Apparaatattestatie	Niet ondersteund (cloudsync verbreekt chain-of-trust)	Ondersteund (hardware-ingebed fabrikantcertificaat)
Herstelmodel	Cloudaccountherstel via provider	Fysieke back-up key of admin-gemedieerde herinschrijving
Gebruikerservaring	Transparant, werkt over gesynchroniseerde apparaten	Fysiek token vereist bij elke login
Hardwarekosten	Geen (software-gebaseerd)	Aanschaf token per gebruiker en lifecycle management
Cross-platform ondersteuning	Afhankelijk van provider-ecosysteem	Universeel (USB, NFC, BLE op elk FIDO2-platform)
Beste toepassing	Algemene medewerkers, BYOD-omgevingen	Bevoorrechte admins, gereguleerde sectoren, AAL3-compliance

De protocolstack, het opslagmodel en de attestatie-ondersteuning achter elke optie bepalen je assurance-niveau. Hier volgt hoe die componenten zijn opgebouwd.

Hoe FIDO2-authenticatie onder de motorkap werkt

Zowel passkeys als security keys vertrouwen op dezelfde FIDO2-protocolstack, maar verschillen in hoe ze het onderliggende cryptografische materiaal opslaan, beschermen en beheren. Inzicht in deze componenten helpt je het juiste type inloggegeven te koppelen aan het juiste risiconiveau.

FIDO2-protocolstack

FIDO2 bestaat uit twee kerncomponenten zoals gedefinieerd door de FIDO-specificaties:

1. W3C Web Authentication (WebAuthn): De browser-API die FIDO-authenticatie op websites en applicaties mogelijk maakt.
2. Client-to-Authenticator Protocol (CTAP): Het protocol waarmee externe authenticators kunnen communiceren met FIDO2-compatibele browsers en besturingssystemen.

Deze twee lagen zorgen voor origin binding en het cryptografisch bewijs dat sterke, phishing-resistente aanmelding mogelijk maakt.

Architectuur voor opslag van inloggegevens

Het opslagmodel is het bepalende verschil tussen passkeys en security keys. Elke aanpak gaat anders om met de privésleutel:

• Hardware security keys slaan privésleutels op in speciale hardware security modules (HSM), vaak met gebruik van een Trusted Platform Module (TPM)-chip. Volgens Microsoft Entra-documentatie is het sleutelmateriaal niet exporteerbaar. Je kunt het niet kopiëren, back-uppen of synchroniseren.
• Gesynchroniseerde passkeys gebruiken een besturingssysteem of derde partij voor synchronisatie van cryptografische sleutels over apparaten. De FIDO Alliance enterprise deployment guide merkt op dat dit een afhankelijkheid creëert van de synchronisatie-infrastructuur van de passkey-provider en hun beveiligingsmaatregelen.

Dat opslagverschil bepaalt alle vervolgkeuzes rond attestatie, compliance en herstel.

Attestatie

Apparaatattestatie is een techniek ingebouwd in FIDO- en WebAuthn-protocollen waarmee de authenticator cryptografisch de chain of trust van de fabrikant van het apparaat kan verifiëren. Volgens de FIDO Alliance attestation white paper vereist dit een hardware-ingebed fabrikantcertificaat in het beveiligde element van de authenticator.

Gesynchroniseerde passkeys kunnen geen apparaatprovenance bieden omdat cloud-synchronisatie deze cryptografische keten verbreekt. Als je attestatie afdwingt in je identity platform, komen alleen apparaatgebonden inloggegevens in aanmerking.

Compliance-afstemming

NIST SP 800-63B-4 trekt een duidelijke lijn. AAL2 vereist phishing-resistente authenticatie, en zowel gesynchroniseerde passkeys als security keys kunnen hiervoor in aanmerking komen. AAL3 vereist een niet-exporteerbare authenticatiesleutel, wat gesynchroniseerde passkeys volledig uitsluit.

Deze componenten zijn direct gekoppeld aan wat er gebeurt tijdens het aanmelden en waar de twee typen inloggegevens verschillend gedrag vertonen.

Registratie, authenticatie en waar de twee uiteenlopen

De authenticatiestroom voor passkeys en security keys volgt hetzelfde FIDO2-patroon. Het verschil zit in hoe elk type omgaat met opslag, overdraagbaarheid en herstel van inloggegevens achter de schermen.

Registratie (beide methoden)

Tijdens registratie genereert de authenticator een uniek publiek/privé sleutelpaar dat is gebonden aan het domein van de dienst. De privésleutel blijft op de authenticator, en de server slaat alleen de publieke sleutel op.

Authenticatie (beide methoden)

1. De server stuurt een cryptografische uitdaging.
2. Je voert lokale verificatie uit: een vingerafdrukscan, gezichtsherkenning, pincode of een fysieke knopdruk.
3. De authenticator ondertekent de uitdaging met de privésleutel.
4. De server valideert de handtekening met de opgeslagen publieke sleutel.

Die gedeelde stroom is de reden dat beide benaderingen phishing-aanvallen op protocolniveau blokkeren.

Overdraagbaarheid

Met een fysieke security key draag je één token dat authenticatie mogelijk maakt op onbeperkt aantal apparaten. Steek hem in een FIDO2-compatibele browser of tik via NFC, en je bent ingelogd.

Met gesynchroniseerde passkeys worden je inloggegevens automatisch gerepliceerd over apparaten binnen het ecosysteem van je provider: Apple, Google of een derde partij. Je authenticeert op je laptop, en dezelfde passkey werkt op je telefoon zonder extra hardware. Cross-ecosysteem overdraagbaarheid blijft echter inconsistent. Een flow die werkt op Chrome/Windows kan anders werken op Safari/macOS, en browser-UX-verschillen blijven een aanhoudend knelpunt voor enterprise-implementaties.

Beveiligingsgrenzen

Voor apparaatgebonden inloggegevens heeft een aanvaller je inloggegevens, fysieke toegang tot het hardwaretoken en de mogelijkheid om lokale authenticatie te omzeilen nodig.

Voor gesynchroniseerde inloggegevens verschuift de beveiligingsgrens naar je cloudprovider. Als een aanvaller het cloudaccount compromitteert via social engineering of provider-resetmanipulatie, kan hij inloggegevens synchroniseren naar een door de aanvaller beheerd apparaat.

Die verschuiving in beveiligingsgrens vraagt om operationele planning. Beide typen inloggegevens brengen afwegingen met zich mee die je moet meenemen voordat je organisatiebreed afdwingt, en die afwegingen zijn alleen relevant als de platforms, browsers en identity providers die je gebruikt het gekozen type inloggegeven daadwerkelijk ondersteunen.

Waar passkeys en security keys vandaag worden ondersteund

Vanaf 2025 is de adoptie van passkeys en security keys op een praktisch kantelpunt beland in zowel consumenten- als bedrijfsomgevingen.

• Besturingssystemen en browsers. Apple (iOS 16+, macOS Ventura+), Google (Android 9+) en Microsoft (Windows 10/11 via Windows Hello) ondersteunen allemaal native het aanmaken en gebruiken van passkeys. Elke grote browser, waaronder Chrome, Safari, Edge en Firefox, ondersteunt WebAuthn. Volgens de FIDO Alliance is meer dan 95% van de iOS- en Android-apparaten nu passkey-ready, en hebben meer dan een miljard gebruikers minstens één passkey geactiveerd.
• Identity providers. Enterprise IdP's hebben FIDO2-ondersteuning toegevoegd. Microsoft Entra ID ondersteunt apparaatgebonden passkeys op FIDO2 security keys en in Microsoft Authenticator, met gesynchroniseerde passkey-ondersteuning in preview. Okta ondersteunt zowel passkeys als FIDO2 security keys als phishing-resistente authenticators, met attestatie- en AAGUID-gebaseerde beleidscontroles. Cisco Duo, Ping Identity en andere grote IdP's ondersteunen ook FIDO2-registratie voor beide typen inloggegevens. Dit betekent dat je IdP waarschijnlijk geen belemmering vormt.
• Hardware security keys werken universeel op FIDO2-compatibele platforms via USB, NFC of Bluetooth. Toonaangevende fabrikanten zoals Yubico leveren multi-protocol keys (YubiKey 5 Series) die FIDO2, PIV/Smart Card en OTP ondersteunen, zodat zowel moderne als legacy authenticatiebehoeften in één token worden afgedekt.
• Cross-platform overdraagbaarheid. Gesynchroniseerde passkeys ondervinden nog steeds frictie bij overstap tussen ecosystemen. Een passkey aangemaakt in Apple Keychain synchroniseert niet native naar Google Password Manager of een Windows-apparaat. De FIDO Alliance werkt aan de Credential Exchange Protocol (CXP), een concept-specificatie ontwikkeld door Apple, Google, Microsoft, 1Password, Bitwarden en Dashlane om veilige, versleutelde passkey-overdracht tussen providers te standaardiseren. CXP wordt verwacht als publieke reviewversie in 2026. Tot die tijd bieden derde partij password managers zoals 1Password en Bitwarden de meest consistente cross-platform passkey-ervaring.

Voor enterprise planning is de belangrijkste conclusie dat platformondersteuning geen adoptiebarrière meer is. De resterende frictie zit in cross-ecosysteem overdraagbaarheid voor gesynchroniseerde passkeys en organisatorische gereedheid rond registratie, herstel en beleidsafdwinging. Die operationele uitdagingen verdienen nadere aandacht.

Uitdagingen en beperkingen om rekening mee te houden

Geen enkele authenticatiemethode elimineert alle risico's. Bij grootschalige uitrol van passkeys versus security keys kom je een aantal terugkerende uitdagingen tegen:

• Herstelprocessen worden een primaire controle. Als aanvallers je helpdesk of provider-resetproces kunnen beïnvloeden, kunnen ze je sterkste aanmeldingsstroom omzeilen.
• Sleutelverlies wordt een beschikbaarheidsprobleem. Een verloren token kan een gebruiker buitensluiten tenzij je vooraf back-ups en admin-workflows inricht.
• Platformverschillen veroorzaken frictie. Fragmentatie van browsers en besturingssystemen kan leiden tot inconsistente WebAuthn-ervaringen en hogere supportlast.
• Levenscyclusbeheer is reëel. Uitgifte, vervanging en intrekking brengen extra werk met zich mee, vooral als je tokens breder uitrolt dan alleen voor bevoorrechte gebruikers.

Dit zijn geen theoretische problemen. In 2023 maakte MGM Resorts een cyberincident bekend, veroorzaakt door social engineering, met een geschatte negatieve impact van $100 miljoen, volgens een MGM-melding. Sterke aanmeldfactoren helpen, maar je moet ook identity operations, inclusief servicedesk- en fallbackprocessen, versterken. Het goede nieuws is dat elk van deze beperkingen te koppelen is aan een specifieke implementatiepraktijk die je vooraf kunt inrichten.

Best practices voor uitrol van passkeys en security keys

Of je nu passkeys, security keys of beide uitrolt, deze praktijken helpen je de uitrol af te stemmen op risico, gebruiksgemak en operationele realiteit:

1. Segmenteer op risico en assurance. Geef een hardware security key uit aan bevoorrechte beheerders, executives en gereguleerde rollen waar AAL3 of hoge assurance-attestatie vereist is. Gebruik gesynchroniseerde passkeys voor de bredere medewerkerspopulatie waar AAL2 volstaat.
2. Maak registratie en back-ups standaard. Vereis passkey-instelling tijdens device onboarding, en registreer meerdere authenticators per gebruiker zodat je een back-up hebt die gebruikers niet terugstuurt naar makkelijk te phishen factoren.
3. Versterk account recovery en fallback. Behandel account recovery als controle: verscherp identiteitsverificatie voor helpdesk-resets, beperk fallback-methoden en monitor op abnormaal fallback-gebruik.
4. Rol gefaseerd uit en monitor continu. Start met risicogroepen, breid gefaseerd uit en dwing pas af als gebruikerssupport en resetprocessen standhouden. Houd blijvend zicht op ongebruikelijke reizen, risicovolle apparaatwijzigingen en verdachte herregistraties.

Als je deze vier praktijken uitvoert, verklein je het aantal lockouts en beperk je de opties van aanvallers zonder gebruikers te vertragen. Van daaruit kun je een duidelijk segmentatiemodel opbouwen voor welk type inloggegeven je waar inzet.

Hoe kies je tussen een passkey en een security key

Kiezen tussen een passkey en een security key hoeft geen of/of-keuze te zijn. De meeste organisaties eindigen met een hybride model omdat verschillende groepen verschillende assurance-niveaus en herstelpaden nodig hebben.

Gebruik deze segmentatie om de keuze duidelijk te maken:

• Hardware security key: Gebruik wanneer je AAL3, niet-exporteerbare sleutels en sterke apparaatattestatie nodig hebt voor bevoorrechte toegang.
• Gesynchroniseerde passkey: Gebruik wanneer AAL2 volstaat en je lagere IT-overhead wilt voor brede medewerkerspopulatie.
• Hybride beleid: Gebruik security keys voor beheerders en gereguleerde rollen, en gesynchroniseerde passkeys voor de rest van je gebruikers.
• Recovery-first ontwerp: Behandel reset- en fallbackpaden als onderdeel van je controleset, niet als bijzaak, omdat ze phishing-resistente MFA kunnen ondermijnen.

Als je die segmentatie hebt, is de volgende stap zorgen dat je identiteitgedreven activiteiten na aanmelding nog steeds kunt detecteren en stoppen.

Belangrijkste punten

Passkeys en fysieke security keys bieden beide phishing-resistente authenticatie via FIDO2 cryptografie, maar ze dienen verschillende behoeften binnen organisaties. Gesynchroniseerde passkeys geven prioriteit aan gebruikerservaring en schaalbaarheid voor algemene medewerkers op AAL2. 

Apparaatgebonden security keys bieden niet-exporteerbare inloggegevens, hardware-ondersteunde attestatie en AAL3-afstemming voor bevoorrechte gebruikers en gereguleerde omgevingen. Voor de meeste organisaties zul je beide inzetten in een risicogebaseerd model, en daarbovenop zichtbaarheid op identiteitsdreigingen toevoegen om te detecteren wat authenticatiecontroles alleen niet kunnen afvangen.

Veelgestelde vragen

Wat is een Passkey?

Een passkey is een FIDO2-authenticatiegegevens die gebruikmaakt van publieke-sleutelcryptografie in plaats van een gedeeld geheim zoals een wachtwoord. Wanneer u een passkey registreert, genereert uw apparaat een uniek sleutelpaar: de privésleutel blijft op het apparaat (of wordt gesynchroniseerd via een cloudprovider), en de server slaat alleen de publieke sleutel op. 

U authenticeert met een biometrische scan, pincode of apparaatontgrendeling. Omdat de gegevens aan een specifiek domein zijn gebonden en nooit worden verzonden, voorkomt dit phishing en credential stuffing op protocolniveau.

Wat is het verschil tussen AAL2 en AAL3?

AAL2 en AAL3 zijn NIST-authenticatiezekerheidsniveaus die bepalen hoe sterk u op een aanmelding kunt vertrouwen. AAL2 vereist phishing-resistente authenticatie, maar kan gesynchroniseerde referenties toestaan die onder controle van een provider tussen apparaten worden verplaatst. 

AAL3 verhoogt de eisen door een hardware-ondersteunde, niet-exporteerbare sleutel en strengere verificatievereisten te vereisen. In de praktijk betekent dit dat gesynchroniseerde passkeys geschikt zijn voor AAL2, terwijl beveiligingssleutels of andere apparaatgebonden authenticators worden gebruikt voor AAL3.

Wat zijn Passkey Redaction Attacks?

Passkey-redactieaanvallen richten zich op de gebruikersinterface door passkey-prompts te verbergen of te onderdrukken, waardoor gebruikers worden gedwongen om wachtwoorden, sms of andere zwakkere alternatieven te gebruiken. Aanvallers kunnen dit doen via adversary-in-the-middle proxies, manipulerende inlogpagina's of kwaadaardige browserextensies die het zicht van de gebruiker aanpassen. 

Om het risico te verkleinen, minimaliseer alternatieven, pas voorwaardelijke toegangsregels toe en beperk het beleid voor extensies. U dient ook te waarschuwen bij plotselinge pieken in het gebruik van alternatieven, wat vaak wijst op actieve dwang.

Hoe rolt u Passkeys en Security Keys gefaseerd uit?

Een gefaseerde uitrol begint meestal met basiswerk: bevestig WebAuthn-ondersteuning, definieer AAL2- versus AAL3-beleid en bouw robuuste reset- en herinschrijvingsprocedures. Implementeer security keys eerst bij bevoorrechte en hoog-risico rollen, rol daarna gesynchroniseerde passkeys in golven uit naar de algemene medewerkers. 

Handhaaf uitsluitend FIDO-beleid zodra adoptie en ondersteuningsgereedheid stabiel zijn. Behoud legacy-factoren alleen zolang als nodig is om lockouts tijdens de overgang te voorkomen, en schakel ze daarna uit.

Zijn gesynchroniseerde Passkeys veilig in BYOD-omgevingen?

Ja, maar u heeft waarborgen nodig. Sla zakelijke passkeys op in beheerde containers of werkprofielen zodat de sleutels binnen uw beheerde context blijven, niet in een persoonlijke cloudkluis. Beperk het aanmaken van passkeys tot beheerde browsers en apps waar mogelijk, en controleer op zakelijke credentials die onder persoonlijke accounts zijn geregistreerd. 

Uw accountherstelscenario is hier ook van belang: als resets terugvallen op eenvoudig te manipuleren stappen, verliezen gesynchroniseerde passkeys veel van hun zekerheid.

Waarom gebruiken organisaties zowel Passkeys als Security Keys?

U gebruikt beide omdat geen enkele authenticator de juiste balans biedt tussen zekerheid, gebruiksgemak en operationele efficiëntie voor elke rol. Geef beveiligingssleutels aan bevoorrechte gebruikers, beheerders en gereguleerde rollen die niet-exporteerbare sleutels en sterk bewijs van de herkomst van de authenticator vereisen. 

Gebruik gesynchroniseerde passkeys voor het brede personeelsbestand waar AAL2 voldoende is en gebruiksgemak de adoptie stimuleert. Handhaaf vervolgens consistente fallback- en herinschrijvingsbeleid voor beide groepen, zodat aanvallers gebruikers niet kunnen downgraden naar zwakkere factoren.