Attackers do not retire. They relocate.
Part 3 showed four attacks that passkeys remove at the root. It would be comforting to stop there. But attackers were never interested in passwords for their own sake; passwords were simply the cheapest way into an account. Take them away and the effort moves to the next cheapest step. That step is almost always either after the sign-in, or around it.
Session hijacking
Steal the cookie the passkey sign-in produced.
Service desk social engineering
Get a new passkey registered to the attacker.
Consent phishing
Have the user grant an app access, legitimately.
Malware on a trusted device
Act from the machine the user has just unlocked.
Authentication ends; the session begins
This is the attack worth understanding most deeply, because it is the one passkeys most often get blamed for missing. Signing in and staying signed in are two different things. The passkey ceremony proves who you are at one moment. The service then issues a session cookie (or, in Microsoft's world, a set of tokens), and from that point on the cookie is your identity. Every request you make carries it. The cryptography has finished its job and left the building.
An attacker who obtains the cookie does not need to defeat the passkey. They skip authentication entirely, because it has already happened. There are two main ways to get it.
- Infostealer malware. Software on the device reads the browser's stored cookies and sends them off. Infostealers are sold as a service and delivered through fake downloads, cracked software, malicious browser extensions and the fake verification pages described in section 04.
- A proxy, after a downgrade. A real-time phishing proxy cannot make a passkey sign for the wrong site, but if it can persuade the person to use a weaker fallback method, it catches the session at the end. Proofpoint demonstrated exactly this in 2025 by making the proxy pretend to be an unsupported browser.
What stops it: mostly technical, partly human
The strongest fixes bind the session to the device, so a copied cookie is useless elsewhere. Google began rolling out Device Bound Session Credentials to Chrome on Windows in April 2026: cookies are short-lived and can only be renewed by proving possession of a key held in the TPM. Microsoft Entra ID offers token protection, a Conditional Access control that accepts only device-bound sign-in tokens, though at the time of writing it covers native apps such as Outlook, Teams and SharePoint far more completely than browsers.
Technical controls
- Device-bound sessions where available (Chrome DBSC, Entra token protection).
- Shorter session lifetimes for sensitive apps, and re-authentication for high-risk actions.
- Continuous access evaluation, so a revoked session ends quickly.
- Access only from managed, compliant devices.
- Remove fallback sign-in methods wherever passkeys are in place.
What people need to watch
- What they install: browser extensions, "updates" from web pages, software from unofficial sources.
- Fallback prompts: "this browser is not supported, try another way" is a moment to stop.
- Unexpected sign-in or new-device alerts, reported immediately.
- Speed matters: a stolen session is only useful until it is noticed and revoked.
The softer door: getting a new passkey registered
A passkey cannot be phished, but it can be replaced. Every organisation needs a way to help someone who has lost their phone or broken their laptop, and whoever controls that process controls the account. CISA and the FBI describe the group known as Scattered Spider posing as employees to convince IT help desks to reset MFA or register a new device, then using the access that follows.
Notice what the attacker relied on: urgency, publicly findable details, and a process that accepted knowledge as proof of identity. Each of those is a design decision, and each can be changed. Section 05 covers how.
Phishing that survives every sign-in control
Consent phishing, also called illicit consent grant or OAuth abuse, does not want your credentials at all. The attacker registers an application with a cloud identity platform, which is free and quick, and sends you a link. You land on a genuine sign-in page on a genuine domain. You might sign in with your passkey, and it works perfectly. Then the platform asks whether you want to give the app access to your mailbox or files. If you accept, the attacker's app holds tokens that keep working after you close the tab, and, as Microsoft notes, can continue until they expire even after the app itself is disabled.
Nothing here is compromised. The platform is doing exactly what it was designed to do: asking whether you trust an application. The trust model is being used as intended, by the wrong party.
Malicious applications are not only a consumer problem. In its January 2024 guidance, Microsoft described how Midnight Blizzard, after its initial password spray, compromised a legacy test OAuth application with elevated access, created further malicious OAuth applications, and used them to reach corporate mailboxes. Attackers also routinely name apps after trusted brands; Microsoft advises not relying on an app's name or domain as a sign of authenticity.
Technical controls
- Restrict user consent to verified publishers and low-risk permissions.
- Turn on an admin consent workflow, so users can request apps rather than approve them.
- Audit consented applications and their permissions regularly.
The user's rule
- If you did not go looking for this app, do not approve it.
- Read who published it and what it will be able to do.
- Treat "maintain access" and mail or file permissions as a serious request.
The quiet one: when the right person is at a compromised machine
If an attacker controls the endpoint, a passkey does not help, because they do not need to steal it. They wait for you to authenticate legitimately, then act inside the session you just opened. Remote access trojans do exactly this. The cryptography works perfectly; it simply proves that the right person is sitting at a compromised machine.
Passkeys changed authentication, not delivery, so malware still arrives the familiar ways: attachments, fake software downloads and cracked applications, bogus browser updates, malicious extensions and compromised supply chains. One technique deserves particular attention because it is pure social engineering. Microsoft calls it ClickFix.
Microsoft reported in August 2025 that ClickFix campaigns had been targeting thousands of enterprise and end-user devices every day since early 2024, delivering infostealers such as Lumma Stealer and remote access tools. There is no exploit and no vulnerability: just a person following instructions.
Technical controls
- Endpoint detection and response on every device that can sign in.
- Application control, and blocking the Run dialog where it is not needed.
- PowerShell logging and attack surface reduction rules.
- Browser extension allow-lists on managed browsers.
What people need to watch
- No genuine website asks you to paste and run a command. Ever.
- Updates come from the operating system or IT, not from a web page.
- A device behaving oddly after a download is worth reporting straight away.
The back door you design yourself
A passkey is only as strong as the weakest way to replace it. If losing your phone means ringing a service desk that registers a new passkey after three security questions, the organisation has built a cryptographic front door with a cardboard back door. Everything strong about passkeys can be undone at enrolment.
Never let anyone reach zero credentials. The strongest pattern is also the simplest: every person registers at least two authenticators, ideally of different kinds, such as a platform passkey on the laptop and a security key or a passkey on the phone. Losing one becomes an inconvenience, not a crisis, and the service desk is not needed at all.
When a reset is needed, issue a Temporary Access Pass, not a password. In Microsoft Entra ID, a Temporary Access Pass is a time-limited passcode, one hour by default, that can be set to single use. It lets a person register a new passkey without the service desk handing out a reusable secret, and it should only be sent through a verified channel.
Prove the person, not what they know. Employee numbers, managers' names and dates of birth are findable. Stronger options include a video call comparing the person with the identity document checked at onboarding, verification in person, or a manager confirming the request through a separate, known channel.
Verify identity at onboarding, in person or with checked documents, and register the first passkeys at that moment. Avoid emailing enrolment links to addresses anyone could reach.
When someone gains privileged access, move them to the privileged passkey rules, with attestation and security keys, before the access is granted.
Disabling the account is not enough. Remove registered passkeys, revoke sessions and tokens, and recover or deregister security keys and badges, which can otherwise walk out of the door still enrolled.
Use the second authenticator. If there is none, issue a single-use Temporary Access Pass only after identity has been proven, and log and review every re-issue.
What to take into your next risk conversation
Protect the session, not just the sign-in
Device-bound sessions, shorter lifetimes and managed devices close the gap after authentication.
Recovery is the real perimeter
Two authenticators per person, Temporary Access Passes and proof of identity rather than knowledge.
Restrict what users can consent to
Verified publishers, low-risk permissions and an admin consent workflow take the decision off the busiest person.
Every remaining attack involves a person
An install, an approval, a phone call, a pasted command. That is where training now earns its keep.
Security awareness training after passkeys: what needs to change
- Microsoft Threat Intelligence, From cookie theft to BEC, July 2022
- Proofpoint, FIDO authentication downgrade, August 2025
- Google, Protecting cookies with Device Bound Session Credentials
- Microsoft Learn, Token protection in Conditional Access
- CISA and FBI, Scattered Spider, advisory AA23-320A, updated July 2025
- Microsoft Learn, Protect against consent phishing
- Microsoft Threat Intelligence, Midnight Blizzard: guidance for responders, January 2024
- Microsoft Threat Intelligence, Think before you Click(Fix), August 2025
- Microsoft Learn, Configure a Temporary Access Pass