Passkeys & FIDO2: Passwordless Authentication Explained

Passkeys are the most serious attempt yet to retire the password, and unlike earlier efforts, this one is backed by Apple, Google and Microsoft at the same time. According to the FIDO Alliance report "The State of Passkeys 2026" (published 7 May 2026), roughly 5 billion passkeys are now in active use worldwide. Yet confusion is everywhere: What exactly is a passkey? What is FIDO2, what is WebAuthn, and how does any of it relate to the hardware security keys you already know?

This article clears up the terminology and goes considerably deeper than the usual explainer. You will get a watertight hierarchy of terms (FIDO2 = WebAuthn + CTAP2, passkey as a discoverable credential), the cryptographic basis of phishing resistance, real, working code for browser registration and login, plus the native iOS equivalent in Swift. It also includes an honest section on the limits of passkeys that most vendors leave out, grounded in the nuanced assessment of the UK National Cyber Security Centre (NCSC).

By the end you will understand not only why passkeys effectively defeat phishing, but also where their real weaknesses lie (recovery, ecosystem lock-in, enterprise rollout) and how to adopt passkeys sensibly, whether you are an individual user or an organisation.

What are passkeys and FIDO2? Sorting out the terms

The most common mistake in explainer articles is treating passkeys and FIDO2 as the same thing, or as competitors. Both are wrong. The clearest one-liner comes from identity provider Corbado: "FIDO2 is a standard; passkeys are its implementation." Let us build it from the bottom up.

FIDO2 = WebAuthn + CTAP2

FIDO2 is not a single protocol. It is the FIDO Alliance's umbrella term for the combination of two complementary specifications:

WebAuthn (Web Authentication) is the official standard of the World Wide Web Consortium (W3C). It defines the browser and client API, specifically the calls navigator.credentials.create() (registration) and navigator.credentials.get() (sign-in). WebAuthn describes the abstract operations between a web application and the client.
CTAP2 (Client to Authenticator Protocol 2) is the FIDO Alliance specification governing communication between the client device (for example a laptop) and an external authenticator (for example a USB security key) over USB, NFC, Bluetooth Low Energy (BLE) or the newer hybrid transport.

The relationship between the two matters: they are not competing standards, but two layers of the same project. WebAuthn defines what happens (create a credential, sign a challenge), and CTAP2 provides the concrete parameters and commands for how the device does it. Germany's Federal Office for Information Security (BSI), itself a member of the FIDO Alliance since 2015, aptly calls WebAuthn the "core component of FIDO2".

What exactly is a passkey?

A passkey is a FIDO2 credential presented under a user-friendly name, not a separate technical standard. The term was deliberately chosen to be consumer-friendly and platform-neutral. According to the FIDO Alliance, "passkey" is a common noun (lowercase except at the start of a sentence). It was coined in 2022 by Apple, Google and Microsoft as part of their joint multi-device FIDO credentials initiative.

Technically, a passkey is a so-called discoverable credential (more on that below). The key point: passkey is the marketing and UX term, while WebAuthn and CTAP2 are the technical specifications underneath. The word "passkey" does not even appear in the CTAP specifications themselves.

That gives us this hierarchy:

FIDO2 is the FIDO Alliance's standard bundle.
WebAuthn (W3C) and CTAP2 (FIDO Alliance) are the two specifications that make up FIDO2.
Passkey is the user-friendly name for a sign-in credential created with it.

How does passkey authentication work cryptographically?

At the heart of every passkey is asymmetric cryptography, meaning a key pair consisting of a private and a public key. Unlike traditional passwords, there is no shared secret that could be stolen.

According to the BSI, three roles are involved in every passkey interaction, and the W3C WebAuthn specification defines them the same way:

Relying Party (RP): the online service or website you sign in to. It is identified by its RP ID (essentially its domain).
Client: the browser or operating system that exposes the WebAuthn API.
Authenticator: the cryptographic entity that generates and stores the keys. It can be built into the device (a platform authenticator, such as Windows Hello or the Secure Enclave in an iPhone) or external (a roaming authenticator, such as a YubiKey).

Registration: the key pair is created

During registration, the authenticator generates a brand-new key pair, one secret private key and a matching public key. The private key never leaves the device's secure hardware. Only the public key travels to the relying party, where it is stored against your account.

Domain binding is decisive here: an authenticator must create a separate key pair for every website and every user. This is technically enforced, not merely recommended. That is exactly where phishing resistance comes from: a passkey created for bank.com simply will not work on bank-secure-login.com.

Sign-in: challenge and response

Every sign-in runs a challenge-response exchange. The BSI describes it precisely: the website sends the client a message containing a cryptographic challenge, which is "nothing more than a sufficiently large random number". The authenticator signs that challenge with the private key, and the website verifies the signature against the public key it stored during registration.

Microsoft describes the same flow step by step in its Entra ID documentation:

The user initiates sign-in with the relying party.
They choose a passkey (same device, cross-device via QR code, or a FIDO2 security key).
The service sends a challenge (nonce) to the authenticator.
The authenticator locates the matching key pair via the hashed RP ID and credential ID.
The user performs a biometric or PIN gesture to unlock the private key.
The authenticator signs the challenge and returns the signature.
The service verifies the signature with the public key and issues a token.

Because the secret (the private key) never leaves the device and is never transmitted, classic attacks such as phishing, credential stuffing, replay or harvesting from a leaked database are effectively useless. Even a successful server breach yields only public keys, which no one can sign in with.

The key technical terms in detail

This is where precision separates from half-knowledge. You should be able to keep these terms apart cleanly.

Discoverable credential (resident key)

A discoverable credential, called a resident key in the CTAP2 world, is defined by the W3C as a "public key credential source which is discoverable and usable in authentication ceremonies where the relying party does not provide any credential IDs". In plain terms: the authenticator can find the right credential on its own, without you typing a username first. That is precisely what enables "usernameless" sign-in, where you just tap a button and confirm with biometrics. In CTAP2 this corresponds to the rk option flag on the authenticatorMakeCredential command. Every passkey in today's usage is such a discoverable credential.

Attestation

Attestation, per the W3C, is a "statement about the provenance and characteristics of the authenticator" made during registration. It gives a relying party a cryptographically verifiable device identity, checked against the FIDO Metadata Service (MDS). This lets an organisation insist that only specific, certified authenticator models be accepted.

Important and often overlooked: synced passkeys do not support attestation (Microsoft Entra documentation). If a relying party enforces attestation, only device-bound passkeys and hardware security keys are effectively allowed; synced passkeys are then excluded. In Microsoft Entra ID this can be configured at the passkey-profile level.

User presence vs. user verification

These two are frequently confused but mean different things:

User presence (UP) is merely an interaction gesture, such as touching a security key. It confirms that a human is present, but does not check their identity.
User verification (UV) requires a real identity check via biometrics (fingerprint, face) or a PIN. Only this turns the passkey, in the BSI's words, into a de facto two-factor operation and thus a form of multi-factor authentication: possession of the device plus knowledge (PIN) or inherence (biometrics).

This is why the BSI stresses that passkeys need a second factor: without a biometric hurdle, "anyone who finds a smartphone, borrows a laptop or steals a tablet could compromise the owner's accounts".

Synced vs. device-bound passkeys

This is the most important practical distinction, and the BSI provides the clearest critical framing.

Device-bound (hardware-bound): the key is "bound to exactly the authenticator on which it was created" (BSI). It cannot be copied or synced. Examples: FIDO2 security keys such as a YubiKey, or a passkey bound to the Microsoft Authenticator app.
Synced (cloud-based): the keys "are therefore duplicable, can be stored in a cloud or synchronised across further devices" (BSI). As a result they survive the loss of a single device. Examples: Apple iCloud Keychain, Google Password Manager.

Microsoft adds the technical detail for synced passkeys: a Hardware Security Module (HSM) generates the key, encrypts it locally, and only then syncs it to the provider's cloud. Other devices authenticated with the same provider can then use the passkey.

That convenience has a price, and the BSI names it openly: with "the copyability and the storage of keys in provider clouds comes a certain loss of security. In theory the servers could be compromised, the keys copied and misused." This balanced view from a national security agency is missing from almost every marketing-flavoured explainer.

Passkey vs. classic FIDO2 security key

A common misconception is that a passkey and a FIDO2 security key are opposites. They are not. A classic USB or NFC security key (such as a YubiKey) generates and stores its key pair strictly in hardware, but it can equally hold a discoverable credential, that is, a passkey in the technical sense.

So the difference is not in the protocol (both use FIDO2, WebAuthn and CTAP2), but in storage location and syncability: dedicated, non-copyable hardware on one side, cloud-synced software credentials on the other. In common usage, "passkey" usually refers to the syncable, consumer-friendly variant, while "security key" refers to the hardware-bound one.

WebAuthn in practice: working code

This is exactly where competing articles fall short. Almost none show real code. The following examples are taken verbatim from the W3C WebAuthn specification and Google's official developer documentation (web.dev, last updated 9 April 2026). One caveat first: do not build the passkey server yourself. Google explicitly warns that doing so is "not time-effective, and may cause bugs that could lead to a critical security incident". Use an established WebAuthn library for server-side verification.

Registration options (server to client)

The relying party first supplies a PublicKeyCredentialCreationOptions object. Here is a typical options object:

{
  challenge: *****,
  rp: {
    name: "Example",
    id: "example.com",
  },
  user: {
    id: *****,
    name: "john78",
    displayName: "John",
  },
  pubKeyCredParams: [{
    alg: -7, type: "public-key"
  },{
    alg: -257, type: "public-key"
  }],
  excludeCredentials: [{
    id: *****,
    type: 'public-key',
    transports: ['internal'],
  }],
  authenticatorSelection: {
    authenticatorAttachment: "platform",
    requireResidentKey: true,
  }
}

The key fields, per the W3C specification:

challenge: server-generated random bytes that protect against replay attacks.
rp: the relying party's name and ID (domain).
user: account data with id, name and displayName.
pubKeyCredParams: accepted algorithms. The values are COSE identifiers: alg: -7 is ES256 (ECDSA with P-256 and SHA-256), alg: -257 is RS256 (RSASSA-PKCS1-v1_5 with SHA-256).
excludeCredentials: already registered credentials, to prevent duplicate registration.
authenticatorSelection: criteria for authenticator selection. requireResidentKey: true forces a discoverable credential (a true passkey), and authenticatorAttachment: "platform" prefers the built-in authenticator.

Creating the passkey (client)

On the client side, the web app calls navigator.credentials.create(). The modern approach uses the helper parseCreationOptionsFromJSON() to turn the server's JSON response directly into the required format:

const _options = await fetch('/webauthn/registerRequest');
const decoded_options = await _options.json();
const options = PublicKeyCredential.parseCreationOptionsFromJSON(decoded_options);

const credential = await navigator.credentials.create({
  publicKey: options
});

The minimal core form of the call, taken from the W3C specification, looks like this:

navigator.credentials.create({ publicKey })
  .then(function (newCredentialInfo) {
    // Send new credential info to server
  }).catch(function (err) {
    // Handle error
  });

After biometric confirmation, the authenticator generates the key pair and returns a public key credential. You send this to the backend, which permanently stores the public key and the credential ID:

const _result = credential.toJSON();
const result = JSON.stringify(_result);

const response = await fetch('/webauthn/registerResponse', {
  method: 'post',
  credentials: 'same-origin',
  body: result
});

Sign-in (login)

For sign-in, the relying party calls navigator.credentials.get() with a PublicKeyCredentialRequestOptions object. The core form from the W3C specification:

navigator.credentials.get({ "publicKey": options })
  .then(function (assertion) {
    // Send assertion to server for verification
  }).catch(function (err) {
    // Handle error
  });

Per the specification, the request options contain the mandatory challenge, and optionally timeout, rpId, allowCredentials (which can be left empty for discoverable credentials) and extensions. The authenticator produces a signed assertion, which the backend verifies against the stored public key.

Reporting orphaned credentials

A useful detail from WebAuthn Level 3: if the server no longer recognises a credential (for example after account deletion), the client can inform the passkey provider so it removes the orphaned passkey from its list:

if (response.status === 404) {
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "example.com",
      credentialId: "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA"
    });
  }
}

Such signal methods (signalUnknownCredential, signalAllAcceptedCredentials, signalCurrentUserDetails) and getClientCapabilities() are additions in WebAuthn Level 3 over Level 2.

Passkeys natively on iOS: Swift code

On the web you use the WebAuthn JavaScript API. In native iOS apps, Apple's AuthenticationServices framework does the same job through the ASAuthorizationPlatformPublicKeyCredentialProvider class. Prerequisite: the relyingPartyIdentifier (the domain) must match exactly the domain configured via the Associated Domains capability, otherwise passkey creation fails.

Creating a registration request

let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
    relyingPartyIdentifier: "example.com")

let registrationRequest = provider.createCredentialRegistrationRequest(
    challenge: challenge, displayName: email, userID: userID)

let authController = ASAuthorizationController(authorizationRequests: [registrationRequest])
authController.delegate = self
authController.presentationContextProvider = self
authController.performRequests()

Registration callback

In the delegate callback you cast the result to ASAuthorizationPlatformPublicKeyCredentialRegistration and extract the credential ID, client data JSON and attestation object for server-side verification:

func authorizationController(
    controller: ASAuthorizationController,
    didCompleteWithAuthorization authorization: ASAuthorization
) {
    if let credential = authorization.credential
        as? ASAuthorizationPlatformPublicKeyCredentialRegistration {
        let credentialID = credential.credentialID
        let clientDataJSON = credential.rawClientDataJSON
        let attestationObject = credential.rawAttestationObject
        // Send these values to backend for verification
    }
}

Sign-in and case distinction

For login you create an assertion request. The same delegate callback then cleanly distinguishes between registration (attestation) and sign-in (assertion):

let request = credentialProvider.createCredentialAssertionRequest(challenge: challenge)

func authorizationController(
    controller: ASAuthorizationController,
    didCompleteWithAuthorization authorization: ASAuthorization
) {
    switch authorization.credential {
    case let registration as ASAuthorizationPlatformPublicKeyCredentialRegistration:
        // Send attestation data to backend (finish registration)
    case let assertion as ASAuthorizationPlatformPublicKeyCredentialAssertion:
        let signature = assertion.signature
        let clientDataJSON = assertion.rawClientDataJSON
        let authenticatorData = assertion.rawAuthenticatorData
        let credentialID = assertion.credentialID
        // Send signature and related data to backend (finish login)
    default:
        break
    }
}

The pattern is the same on every platform: the client creates or uses the credential locally, and your backend verifies it cryptographically. The backend is the trust anchor, never the client.

CTAP2 under the hood: what the device actually does

WebAuthn only describes the browser side. The moment an external authenticator such as a YubiKey enters the picture, CTAP2 governs the communication. The abstract WebAuthn operations map onto concrete CTAP commands:

navigator.credentials.create() triggers, at the device level, the CTAP command authenticatorMakeCredential (0x01).
navigator.credentials.get() corresponds to authenticatorGetAssertion (0x02).

The parameters translate cleanly (the WebAuthn-to-CTAP mapping): WebAuthn requireResidentKey becomes the CTAP option options.rk, requireUserVerification becomes options.uv or a pinUvAuthParam, and rpEntity becomes CTAP rp. The data is encoded in CBOR (Concise Binary Object Representation).

For cross-device authentication (CDA), that is, signing in on one device with the passkey of another, the hybrid transport from CTAP 2.2 is responsible. It is initiated by QR code and uses Bluetooth Low Energy only for a proximity check, while the actual cryptographic security remains independent of Bluetooth. According to Yubico's developer documentation (as of 22 May 2026), the current FIDO2 certification baseline is now CTAP 2.3, fully backward-compatible with 2.2.

You do not need to master these protocol details to build an integration; your WebAuthn library and the operating system handle the mapping. But it explains why FIDO2 consists of two specifications: WebAuthn alone could not talk to an external security key at all.

Numbers and adoption: what is documented and what is not

Be careful with passkey statistics, because different issuers publish similar-sounding but non-identical figures. For each number we therefore state the source, the population and the timeframe.

Solid primary sources

The most methodologically sound source is the FIDO Alliance report "The State of Passkeys 2026" (7 May 2026), conducted by Sapio Research:

Roughly 5 billion passkeys are in active use worldwide.
90 % of consumers are aware of passkeys, and 75 % have enabled them on at least one account. Population: 11,000 adults across ten countries, regular login users, surveyed in April 2026, margin of error ±0.9 percentage points.
68 % of organisations are deploying, piloting or rolling out passkeys for workforce authentication. Population: 1,400 decision-makers at organisations with 500 or more employees, the same ten countries, April 2026, margin of error ±2.6 percentage points.

On speed there are two separate figures from Microsoft that must not be mixed:

Per Microsoft's Entra ID documentation, 99 % of users successfully register synced passkeys. Microsoft reports the speed there as two separate telemetry figures that should not be combined into a single multiplier: sign-in is roughly 14 times faster than password plus traditional MFA on the one hand, and takes an average of 3 seconds versus 69 seconds on the other. Microsoft additionally reports sign-in as three times more successful (95 % vs. 30 %). Important: these figures come from internal telemetry of "hundreds of millions" of Microsoft consumer accounts, not from enterprise Entra ID in general, and not across industries.
Distinct from that is a second figure cited by the UK NCSC: passkey sign-ins took "on average 8 seconds compared with 69 seconds using a traditional password and second factor". The source, per the NCSC, is the Microsoft Security Blog of December 2024, a different measurement from the Entra telemetry.

Individual company case studies

The FIDO Alliance collects a series of single-company figures on its passkeys page. Each number comes from a different company with its own methodology, so these are not representative aggregate statistics:

6x faster sign-in (Amazon).
4x higher success rate than passwords (Google).
50 % lower login abandonment (Air New Zealand).
98 % reduction in mobile account takeovers (CVS Health).
70 % higher sign-in conversion (Dashlane).

These values illustrate the trend, but they only hold up when cited with company and context, not as universal metrics.

The limits of passkeys: the honest part

Almost every explainer ends on a hymn of praise. That is dishonest. The UK NCSC named the real weaknesses in its post "Passkeys: they're not perfect but they're getting better" (15 January 2025). Anyone adopting passkeys should know them.

Account recovery becomes the real weak point

The stronger the actual authentication, the more attackers shift their focus to the recovery processes. When the login is effectively unassailable, the "forgot password" or "lost device" path becomes the most rewarding target for phishing and social engineering. These backend systems must be hardened, the NCSC says, or the entire security gain evaporates. A passkey is only as strong as its weakest recovery path.

Device loss and missing backups

For device-bound passkeys the question is: what happens if the only device breaks or is lost? Recovery depends on users having set up backups in their credential manager beforehand, a preparatory step that, per the NCSC, many simply never take. Without a second device or a synced passkey, permanent lockout looms.

Ecosystem lock-in and portability

Synced passkeys have so far lived within their provider's ecosystem. A passkey created in iCloud Keychain cannot easily be carried over to Bitwarden or Google Password Manager. The NCSC calls transferring passkeys between providers "currently challenging to do", which effectively locks users in. This problem is being actively addressed (see the next section), but is not yet solved across the board.

Inconsistent terminology and unclear MFA status

Different platforms name the same process differently, which confuses and deters users. More serious for enterprises: there is no consensus on whether every passkey type counts as full multi-factor authentication. Synced, potentially shareable passkeys in particular raise the question, for regulated domains (banking, powers of attorney), of whether they are secure enough. That creates regulatory uncertainty.

Accessibility and shared devices

Passkeys assume exclusive device access and biometric capabilities. Shared household devices, public library computers or users with biometric limitations are left underserved. Multi-domain setups too (for example example.co.uk and example.com) require separate passkeys each, which complicates implementation for service providers.

Despite these points, the NCSC's recommendation is unambiguous: consumers should use passkeys now, because they "protect you from the most widespread attacks". The limitations are reasons for care during rollout, not reasons to wait.

Passkey portability: CXP and CXF

The lock-in problem has a name and a solution in progress. Because passkeys rest on cryptographic key pairs, there was long no standardised export and import format, unlike passwords, which can (insecurely, but at least) be exported as CSV. The FIDO Alliance is developing two complementary specifications for this:

CXF (Credential Exchange Format): a JSON-based data format for credentials with four types (public-key-credential, password, totp, note), extensible for future types. It also enables local, on-device transfers. CXF was published as a Review Draft on 13 March 2025.
CXP (Credential Exchange Protocol): the secure transport layer using Hybrid Public Key Encryption (HPKE), end-to-end encrypted for cross-provider transfer. The goal is formal standard status in early 2026.

The initiative is driven by Apple, Google, Microsoft, 1Password, Bitwarden and Dashlane. Apple has already shipped CXF-based on-device credential transfer in iOS and macOS 26. An important distinction: CXP and CXF solve the cross-provider migration problem (say, Apple to Bitwarden), not synchronisation within one ecosystem, which is the older synced-passkey concept.

Adopting passkeys: practical steps for users and organisations

For individual users

Getting started is low-friction because the major platforms already support passkeys:

Check which services offer passkeys. Google, Apple, Microsoft, Amazon, PayPal and many more support them. You will usually find a "create a passkey" option in each account's security settings.
Use your existing password manager or platform keychain. Apple iCloud Keychain and Google Password Manager sync passkeys automatically across your devices, so losing one device does not lock you out.
Set up a second path. Where possible, register a passkey on more than one device, or add a hardware security key as a backup. This defuses exactly the recovery weakness the NCSC describes.
Keep your password as a fallback for now, until you are confident your passkey setup works reliably.

For organisations

The enterprise rollout is more demanding and should be phased and embedded into your existing identity and access management. Proven guardrails:

Offer passkeys in parallel, do not force them immediately. Google, Microsoft and the IPG Group all recommend keeping existing methods (password, traditional MFA) during the transition, because of incomplete platform support and user readiness.
Match the authenticator type to the protection need. Microsoft recommends device-bound FIDO2 security keys for heavily regulated domains or privileged users, since (unlike synced passkeys) they support attestation. For the broad workforce, synced passkeys are the cheaper, more convenient choice.
Use attestation deliberately. In Microsoft Entra ID, attestation can be enforced at the passkey-profile level. When it is active, only certified, device-bound passkeys are allowed, useful for high-security accounts but incompatible with cloud passkeys.
Harden recovery processes. Since attackers pivot to recovery when authentication is strong (NCSC), the recovery backend belongs at the top of the priority list.
Fit them into the compliance framework. Passkeys support the phishing-resistant authentication called for in the context of NIS2, DORA and TISAX, among others, and integrate well into a zero-trust architecture and your existing identity and access management.

Passkeys are a particularly strong form of multi-factor authentication and the most effective known defence against phishing attacks, because they completely eliminate the shared secret that makes phishing exploitable in the first place.

FAQ

Are passkeys really more secure than passwords?

Yes, and the reason is structural. With a passkey, the private key never leaves the device's secure hardware, and every credential is firmly bound to a single domain. There is no shared secret that could be harvested. As a result, phishing, credential stuffing, replay attacks and leaked databases are effectively neutralised. Even a successful server breach yields only public keys, which no one can sign in with.

What happens to my passkeys if I lose my phone?

It depends on the passkey type. Synced passkeys (for example in Apple iCloud Keychain or Google Password Manager) are backed up automatically across your devices, so losing one device does not lock you out. Device-bound passkeys require you to have set up a backup beforehand by registering a passkey on a second device or adding a hardware security key. Without that preparatory step, permanent lockout looms. This is exactly why account recovery is the real weak point you should secure.

Are passkeys a form of two-factor authentication?

In practice, yes: once user verification via biometrics or a PIN is active, the passkey becomes, in the BSI's words, a de facto two-factor operation, namely possession of the device plus knowledge (PIN) or inherence (biometrics). However, there is still no industry-wide consensus on whether every passkey type counts as full multi-factor authentication. Synced, potentially shareable passkeys in particular leave the MFA status unresolved for regulated domains.

Can I sync passkeys between Apple, Google, and Microsoft?

Not easily at the moment. Synced passkeys have so far lived within their provider's ecosystem, so a passkey created in iCloud Keychain cannot simply be carried over to Google or Bitwarden. The NCSC calls transferring passkeys between providers "currently challenging to do". The FIDO Alliance is working on exactly this cross-provider migration through the CXP and CXF standards, and Apple has already shipped CXF-based on-device transfer in iOS and macOS 26.

What is the difference between a passkey and FIDO2?

FIDO2 is the technical standard, more precisely the FIDO Alliance's standard bundle of WebAuthn (W3C) and CTAP2. A passkey is the user-friendly name for a sign-in credential created with it, technically a discoverable credential. In short: FIDO2 is the standard, and the passkey is its implementation. Passkey is the UX term, while WebAuthn and CTAP2 are the specifications underneath.

Conclusion

Passkeys are not a marketing promise but a mature, standardised technology built on FIDO2 (that is, WebAuthn and CTAP2). Their decisive advantage is structural: because the private key never leaves the device and every credential is bound to exactly one domain, phishing, credential stuffing and database leaks come to nothing. The documented figures from the FIDO Alliance and Microsoft also show faster and more successful sign-ins.

At the same time, passkeys are not perfect. The honest weaknesses lie not in the cryptography but around it: in account recovery, in ecosystem lock-in (which CXP and CXF are working on), and in inconsistent terminology. For individual users, the recommendation from the BSI and the NCSC is nonetheless clear: adopt them, but with a backup path. For organisations: roll out in stages, match the authenticator type to the risk, and above all harden the recovery processes with the same care as the login itself. Do that, and you replace the weakest link in security, the password, with one of the strongest.