Det intressanta med Passkeys och WebAuthn är hur snabbt teori möter drift: en kontroll måste fungera även när systemet uppdateras, felsöks och utsätts för fel. Passkeys bygger på publika nycklar och origin-bunden autentisering, vilket gör dem motståndskraftiga mot klassisk phishing på ett sätt som delade hemligheter inte är.
Passkeys och WebAuthn i praktiken
Första byggstenen: WebAuthn använder en unik credential per relying party. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: Den privata nyckeln lämnar normalt inte authenticatorn. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Origin-kontrollen gör att en falsk webbplats inte kan använda credentialen för rätt domän. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: Recovery och synkronisering måste bedömas utifrån organisationens hotmodell. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Så skulle jag testa det i en riktig miljö
- Börja med konton där phishingrisken är hög.
- Registrera mer än en godkänd recovery-väg.
- Testa olika klienter och plattformar som verksamheten använder.
- Behåll tydlig policy för borttappad enhet.
- Mät hur fallback-metoder påverkar den faktiska säkerhetsnivån.
För Passkeys och WebAuthn håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Praktiskt exempel
För privilegierade konton är det särskilt värdefullt att testa en riktig phishingdomän i ett kontrollerat labb: användaren kan luras visuellt, men credentialen ska ändå inte vara giltig för angriparens origin.
Misstag som skapar falsk trygghet
- Att införa passkeys men behålla en svag SMS-fallback för alla.
- Att sakna process när den enda authenticatorn går sönder.
- Att anta att alla passkeyimplementationer har samma recoverymodell.
Verifiering före stängning
För Passkeys och WebAuthn vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Inloggning misslyckas på fel origin.
- Borttappad enhet kan hanteras utan att helpdesk kringgår identitetskontrollen.
- Administratörskonton har minst två robusta autentiseringsvägar.
Ett negativt test hör också till Passkeys och WebAuthn: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
Passkeys och WebAuthn – phishingresistent inloggning utan traditionella lösenord handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.