Passkey Q & A

This Q&A is designed to help IT administrators, MSPs, and business leaders understand, plan, and deploy passkeys securely.

What are passkeys?

Passkeys are a modern, passwordless authentication method based on the FIDO2 and WebAuthn standards. Instead of a string of characters you must remember, a passkey consists of a cryptographic key pair. The “public key” is registered with the app or website, while the “private key” is securely stored on your device (smartphone, computer, hardware key, or password manager). When logging in, the server challenges the device, and the device uses the private key to sign the challenge, proving identity without ever exposing the secret.

What are the benefits of passkeys?

• Phishing-Resistant: Because there is no secret to intercept or type in, attackers cannot trick users into giving away their passkeys via fake login pages.
• No Password Reuse or Weak Credentials: Passkeys are inherently strong and unique to every single application or website.
• No Server-Side Breaches: Even if a service’s database is hacked, attackers only get public keys, which are useless for logging into accounts.
• Frictionless User Experience: Logging in becomes as simple as using Face ID, Touch ID, Windows Hello, or a device PIN.
• Reduced IT Overhead: Passkeys eliminate the vast majority of helpdesk tickets related to password resets and lockouts.

What are the drawbacks of passkeys?

• Legacy Incompatibility: Not all software, especially older on-premises applications, supports FIDO2/WebAuthn standards.
• Ecosystem Lock-in: By default, consumer passkeys are heavily tied to specific ecosystems (e.g., Apple iCloud or Google accounts), which can complicate cross-platform use.
• Enterprise Management Challenges: If not managed properly, corporate access can become tied to an employee’s personal Apple ID or Google account.
• Recovery Friction: If a user loses a device that holds a device-bound passkey (and doesn’t have a backup method), account recovery can be difficult.

How do passkeys and passwords compare?

• Creation: Passwords are created by humans (often poorly). Passkeys are generated mathematically by the device.
• Storage: Passwords require the server to store a hash of the secret. Passkeys require the server to store only public, non-sensitive math (the public key).
• Transmission: Passwords are sent over the internet during login. Passkeys are never sent over the internet; only the cryptographic proof is transmitted.
• Vulnerability: Passwords are highly susceptible to phishing, credential stuffing, and brute force. Passkeys are immune to all three.

How are passkeys established?

1. Registration: The user logs into an application (often using an existing password or temporary code to verify identity). The app prompts the user to create a passkey.
2. Key Generation: The user’s device (or password manager) generates a unique public-private key pair for that specific domain.
3. User Verification: The user authorizes the creation using a local biometric (fingerprint, facial recognition) or device PIN.
4. Storage: The private key is secured in the device’s secure enclave (or synced via a passkey provider), and the public key is sent to the application’s server.

Where are passkeys stored? What options exist?

Passkeys can be “synced” or “device-bound.”

• Option 1: Consumer Platform Authenticators (Apple iCloud Keychain, Google Password Manager)
  • How it works: The passkey is stored in the user’s OS ecosystem and synced to their other personal devices.
  • Pros: Great user experience, seamless backup if a phone is lost.
  • Cons: Very poor enterprise control. A corporate passkey lives in an employee’s personal iCloud account, making offboarding a security risk.
• Option 2: Enterprise Password Managers (EPMs like 1Password, Bitwarden, Keeper)
  • How it works: An OS-agnostic application stores and syncs the passkeys across any device the user owns.
  • Pros: IT maintains control. Keys can be revoked during offboarding. Works across Windows, Mac, iOS, and Android.
  • Cons: Requires the organization to purchase, deploy, and train users on third-party software.
• Option 3: Hardware Security Keys (e.g., YubiKey)
  • How it works: The passkey is “device-bound,” meaning the private key lives purely on the physical USB/NFC key and cannot be extracted or synced.
  • Pros: The highest possible level of security. Perfect for shared workstations or highly privileged IT admin accounts.
  • Cons: Hardware costs, physical logistics of distributing keys, and users can lose them.

What are the risks of taking a hands-off approach to passkey management?

If an SMB allows passkeys without a strategy, users will default to saving corporate passkeys in their personal Apple or Google accounts. This creates “Shadow Identity IT.”

When an employee leaves the company, they retain the cryptographic keys to your corporate systems in their personal iCloud. While IT can disable the user’s underlying account at the Identity Provider, any standalone SaaS apps where the user established a passkey directly will remain vulnerable to unauthorized access by the former employee.

How can an organization gain control of passkey implementation?

To maintain control, SMBs must decouple corporate credentials from personal devices. This is achieved by:

1. Mandating a Corporate Passkey Provider: Standardize on an Enterprise Password Manager (EPM) that supports passkeys, or issue managed hardware security keys.
2. Using MDM (Mobile Device Management): Implement endpoint policies that restrict saving work credentials to personal platform authenticators.
3. Restricting Passkey Registration: Use conditional access and Identity Provider (IdP) controls to dictate which passkeys are allowed to register for corporate access.

What mechanisms are available at the IdP vs. the client-side for passkey control?

• IdP Controls (Server-Side): Advanced Identity Providers (like Microsoft Entra ID or Okta) can use AAGUID filtering. Every passkey provider (Apple, Google, YubiKey, 1Password) has an Authenticator Attestation Globally Unique Identifier (AAGUID). The IdP can be configured to only accept passkey registrations from approved AAGUIDs (e.g., rejecting Apple iCloud, but allowing YubiKeys).
• Client-Side Controls (Endpoint): Through MDM (like Intune or Jamf), IT can push policies to company-owned devices that disable the built-in browser/OS prompt to save passkeys to personal accounts, redirecting those requests to the company’s approved Enterprise Password Manager.

How do IdP, SSO, SAML, OAuth, and other authentication mechanisms influence passkey usage?

Passkeys shine brightest when paired with Single Sign-On (SSO). Instead of having an employee create 20 different passkeys for 20 different SaaS apps, the organization centralizes identity via an IdP using SAML or OAuth.

The user registers one passkey with the central IdP (e.g., Entra ID). The user uses that passkey to authenticate into the IdP, and the IdP then uses SAML/OAuth to seamlessly log the user into all downstream applications. This centralizes control, simplifies the user experience, and makes offboarding instantaneous.

Can an organization operating on-prem Active Directory, local resources, M365, and SaaS utilize passkeys for each system?

Yes, but it requires a hybrid architecture.

• M365 & SaaS: Easily handled by deploying passkeys as the primary authentication method in your cloud IdP (e.g., Entra ID), which acts as the SSO provider for SaaS.
• On-Prem Active Directory & Local Workstations: This is handled via Windows Hello for Business (which is fundamentally a device-bound passkey) or FIDO2 hardware keys. By configuring Hybrid Azure AD Join, users can use a FIDO2 security key to log into their physical Windows workstation. Entra ID authenticates the FIDO2 key and securely passes a Kerberos Ticket-Granting Ticket (TGT) down to the machine, which then grants the user seamless access to legacy on-prem file shares and servers without ever typing a password.

How does an organization go about implementing passkeys in a controlled manner?

1. Audit and Centralize: Ensure as many applications as possible are routed through your central IdP via SSO (SAML/OIDC).
2. Select an Authenticator Strategy: Decide if you will use FIDO2 hardware keys (best for high-security/shared devices) or an Enterprise Password Manager (best for general knowledge workers).
3. Configure Restrictions: Set up MDM policies on endpoints to favor your chosen authenticator and configure AAGUID filtering on your IdP to block personal iCloud/Google accounts.
4. Establish Recovery Protocols: Create a secure Helpdesk workflow for issuing Temporary Access Passes (TAPs) so users can register a new passkey if they lose their device.
5. Pilot Group: Roll out to the IT team first, followed by a tech-savvy department, to identify workflow friction.
6. Phased Rollout: Gradually enforce passkey usage across the organization, eventually disabling password-based logins entirely.

What are the best ways to educate and inform end users?

• Focus on the Benefit: Don’t lead with “security;” lead with “convenience.” Frame the transition as “No more passwords to remember or change every 90 days.”
• Clarify Biometric Privacy: A major user concern is that the company is stealing their fingerprints or face scans. Explicitly educate them that biometrics never leave their device; they simply act as a local “unlock button” for the passkey.
• Provide Visual Guides: Create short video clips or GIF-based documentation showing exactly what the passkey prompt looks like on their specific devices (Windows vs. Mac).
• Establish a Clear “What If” Guide: Users will panic about losing their phone. Provide clear, simple instructions on what to do if a device is lost or replaced (e.g., “Call the helpdesk for a temporary 8-hour access code to set up your new phone”).

What is the current passkey experience like?

• Logging In: When returning to an app or website, clicking into the username field triggers a native browser autofill prompt. Selecting the prompt prompts a quick biometric check (Face ID, Touch ID, fingerprint), device PIN, or hardware key tap. Login completes in 1–2 seconds with no passwords typed or SMS codes required.
• Setting Up: Passkeys are typically generated during account creation, through an account’s security settings, or via “Conditional Create” (a system prompt that offers to upgrade your account immediately after a traditional password sign-in). The browser or password manager prompts for authorization and saves the key pair automatically.

What are the key user challenges?

• UI Fragmentation: Prompts look different across operating systems (Windows Hello, macOS, Android) and enterprise password managers (1Password, Bitwarden, Keeper). This can cause initial confusion over where a passkey is actually being saved.
• Cross-Platform Hurdles: Logging into a Windows desktop using a passkey stored on an iPhone requires displaying and scanning an on-screen QR code over Bluetooth, which can fail if Bluetooth is disabled or restricted on corporate networks.
• Stale Credentials: If a passkey is deleted from a service’s server but remains in a user’s credential manager, the browser may still offer the invalid credential at sign-in, leading to failed attempts.
• Recovery Confusion: Users frequently worry that losing their phone means losing total access to their accounts, requiring education around synced cloud backups vs. physical security keys.

How can an end user recognize a legitimate passkey interaction?

• System-Level UI: Genuine passkey prompts are rendered directly by the operating system or a trusted browser extension—never as embedded HTML elements inside a webpage.
• Cryptographic Origin Binding: Passkeys are cryptographically bound to the exact domain registered in the browser. If a phishing site clones a login page on login-micros0ft.com, the OS detects the domain mismatch and will refuse to offer the passkey for microsoft.com.
• Hardware Activation: Legitimate prompts directly trigger local physical device hardware (e.g., lighting up the IR camera for Face ID, activating the fingerprint sensor, or illuminating a USB security key).

What should an end user do with an arbitrary passkey setup interaction?

• Evaluate Intent: Only approve a setup prompt if you actively initiated an action, such as logging in, registering, or navigating account security settings.
• Verify the Domain and Destination Vault: Confirm that the prompt displays the correct, official web domain and is saving to your company-approved credential manager or device vault.
• When Unsure, Cancel: Dismissing or canceling an unexpected passkey prompt will not lock you out of an account. If a prompt pops up unexpectedly while browsing, cancel it and navigate directly to the account’s official security settings to configure it manually.

What role does the browser or operating system play in passkey establishment and storage?

The Browser’s Role

• Exposing the WebAuthn API: The browser provides the JavaScript API (navigator.credentials.create() for establishment and .get() for login) that allows websites to request passkey operations without giving the site access to underlying device secrets.
• Enforcing Origin Binding: The browser automatically captures and verifies the exact web domain (e.g., login.company.com). It injects this origin into the authentication challenge, ensuring passkeys can only be generated or used on legitimate sites—completely eliminating URL spoofing and phishing attacks.
• UI Routing: The browser acts as a traffic cop, determining whether to route the passkey request to the native operating system prompt, a browser extension (like an Enterprise Password Manager), or a cross-device mobile prompt via QR code.

The Operating System’s Role

• User Verification: The OS handles local identity checks. It directly controls hardware sensors to prompt for biometrics (Face ID, Touch ID, Windows Hello) or a device PIN before approving any cryptographic operation.
• Hardware-Backed Storage: The OS manages key storage within isolated hardware security chips—such as Apple’s Secure Enclave, Android’s Titan security module, or a PC’s Trusted Platform Module (TPM). Private keys stored here cannot be extracted by malware or exported in plain text.
• Ecosystem Syncing: For platform passkeys, the OS handles end-to-end encrypted synchronization across a user’s device fleet via native cloud services (e.g., Apple iCloud Keychain, Google Password Manager, or Microsoft Credential Manager).
• Hardware Interfacing: The OS acts as the driver layer when communicating with external authenticators, handling connection protocols for USB, NFC, and Bluetooth hardware keys (e.g., YubiKeys).