Passkeys are FIDO credentials that replace shared passwords with public-key cryptography tied to a relying party. FIDO2 combines the W3C Web Authentication (WebAuthn) API used by websites/app platforms with the FIDO Client-to-Authenticator Protocol (CTAP) used between clients and external authenticators. WebAuthn Level 3 became a W3C Recommendation in August 2026, and FIDO Alliance continues to position passkeys as phishing-resistant credentials that can be synchronized by credential providers or kept device-bound.
Within Security Engineering, passkeys are most powerful when the entire account lifecycle—including enrollment, device migration, recovery, and step-up authentication—does not fall back to easily phished passwords or weak knowledge-based recovery.
The existing Zero Trust Identity Architecture article provides the wider identity-control context.
Every passkey is a public/private key credential
During registration, the authenticator creates a key pair scoped to the relying party. The server stores the public key and credential metadata; the private key stays under the passkey provider/authenticator’s control.
Authentication signs a server challenge with the private key.
There is no password-equivalent shared secret for a breached server database to expose.
WebAuthn binds credentials to the relying party
The browser/platform verifies the web origin and relying-party ID before letting a credential sign the challenge.
A phishing site on a lookalike domain cannot normally invoke the credential registered for the legitimate domain.
This origin binding is why FIDO authentication is resistant to credential phishing even when users can be tricked into visiting the attacker’s site.
CTAP connects external authenticators
CTAP is the FIDO protocol used when a browser/platform communicates with security keys or another external authenticator.
Together with WebAuthn it enables USB/NFC/BLE security keys and cross-device experiences while preserving the relying-party-bound credential model.
Do not call every WebAuthn credential a “hardware key”; synced passkeys can live in platform/provider credential managers.
Synced and device-bound credentials have different recovery trade-offs
Synced passkeys can move across a user’s trusted devices through an end-to-end encrypted passkey provider, improving usability and loss recovery.
Device-bound credentials remain tied to a particular authenticator and can fit high-assurance admin or regulated use cases.
Select based on threat model: consumer scale often favors secure sync, while privileged break-glass or workforce admin accounts may justify hardware-bound keys.
User verification is separate from relying-party authentication
Biometric or local PIN unlocks the authenticator and provides user verification; the biometric template is not sent to the website.
The relying party validates the cryptographic assertion and relevant flags.
Make product messaging clear: Face ID/fingerprint may unlock the passkey, but the server authenticates the passkey credential, not a copy of the user’s biometric.
Discoverable credentials enable username-less flows
Passkeys are typically discoverable/resident credentials, allowing the authenticator to identify available accounts for a relying party.
This can simplify sign-in and reduce username phishing/enumeration patterns.
Account-selection UX still needs privacy review on shared devices and support for users with multiple organization/consumer accounts.
Account recovery is the weakest link if left unchanged
FIDO’s current passkey deployment guidance emphasizes that full phishing prevention requires strengthening recovery as well as primary login.
If an attacker can bypass a passkey by calling support and resetting the account with email/SMS security questions, phishing resistance is only partial.
Design recovery with trusted devices, verified identity, recovery codes, multiple enrolled authenticators, or other high-assurance methods appropriate to the account risk.
Passkey registration must protect session integrity
An attacker who hijacks an authenticated session and adds their own passkey can create durable access.
Require recent/strong authentication or step-up for adding/removing credentials, show the user credential inventory, and notify them when authenticators change.
Log passkey enrollment and removal so account-takeover investigations can reconstruct credential lifecycle.
Attestation should be requested only when you need authenticator properties
WebAuthn attestation can give the relying party information about authenticator provenance/capabilities, but it can add privacy and operational complexity.
Consumer services often do not need strict authenticator attestation; workforce/high-assurance deployments may use it to require approved hardware.
Define the requirement from policy rather than enabling attestation because it sounds more secure.
Migration should avoid a permanent password fallback
Offer passkey creation after a trusted authentication, promote it as primary sign-in, and gradually reduce password use for users who have sufficient recovery coverage.
Monitor how often users fall back to passwords and why.
OpenID Connect Basics remains relevant because passkeys authenticate users at the identity provider while OIDC can federate that authentication into applications.
Passkeys succeed when phishing resistance covers login, enrollment, and recovery
The mature rollout uses WebAuthn/FIDO2 libraries, correct RP/origin configuration, secure sync or hardware-bound credentials as appropriate, protected enrollment, strong recovery, multiple authenticators for critical accounts, and telemetry on fallback paths.
Replacing the password prompt is only the first step; the security benefit comes from removing phishable shared secrets from the entire account lifecycle.
Relying-party ID configuration is foundational. WebAuthn credentials are scoped to an RP ID derived from the domain, so changes to domain structure, white-label domains, or application-hosting strategy can affect which passkeys are discoverable and usable. Plan domain/RP relationships before mass enrollment because moving credentials later may require users to register new passkeys.
Passkey provider account security matters for synced credentials. If a provider synchronizes passkeys across devices, recovery and authentication of the provider account becomes part of the relying party’s security posture. Organizations with high-assurance workforce requirements may choose managed platform accounts, device-bound security keys, or policy that limits which authenticator classes are accepted.
Attestation should be privacy-aware. Device model or authenticator provenance can become identifying metadata and can complicate BYOD programs. Ask for attestation only when policy genuinely requires approved hardware or assurance properties, and define how unsupported/new authenticators are handled so legitimate users are not locked out unnecessarily.
Registration should require explicit user intent. Do not silently create a passkey during unrelated activity without making the user understand which account/device/provider is being enrolled. Clear naming and credential-management UI reduce confusion when users later see several passkeys across personal and work devices.
Account linking deserves special care. If an application already supports passwords, social login, and enterprise OIDC, ensure passkey registration attaches to the correct authenticated account and cannot be abused to merge identities accidentally. High-risk linking should require recent authentication from both identities or an administrative workflow.
Passkeys reduce credential stuffing because each relying party receives a unique key pair rather than a reused shared password. That benefit disappears if the service still accepts the same password from every passkey-enabled user as an unrestricted fallback. Measure password-login volume after migration and progressively tighten fallback for accounts with sufficient recovery coverage.
Help-desk procedures should be redesigned before broad rollout. Support staff need clear methods to verify users, remove lost credentials, restore access, and identify social-engineering attempts. A passkey strategy can be undermined if an attacker can convince support to disable strong authentication and issue a weak temporary password without sufficient verification.
Privileged accounts should enroll multiple independent authenticators. An administrator who has one device-bound security key can be locked out by device loss; one synced provider can represent a concentration risk. Use multiple hardware keys or an approved mix of platform/synced and offline backup credentials, with secure storage and periodic sign-in tests.
Risk-based step-up can use passkeys even before passwords disappear completely. Require a passkey for sensitive account changes, administrator elevation, high-value transactions, or recovery while allowing a transitional password path for lower-risk login. This creates immediate phishing-resistance benefits while migration coverage grows.
Passkey telemetry should distinguish registration, authentication, fallback, recovery, failed user verification, device/provider type where privacy permits, and account changes. Track the percentage of active users with at least two recovery-capable credentials and the share of sign-ins still using passwords; those metrics show whether deployment is truly reducing phishing exposure.
Enterprise device management can strengthen workforce passkeys. Managed OS/browser policy can require screen lock, secure hardware, approved password/passkey providers, and security-key use for privileged groups. Relying parties should avoid duplicating controls the device platform can enforce more reliably, while still validating WebAuthn assertions correctly.
Recovery codes and backup credentials should be protected as seriously as passwords. Store one-time codes hashed where possible, make them revocable/regenerable, avoid displaying them repeatedly, and notify users when recovery is used. A strong passkey sign-in flow paired with weak static recovery secrets remains vulnerable to theft or social engineering.
Passkey rollout should cover service-to-service and recovery paths separately. Human passkeys do not replace workload identities, API keys, certificates, or OAuth client credentials used by applications. Avoid presenting passkeys as a universal credential strategy; use them for interactive human authentication while engineering strong non-human identity controls alongside.
Legacy browsers or platforms may not support the same passkey UX, cross-device flow, or conditional UI. Define minimum supported versions and a controlled compatibility path, then measure whether fallback users are concentrated in high-risk populations or outdated unmanaged devices. Compatibility should not become an indefinite excuse to preserve password login for everyone.
High-risk actions can require fresh user verification even during an existing session. A passkey assertion near the transaction can provide stronger proof than relying on a long-lived cookie established hours earlier. Use step-up selectively for adding payment destinations, changing recovery methods, exporting sensitive data, or modifying privileged access.
