Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Passkeys and FIDO2 security keys are the strongest choices here for stopping phishing at sign-in. Both can use WebAuthn, which binds authentication to the real website’s domain; a fake site generally cannot capture and relay the credential the way it can with a manually entered authenticator-app code. For many people, a supported platform passkey is the easiest place to start. A physical security key is a useful alternative or backup when you want a separate authenticator. If a service offers only one-time codes, enabling them is still better than using a password alone—but those codes are not phishing-resistant.
At a glance
| Name | Best for | Key spec | Checked |
|---|---|---|---|
| Platform or synced passkey | Convenient phishing-resistant sign-in using a supported device | FIDO/WebAuthn; phishing-resistant when implemented with user verification | Nov 2026 |
| Dedicated FIDO hardware security key | A separate authenticator, including an option for non-exportable keys | FIDO/WebAuthn; phishing-resistant when supported and used as a FIDO authenticator | Nov 2026 |
| Authenticator app with one-time codes (OTP) | Adding MFA where a service does not offer FIDO sign-in | Replay-resistant, but manually entered codes are not phishing-resistant under NIST’s definition | Nov 2026 |
Why do passkeys and security keys stop phishing better?
They can make authentication depend on the website’s verified domain, rather than on a secret you type into whichever page asks for it. That difference is what frustrates the familiar real-time phishing trick: a criminal site asks for your password and current code, then relays them to the real service before the code expires.
The National Institute of Standards and Technology (NIST) calls this kind of protection phishing resistance. Its current digital identity guideline, SP 800-63B-4, describes WebAuthn—the web authentication standard used by FIDO2 authenticators—as an example of verifier-name binding. In plain language, the authenticator selects a credential based on the authenticated verifier’s domain. A lookalike site does not get the same valid response as the genuine site.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →By contrast, a time-based one-time password (TOTP) is a short-lived code that a person reads from an app and types into a sign-in page. The code can be valid and still be handed to an impostor: its digits are not bound to the real site or sign-in session. NIST classifies TOTP apps as replay-resistant, but not phishing-resistant. Replay resistance helps prevent reuse of a captured code later; it does not prevent a phisher from relaying a current code immediately.
Popular on Amazon
That is why the useful distinction is not simply “MFA versus no MFA.” All three methods can be part of a stronger sign-in setup than a password alone, but they do not provide the same protection against credential capture. For this specific threat, FIDO/WebAuthn is the important property.
Are passkeys and security keys different technologies?
Not exactly. A passkey is a cryptographic sign-in credential; it may be stored by a device’s platform authenticator, synchronized between a person’s devices, or associated with a dedicated hardware security key. A security key is a physical device that can act as a FIDO authenticator. So “passkey versus security key” is partly a comparison of where the credential lives and how it is recovered—not two wholly unrelated methods.
A platform authenticator is integrated into a device. A person may unlock its use with a device PIN or biometric, depending on the implementation. The fingerprint or face scan is generally a local check that authorizes use of the cryptographic credential; it is not itself the passkey sent to the website.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
A dedicated hardware key is a separate device that you connect or tap, if the account, key, and device support the relevant connection method. It can provide a credential that is non-exportable: the private key is designed to remain in the hardware instead of being copied out. A synced passkey, by contrast, is meant to be available across devices through an account or platform’s synchronization and recovery system.
These differences affect convenience, control, and recovery. They do not make every platform passkey identical or every physical key compatible with every account. Confirm the sign-in options a service supports, and check how you would regain access if the device or key disappeared.
Also popular on Amazon
Which option should I choose?
Choose a supported passkey as a convenient first phishing-resistant method for many everyday accounts. Prefer a dedicated FIDO security key if you want a separate physical authenticator, want the non-exportable-key option, or want an additional authenticator you can keep as a backup. Use an authenticator app’s codes when that is the strongest method the account offers, while understanding that a code can be phished in real time.
| Method | Phishing resistance | Main benefit | Main trade-off |
|---|---|---|---|
| Platform or synced passkey | Yes, when implemented through FIDO/WebAuthn with user verification | Uses a device you may already have; syncing can help with cross-device access and recovery | Account and platform support varies; synced credentials depend on the security of the synchronization and recovery account |
| Dedicated FIDO hardware key | Yes, when supported and used as a FIDO/WebAuthn authenticator | Separate physical authenticator; hardware can keep keys non-exportable | Must be carried, compatible with the account and device, and replaced or backed up safely if lost |
| Authenticator app generating OTP codes | No, for manually entered OTP under NIST’s definition | Familiar MFA option available on accounts that support app codes | A fake site can solicit and relay a current code |
There is no evidence-based percentage that says one of these methods prevents a particular share of phishing attacks. NIST’s classifications explain how the protocols handle phishing; they are not a measured ranking of consumer incident rates. Choose based on the account’s actual support, the credential’s storage model, and whether you can recover access—not on an invented prevention score.
How should I compare recovery and key storage?
Consider four things for each account: whether the method resists phishing, where its authentication key is stored, what happens if the phone or key is lost, and whether the service and your devices support it. A method that is technically strong but unavailable on a critical account cannot protect that account.
Synced passkeys: easier access, shared recovery dependencies
Synchronization can make a passkey available on more than one device and can simplify recovery when a device is replaced. The trade-off is that the credential participates in a platform or account’s syncing and recovery system. NIST’s terminology treats syncable authentication keys as inherently exportable, because availability across devices requires the ability to move or reproduce the credential in a protected manner. “Exportable” here is a technical key-management distinction; it does not mean the credential is posted publicly or that syncing is automatically unsafe.
NIST’s 2024 supplement on syncable authenticators discusses the security and usability considerations of these credentials. The practical point is to protect the account and recovery route that makes synchronization possible. A passkey’s phishing resistance does not protect a weakly secured recovery account or a compromised device.
Also popular on Amazon
Hardware keys: separate and potentially non-exportable
A dedicated hardware security key is a physical authenticator separate from the computer or phone where you sign in. A suitable hardware key can keep its authentication key non-exportable. NIST says non-exportable keys are more secure and requires them at Authentication Assurance Level 3 (AAL3); that is an assurance-level requirement, not a claim that every consumer account using a hardware key is AAL3.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →The separation is useful only if the service supports that key for the sign-in you need and you can keep access to it. If it is lost, damaged, or unavailable, your recovery options matter. Before removing a working method, check the service’s account-recovery process and, where appropriate, register a spare key. A physical key can improve control over credential storage, but it also creates a practical obligation to carry, protect, and replace it.
OTP apps: a useful fallback, not a phishing shield
Authenticator apps are often a meaningful improvement over password-only sign-in, especially when they are the only additional factor a service supports. NIST’s authenticator examples identify TOTP smartphone apps as replay-resistant but not phishing-resistant. The code’s short lifetime does not solve the relay problem: a fake sign-in page can forward a freshly entered code to the real site right away.
When codes are the available option, enter them only on the service’s genuine sign-in page, reached through a trusted route such as a saved bookmark or the service’s official app. This is prudent practice, not a change to the code’s technical limits; a convincing phishing page can still deceive a person.
How do I switch to a phishing-resistant sign-in?
Start with the account’s own security settings and keep a recovery route until the new method is confirmed. Exact menu names vary by service, so look for settings labeled “Passkeys,” “Security key,” “Sign-in methods,” or “Two-step verification,” rather than assuming every site uses the same path.
Also popular on Amazon
- Check support first. In the account’s security or sign-in settings, confirm whether it accepts passkeys, FIDO security keys, or only app codes. Support can differ by account type and platform.
- Choose the storage model. Select a platform passkey if convenience and cross-device access fit your needs. Choose a dedicated FIDO key if you want a separate authenticator or a non-exportable-key option. A key purchase alone does not secure an account that does not support it.
- Set up the method while you still have access. Follow the service’s enrollment flow and complete any device verification it requires. If the service offers a way to register another authenticator, decide whether you need a spare before relying on one physical key.
- Confirm the new method works. Sign out only if it is safe to do so, then verify you can sign in with the new credential. Keep the existing supported recovery method until the new method and recovery path are both clear.
- Review recovery and support protections. Check what the service requires if you lose the phone, change devices, or lose a key. Protect the email or other account used for recovery, since a weak recovery channel can undermine a strong sign-in method.
- Remove obsolete methods cautiously. Once the new credential is confirmed and you understand recovery, remove old methods only if you no longer need them. Do not delete your last working route before verifying the replacement.
For a hardware key, also check the device connector and whether USB or NFC is needed for your account and devices. A physical key’s FIDO capability, connector, and service compatibility must line up; a USB-C connector by itself does not guarantee account support.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What does NIST’s guidance mean for ordinary accounts?
NIST SP 800-63B-4, published in July 2025, supersedes the 2020 edition of SP 800-63B. It is federal digital identity guidance focused on authentication for people interacting with government information systems. Its classifications are useful standards guidance, but they do not mean that every consumer service follows the standard or implements every authenticator in the same way.
NIST recognizes phishing resistance through channel binding or verifier-name binding. The WebAuthn/FIDO mechanism described above is an example of verifier-name binding. In its implementation table, NIST lists FIDO2 passkeys with user verification as phishing-resistant and TOTP smartphone apps as replay-resistant but not phishing-resistant. That classification supports the core choice: use a supported FIDO method when the objective is to prevent a fake verifier from obtaining a usable sign-in response.
The standard also specifies a cryptographic floor: keys used to establish phishing resistance must provide at least the minimum security strength in the latest SP 800-131A revision, identified in the 2025 standard as 112 bits. That is a cryptographic-strength requirement—not a measured reduction in phishing attempts, an attack-success rate, or a consumer-facing score comparing products.
NIST’s general multi-factor authentication guidance explains why adding factors matters, while its guidance on creating a good password remains relevant for accounts that still use passwords. A phishing-resistant authenticator is not a substitute for protecting the rest of the account.
Also popular on Amazon
What can these methods not protect against?
Phishing resistance addresses a specific attack: an impostor verifier trying to capture authentication secrets or a valid sign-in response. It is not a complete account-takeover defense. It cannot make an infected or controlled device trustworthy, fix insecure account recovery, prevent every form of social engineering, or guarantee that a service’s implementation is sound.
Do not assume a passkey is impossible to steal under every circumstance. The defensible advantage is narrower and important: an ordinary fake-site OTP relay does not normally let the attacker reuse a FIDO/WebAuthn credential, because the authentication is bound to the verifier. Keep devices updated and protected, secure the accounts that manage synchronized credentials, and treat recovery and support channels as part of account security.
Likewise, buying a security key does not automatically protect every account. The account must support the key as a FIDO authenticator, and the key must work with the device and connection method involved. If an account offers only OTP codes, those codes remain preferable to password-only sign-in when MFA is the available option, but they do not acquire phishing resistance simply because they are generated by an app.
Free tools Windows power users keep installed
One-click scans. No signup required.
Frequently Asked Questions
Can a phishing site steal an authenticator app code?
Yes. If you type a current one-time code into a fake sign-in page, the operator may relay it to the genuine service before it expires. The code’s short validity limits later reuse, but it does not bind the code to the real website.
Do passkeys work when I change phones?
It depends on how the passkey is stored and synchronized, and on the account’s recovery options. Before replacing a device, check the service and platform guidance for restoring access; do not assume every passkey transfers in the same way.
Can I use a security key on any account?
No. The service must support a compatible FIDO sign-in method, and your device must be able to connect to the key in the way required. Check both before buying a key or removing another sign-in method.
Does a fingerprint replace my passkey?
Usually not: a biometric is a local way to authorize use of the credential on a device, rather than the cryptographic credential itself. Exact prompts and device behavior depend on the implementation.
