Passkey playbook FAQ

It is important to explain how the solution addresses their priorities and concerns. Frame the case around cost, security, and user experience:

• Cost – Passkeys can be cost-effective from both resource and recovery standpoints. They reduce helpdesk ticket volume (password resets, lockouts, lost authenticators), so present the cost of your current authentication-related tickets alongside the projected reduction. Passkeys also lower the risk of credential-based attacks that carry significant incident response and recovery costs. 
• Security – Passkeys are more secure than passwords or one-time codes, as they cannot be intercepted or compromised via common tactics such as brute-force attacks, infostealers, and phishing.
• User experience – Users no longer need to remember passwords, wait for codes, or figure out whether to approve a push. In our rollout, average login time dropped from 30 seconds to 10. The convenience and time savings win over non-security stakeholders.

Give your leadership team concrete materials documenting projected cost and resource benefits. Generic “it’s more secure” messaging isn’t a strong argument. Additionally, recognize that end users may be wary of or resistant to change. Maintain open communication throughout the process so they feel informed and have an opportunity to raise concerns.

The first decision is whether you want to create an in-house custom implementation or use a third-party platform or provider. Your organization may have specific needs that require an in-house solution. If you opt for a third-party solution, evaluate the options based on factors such as compatibility across your network infrastructure, reputation, cost, ease of implementation and use, and security and support features. 

Cost and resource requirements factors vary depending on your current network environment and which passkey platform or provider you choose. The amount of money and time saved also factors into the discussion, as passkeys can reduce the number of helpdesk tickets requesting password resets and the likelihood of successful credential-based attacks that can generate significant financial and resource costs.

Because passkeys are cryptographically bound to the device and origin, they cannot be shared, dictated, or extracted by an AI agent — unlike passwords or one-time codes. Passkeys are also well-suited to just-in-time access models, where authentication is triggered at the moment a sensitive action is requested rather than relying on long-lived sessions or pre-shared secrets. As organizations adopt agentic AI workflows that interact with corporate systems, passkeys provide an authentication boundary that is resistant to the credential leakage risks that come with passwords in automated pipelines.

A mobile phone is not necessary for passkey access to corporate devices such as laptops. Passkeys can be stored directly on the laptop, on a physical token such as a YubiKey, or in a cloud-based password manager that syncs access across devices. If you implement a solution that requires employees to download work-related apps on their personal devices, ensure that the apps are restricted to just verifying identity to corporate resources. Explaining why the app is necessary and what permissions it has may also alleviate concerns that the app and organization could access personal information from the device. 

Passkeys do not necessarily require biometrics. Face and fingerprint recognition are often used for convenience, but PINs and passwords are alternative mechanisms. When biometrics are used, the biometric data never leaves the device. It is not transmitted to the server, the identity provider, or the organization. The biometric simply unlocks the device, and the device then provides the passkey. For privacy considerations, consult your legal team for guidance. Consider applicable regional and sector-based laws and regulations such General Data Protection Regulation (GDPR) requirements, Health Insurance Portability and Accountability Act (HIPAA) rules, and financial privacy laws to ensure that you comply with all appropriate requirements. 

Yes, a PIN or device password used to unlock a passkey is fundamentally different from a password used to log in to a remote service. The PIN/password is a local unlock factor: it stays on the device and is used only to authorize the secure hardware/OS to release or use the passkey’s private key. It is not transmitted to the relying party, and there is no server-side password database or hash for an attacker to steal and crack offline. In most implementations, the key material is protected by hardware (for example, TPM/Secure Enclave), with hardware-enforced anti-hammering/rate limiting that makes guessing impractical even if the device is in hand. The remote service only ever receives cryptographic proof from the private key, which also binds authentication to the correct site, reducing phishing and credential replay risks.

Passkeys cannot be compromised or intercepted in the same way that threat actors might steal passwords or a shared token. However, there are still risks. After a user authenticates via a passkey, servers may issue a session token. If an attacker can obtain that token, they could impersonate the user to change settings and conduct malicious activity. Additionally, device code phishing, where an attacker tricks a user into entering a code on a legitimate authentication page to authorize an attacker-controlled device, is an emerging threat that bypasses passkeys without attacking the cryptography. Other social engineering attacks such as ClickFix are also not solved by passkeys. A defense-in-depth approach that includes employee training to recognize and report social engineering attacks remains important.  

While implementing passkeys across your environment, you might encounter situations that require exceptions. For example, VMs can be problematic because by design they are segmented from the computer and from features such as Bluetooth. Passkeys also pose a challenge for situations where pass through is managed by third-party virtualized infrastructure. Evaluate these situations on a case-by-case basis to determine the appropriate authentication method that aligns with your security policy.

The process can differ depending on the passkey solution. However, users will need to perform certain actions to create their passkey during the implementation phase. These actions may include setting up biometric or PIN access and downloading apps on their devices. The implementation team should attempt to create a smooth and painless process for users and clearly explain necessary steps to avoid confusion and frustration. Following the transition, the user experience should be simpler. Passkeys will replace the need for some additional logins, so the user will be able to access resources without as many login prompts.

Recovery depends on how passkeys are stored and the nature of the event. It helps to map common employee lifecycle scenarios to your passkey architecture:

• New laptop – If passkeys are device-bound, the user will need to re-enroll on the new device. If the user has a second registered method (such as an authenticator app or physical key), they can use it to bootstrap the new device.
• New phone – Device-bound passkeys stored in an authenticator app will need to be re-registered from a trusted device (for example, by visiting the identity provider’s security settings from a laptop that already has a valid passkey).
• Lost or stolen device – An administrator needs to immediately revoke the passkey associated with that device. If the user has a second registered method, they can continue working while re-enrollment is completed.
• Physical token lost – Hardware keys like YubiKeys cannot be recovered. Users who rely on physical tokens are often advised to register two.

When implementing a passkey solution, establish clear processes for each of these scenarios so support teams can act quickly and users experience minimal disruption.

Passkeys simplify offboarding rather than complicating it. When you disable a user’s account in your identity provider, passkeys tied to that account stop working. There is no separate passkey to hunt down and revoke. This is the same as disabling any other account; you do not need to change a password because there is no password. If the employee used a hardware security key, there is no need to recover it — the key is useless without an active account to authenticate against. Your existing joiner-mover-leaver processes apply. The only addition is revoking any active sessions at the time of offboarding.

Passkeys don't completely solve the issue, but they represent a significant advance. By relying on a cryptographic chain of trust (public-private key pairs, device presence) rather than human factors that can put credentials at risk (e.g., poor password hygiene, susceptibility to phishing), they resist traditionally effective attack techniques. But authentication is not the whole picture. Remaining challenges include session security (tokens issued after authentication can still be stolen if the device is compromised, and standards like Demonstrating Proof of Possession (DPoP) are emerging but not yet widely adopted), enrollment integrity (if an attacker can social engineer a credential reset or device enrollment, passkeys can be bypassed without touching the cryptography), and machine identity (as machine-to-machine communication grows, the challenge of managing and monitoring non-human identities is expanding faster than the human side of the equation). Defense in depth remains essential.