How Do Passkeys Work? Authentication Flow Guide

How does passkey work? It uses FIDO2 public-key cryptography to make credential theft impossible. Learn the authentication flow, platforms, and deployment practices.

What Is a Passkey?

Stolen credentials opened the door in 22% of confirmed breaches, according to the Verizon 2024 DBIR. Credential theft, particularly through infostealer malware and phishing campaigns, remains the weak link in traditional password-based authentication. You can see that pattern play out in real incidents:

• MGM Resorts (2023): Attackers used a social engineering call to gain credentials and ultimately disrupted hotel and casino operations; MGM disclosed a $100 million hit to adjusted property EBITDAR in the quarter and $10 million in one-time costs (MGM Resorts 8-K filing).
• Colonial Pipeline (2021): The DOJ stated the incident stemmed from a compromised account used for remote access, leading to a major fuel supply disruption across the U.S. East Coast (DOJ press release).
• Twilio (2022): A phishing campaign captured employee credentials, enabling access to internal systems and downstream customer impact (Twilio incident report).

Passkeys eliminate this failure mode through cryptographic authentication bound to specific domains, making credential theft and reuse architecturally impossible.

A passkey is a cryptographic authentication credential built on the FIDO2 protocol. Instead of a shared secret like a password that both your device and a server store, a passkey uses asymmetric public-private key pair cryptography. Your device generates and stores a private key inside secure hardware, such as a Trusted Platform Module (TPM) or secure enclave. The corresponding public key goes to the server. During login, the server issues a cryptographic challenge, your device signs it with the private key, and the server verifies the signature using the public key.

The private key never leaves your device. The server never holds a reusable secret. There is nothing to phish, nothing to stuff, and nothing to steal from a breached database.

That design has direct implications for how organizations defend against the most common attack vectors targeting identity infrastructure.

How Passkeys Relate to Cybersecurity

Passkeys address the dominant category of initial access in enterprise breaches: credential compromise. The Verizon DBIR found that compromised credentials were involved in 42% of breaches overall (Verizon 2024 DBIR). Traditional MFA methods like SMS codes and TOTP remain vulnerable to real-time phishing, where attackers relay codes to legitimate services before they expire. Passkeys use cryptographic domain binding, meaning the credential only functions on the legitimate origin domain. Even if a user interacts with a phishing page, the passkey cannot authenticate against a spoofed domain. For a refresher on how these attacks work, review SentinelOne's phishing attack guide.

For security teams managing identity infrastructure, passkeys shift your defensive posture from reducing the probability of credential theft to making it architecturally impossible. SentinelOne's identity security overview can help you map authentication hardening to the broader identity risk area.

That context sets up a direct comparison between what passkeys replace and what they deliver.

Passkeys vs. Passwords

The table below summarizes the core passkey vs password differences across the security and operational dimensions that matter most to defenders.

Dimension	Passwords	Passkeys
Authentication model	Shared secret stored on both client and server	Asymmetric key pair: private key on device, public key on server
Phishing risk	High: users can enter credentials on spoofed domains	Eliminated: cryptographic domain binding prevents use on illegitimate origins
Server breach exposure	Password hashes can be exfiltrated and cracked offline	Public keys are useless without the corresponding private key
Credential reuse	Common: 52% of adults reuse passwords across multiple accounts (Google/Harris Poll)	Impossible: each passkey is unique to a single domain and account
MFA requirement	Separate factor required (SMS, TOTP, push)	Built-in: possession (device) plus inherence (biometric) or knowledge (PIN) in one step
Login success rate	~63% average across traditional methods	93% for passkey logins (FIDO Alliance Passkey Index)
Login speed	31.2 seconds average with MFA	8.5 seconds average, a 73% reduction (FIDO Alliance Passkey Index)
Help desk burden	Password resets are a top IT support cost driver	Passkey adopters report 81% fewer sign-in-related help desk calls (FIDO Alliance Passkey Index)
Recovery model	Email or SMS reset (re-introduces phishable channels)	Synced credentials via platform managers or pre-registered backup passkeys

That passkey vs password comparison explains why the industry is moving fast. The next section breaks down the building blocks that make passkey authentication work.

Core Components of Passkey Authentication

Passkey authentication uses a layered stack of protocols, hardware, and platform services that protects your credentials at every stage. Each component plays a specific role in keeping credentials phishing-resistant and cryptographically bound.

1. FIDO2 protocol stack: FIDO2 is the umbrella framework comprising two core specifications. WebAuthn, defined by the W3C Web Authentication spec, is the browser-facing API that relying parties use to create and verify public key credentials through JavaScript calls. CTAP (Client to Authenticator Protocol) handles communication between the client platform and the authenticator hardware over USB, NFC, or Bluetooth Low Energy (BLE). Together, WebAuthn and CTAP bridge your application, browser, and the secure hardware protecting your private key.
2. Authenticator types: The FIDO Alliance authenticator specs define two categories. Platform (embedded) authenticators integrate directly into the device hardware and store private keys in secure enclaves or TPMs. Roaming (cross-platform) authenticators are external hardware devices that operate across systems via USB, NFC, or BLE and provide the strongest isolation because private keys remain within a dedicated secure element. The authenticator choice drives your assurance level, recovery plan, and user experience.
3. Secure hardware layer: The security of every passkey depends on the authenticator protecting the private key. Hardware security keys offer the strongest protection through dedicated secure elements designed to resist both physical and logical extraction attacks.
4. Attestation: During credential registration, attestation lets you verify that a passkey was created on an approved authenticator model (identified by its AAGUID) meeting your security requirements, such as hardware-backed key storage or FIPS 140-2 certification.

These four layers, the FIDO2 protocol stack, authenticator types, secure hardware, and attestation, work together during every passkey interaction. The next section walks through exactly how they combine during registration and login.

How Passkey Authentication Works

The passkey lifecycle has two ceremonies: registration (creating the credential) and authentication (proving you hold it). Both follow a challenge-response model using public key cryptography.

Registration: Creating a Passkey

1. Server generates a challenge. When you initiate passkey setup, the relying party server generates a cryptographically random challenge along with registration parameters: the RP identifier, user information, supported algorithms (typically ES256), and authenticator requirements.
2. Your device creates a key pair. The client calls credentials. create(challenge). Your authenticator generates a new public-private key pair inside secure hardware. The private key never leaves this protected boundary.
3. The response goes back signed. Your device sends the public key, a credential ID, and the signed challenge to the server. The W3C specification ensures the full origin is cryptographically signed into the attestation object, binding the credential to the legitimate domain.
4. The server verifies and stores. The server confirms the signed challenge, validates the origin, checks attestation (for enterprise deployments), and stores the public key and credential ID associated with your account.

At this point, the server holds your public key and credential ID but has never seen your private key. That asymmetry is what makes every subsequent login phishing-resistant.

Authentication: Signing in with a Passkey

1. Server issues a fresh challenge. Each login attempt produces a new cryptographically random challenge, preventing replay attacks.
2. Your device signs the challenge. The client calls credentials.get(challenge). Your authenticator prompts for user verification (biometric scan or device PIN), retrieves the private key, increments the signature counter, and signs the authenticator data and client data hash.
3. The server verifies the signature. Using your stored public key, the server verifies the signature, cryptographically proving you possess the private key without it ever leaving your device.

Intercepted traffic contains nothing reusable because each session uses a unique challenge. The private key stays locked in hardware. Your biometric data never reaches the server; verification occurs entirely on-device.

Both ceremonies assume the passkey lives on the device you are using at that moment. In practice, users work across multiple devices, which raises the question of how passkeys move between them.

Cross-Platform Synchronization

Passkeys can be either device-bound or synced across your device ecosystem.

• Synced passkeys replicate through platform credential managers using end-to-end encryption. According to Apple's iCloud Keychain documentation, Apple cannot read keychain contents even if the cloud account is compromised. However, NIST SP 800-63B requires non-exportable private keys for AAL3 compliance, a requirement synced passkeys violate because private keys must leave the original device for synchronization.
• Device-bound passkeys never leave the authenticator hardware and meet the strictest requirements, including NIST SP 800-63B AAL3. Synced passkeys still qualify as AAL2 authenticators for phishing-resistant authentication under federal guidelines.

Once you understand that device-bound versus synced decision, you can evaluate where passkeys are already supported and where adoption is heading.

Which Services and Platforms Support Passkeys

Over 15 billion online accounts now support passkey authentication, and 48% of the top 100 websites offer passkeys as a login option (FIDO Alliance). Adoption spans consumer platforms, enterprise tools, and financial services.

• Operating systems and browsers: Apple (iOS, macOS, Safari), Google (Android, Chrome), and Microsoft (Windows, Edge) have fully integrated passkey support. Over 95% of iOS and Android devices are passkey-ready, and Windows is expanding synced passkey support through Windows Hello (Biometric Update). Cross-device authentication works via CTAP over Bluetooth Low Energy (BLE), letting you authenticate on a laptop using a passkey stored on a nearby phone.
• Consumer platforms: Google has enabled passkeys for over 800 million accounts and reports sign-ins that are four times more successful than passwords. Amazon crossed 175 million customers with passkeys enabled. TikTok achieved a 97% authentication success rate with passkeys. Other major consumer services supporting passkeys include PayPal, eBay, GitHub, and Target (FIDO Alliance Passkey Index).
• Enterprise and workforce tools: Enterprise adoption is accelerating. HID and FIDO Alliance data indicates approximately 87% of businesses have deployed or are actively deploying passkeys. Platforms like Okta, HubSpot, and Cisco Duo have launched passkey support, with HubSpot reporting a 25% improvement in login success rates and 4x faster logins compared to passwords and two-factor authentication (Dashlane Passkey Report).
• Financial services and government: Banks including American Express, Bank of America, and Wells Fargo have begun rolling out passkey support. Cryptocurrency exchange Gemini became one of the first major platforms to mandate passkeys for all users. In the public sector, Australia's MyGov service has made passkeys available to nearly 30 million people, and the European Union launched its Digital Identity Wallet framework with passkeys as a core component.

Broad platform support means most organizations can begin piloting passkeys today. That does not mean deployment is frictionless, and the next section covers the operational challenges you should plan for.

Challenges in Implementing Passkeys

Passkeys solve the credential theft problem, but they introduce operational challenges you need to plan for before deployment.

• The recovery security dilemma: If a user loses their only device with a device-bound passkey and has no backup registered, the account becomes effectively unrecoverable without fallback mechanisms. Traditional recovery flows using email or SMS reintroduce the very vulnerabilities passkeys are designed to eliminate.
• Legacy system compatibility: Older applications frequently lack FIDO2/WebAuthn support. According to the FIDO Alliance's enterprise passkeys paper, federated environments can implement passkeys at the IdP level, enabling downstream support without individual modifications. Non-federated environments must implement FIDO across each application individually or migrate to a federated model first.
• Organizational and cross-platform barriers: Even with strong security benefits, passkey deployment can stall on resourcing, ownership, and process change. Passkey behavior also varies across platforms and browsers, with different registration flows and sync behaviors complicating training and increasing support burden during rollout.

None of these challenges are blockers, but each one requires a deliberate decision during planning rather than a fix after launch. The following best practices address recovery, compatibility, and rollout friction directly.

Passkey Best Practices for Enterprise Deployment

A successful passkey rollout requires architectural planning, tiered policies, and phased execution.

• Establish a two-tier credential strategy: Separate your user base by risk profile and assurance level requirements. Privileged accounts (administrators, finance, regulated access) requiring AAL3 compliance should use device-bound passkeys or hardware security keys with non-exportable private keys. General workforce users can use synced passkeys (meeting AAL2 phishing-resistant requirements) for improved usability and platform-backed recovery through their device credential managers.
• Deploy in three phases: Implement a structured rollout: start with a pilot of 50 to 100 users on high-value applications (email, VPN, HR systems) to establish lifecycle and recovery processes. Scale to additional applications and user segments while formalizing provisioning, revocation, and audit workflows. Finally, make passkeys the default authentication method and move password-based fallback to emergency-only status.
• Federate before you deploy: If your authentication architecture is not centralized through an Identity Provider, address that first. Federated environments implementing passkeys at the IdP level can support downstream applications without individual modifications. Non-federated environments face a more resource-intensive path, requiring passkey support across each application individually.
• Design phishing-resistant recovery: Phase out SMS and email-based recovery in favor of time-boxed recovery mechanisms and backup passkeys. Recovery tokens should have 5 to 15 minute expiration windows, bind to originating sessions, and enforce one-time use. Backup passkeys registered on secondary devices provide the strongest fallback because they maintain the cryptographic security properties of primary authentication.
• Require attestation for enterprise registrations: Implement AAGUID-based attestation filtering to ensure only approved authenticator models can register credentials. This prevents users from registering passkeys on authenticators that do not meet your hardware security requirements.
• Invest in targeted training: Training programs should cover passkey registration across different device types, recovery procedures for lost devices, fallback authentication use, and the security rationale behind the policy changes. Cross-platform inconsistencies make hands-on training more effective than documentation alone.
• Implement audit logging from day one: Track every registration event, authentication attempt, recovery action, and credential revocation in your SIEM. Integrate passkey lifecycle events to maintain audit trails supporting ISO 27001 control objectives and SOC 2 CC6 logical access security requirements. SentinelOne's SIEM guide and XDR overview can help you align identity telemetry with endpoint and cloud signals.

These operational foundations prepare you to translate passkeys into audit-ready controls, which is where compliance and regulator expectations come into play.

Compliance and Regulatory Drivers for Passkey Authentication

Regulatory pressure is accelerating passkey adoption. CISA urges every enterprise to implement phishing-resistant MFA for email, VPNs, and systems touching critical infrastructure. CISA and NIST have also published a draft interagency report on protecting authentication tokens from tampering, theft, and replay attacks. NIST SP 800-63B establishes that AAL2 requires a phishing-resistant option, while AAL3 requires a phishing-resistant authenticator with a non-exportable private key.

To align passkeys to audits, you typically need to show three things:

• Control mapping: Document how passkeys meet or exceed existing access control objectives (for example, ISO 27001 Annex A access control requirements).
• Risk assessment: Capture the risks you introduce (device loss, vendor lock-in, recovery complexity, downgrade attacks) and your compensating controls.
• Evidence and enforcement: Maintain implementation documentation, prove policy enforcement, and keep audit trails for authentication and recovery events.

Packaging these items together lets you position passkeys as both a security upgrade and an audit-friendly control set. Authentication is only one layer of the identity attack surface, though, and the tooling you wrap around passkeys determines how quickly you detect and respond when threats move beyond the login prompt.

Strengthen Passkey Authentication with SentinelOne

Passkeys eliminate credential-based attacks at the authentication layer, but identity security extends beyond the login prompt. Session token theft, lateral movement, and identity-based persistence all operate downstream of authentication. Singularity Identity correlates endpoint and identity activity for context-driven detection and faster triage when passkeys are only part of the story. It hardens Active Directory and cloud identity providers including SecureAuth, Ping, Duo, Entra ID and Okta, deploys deception techniques to trap intruders early, and detects credential theft and privilege escalation in real time.

Purple AI accelerates investigation of identity-related alerts by translating natural language queries into cross-domain searches. Organizations using Purple AI report up to 55% faster threat remediation and a 40-50% reduction in investigation time (IDC research).

SentinelOne produced 88% fewer alerts than the median across all vendors in the independent 2024 MITRE ATT&CK Evaluations (MITRE ATT&CK Evaluations results), helping your team spend time on real incidents instead of alert volume.

When you centralize passkey, endpoint, and identity telemetry, Singularity AI SIEM gives you one place to hot-store normalized security events for faster hunting and forensics. SentinelOne's cybersecurity 101 hub provides supporting concepts for internal runbooks. Sign up for a SentinelOne demo to see how identity, endpoint, and cloud telemetry come together in one platform.

Key Takeaways

At its core, what is a passkey? It is a cryptographic credential that replaces shared secrets with asymmetric cryptography, eliminating the credential theft risk behind 22% of breaches (Verizon 2024 DBIR). Enterprise deployment requires a two-tier credential strategy: device-bound passkeys for AAL3-compliant privileged accounts and synced passkeys for the general workforce. 

Build phishing-resistant recovery workflows, federate your authentication architecture, and roll out in phases. Regulatory mandates from CISA and NIST are accelerating adoption.

FAQs

What is a Passkey?

A passkey is a cryptographic authentication credential built on the FIDO2 protocol that replaces passwords with asymmetric public-private key pair cryptography. Your device generates and stores a private key inside secure hardware, while the public key is sent to the server. 

During login, the server issues a challenge, your device signs it with the private key, and the server verifies the signature. The private key never leaves your device, making credential theft and phishing architecturally impossible.

What is the difference between a passkey and a password?

The passkey vs password distinction comes down to architecture. A password is a shared secret stored on both your device and the server. If the server is breached, the password is exposed. A passkey uses asymmetric cryptography: your private key stays in device hardware, and the server holds only the public key. 

Even a complete server compromise does not expose a usable credential. Passkeys also bind cryptographically to the legitimate domain, making phishing impossible.

Can passkeys be phished or intercepted?

Passkeys are phishing-resistant because WebAuthn signs data that includes the legitimate website origin (the relying party ID and origin binding). If you land on a lookalike domain, the browser and authenticator will not release a valid assertion for that origin, so the login fails even if you approve it. 

If an attacker intercepts traffic, they only get a one-time signed challenge response tied to that session. They cannot replay it because the challenge is unique

What happens if I lose the device that stores my passkey?

With synced passkeys, your credentials replicate across your device ecosystem through services like iCloud Keychain, providing recovery if you lose one device. With device-bound passkeys, your private key never leaves the original device, so you need a pre-registered backup passkey on a separate device or hardware key. 

Enterprise environments should implement administrative recovery workflows with time-boxed tokens and identity verification rather than relying on email or SMS fallback.

Do passkeys meet enterprise compliance requirements like SOC 2 and ISO 27001?

Synced passkeys meet NIST AAL2 requirements and qualify as phishing-resistant authenticators. Device-bound passkeys on hardware security keys meet NIST AAL3 requirements. 

Organizations must conduct risk assessments mapping passkey controls to their specific compliance frameworks, including SOC 2 Common Criteria 6 and ISO 27001 access control objectives, with proper audit logging and documented procedures.

How do passkeys work across different operating systems and browsers?

Each major platform provides its own credential manager for storing passkeys. Synced passkeys replicate within an ecosystem using end-to-end encryption. Cross-device authentication uses CTAP over Bluetooth Low Energy (BLE), allowing you to authenticate on a laptop using a passkey stored on a nearby phone. 

Browser support for WebAuthn is broadly available, which is why rollouts typically focus on user training and recovery design more than browser enablement.