PASSKEYS - MICROSOFT ENTRA

Can a passkey be phished? Nobody has stolen one. They just stop you using it.

Every published attack on passkeys leaves the cryptography alone. The one that matters for phishing works by convincing you that your passkey is unavailable, and the reason that lie is believable comes from Microsoft's own documentation.

SB

SafeBrowz Threat Research Security Research · 13 September 2026 · 10 min read

Why a passkey cannot be handed over by mistake

Worth being precise about this first, because everything else follows from it.

When you create a passkey, your device generates a key pair and permanently ties it to the site's origin, the exact domain in the address bar. Signing in means your device proves it holds the private key for that origin. There is no secret to type, so there is nothing to hand to a stranger, and the browser will not present a passkey created for one domain to a different one. That is not a policy or a warning you can click through. It is how the mechanism is built.

Which gives you a property nothing else in authentication has. A code from an authenticator app can be read aloud, retyped, or relayed to a real login page by a proxy sitting in the middle, which is exactly what an adversary-in-the-middle attack does. A passkey cannot, because the wrong address never gets the chance to ask.

So an attacker who wants your account has two options left. Stop you from reaching for the passkey. Or attack the device where it lives. Both have now been published, and they are very different problems.

Option one: make the passkey look unavailable

Proofpoint published this on 12 August 2025, written by researcher Yaniv Miron under the title "Don't Phish-let Me Down".

The setup is an ordinary adversary-in-the-middle phishing page, the kind built on the Evilginx framework, for which the researchers wrote a dedicated phishlet. The one addition is small. Between you and the real Microsoft sign-in, the attacker spoofs a browser user agent that Entra ID does not support for passkeys.

Microsoft then does the correct thing. Told it is talking to an unsupported client, Entra declines to use a passkey. Nothing is broken and nothing is exploited. The refusal is genuine, and it is the attack.

Proofpoint describe what the target sees next as three screens: a sign-in error message, then a prompt to select a different authentication method, then, if the victim picks Microsoft Authenticator, a request for a verification code. That code goes to the attacker's proxy and straight on to the real login page.

The reason the lie is believable, in Microsoft's own table

This is the part most write-ups skip, and it is the part that makes the attack work on a careful person.

Passkey support in Entra ID genuinely depends on which browser and operating system you are on. Microsoft publishes the matrix, and the date on it matters here, so we opened it while writing this rather than trusting the 2025 research to still hold. It does. The page was last updated on 10 September 2026 and still shows:

• Safari on Windows: not available. This is the exact combination the Proofpoint research names.
• Firefox on Android: an explicit cross. Not supported.
• Chrome, Edge and Firefox on Windows: supported. All four major browsers on macOS and iOS: supported.

So a message saying your browser cannot use a passkey is not absurd. Some users really do meet one. The attack borrows an experience that legitimately exists.

There is a quiet elegance in the choice of Safari on Windows, too. Apple stopped shipping Safari for Windows well over a decade ago, so almost nobody is genuinely in that state, which means the spoof is unlikely to collide with a real user's setup while still being a combination Microsoft's own table marks as unavailable. The attacker does not need a real unsupported browser. They need an unsupported string.

What the attack actually requires, and what it does not

Strip it back and the dependency list is unusually short.

It needs no vulnerability. Not in FIDO2, not in Entra ID, not on your device, not in your browser. Nothing here is a bug that anyone can patch.

It needs exactly one thing: a weaker method still enabled on your account. If there is nothing to fall back to, the sequence stops dead at the downgrade prompt, because there is nowhere to downgrade to. That single fact is why the defence below is a setting rather than a piece of software.

And one more thing deserves stating plainly, because it is routinely lost in the headlines. Proofpoint said they had yet to observe FIDO authentication downgrade attacks in the wild. The likely reason is economics rather than difficulty: there are still enormous numbers of accounts with no multifactor authentication at all, and criminals go there first. This is a documented, working technique, not a wave currently hitting people.

Option two: go after the device instead

The second family is newer and belongs to a different threat model, so it is worth separating rather than blending the two.

At Black Hat USA on 5 August 2026, SpecterOps principal researcher Michael Grafnetter presented Pass-the-Passkey, a set of techniques against Windows and Entra ID. One chained reusable YubiKey signatures that Windows had written to event logs in cleartext with weaknesses in Entra's passkey validation, which allowed impersonating privileged users. That logging issue is tracked as CVE-2026-34348, rated CVSS 6.5, and Microsoft patched it in the July 2026 updates so the logged assertions can no longer be replayed.

Alongside it, Unit 42's "Pass-ta-key" research targeted Chrome's password manager, with a "Golden Pass-ta-key" variant that could recover synced passkey private keys through exposure of the Security Domain Secret. Independently, Dirk-jan Mollema showed low-privilege processes inside an already-compromised session minting fresh WebAuthn assertions using non-exportable TPM keys.

The Hacker News summarised the whole group in four words that are hard to improve on: "strong cryptography, weaker surroundings."

Notice what every one of those requires. Code already running on the machine, or an attacker already inside the session. That is a serious problem, but it is a malware and endpoint problem, not a link-in-an-email problem. If an attacker is executing code on your laptop, your authentication method stopped being the deciding factor some time ago.

The tell, and why it is the opposite of what feels natural

Here is the practical part, and it inverts an instinct.

A passkey not appearing feels like a technical annoyance. Something to work around so you can get on with your day. The whole downgrade attack rests on that feeling, because it dresses an alarm up as a compatibility problem.

But think about what the silence means. Your passkey is refusing to appear because the address in front of it is not the one it was created for. It is doing precisely the job it was built for, and doing it without a warning dialog, without a red banner, without anything at all. The absence is the signal.

So the rule is short enough to keep: a passkey that normally works and suddenly is not offered is a question about the address, not about your browser. Read the address bar before you select another method. On a work account the real host is login.microsoftonline.com, and Microsoft's own pages live on microsoft.com. If reading it does not settle the question, paste it into a checker rather than squinting at it, because lookalike domains are built specifically to survive squinting. The same reflex is the one that catches device code phishing and browser-in-the-middle pages.

Close the fallback, because that is the actual fix

Everything above points at one setting rather than a product.

1. On a personal Microsoft account: turn on passwordless sign-in and remove SMS codes as a method. A fallback you keep for convenience is a fallback an attacker can steer you into.
2. In an organisation: use an authentication strength policy that requires phishing-resistant methods for the accounts that matter, and resist leaving a secondary route open "just in case". The Proofpoint work is the argument for why that exception is expensive.
3. Everywhere: keep the endpoint healthy and patched. The 2026 device-side research is a reminder that a clean machine is a precondition, not a bonus. CVE-2026-34348 is fixed in the July 2026 updates for anyone who has not applied them.
4. Keep the habit. Check the address before you authenticate by any method, passkey or not.

What a link checker settles here, and what it cannot

Being exact about the boundary matters more than usual on this one.

We cannot see your sign-in prompt. We cannot tell you whether a particular passkey refusal came from a genuine compatibility gap or an attacker's spoofed user agent, and nothing on this page changes that. Nor do we touch the device-side research at all, which is endpoint security's problem rather than a browser tool's.

What is checkable is the one thing the whole downgrade depends on, which is that you were on the attacker's address when the prompt appeared. Layer 1 runs local checks in the browser before the page renders. Layer 2 checks the address server-side against reputation sources, our blocklist, and a brand database of more than 550 names, which is the layer that carries Microsoft lookalikes. Layer 3 is the AI deep scan, reading what the page actually serves rather than what it resembles, one free scan a day for everyone and unlimited on Premium at $14.99 a year across up to three devices.

And the honest limit on an AiTM page specifically: it proxies the real Microsoft content, so the page can read almost perfectly to a content scan. The domain is where it gives itself away, which is why the layers that judge the address do the work here and the deep scan supports them rather than leading.