A password is a reusable secret the user and service rely on. An OTP is a short-lived code used as a sign-in factor or approval, but it can still be phished. A passkey uses public-key cryptography and is bound to the real service domain, so a lookalike site cannot simply collect and replay it. Recovery and device access still need planning.
Last reviewed: 26 August 2026 · 10 min read
The core difference
| Method | What proves access | Main risk |
|---|---|---|
| Password | Knowledge of a reusable shared secret | Guessing, theft, reuse and phishing |
| OTP | Possession of a temporary code channel or generator | Real-time phishing, interception, mailbox or SIM compromise |
| Passkey | Cryptographic response from an authorised authenticator | Device/ecosystem loss and poorly planned recovery |
These methods can coexist. A service may use password plus OTP, or offer passkey alongside legacy recovery.
How passwords work
The user presents a memorised secret. A responsible service stores a protected verifier rather than plain text, but a weak, reused or phished password can still be abused.
Passwords are universal and easy to move between devices. Their weakness is that the user can type the same secret into the wrong site, and the secret can be replayed elsewhere.
The safest password model is long, unique credentials generated and stored by a password manager.
What an OTP adds
One-time PINs or passcodes expire quickly and are usually linked to a particular authentication or transaction event. Delivery methods include:
- SMS;
- email;
- authenticator app;
- hardware token; and
- recovery or backup code.
An OTP can prevent a person with only the password from signing in. But “one time” does not mean “safe to share.” A phishing site can ask for the current code and relay it immediately to the real service. A caller can persuade the victim to read it aloud.
Always read the surrounding notification. It may explain that the code approves a payment, password reset or new device—not a supposed cancellation.
How passkeys work in user terms
A passkey creates a matched cryptographic key pair for a service:
- the service keeps the public key;
- the user’s device, security key or credential provider protects the private key;
- sign-in requires proof produced by the authenticator; and
- the credential is bound to the genuine service identity.
The user normally unlocks the passkey with the same local method used to unlock a device, such as a PIN or biometric. The biometric usually unlocks the local credential; it is not sent to the website as the passkey.
Because the passkey is domain-bound, a lookalike phishing site cannot request a valid response for the genuine domain. FIDO describes passkeys as phishing-resistant.
Synced and device-bound passkeys
A passkey may be:
- synchronised across devices through a credential provider; or
- kept on a specific device or physical security key.
Synchronisation improves convenience and device replacement. Device-bound credentials can offer stronger control in some high-risk environments. The service and platform determine what is supported.
Users should understand which account protects synchronisation. If the Apple, Google, Microsoft or password-manager account is the recovery root, that account deserves strong protection.
Passkeys do not remove every account risk
An attacker may still exploit:
- weak account recovery;
- a compromised email account;
- an unlocked device;
- malicious remote access;
- session-cookie theft;
- fraudulent customer-support recovery;
- a linked platform account; or
- a user approving the wrong cross-device flow.
Passkeys strengthen authentication. They do not make a device, support desk or account ecosystem invulnerable.
Which method should a person choose?
When a reputable service supports passkeys and the user can manage recovery, a passkey is generally a strong choice because of phishing resistance.
Where passkeys are unavailable:
- Use a unique generated password.
- Enable MFA.
- Prefer stronger available factors over manually entered SMS or email codes where practical.
- Protect the recovery email and phone account.
- Store backup codes offline or in a protected vault.
The strongest method that a person cannot recover safely may create a lockout. Security and recoverability must be designed together.
Migration without losing access
Before adding a passkey:
- confirm the service’s recovery options;
- update the recovery email and phone;
- protect the synchronisation account;
- add more than one authorised authenticator where supported;
- record backup methods;
- test sign-in on another normal device; and
- do not remove the last working method prematurely.
Before selling or resetting a device, confirm that the passkey exists on another authorised device or can be recovered through the provider.
OTP scams to recognise
No legitimate need exists to read an OTP to someone who contacted you unexpectedly. Common stories include:
- “This code cancels the fraud.”
- “I need it to verify your ISP account.”
- “Send the code so I can release your parcel.”
- “Approve the prompt so I can refund you.”
- “Your game trade needs Steam Guard confirmation.”
Reject unrequested prompts and contact the organisation independently.
Sources
- FIDO Alliance Passkeys
- FIDO Alliance: Displace Password and OTP Authentication with Passkeys
- NIST Digital Identity Guidelines: Authentication
- CISA: Phishing-Resistant MFA Is Key
Follow on Google