What a Passkey Is and What to Do If You Lose Your Phone

TL;DR — A passkey is a modern login credential stored on a device or password manager, usually unlocked with Face ID, fingerprint, or a device PIN. If you lose your phone, you usually do not lose access forever: the most likely fix is to sign in on another trusted device in the same ecosystem or use your account recovery method, then register a new passkey on the replacement phone. Reading time: ~7 min

What it is and where it sits

A passkey is a login credential based on public-key cryptography (a way to prove identity using a matched public/private key pair). In plain English: instead of remembering a password, your device creates a secret key that stays on the device, and a matching public key is stored by the website or app.

When you sign in, the site does not ask for your password. It asks your device to prove it holds the private key. Your device only does that after you unlock it with something local, like Face ID, Touch ID, fingerprint, Windows Hello, or your device PIN.

What it replaces

A passkey usually replaces one or both of these:

• Passwords — the thing users forget, reuse, and get phished for.
• SMS or authenticator-based 2FA — the second factor often added after a password.

In many products, passkeys become the primary sign-in method. In others, they are an additional sign-in option alongside email/password.

Where it lives in the architecture

In a typical login flow:

• The browser or mobile app talks to the website.
• The website talks to its authentication service (your app’s auth backend or an identity provider).
• The authentication service stores the user account and the user’s public key.
• The private key lives on the user’s device or in a synced credential store, such as the device ecosystem’s cloud keychain or a password manager that supports passkeys.

The important boundary is this: your server never stores the secret private key.

[User] ---- 1. click "Sign in with passkey" ----> [Browser/App]
[Browser/App] ---- 2. auth request ----> [Website/Auth Service]
[Website/Auth Service] ---- 3. challenge ----> [Browser/App]
[Browser/App] ---- 4. ask device to verify ----> [Phone/Computer]
[Phone/Computer] ---- 5. biometric or PIN ----> [Phone/Computer]
[Phone/Computer] ---- 6. signed response ----> [Browser/App]
[Browser/App] ---- 7. response ----> [Website/Auth Service]
[Website/Auth Service] ---- 8. verify with public key ----> [Account]

Why this matters in IAM terms

In Identity & Access Management, passkeys change two things:

1. Authentication gets stronger because there is no shared secret password for attackers to steal from your users and reuse elsewhere.
2. Recovery becomes a first-class design problem because access depends on devices and synced credential stores, not just a memorized password.

That second point is why “what happens if I lose my phone?” is the right question.

How it actually works

Let’s walk one realistic example end to end: a customer signs in to your client portal with a passkey created on their iPhone, then later loses that phone.

Step 1: The passkey is created

The user opens your site and chooses Create passkey or Use passkey next time.

Behind the scenes:

• Your site asks the browser to register a credential using the WebAuthn standard (Web Authentication, the browser API for passkeys and security keys).
• The device creates a private key and a matching public key.
• The private key stays protected by the device.
• The public key, plus metadata like a credential ID, is sent to your server and stored on the user’s account.

From the user’s point of view, this usually looks like:

• Browser prompt appears
• They choose iPhone, This device, or a password manager
• They confirm with Face ID or fingerprint
• Done

Step 2: The next login

Later, the user visits your login page and clicks Sign in with passkey.

Your server sends a one-time challenge (a random value used once to prevent replay attacks) to the browser. The browser asks the device to sign that challenge with the stored private key. The device requires local unlock. The signed result comes back to your server, which checks it against the public key on file.

If it matches, the user is signed in.

Step 3: The phone is lost

Now the user loses the iPhone.

What happens next depends on where the passkey was stored:

Case A: The passkey was synced in the user’s ecosystem

This is the most common consumer setup.

Examples:

• Apple devices syncing through iCloud Keychain
• Android devices syncing through the user’s Google account
• A password manager syncing passkeys across devices

In this case, the user often signs in on a second trusted device they already own, such as a laptop or tablet in the same ecosystem. The passkey is available there too.

Practical recovery flow:

1. On the replacement phone or another trusted device, sign in to the device account first.
2. Open the website.
3. Choose Sign in with passkey.
4. Approve with the local biometric or PIN.
5. After login, go to your app’s security settings and add a passkey for the new phone.

Case B: The passkey existed only on the lost device

This happens if the passkey was created on a single device and was not synced anywhere, or if the user used a hardware security key and lost it.

In that case, the passkey itself is gone. The website cannot reconstruct it, because the server never had the private key.

The user must use a recovery path. Common recovery options are:

• Another registered passkey on another device
• A hardware security key kept as backup
• A recovery code saved earlier
• An email-based account recovery flow
• Support-assisted identity verification for high-risk accounts

After recovery, the old lost-device passkey should be removed from the account, and a new passkey should be registered.

The key idea

Losing the phone does not automatically mean losing the account. It means losing one way to prove identity. Whether that is a small inconvenience or a major lockout depends on whether you planned recovery.

When to use it (and when not to)

Passkeys are a strong default for customer logins, employee logins, and admin access — but only if you also design a recovery path.

You probably don’t need this if...

• You are still struggling with basic account separation and role-based access.
• Your app has no reliable email ownership checks, no support process, and no recovery policy.
• Your real problem is not phishing resistance but abandoned accounts and weak onboarding.

In those cases, a simpler first step is often: use a mainstream identity provider, turn on MFA, and add passkeys after the support workflow is ready.

Trade-offs

Passkeys are excellent, but they are not free.

Operational reality

For a software agency, the biggest hidden cost is not coding the button. It is policy:

• What counts as acceptable recovery proof?
• Who can remove a lost-device credential?
• How do you avoid social-engineering your own support team?
• Do admins need two passkeys enrolled before production access is granted?

That is IAM work, not just frontend work.

In practice

Below are two practical examples you could adapt today: one for the browser side and one for the server-side data shape.

Example 1: Browser registration with WebAuthn

const publicKey = {
  challenge: Uint8Array.from(atob(window.challengeB64), c => c.charCodeAt(0)),
  rp: { name: "Client Portal" },
  user: {
    id: Uint8Array.from(atob(window.userIdB64), c => c.charCodeAt(0)),
    name: "alex@example.com",
    displayName: "Alex"
  },
  pubKeyCredParams: [
    { type: "public-key", alg: -7 },
    { type: "public-key", alg: -257 }
  ],
  authenticatorSelection: {
    residentKey: "preferred",
    userVerification: "preferred"
  },
  timeout: 60000,
  attestation: "none"
};

const credential = await navigator.credentials.create({ publicKey });

await fetch("/webauthn/register/finish", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(credential)
});

This asks the browser to create a passkey and sends the result to your backend. The gotcha: binary fields must be encoded correctly; many teams trip over base64url conversion between browser and server.

Example 2: Storing registered passkeys per user

{
  "user_id": "usr_12345",
  "email": "alex@example.com",
  "passkeys": [
    {
      "credential_id": "p1L9...base64url...Q",
      "public_key": "BCd7...base64url...w",
      "sign_count": 42,
      "device_label": "Alex iPhone",
      "created_at": "2026-10-30T09:15:00Z",
      "last_used_at": "2026-10-29T18:22:11Z"
    },
    {
      "credential_id": "m8K2...base64url...Z",
      "public_key": "BErr...base64url...A",
      "sign_count": 3,
      "device_label": "MacBook Air",
      "created_at": "2026-10-01T12:00:00Z",
      "last_used_at": "2026-10-28T08:10:44Z"
    }
  ],
  "recovery_codes_enabled": true
}

This shows the kind of account record your auth system needs: multiple passkeys per user, not just one. The gotcha: if you support only a single credential, a lost device becomes a support incident instead of a normal self-service event.

Practical UI and policy actions

If you are choosing or reviewing an auth system, look for these exact user-facing capabilities in your provider dashboard or product backlog:

• Account settings → Security → Passkeys — list, label, add, and remove passkeys
• Account settings → Security → Recovery codes — generate and regenerate codes
• Admin console → Authentication methods — require at least one backup method for admins
• Support runbook — documented steps for lost-device recovery and credential revocation

⚠️ Removing a registered passkey can lock a user out if it is their only sign-in method. Before deleting a credential, confirm the user has another passkey, a recovery code, or a verified recovery path.

A sensible support sequence is:

1. Ask the user to try another trusted device first.
2. If that fails, use the recovery flow already built into the product.
3. Only after successful recovery, remove the lost-device passkey.
4. Prompt the user to register a new passkey immediately on the replacement device.

Further reading

• WebAuthn Level 3 specification
• FIDO2: Client to Authenticator Protocol (CTAP)
• MDN Web Docs: "Web Authentication API"
• NIST SP 800-63B Digital Identity Guidelines
• OWASP Authentication Cheat Sheet

This article was written by an AI system and published pending human review. Verify anything you intend to act on.