You receive an email that looks exactly like one from your provider. You click, you land on a page that looks exactly right, you enter your password, and you enter the six-digit code from your authenticator app. Everything appears to work.
The site was a proxy. It forwarded your password and your code to the real service in real time, and the attacker now has a logged-in session. Your authenticator app did nothing wrong — it generated a valid code, and you typed it into the wrong place.
A hardware security key would not have worked, and that is the entire point.
What changed in 2026
- Passkeys mainstreamed the underlying technology. The same cryptographic approach that powers security keys became the basis for passkeys, which pushed support across a much wider set of services.
- Phishing-resistant authentication became an enterprise requirement. Organisations with meaningful security postures moved from "recommended" to "required" for privileged accounts.
- SMS continued declining as an option. More services deprecated or discouraged it as SIM swap attacks stayed effective.
- Key prices stayed modest. A pair of keys remains inexpensive relative to what they protect.
Why phishing fails against them
The mechanism is worth understanding because it explains the whole security property.
When you register a key with a service, the key generates a keypair and permanently associates it with that service's domain. Authenticating means the site sends a challenge, the key signs it, and the signature is verified.
Crucially, the key includes the requesting domain in what it signs, and it will only produce a signature for the domain it registered with. A phishing site at a lookalike domain asks for a signature and gets nothing usable — not because the key detected something suspicious, but because the domain does not match and there is no code path that produces a valid response.
The user cannot be tricked into overriding this. There is no code to read out, nothing to type into the wrong box, no judgement call about whether a site looks right. The check happens in the hardware, on data the user never sees.
| Method |
Stops password theft |
Stops real-time phishing |
Stops SIM swap |
| Password only |
No |
No |
N/A |
| SMS code |
Yes |
No |
No |
| Authenticator app |
Yes |
No |
Yes |
| Push approval |
Yes |
Weakly |
Yes |
| Security key |
Yes |
Yes |
Yes |
Buy two, register both, immediately
The single most important practical advice: get two keys and register both on every account at the same time.
A single key is a single point of failure. Lose it, break it, or leave it in a hotel, and you are into account recovery on every service you protected — which is exactly the process a security key was meant to make unnecessary, and which is frequently the weakest part of a service's security anyway.
Registering the backup later means repeating the registration process across every account, which is tedious enough that people postpone it indefinitely. Doing both at once costs a few extra minutes per account.
Keep the backup somewhere physically separate — a safe, a drawer at another address, a safe deposit box. Not in the same bag as the primary.
Consider the connector too. A key that works with your laptop and not your phone is half a solution; USB-C and NFC together covers most situations.
Where to start, and the fallback trap
Not every service supports keys, so prioritise.
Start with your email account, without exception. Email is the recovery mechanism for nearly everything else, so an attacker with your email has your other accounts regardless of how well those are protected.
Then your password manager, your primary cloud account, financial accounts that support it, and any developer or infrastructure accounts where a compromise would be severe. See the best password managers for the vault side.
The trap that undoes all of this: leaving SMS enabled as a fallback. If an account accepts a key or an SMS code, an attacker simply uses the SMS route, and you have gained nothing against a determined one. Where a service permits it, remove weaker methods after registering your keys. Where it does not, understand that your real security level is the weakest enabled method.
Recovery codes are the better fallback: printed, stored offline, and not attached to a phone number anyone can hijack — see SIM swap protection.
Common mistakes
- Buying one key. Loss becomes an account recovery ordeal.
- Registering the backup later. It does not happen.
- Leaving SMS enabled. The weakest enabled method is your actual security level.
- Both keys in the same place. One incident takes both.
- Not saving recovery codes. The legitimate fallback, and it needs to exist before you need it.
- Skipping email. The account that unlocks the others.
- Wrong connector. A key that will not work with your phone leaves a gap.
FAQ
How do passkeys relate to security keys?
Same underlying standard. A passkey is typically stored on your phone or in a password manager and syncs; a security key is dedicated hardware that does not. Passkeys are more convenient and cover more services; a hardware key keeps the secret in a device that never leaves your possession. See passkeys vs 2FA.
What if I lose both?
That is what recovery codes are for. Without them, you are into each service's account recovery process, which varies from tedious to genuinely difficult.
Do they work on mobile?
Yes, via NFC or USB-C depending on the key and phone. Check compatibility before buying if mobile is your primary device.
Can a key be cloned or extracted?
The private keys are designed to be non-extractable from the hardware. Physical possession is the threat model — which is why a lost key should be deregistered from your accounts, not just replaced.
Where to go next
For the broader authentication picture, read passkeys vs 2FA and the best password managers. For the attack that makes SMS unsuitable as a fallback, SIM swap protection.