Passkeys are the most significant change to mobile authentication in years, because they remove the thing attackers most want: a password. Built on the FIDO and WebAuthn standards, a passkey is a public-key credential where the private key never leaves the user's secure hardware, so there is no shared secret to phish, leak, or reuse. For a mobile app, passkeys mean sign-in backed by Face ID, Touch ID, or device authentication, with the platform handling the cryptography. Here is what passkeys are, how they compare to passwords, and how to add them to a mobile app.
Short answer
Passkeys are passwordless, phishing-resistant credentials based on the FIDO and WebAuthn standards, where the user's device holds a private key in secure hardware and your server stores only the corresponding public key. Per Apple and the equivalent Android support, signing in means the device signs a server challenge with the private key, verified by your server, with no password to steal or phish. On mobile, you implement them with the platform credential APIs, iOS AuthenticationServices and Android Credential Manager, bound to your domain through an associated-domain file. Passkeys remove the shared secret that drives most account attacks, and your backend acts as the relying party that verifies the signatures.
What you should know
- Passkeys are passwordless: a public-key credential, no shared secret.
- The private key stays in secure hardware: it never leaves the device.
- They are phishing-resistant: bound to your domain, nothing to steal centrally.
- Platform APIs implement them: AuthenticationServices and Credential Manager.
- Your server is the relying party: it stores public keys and verifies signatures.
What are passkeys?
They are credentials based on public-key cryptography that replace passwords. When a user creates a passkey for your app, the device generates a key pair: the private key is stored in the device's secure hardware, often synced across the user's devices through the platform's password manager, and the public key is sent to your server. To sign in, your server issues a challenge, the device signs it with the private key after the user authenticates locally with biometrics or the device passcode, and your server verifies the signature against the stored public key. Because there is no shared secret, there is nothing for an attacker to phish from the user, steal from your database, or reuse across sites. Passkeys implement the FIDO and WebAuthn standards, and the platform handles the cryptography and key storage, so the user experience is simply authenticating with Face ID, Touch ID, or device authentication.
Passkeys versus passwords
The difference is whether a stealable secret exists. The table compares them.
| Aspect | Password | Passkey |
|---|---|---|
| Secret to steal | Yes, a shared password | No, only a public key on the server |
| Phishing risk | High; users can be tricked into entering it | Low; bound to your domain, nothing to enter |
| Reuse across sites | Common and dangerous | Not applicable; unique per service |
| Server breach exposure | Password hashes can be cracked | Public keys are not sensitive |
| User experience | Type and remember | Authenticate with biometrics or device passcode |
The core advantage is that a passkey has no shared secret. A password can be phished, reused, leaked in a breach, or guessed; a passkey cannot be phished because the credential is bound to your domain and never typed, and a server breach exposes only public keys, which are not useful to an attacker. That eliminates whole categories of account attack, credential stuffing, password phishing, reuse, at the source.
How do you add passkeys to a mobile app?
Use the platform credential APIs and make your backend a WebAuthn relying party. On iOS, use AuthenticationServices to create and use platform passkeys, and on Android use the Credential Manager API; both present the system passkey experience backed by biometrics or device authentication. Bind passkeys to your domain with an associated-domain configuration, the same apple-app-site-association and assetlinks.json mechanism used for universal and app links, so the credential is tied to your verified domain and cannot be used elsewhere. On the server, implement the WebAuthn registration and authentication ceremonies as the relying party: store users' public keys, issue challenges, and verify the signed responses. Plan for account recovery, since a user could lose access to their devices, and decide whether to offer passkeys alongside existing sign-in during a transition. The platform does the cryptography; your work is the relying-party logic and the domain binding.
What to watch out for
The first trap is treating passkeys as a drop-in without the relying-party work, when your server must implement WebAuthn verification and store public keys correctly. The second is missing the associated-domain binding, which is what ties passkeys to your domain and makes them phishing-resistant. The third is neglecting account recovery, leaving users stuck if they lose their devices. Passkeys are an authentication design choice rather than something a binary scan evaluates, but a pre-submission scan such as PTKD.com (https://ptkd.com) reads your app against OWASP MASVS and checks the storage and handling of any remaining secrets and tokens, which complements adopting passkeys by confirming the rest of your auth data is handled securely. The passkey implementation lives in the platform APIs and your server.
What to take away
- Passkeys are passwordless, phishing-resistant credentials where the private key stays in the device's secure hardware and your server holds only the public key.
- They remove the shared secret behind most account attacks, so there is nothing to phish, reuse, or steal in a server breach.
- Implement them with iOS AuthenticationServices and Android Credential Manager, bind them to your domain with an associated-domain file, and make your backend the WebAuthn relying party.
- Plan account recovery, and use a pre-submission scan such as PTKD.com to confirm any remaining tokens and secrets are stored securely.
