Passkeys do not make phishing simulations pointless. They change what they are for.
Start with what is genuinely true. For an account protected only by a passkey, the classic phishing scenario fails whatever the person does. They can click the link, believe the page completely and try to sign in, and the authenticator will still refuse to sign for the wrong domain. A simulation that measures whether people type a password into a fake page is measuring a risk that, for those accounts, no longer exists.
But the email itself has not gone anywhere, and neither has the person reading it. The same message can carry a link to a genuine consent screen, a fake verification page that installs malware, a "try another way" fallback, or a request to change a supplier's bank details, which never needed anyone's login in the first place. As we set out in Phishing left the inbox, many of these no longer arrive by email at all.
Passkeys remove the need to judge a login page. They increase the importance of judging everything else.
So the claim worth making is not "you no longer need phishing simulations". It is that a programme built entirely around inbox simulations is now training for the shrinking half of the problem.
Every path that remains runs through a person's judgement
Parts 3 and 4 mapped the attack surface around a passkey sign-in. Laid side by side, the shift in where training effort belongs is stark.
| Attack path | With passkeys | The moment a person decides |
|---|---|---|
| Credential phishing | Closed | None: the authenticator refuses for the wrong domain |
| Fallback and downgrade | Open | Choosing "try another way" when a page says passkeys will not work |
| Session theft | Open | Installing an extension, an "update" or cracked software |
| Consent phishing | Open | Clicking Accept on a genuine permissions screen |
| Fake fixes and malware | Open | Pasting and running a command a web page asked for |
| Service desk resets | Open | An agent accepting knowledge as proof of identity |
| Payment fraud | Open | Changing bank details on the strength of a message or a call |
From "spot the link" to "judge the request"
The old core skill was visual: inspect the sender, hover over the link, read the domain. With passkeys, the browser and authenticator handle the domain check, and handle it better than any person could. What remains is judgement about requests: is this a thing I should be doing at all, right now, for this person, through this channel?
Refuse the easier path
A page saying passkeys will not work, offering a code or a password instead, is a reason to stop, not a reason to comply.
Read the consent screen
Who published the app, what it can do, and whether you went looking for it. If you did not, cancel and report.
Never paste and run
No genuine website, CAPTCHA or support page asks you to run a command. Updates come from IT, not from a web page.
Verify through a known channel
For payment changes, access requests and reset calls, call back on a number you already hold, never the one in the message.
Keep the PIN personal
On shared devices the badge PIN is the second factor. Shared, written down or told to a colleague, it stops being one.
Report in minutes
A stolen session or a malicious app is only useful until it is noticed. Fast reporting shortens every attack on this list.
Each of these is a version of the same habit. Stop. Check. Then act.
What a passkey-era programme looks like
Phishing simulation stays in the programme. It simply stops being the whole of it, and the scenarios change to match where attacks now land.
Consent-screen exercises, fake verification pages, fallback prompts and payment-change requests alongside classic lures, delivered by email, text, messaging apps and phone.
Service desk staff trained and supported to prove identity rather than accept knowledge. Finance teams drilled on verification by callback. Administrators on consent and privileged access.
Click rates matter less when credentials cannot be phished. Reporting rate, time to report and correct refusals say far more about how an organisation will respond on a bad day.
Every miss is a chance to find out why the request seemed reasonable. That is where the real fixes to process come from.
That last point is the subject of an earlier piece, why every failed phishing test should start a conversation. It matters more, not less, once the remaining attacks are about judgement rather than spotting.
Five steps for organisations already rolling out passkeys
Map which groups are fully on passkeys, which still have fallbacks, and which are still on passwords. Training should match each group's actual exposure.
Retire credential-harvesting simulations for passkey-only groups, and replace them with consent, fallback and fake-fix scenarios.
Give the service desk a written identity-proofing procedure and the authority to refuse, then rehearse it with realistic pretext calls.
Make reporting effortless, and start measuring how quickly and how often people report rather than how often they click.
Revisit the programme as fallbacks are removed. The fewer technical gaps remain, the more each behaviour above is carrying.
What to take into your next training review
The login-page lesson is closing
For passkey-only accounts, typing a password into a fake page is no longer possible to get wrong.
The inbox is still the delivery route
Consent links, fake fixes, fallbacks and payment fraud all still arrive as messages.
Train judgement about requests
Fallbacks, consent, pasted commands, verification, PINs and reporting: six behaviours that now decide outcomes.
Measure reporting, not clicking
How fast and how often people raise the alarm says more than a click rate ever did.
You have read all five parts.
- CISA and FBI, Scattered Spider, advisory AA23-320A, updated July 2025
- Microsoft Threat Intelligence, From cookie theft to BEC, July 2022
- Microsoft Threat Intelligence, Think before you Click(Fix), August 2025
- Microsoft Learn, Protect against consent phishing
- Proofpoint, FIDO authentication downgrade, August 2025
- FBI Internet Crime Complaint Center, IC3, business email compromise guidance
- UK NCSC, Passkeys: what you need to know