Cybersecurity & Privacy / Account security
Choose a passkey for everyday sign-in when the service supports it and you have a recovery route you can use. Choose authenticator-app codes when passkeys are unavailable or your workplace requires them. You can keep both where the service allows it, but adding a passkey does not automatically remove older sign-in or recovery methods.
A passkey can verify that you are signing in to the correct service. A rotating code can be copied into a convincing fake sign-in page. The best choice therefore depends on phishing protection, device compatibility, and what happens when your phone disappears.
Here, “authenticator app” means an app generating time-based one-time passwords (TOTP), usually short numeric codes. Some apps also handle passkeys or push approvals; those are different methods. Compare the sign-in mechanism, not just the app’s name.
Passkeys vs authenticator-app codes at a glance
| Question | Passkey | Authenticator-app TOTP |
|---|---|---|
| What do you do? | Approve a sign-in through a credential manager or security key, often with a local PIN or biometric check. | Usually enter your account password, then a current code. |
| Phishing resistant? | Yes, through FIDO/WebAuthn’s binding to the service. | No. A fake page can relay a manually entered code. |
| Where is it stored? | In a passkey provider, on a particular device, or on a compatible security key. | The app stores a secret used to generate codes; backup and sync depend on the app. |
| What if the phone is lost? | Another synced device, a separately registered passkey, or the service’s recovery process may help. | A verified app backup, another registered factor, or service-issued recovery codes may help. |
| Best starting point | A supported account on devices you control, with recovery checked first. | An account that supports app codes but lacks a usable passkey option. |
These are method-level differences, not a promise that every website offers the same options. Check the account’s security page and the documentation for the device or credential manager you actually use.
What changes when you sign in?
A passkey proves possession of a cryptographic key
At registration, a passkey creates a private and public key pair. The service receives the public key; your credential manager or authenticator retains the private key. At sign-in, it answers a challenge using that private key after you approve. You do not type a reusable account secret into the page. FIDO Alliance’s explanation of how passkeys work describes this exchange.
A phone or computer may already have a compatible credential manager, so a separate hardware purchase is not always necessary. Compatibility still involves the service, operating system, browser, and chosen provider. Try the combination you use daily before committing your important accounts to it.
TOTP generates a short-lived code from a shared secret
During setup, the service provisions a secret into your app, commonly through a QR code. The app and service then calculate codes from that secret and the current time. RFC 6238 defines TOTP and recommends a default 30-second time step; individual implementations determine their settings.
That setup QR code is sensitive: it represents the ability to generate future codes, not just one temporary number. Do not paste it into chat, keep it in a shared photo album, or send it to someone offering account support. If it has been exposed, use the service’s security settings to replace the authenticator enrollment.
The code generator need not receive an SMS. For example, Google Authenticator can generate codes without internet access or mobile service. That does not make the website you are signing in to available offline.
Why passkeys offer stronger phishing protection
A code’s short lifetime limits how long it can be used; it does not prove where you entered it. A fake sign-in page can ask for your password and current code, then relay both to the real service before the code expires. NIST’s authentication guidance explicitly excludes manually entered OTP outputs from phishing-resistant authentication because they are not bound to the specific session.
Passkeys use the browser and authenticator to check the service identity. A lookalike domain does not receive the passkey registered for the genuine site. FIDO’s passkey security explanation covers this distinction.
Phishing-resistant sign-in is not a guarantee against every route into an account. Continue protecting your devices, reviewing active sessions, and checking recovery settings. An account may still permit other ways to sign in or reset access.
Google provides a useful concrete example: adding a passkey does not remove existing authentication or recovery factors. Its consumer sign-in flow can use a passkey in place of the password and second step. Workplace account policies can differ. Do not assume another service follows Google’s exact flow.
Choose storage and recovery together
Before enabling either method, answer a practical question: “If this phone were unavailable right now, how would I sign in from another device?” “I think it backs up” is not a complete answer.
Synced passkeys and device-bound passkeys
FIDO distinguishes synced and device-bound passkeys. A synced passkey can become available on other supported devices through its credential manager. A device-bound passkey stays with one device or security key. Both are passkeys; their recovery implications differ.
For synced storage, understand how you would regain access to the provider on a replacement device. For device-bound storage, consider registering another supported authenticator before the first one is lost. A spare security key only helps with an account if it has been enrolled for that account.
Do not confuse cross-device sign-in with backup. Using your phone to approve a login on a nearby laptop does not establish that the laptop now holds an independent passkey. FIDO describes cross-device authentication as using a second device that already has the credential.
Authenticator backup is an app-specific feature
Installing an authenticator app on a replacement phone does not by itself establish that your previous entries will return. Google Authenticator, for example, supports account-based synchronization and a separate manual transfer process for people using it without a Google Account. Its transfer instructions require the old device for manual export. Check your own app’s current backup and restore documentation before wiping anything.
Keep service-issued recovery codes separate from the phone whose loss they are meant to address. A securely stored printed copy can be appropriate if you can control physical access to it. Google’s backup-code documentation explains that its codes are single-use and that generating a new set invalidates the old set. Other services set their own rules.
Draw a simple dependency list: email account → credential manager → authenticator backup. If opening each one requires something locked inside another, add a documented recovery route that breaks the loop. Keep the instructions accessible without revealing the secrets to people who should not have them.
Which method fits your situation?
| Your situation | Practical choice | Check before proceeding |
|---|---|---|
| Personal account with passkey support | Prefer a passkey for routine sign-in. | Where it is saved and how you recover without the current device. |
| Service only offers password plus app codes | Enable TOTP rather than postponing an additional factor. | App backup, recovery codes, and a unique account password. |
| Frequent switches between device ecosystems | Evaluate your passkey provider on every required device. | Creation, sign-in, sync, and recovery; do not assume portability. |
| Employer-managed account | Use the approved method and enrollment process. | Allowed authenticators and the organization’s help-desk recovery procedure. |
| Account where loss of access would halt work | Prioritize an independent recovery route alongside the main method. | Whether the backup still works without the main phone or provider account. |
Hypothetical example: a freelance designer keeps email and client-portal sign-ins on a phone. Adding passkeys can simplify daily access, but storing all recovery information only on that same phone leaves a practical gap. The useful next action is to register and verify another supported route, then document which provider holds each credential.
If you are choosing a password manager as the storage layer, our Bitwarden Free vs Premium guide separates passkey storage, vault sign-in, and integrated code generation. Those are separate purchasing and setup decisions.
A checklist for switching without losing access
- Start with an account inventory. List important accounts, their current sign-in methods, recovery contacts, and whether access is personal or employer-managed. Prioritize accounts that unlock other services.
- Read the service’s own instructions. Confirm what “add a passkey” changes, what remains enabled, and which recovery choices are available for your account type.
- Choose the storage destination deliberately. At the creation prompt, check the provider or device name. Record a descriptive credential label if the service offers one.
- Add a backup you can actually reach. This might be a separately registered passkey, a supported security key, or service-issued recovery codes. Follow the service’s supported options.
- Verify a fresh sign-in. Keep your existing session available while trying the new method in a separate supported browser session or another device. Confirm which method completed the login; an already-open session proves little.
- Check the loss scenario. Verify access to the backup route without relying on the main phone. If using a one-time recovery code during a check, mark it used and maintain a valid remaining set.
- Review older methods after verification. Decide which fallbacks you still need using the service’s guidance. Never delete the only working route merely to make a security-settings page look simpler.
Before replacing a phone, repeat the access checks on the replacement. After confirming access, remove obsolete credentials or lost-device registrations through the relevant services. Keep the distinction clear: moving an app, recovering its data, and revoking an old credential are separate tasks.
Common questions
Does a passkey send my fingerprint or face scan to the website?
No. FIDO protocols keep biometric processing on the device; the service receives the authentication result. A local PIN can also be used in supported flows. The biometric is an unlock mechanism, not an image uploaded as your account password. See FIDO’s passkey FAQ.
Should I delete my authenticator app after adding one passkey?
No. Check every account stored in the app first. One account’s passkey does not replace another account’s code enrollment. Keep necessary entries until you have verified each account’s current sign-in and recovery arrangements.
Why is an authenticator code being rejected?
Confirm the account entry, enter a fresh code, and check that the device’s date and time are correct. TOTP depends on time, so clock drift can matter. Use the service’s official recovery route if access still fails; do not give codes or setup secrets to someone claiming they can repair the account.
Sources and scope
Documentation checked on 23 October 2026. This guide explains authentication methods and provides a planning checklist; it does not report hands-on product testing. Linked sources include FIDO Alliance’s Passkey Central, NIST SP 800-63B-4, RFC 6238, and Google Account Help. Service support and recovery options can change, so confirm your account’s current instructions before changing access methods.
Add comment