What is a passkey?

Key takeaways

• A passkey is a FIDO2 credential packaged for end-user convenience. Same underlying protocol as a hardware FIDO2 key; different storage and user-experience model.
• Passkeys eliminate password entry and the entire phishing surface attached to passwords. The user authenticates by approving on their device, not by typing into a form.
• Major platforms (Apple, Google, Microsoft) and password managers (1Password, Bitwarden, Dashlane) now support synced passkeys across user devices. Microsoft 365 and Google Workspace accept passkeys as sign-in factors.
• For mid-market manufacturers, passkeys are the most practical path to phishing-resistant MFA for general workforce. Hardware FIDO2 keys complement passkeys for high-risk roles and shared-device scenarios.
• ARG advises on passkey adoption as part of the engagement and validates implementation through continuous testing.

What is a passkey, and how is it different from a password?

A passkey is a cryptographic credential that does not require the user to remember anything. The user creates a passkey for a specific service (Microsoft 365, Google Workspace, the ERP, a SaaS app) on a device they trust. On subsequent logins, the user approves the authentication on the device (with biometric or PIN); the device signs the authentication exchange with the private key.

The contrast with passwords is structural:

Property	Password	Passkey
Storage	User's brain or password manager	Device's secure enclave (TPM, Secure Enclave, TEE)
Transmission	Sent to the service on every login	Never leaves the device
Phishability	High; a phishing site can capture	None; cryptographically bound to legitimate site
User burden	Memorize, type, rotate	Approve on device with biometric or PIN
Reusability	Reused across sites (badly); unique per site requires manager	Unique per site by design
Breach exposure	Database breach exposes hashed (sometimes plaintext) passwords	Database breach exposes only public keys; useless to attackers

Passwords are an artifact of authentication design from a different era. Passkeys are the practical replacement: better security and better user experience simultaneously.

How passkeys actually work

The technical flow is the same as the FIDO2 flow, with the credential storage and synchronization layer being what makes a passkey a passkey rather than a hardware-key credential.

Registration. The user creates a passkey for a service. The device generates a public-private key pair. The private key is stored in the device's secure storage (Secure Enclave on iPhone, TPM on Windows, equivalent on Android and Mac). The public key is sent to the service and stored against the user's account.

Authentication. The service sends a challenge. The browser passes the challenge plus the service's relying party identifier to the device. The user approves with biometric or PIN. The device signs the challenge with the private key. The signed challenge goes back to the service.

Sync (for synced passkeys). The platform's account (Apple ID, Google Account, Microsoft Account, password manager account) syncs the passkey across the user's devices end-to-end encrypted. The user can authenticate from any of their devices.

Device-bound passkeys. Some passkeys are not synced; they live only on the device where they were created. Hardware FIDO2 keys are device-bound by design. Some platform passkeys can be configured device-bound for high-security scenarios.

The phishing resistance is the same as FIDO2: the relying party identifier is bound into the signature, so a phishing site (different identifier) cannot complete the authentication.

Why passkeys eliminate entire categories of phishing attack

Passkeys are designed to make several common attacks impossible, not just harder.

Credential harvest phishing. A phishing page that asks the user to enter username and password has nothing to capture in a passkey world. The user does not enter credentials; they approve on their device.

Adversary-in-the-middle phishing. A phishing page that proxies authentication to the legitimate site (Modlishka, evilginx, etc.) cannot complete the authentication. The relying party identifier the device sees is the attacker's site; the credential is registered for the legitimate site; the device refuses to sign.

MFA fatigue. There is no push prompt to bomb because there is no password to start the flow from. The attacker cannot initiate an authentication that produces a prompt the user would approve out of frustration.

Credential stuffing. Reusing credentials from one breach against another service does not work; passkeys are unique per service and not exposable through breaches.

SIM swap (for SMS-based MFA replacement). Not relevant because no SMS is used.

Keylogging on the authentication device. The user types nothing; the keylogger has nothing to capture.

This is materially different from previous MFA improvements. Push-based MFA reduced the value of stolen passwords but did not eliminate phishing. Passkeys eliminate the password and the phishing surface tied to it.

Note: passkeys do not address every authentication-related attack. Session hijacking (after authentication), malware acting in the user's session, social engineering of in-session actions, and SaaS-side compromise still happen. Passkeys close the authentication door specifically; other doors remain open. See What is consent phishing (OAuth phishing)?.

Examples of passkey rollouts and their effect on help-desk tickets

What ARG and the broader industry see in passkey deployments:

• Help-desk ticket volume drops 30-50% post-migration. Password reset tickets, account lockout tickets, and "I forgot my password" tickets all drop materially. The help desk reclaims capacity.
• Phishing-related incidents drop sharply. Documented phishing incidents fall after passkey migration. Some organizations report essentially zero credential-phishing success once the migration is complete.
• MFA fatigue eliminated. Push prompts disappear. The MFA fatigue attack class is no longer relevant against passkey-protected accounts.
• Onboarding speeds up. New employee onboarding includes passkey enrollment; the user authenticates faster on day one than they would with password-plus-MFA.
• User satisfaction improves. Survey data consistently shows users prefer passkey authentication over password-plus-MFA. The friction in the daily workflow drops measurably.
• Edge cases require attention. Shared devices, legacy applications, vendor portals, and recovery scenarios all need explicit handling. The implementations that work address these explicitly; the implementations that fail hand-wave the edge cases.

The pattern: passkey migration is one of the few security improvements that improves both security and user experience simultaneously. The combination produces better-than-expected adoption rates and help-desk satisfaction.

How to evaluate whether your environment is ready for passkeys

Five questions to assess readiness:

1. Does the identity provider support passkeys? Microsoft Entra, Okta, Google Workspace, Auth0, Duo Single Sign-On, JumpCloud all support passkeys as of 2026. If the identity provider is one of these, passkeys are technically possible.
2. Do the high-traffic applications federate to the identity provider? Microsoft 365, Google Workspace, Salesforce, the ERP (if SSO-enabled), HRIS, payroll, expense management. Applications behind SSO inherit the passkey protection. Applications not behind SSO need separate consideration.
3. What is the device landscape? Modern iPhones, Androids, Macs, and Windows laptops with TPM all support passkeys. Older devices (pre-2018 typically) may not. Inventory the workforce's devices.
4. What does the shop-floor and shared-device environment look like? Shared workstations, shop-floor HMIs, and BYOD-restricted environments need a different strategy than the general workforce. Usually hardware FIDO2 keys cover these.
5. What is the recovery model? Lost-device, replaced-device, broken-device scenarios. The help-desk procedures must work; without them, passkeys produce lockouts.

A "yes" on the first four and a documented answer on the fifth puts the organization in a position to plan a rollout. Gaps on any of the five become explicit work items in the plan.

Best practices for passkey backup, recovery, and lost-device handling

Recovery is the hardest part of passkey deployment. Without good recovery, lost devices produce locked-out users.

1. Issue at least two factors per user. Primary passkey on the user's daily-use device plus a backup: another device with synced passkey, a hardware FIDO2 key, or both.
2. Provision recovery before need. The recovery factor is enrolled during onboarding, not when needed. A user without a recovery factor cannot recover gracefully.
3. Document the help-desk procedure. Lost-device scenario, broken-device scenario, no-recovery-factor scenario. The procedures specify identity verification requirements, escalation paths, and recovery actions.
4. Tier recovery by user risk. Executives, finance, and admin recovery procedures should be stricter (video verification, multi-person approval) than general workforce recovery.
5. Avoid SMS-based recovery. SMS as a recovery factor reintroduces SIM-swap risk. If SMS is in the recovery chain, it is the weakest link.
6. Plan for platform account recovery. Apple ID, Google Account, Microsoft Account, password manager account recovery procedures matter. If the platform account is compromised, the user's passkeys are compromised.
7. Onboard new employees with passkeys, not passwords. A new employee never sees a password; their first authentication is passkey-based.
8. Off-board departing employees by revoking passkeys. Passkey revocation is part of standard off-boarding. Without it, departing employees retain access.

Passkey FAQs

Are passkeys safe to sync across devices?

Yes, when synced through a trusted platform. Apple, Google, Microsoft, and major password managers (1Password, Bitwarden, Dashlane) sync passkeys end-to-end-encrypted across the user's devices. The sync is bound to the user's platform account, which has its own security controls. The trade-off is convenience versus the absolute control of device-bound credentials; for most users and most relying parties, synced passkeys are the right balance.

What happens if I lose all my devices?

Recovery runs through the platform's account recovery (Apple ID, Google Account, Microsoft Account, password manager). For corporate environments, the help desk can re-enroll the user after identity verification. The right approach is to provision a recovery factor in advance: a hardware key or a backup authenticator on a second device, so total device loss does not mean total lockout.

Do passkeys work in Microsoft 365?

Yes. Microsoft Entra supports passkeys as a sign-in method through Authenticator (device-bound passkey) and through platform passkeys (Apple, Google, Windows Hello, third-party password managers). Tenant administrators configure which passkey types are accepted; the rollout requires the tenant policy plus the user-side enrollment.

Is a passkey the same as a FIDO2 credential?

Closely related. A passkey is a FIDO2 credential designed for end-user convenience, typically stored on a phone or laptop and (often) synced across devices. The underlying cryptography and protocol are the same as a FIDO2 hardware-key credential; the user experience and the credential lifecycle differ. See What is FIDO2?.

How ARG advises on passkey adoption during engagements

ARG advises on passkey adoption as part of the broader phishing-resistant MFA work delivered through the engagement. The advice is context-specific: the right passkey strategy for a 200-person manufacturer is not the same as for an 800-person manufacturer with multiple facilities or a 75-person manufacturer with a heavy shop-floor workforce.

The work is led by James Wall on the digital identity side. The advisory covers:

• Strategy. Which cohorts use passkeys, which use hardware keys, which use both. How the rollout interacts with PAM and conditional access policy.
• Vendor coordination. Which vendors with remote access can adopt passkeys, which require hardware keys, which need migration support.
• Application coverage. Which applications federate to the identity provider (inheriting passkey protection), which require separate authentication strategy.
• Recovery design. Help-desk procedures, recovery factor provisioning, account recovery for the platforms involved.
• Decommissioning weak factors. The migration is not complete until push, SMS, and TOTP are disabled. The conditional access policy work that produces that state.

Validation runs through the continuous simulation layer: adversary-in-the-middle phishing, consent phishing, and credential-acquisition simulations confirm whether the passkey deployment is actually producing the expected security improvement. Findings flow into the monthly operational packet.

For founding clients, passkey-adoption advisory is part of the standard engagement. The expected outcome is a measurable shift from password-plus-push posture to passkey-dominant posture over the engagement's first year, with the supporting evidence ready for insurance renewal and compliance audit.

Apply as a founding client or see how the engagement works for the full delivery cycle.