{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/passkey","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/passkey/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/passkey/"},"term":{"en":"Passkey","da":"Passkey"},"aka":{"en":["FIDO credential","discoverable credential"],"da":["FIDO-nøgle"]},"domain":["cs"],"cluster":"identity","layer":"identity","status":"emerging","era":2022,"summary":{"en":"A login without a password, where your device proves who you are with a secret key that never leaves it.","da":"Et login uden adgangskode, hvor din enhed beviser, hvem du er, med en hemmelig nøgle, der aldrig forlader den."},"body":{"formal":{"en":"A credential built on public-key cryptography under the FIDO standards, where the device keeps a private key for each site and signs a fresh challenge with it after the user unlocks with a fingerprint, face or PIN; the site stores only the public key.","da":"En loginoplysning bygget på asymmetrisk kryptografi efter FIDO-standarderne, hvor enheden har en privat nøgle for hvert website og signerer en ny udfordring med den, når brugeren låser op med fingeraftryk, ansigt eller PIN; websitet gemmer kun den offentlige nøgle."},"plain":{"en":"Like a key that never leaves your key ring and turns only in your own front door - there is no code to say out loud, so a fake door gets nothing from you.","da":"Som en nøgle, der aldrig forlader dit nøglebundt og kun passer i din egen hoveddør - der er ingen kode at sige højt, så en falsk dør får intet ud af dig."},"inPractice":{"en":"A case officer at a Danish region opens the staff portal on her work laptop and touches the fingerprint reader when asked to use her passkey; she is in with nothing typed and nothing a fake site could capture.","da":"En sagsbehandler i en region åbner medarbejderportalen på sin arbejdscomputer og rører fingeraftrykslæseren, da hun bliver bedt om at bruge sin passkey; hun er inde uden at taste noget, og en falsk side har intet at opsnappe."},"whyItMatters":{"en":"Passwords get guessed, used again and typed into fake pages; a passkey works only on the real site, and the server holds no shared secret worth stealing.","da":"Adgangskoder bliver gættet, genbrugt og tastet ind på falske sider; en passkey virker kun på det rigtige website, og serveren gemmer ingen fælles hemmelighed, der er værd at stjæle."}},"deepDive":{"en":"A passkey is a FIDO2 credential, meaning W3C Web Authentication (WebAuthn) between the relying party and the browser plus the FIDO Alliance's Client to Authenticator Protocol (CTAP 2) between the browser and an external authenticator. Technically it is a discoverable credential, formerly called a resident key: the authenticator stores the private key together with the RP ID and a user handle, so sign-in can begin without a user name, typically through autofill-style conditional mediation. WebAuthn Level 2 became a W3C Recommendation in April 2021, and Level 3 followed on 25 August 2026.\n\nAt registration the site calls navigator.credentials.create() with a random challenge, its RP ID (a registrable domain such as example.dk), a user ID and acceptable algorithms as COSE identifiers, usually -7 (ES256) and -257 (RS256), and requests residentKey \"required\" plus a user-verification preference. The authenticator generates a fresh key pair scoped to that RP ID and returns authenticator data containing the SHA-256 hash of the RP ID, a flags byte, a signature counter, the credential ID and the public key, optionally with an attestation statement. At sign-in, navigator.credentials.get() asks the authenticator to sign the authenticator data concatenated with the hash of clientDataJSON, which the browser fills with the type, the challenge and the actual origin. The server verifies the signature with the stored public key and checks challenge, origin, RP ID hash and the UP (user present) and UV (user verified) flags.\n\nPhishing resistance comes from that binding: the browser, not the user, asserts the origin, and the authenticator will not even offer a credential whose RP ID does not match the site, so a look-alike domain gets nothing to relay. This is verifier-name binding in the sense of NIST SP 800-63B-4 §3.2.5. Server-side, only public keys are stored, so a database breach yields nothing usable for login.\n\nPasskeys are either synced or device-bound. After the joint commitment by Apple, Google and Microsoft in May 2022, platforms began syncing passkeys through iCloud Keychain, Google Password Manager and third-party password managers; the BE (backup eligible) and BS (backup state) flags reveal this, and synced authenticators often report a signature counter of zero, which makes counter-based clone detection meaningless. SP 800-63B-4 accepts syncable authenticators up to AAL2 but not at AAL3, which requires a non-exportable key, so administrator and high-assurance use calls for device-bound passkeys on security keys or platform TPMs, often with attestation to verify the model. Cross-device sign-in uses the hybrid transport, a QR code plus a Bluetooth proximity check, so a phone can authenticate a laptop. The residual risks are the weakest remaining recovery or fallback method (SMS or password left enabled), compromise of the sync account, and theft of the session cookie issued after a perfectly phishing-resistant login.","da":"En passkey er en FIDO2-loginoplysning, dvs. W3C Web Authentication (WebAuthn) mellem relying partyen og browseren plus FIDO Alliances Client to Authenticator Protocol (CTAP 2) mellem browseren og en ekstern autentifikator. Teknisk er det en discoverable credential, tidligere kaldt resident key: Autentifikatoren gemmer den private nøgle sammen med RP ID og et bruger-handle, så login kan starte uden brugernavn, typisk via autofill-lignende conditional mediation. WebAuthn Level 2 blev W3C Recommendation i april 2021, og Level 3 fulgte den 25. august 2026.\n\nVed registreringen kalder websitet navigator.credentials.create() med en tilfældig udfordring (challenge), sit RP ID (et registrerbart domæne som example.dk), et bruger-id og de accepterede algoritmer som COSE-identifikatorer, typisk -7 (ES256) og -257 (RS256), og beder om residentKey \"required\" og en præference for brugerverifikation. Autentifikatoren genererer et nyt nøglepar afgrænset til det RP ID og returnerer authenticator data med SHA-256-hashen af RP ID, en flag-byte, en signaturtæller, credential-id'et og den offentlige nøgle, eventuelt med en attestation. Ved login beder navigator.credentials.get() autentifikatoren signere authenticator data sammensat med hashen af clientDataJSON, som browseren udfylder med typen, udfordringen og den faktiske origin. Serveren verificerer signaturen med den gemte offentlige nøgle og kontrollerer udfordring, origin, RP ID-hash og flagene UP (bruger til stede) og UV (bruger verificeret).\n\nPhishing-resistensen kommer af den binding: Det er browseren og ikke brugeren, der angiver origin, og autentifikatoren tilbyder slet ikke en loginoplysning, hvis RP ID ikke passer til websitet, så et forvekslingsdomæne får intet at videresende. Det er binding til verifierens navn i betydningen fra NIST SP 800-63B-4 §3.2.5. På serversiden gemmes kun offentlige nøgler, så et databasebrud giver intet, der kan bruges til login.\n\nPasskeys er enten synkroniserede eller enhedsbundne. Efter Apples, Googles og Microsofts fælles tilsagn i maj 2022 begyndte platformene at synkronisere passkeys via iCloud-nøglering, Google Password Manager og tredjeparts adgangskodeadministratorer; flagene BE (backup eligible) og BS (backup state) afslører det, og synkroniserede autentifikatorer returnerer ofte signaturtælleren nul, så tællerbaseret kloningsdetektion bliver meningsløs. SP 800-63B-4 accepterer synkroniserbare autentifikatorer op til AAL2, men ikke på AAL3, som kræver en nøgle, der ikke kan eksporteres; administratorer og brug med højt sikringsniveau kræver derfor enhedsbundne passkeys på sikkerhedsnøgler eller platform-TPM'er, ofte med attestation, så modellen kan verificeres. Login på tværs af enheder bruger hybrid-transporten, en QR-kode plus et Bluetooth-nærhedstjek, så en telefon kan autentificere en bærbar. De tilbageværende risici er den svageste tilbageværende gendannelses- eller reservemetode (SMS eller adgangskode, der stadig er slået til), kompromittering af synkroniseringskontoen og tyveri af den sessionscookie, der udstedes efter et fuldt phishing-resistent login."},"edges":[{"type":"requires","to":"cs/authentication","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/public-key-cryptography","confidence":"high","strength":"normal"},{"type":"kind-of","to":"cs/credential","confidence":"high","strength":"normal"},{"type":"alternative-to","to":"cs/password","why":{"en":"Both prove who you are at login; a passkey does it without anything to remember, type or reuse.","da":"Begge beviser, hvem du er, ved login; en passkey gør det uden noget at huske, taste eller genbruge."},"confidence":"high","strength":"primary"},{"type":"mitigates","to":"security/phishing","why":{"en":"The key is tied to the real site's address, so a copy of the login page gets nothing it can use.","da":"Nøglen er bundet til det rigtige websites adresse, så en kopi af loginsiden får intet, den kan bruge."},"confidence":"high","strength":"primary"},{"type":"mitigates","to":"security/credential-stuffing","why":{"en":"There is no password shared between sites, so logins leaked from one site cannot be tried on another.","da":"Der er ingen adgangskode, der deles mellem websites, så lækkede login fra ét website kan ikke prøves på et andet."},"confidence":"high","strength":"primary"}],"depth":3,"sources":[{"title":"FIDO Alliance - Passkeys","url":"https://fidoalliance.org/passkeys/","tier":"official-doc","publisher":"FIDO Alliance"},{"title":"W3C Web Authentication (WebAuthn)","url":"https://www.w3.org/TR/webauthn-2/","tier":"standard","publisher":"W3C"},{"title":"Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard (5 May 2022)","url":"https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins/","tier":"official-doc","publisher":"FIDO Alliance"},{"title":"W3C Web Authentication - An API for accessing Public Key Credentials, Level 3","url":"https://www.w3.org/TR/webauthn-3/","tier":"standard","publisher":"W3C"},{"title":"NIST SP 800-63B-4 - Authentication and Authenticator Management","url":"https://pages.nist.gov/800-63-4/sp800-63b.html","tier":"standard","publisher":"NIST"}],"draft":true}