- Een passkey is een FIDO2-inloggegevens. De prive-sleutel staat op het apparaat en verlaat het nooit. De server slaat alleen de publieke sleutel op, dus een serverlek levert een aanvaller niets bruikbaars op.
- FIDO2 elimineert phishing door de cryptografische challenge te binden aan het geregistreerde oorsprongsdomein. Een nep-phishingsite ontvangt geen geldige handtekening, ongeacht hoe overtuigend die eruitziet.
- NIST SP 800-63B-4 classificeert FIDO2 als phishing-bestendig. TOTP en push-meldingen zijn dat niet, omdat beide doorgezonden waarden bevatten die een proxy in realtime kan doorzetten.
- Microsoft, Apple en Google ondersteunen passkeys standaard. Microsoft schakelde consumentenaccounts in mei 2026 over naar passkey-first, waarbij sms-OTP als standaard werd afgeschaft.
- Bedrijfsimplementatie vereist het in kaart brengen van legacy-applicatieauthenticatie, planning voor gedeelde werkstations en het ontwerpen van een getest herstelproces voordat wachtwoord-fallback voor een gebruikersgroep wordt uitgeschakeld.
- Handhaving in Microsoft Entra ID verloopt via Authentication Strength-beleid in Conditional Access. Temporary Access Pass biedt een gecontroleerd herstelpad dat geen wachtwoorden herintroduceert.
Wat een passkey is
Een passkey is een FIDO2-inloggegevens. Bij registratie genereert het apparaat twee cryptografische sleutels: de prive-sleutel blijft op het apparaat, in een TPM-chip, Secure Enclave of roaming hardware-authenticator, en de publieke sleutel wordt naar de server gestuurd. Bij aanmelden stuurt de server een challenge. Het apparaat ondertekent die met de prive-sleutel. De server verifieert de handtekening met de opgeslagen publieke sleutel. De prive-sleutel verlaat het apparaat nooit en de server slaat nooit een geheim op dat kan worden gestolen.
Apparaatgebonden passkeys zijn gekoppeld aan specifieke hardware: Windows Hello for Business gebruikt de TPM op een beheerde pc, Face ID en Touch ID gebruiken Apple's Secure Enclave, en hardwarebeveiligingssleutels zoals de YubiKey genereren en slaan de sleutel intern op zonder extractiemogelijkheid. Gesynchroniseerde passkeys worden gerepliceerd over uw apparaten via een end-to-end versleutelde cloudservice zoals iCloud Keychain, Google Password Manager of 1Password. Beide typen gebruiken FIDO2. Gesynchroniseerde passkeys bieden meer gemak; apparaatgebonden passkeys bieden sterkere isolatie maar vereisen meer herstelplanning bij verlies van een apparaat.
De server slaat alleen een publieke sleutel op. Die stelen levert een aanvaller niets op.
Waarom wachtwoorden blijven falen
Wachtwoorden zijn een gedeeld geheim: zowel de gebruiker als de server kennen het, wat betekent dat het van beide kanten kan worden onttrokken. Phishing steelt het van de gebruiker. Databaselekken stelen het van de server. Keyloggers stelen het van het apparaat. Adversary-in-the-middle proxy-aanvallen stelen het tijdens een sessie terwijl de gebruiker het actief invoert op wat zij geloven een legitieme inlogpagina te zijn.
Multi-factor authenticatie verkleint het gat. TOTP-codes en push-meldingen gaan echter allebei door dezelfde proxy in een adversary-in-the-middle-aanval: de gebruiker voltooit de MFA-challenge, de proxy stuurt die door naar de echte dienst, en de aanvaller loopt weg met de geauthenticeerde sessiecookie. Het fundamentele probleem is het gedeeld-geheim-model, dat ervoor zorgt dat ten minste een partij een waarde bezit die kan worden gestolen, en die gestolen waarde gaat over een kanaal dat kan worden onderschept.
Hoe FIDO2 de phishing-aanvalsruimte elimineert
Het mechanisme is oorsprongsbinding. Bij registratie legt de authenticator de Relying Party ID vast, in feite het domein van de dienst. Bij authenticatie neemt de browser de exacte oorsprong op in de ondertekende bewering. Als de oorsprong in het antwoord niet overeenkomt met de geregistreerde Relying Party ID, weigert de authenticator te ondertekenen. Een phishing-proxy op login-microsoft-365-veilig.com kan geen geldige bewering verkrijgen voor login.microsoft.com. Er is geen waarde om te onderscheppen omdat er niets geldigs wordt geproduceerd.
Elke eerdere authenticatiefactor, inclusief hardware-TOTP-tokens en push-meldingen, produceert een waarde die de gebruiker of browser naar de server stuurt. Die waarde kan worden doorgezonden. FIDO2 produceert een waarde die wiskundig gebonden is aan de legitieme oorsprong, dus doorsturen is nutteloos: de handtekening verifieert niet op de publieke sleutel van een ander domein.
NIST SP 800-63B-4 vereist phishing-bestendige authenticatie voor Authenticator Assurance Level 3 (AAL3). Zowel CISA als het NCSC identificeren FIDO2 en PIV smart cards als de enige vormen van authenticatie die kwalificeren. TOTP en push-meldingen zijn geclassificeerd als phishing-vatbaar omdat ze doorgezonden waarden bevatten die een proxy in realtime kan doorzetten.
FIDO2 beschermt de aanmelding. Het beschermt de sessietoken niet zodra die is uitgegeven. Een gecompromitteerd apparaat kan zijn sessietoken nog steeds worden onttrokken na een legitieme authenticatie. Apparaatnaleidsbeleid via Conditional Access en Continuous Access Evaluation in Microsoft Entra ID behandelen sessielaagrisico afzonderlijk van de authenticatie zelf.
Passkeys in de praktijk: Microsoft, Google en Apple
Microsoft
Windows Hello for Business gebruikt TPM-backed apparaatgebonden passkeys die per machine worden geregistreerd. De prive-sleutel wordt bij registratie gegenereerd in de TPM en kan niet worden geexporteerd. Microsoft Authenticator ondersteunt nu passkeys voor zowel consumenten- als werkaccounts. In mei 2026 schakelde Microsoft alle consumenten-Microsoft-accounts over naar passkey-first authenticatie, waarbij sms-OTP als standaard aanmeldmethode werd afgeschaft. Bedrijfsimplementaties controleren welke FIDO2-methoden zijn toegestaan via Authentication Methods-beleid in Microsoft Entra ID, en handhaving verloopt via Conditional Access Authentication Strengths.
Apple
iCloud Keychain synchroniseert passkeys over alle Apple-apparaten die zijn aangemeld bij dezelfde Apple ID, met end-to-end versleutelde synchronisatie. Face ID of Touch ID levert de lokale biometrische verificatiestap. Passkeys op Apple-platforms zijn beschikbaar vanaf iOS 16 en macOS Ventura. Cross-platform gebruik, zoals aanmelden op een Windows-apparaat met een iPhone-passkey, verloopt via een QR-code en Bluetooth-nabijheidsverificatie: de gebruiker scant de QR-code met zijn telefoon, die fysieke nabijheid bevestigt en vervolgens de FIDO2-ondertekening lokaal uitvoert.
Google Password Manager synchroniseert passkeys over Android-apparaten en Chrome op elk desktopplatform, beschikbaar vanaf Android 9. Google Workspace ondersteunt FIDO2 voor werknemersauthenticatie. De Chrome-passkey-implementatie verwerkt zowel platform-authenticators als roaming FIDO2-authenticators verbonden via USB of NFC.
Hardware-beveiligingssleutels
Roaming FIDO2-authenticators van fabrikanten zoals YubiKey, Google Titan en Feitian werken op elk apparaat met USB-A, USB-C of NFC. De prive-sleutel wordt bij fabricage of registratie op de hardware gegenereerd en kan door geen enkel softwaremiddel worden geextraheerd. Ze zijn de beste keuze voor bevoorrechte accounts, gedeelde werkstations of omgevingen waar het synchroniseren van inloggegevens via cloudservices onwenselijk is. Na een configureerbaar aantal mislukte pincodepogingen vergrendelen hardwaresleutels en vereisen ze een reset, waardoor brute-force-aanvallen op de pincode worden voorkomen.
Bedrijfsimplementatie: de echte uitdagingen
Compatibiliteit van legacy-applicaties
Moderne browsers en alle grote cloudidentiteitsplatforms ondersteunen WebAuthn standaard. Het gat zit bij on-premise applicaties die authenticeren via RADIUS, NTLM, Kerberos wachtwoordgebaseerde flows of proprietary webauthenticatie die dateert van voor de WebAuthn-specificatie. Die kunnen een FIDO2-bewering niet direct verwerken. Breng uw authenticatiestack in kaart voordat u met een implementatie begint. Applicaties die federeren naar Entra ID of een andere moderne identiteitsprovider via SAML of OIDC kunnen passkey-authenticatie van de identiteitsprovider overnemen zonder wijzigingen aan de applicatie zelf. Applicaties die zelfstandig authenticeren moeten worden geupgraded, gemigreerd naar een moderne identiteitsprovider of voorzien van een proxy die de authenticatievertaling afhandelt.
Gedeelde en kiosk-accounts
Passkeys zijn gebruikersgebonden en apparaatgebonden. Ze zijn niet ontworpen om te worden gedeeld, en het proberen te delen ondermijnt het beveiligingsmodel door de binding tussen een specifieke persoon en de inloggegevens op te heffen. Gedeelde werkstations vereisen een andere aanpak. Windows Hello for Business met gedeelde apparaatmodus stelt individuele gebruikers in staat te authenticeren met hun eigen inloggegevens op een gedeeld apparaat. Hardware-beveiligingssleutels toegewezen aan het werkstation met een bekende pincode zijn een andere optie, hoewel dit het zekerheidsniveau verlaagt. Voor roosterpersoneel dat roteert over apparaten bieden Temporary Access Passes een tijdgebonden, gecontroleerde authenticatiemethode die de kloof overbrugt tijdens registratie.
Gebruikerstraining
De aanmeldbeleving verandert. Gebruikers die een gebruikersnaam- en wachtwoordveld verwachten, krijgen een biometrische prompt, een verzoek om een apparaatpincode, of een tik op een hardwaresleutel. Zonder voorbereiding genereert dit verwarring, servicedeskaanvragen en weerstand. Voer een gestructureerde pilot uit met IT- en beveiligingspersoneel, documenteer elk wrijvingspunt in de registratie- en dagelijkse aanmeldflow, en breid uit naar een bredere gebruikersgroep met duidelijke interne communicatie.
Herstelplanning
NIST vereist dat herstelmechanismen ten minste zo sterk zijn als de primaire authenticator. Dit sluit e-mailgebaseerde herstellinks uit voor een FIDO2-implementatie, aangezien e-mailaccounts doorgaans veel zwakker zijn dan de passkey die ze zouden bypassen. Praktische herstelOpties zijn: een tweede apparaat of hardwaresleutel registreren als back-upauthenticator bij de eerste registratie; Temporary Access Pass in Entra ID gebruiken als tijdgebonden wachtwoordloze code voor gecontroleerde herstelscenarios; of een formele identiteitsverificatieprocedure voor herregistratie via de servicedesk implementeren. De kritieke beperking: het herstelproces moet zijn ontworpen, gedocumenteerd, getest en bekend bij uw servicedesk voordat u wachtwoord-fallback voor een gebruikersgroep uitschakelt.
Ontwerp het herstelproces niet na de implementatie. De meeste passkey-projecten lopen tegen hun eerste echte probleem aan wanneer een gebruiker zijn enige geregistreerde apparaat verliest en er geen herstelpad is. Het identiteitsverificatieproces voor herregistratie moet bestaan, zijn gedocumenteerd, zijn getest en bekend zijn bij uw servicedesk voordat u wachtwoord-fallback uitschakelt voor een gebruikersgroep.
Conditional Access en passkey-handhaving in Microsoft Entra ID
Entra ID Authentication Strengths, beschikbaar sinds eind 2023, stellen u in staat te specificeren welke authenticatiemethoden acceptabel zijn als voorwaarde in een Conditional Access-beleid. Het aanmaken van een aangepaste Authentication Strength die alleen FIDO2-beveiligingssleutels of Windows Hello for Business toestaat, creeert een afdwingbare vereiste: gebruikers die niet kunnen voldoen met een kwalificerende authenticator worden volledig geblokkeerd, niet doorgestuurd naar een zwakkere authenticatievorm. Dit is het mechanisme dat een mogelijkheid omzet in een verplichting.
Voor configuratie: navigeer naar Beveiliging, vervolgens Authenticatiemethoden, dan Authentication Strengths, en maak een nieuwe aangepaste sterkte. Schakel FIDO2-beveiligingssleutels en Windows Hello for Business in als toegestane methoden. Wijs deze sterkte toe als vereiste in een Conditional Access-beleid voor bevoorrechte rollen, beheerdersportals of uw meest gevoelige applicaties.
Temporary Access Pass (TAP) biedt een tijdgebonden, enkelvoudig of meervoudig bruikbare wachtwoordloze pincode voor gebruikers die een nieuwe passkey moeten registreren of herstellen van een verloren apparaat. Stel de geldigheidsperiode in op uren, niet op dagen. Schakel de pass na gebruik uit. TAP is de gecontroleerde brug die de informele en onveilige praktijk vervangt van het tijdelijk uitschakelen van MFA-vereisten voor betrokken gebruikers.
Voor bevoorrechte accounts beheerd via Privileged Identity Management (PIM): vereist passkey-authenticatie als voorwaarde voor rolactivering. Dit zorgt ervoor dat zelfs als een aanvaller een geldig sessietoken heeft voor het standaardaccount van de gebruiker, ze niet kunnen escaleren naar beheerderstoegang zonder een fysieke passkey. De combinatie van PIM-gerichte activering en een passkey-vereiste verwijdert het meest schadelijke escalatiepad uit de meeste scenario's van gecompromitteerde inloggegevens.
Vijf stappen om dit kwartaal te starten
- Auditeer uw authenticatiestack: identificeer welke applicaties WebAuthn standaard ondersteunen, welke federeren naar uw identiteitsprovider via SAML of OIDC, en welke afhankelijk zijn van legacy-protocollen zoals RADIUS of NTLM. De gefedereerde en native applicaties kunnen worden gedekt in de eerste implementatiefase. Legacy-applicaties hebben een apart herstelplan nodig en mogen de implementatie voor al het andere niet blokkeren.
- Schakel FIDO2 in bij uw identiteitsprovider: navigeer in Entra ID naar Beveiliging, Authenticatiemethoden, en schakel FIDO2-beveiligingssleutels en passkeys in Microsoft Authenticator in. Dit ontgrendelt de mogelijkheid zonder die voor een gebruiker te verplichten. De aanmeldflow van niemand verandert totdat u een Authentication Strength-beleid maakt dat dat vereist.
- Pilot met IT- en beveiligingspersoneel: registreer tien tot twintig mensen met hardwarebeveiligingssleutels of platform-passkeys. Leid ze door de volledige aanmeldbeleving, de herstelflow en een gesimuleerd apparaatverliesscenario. Documenteer elk wrijvingspunt voordat u opschaalt. Het doel is de randgevallen vinden wanneer de impact beperkt is tot een kleine groep technisch bekwame gebruikers.
- Bouw en test uw herstelproces: definieer het Temporary Access Pass-proces of de identiteitsverificatieprocedure voor herregistratie. Informeer de servicedesk over hoe het eruitziet vanuit hun perspectief. Test het met een echt herstelscenario met een pilotgebruiker voordat een bredere groep wachtwoorden heeft uitgeschakeld. Herstel dat alleen in een document bestaat is geen herstel.
- Stel handhaving in per applicatierisiconiveau: gebruik Authentication Strength-beleid in Conditional Access om phishing-bestendige authenticatie te vereisen op beheerdersportals, financiele applicaties en e-mail eerst. Breid progressief uit naarmate het vertrouwen in het herstelproces groeit en gebruikerstraining elke groep bereikt. Probeer geen universele overschakeling op de eerste handhavingsdatum.
Ryland leidt cybersecurity-, compliance- en IT-beheertrajecten voor gereguleerde organisaties in het VK, Nederland en Brazilië met meer dan 20 jaar ervaring, inclusief senior functies bij Microsoft, ING en de NHS. Volledig profiel