Brandefense Academy Your trusted hub for learning, developing, and mastering the skills that shape tomorrow's digital defense.
Discover Now
RESOURCES TYPES
Brandefense Academy Your trusted hub for learning, developing, and mastering the skills that shape tomorrow's digital defense.
Discover NowSEPTEMBER 16, 2026
Passkey attacks do not break the cryptography, and anyone waiting for that headline before taking them seriously will wait a long time. The signature scheme underneath passkeys is sound, and the guidance pushing organisations toward them is good guidance. What the attacks published this year target is everything arranged around that scheme: the fabric that synchronises credentials between a person’s devices, the prompt that asks a human to confirm they are present, and the recovery path that exists because people lose phones. Account takeover did not stop being possible. It moved.
The adoption numbers explain why that matters now rather than later. Passkeys crossed into mainstream use this year, but the organisations deploying them are, with few exceptions, running two authentication systems at the same time: the new one they are proud of and the old one they have not finished switching off. An attacker does not have to defeat the new one.
This blog is about where the published attacks actually land, what precondition each of them assumes, and which part of the account takeover problem a passwordless migration leaves untouched.
| 5B passkeys estimated to be in use worldwide Source: FIDO Alliance, May 2026 | 68% of organisations have deployed or are actively deploying passkeys for employee sign-ins Source: FIDO Alliance, May 2026 | 28% of organisations have actually reached fully passwordless authentication for their workforce Source: FIDO Alliance, May 2026 | 57% still rely on password-based methods for employees’ primary day-to-day sign-in Source: FIDO Alliance, May 2026 |
The FIDO Alliance and CISA have both pushed organisations toward phishing resistant authentication with passkeys as the default, and that direction is correct. Passkeys remove the credential that can be typed into the wrong page, which eliminates the single most productive attack path in enterprise security. An organisation moving to passkeys is materially safer than one that is not.
The risk is not in the move. It is in what the move is assumed to have finished. When a control is described as phishing resistant, teams reasonably conclude that the account takeover problem is now closed, and monitoring, response playbooks and executive reporting quietly reflect that conclusion. The published attacks are worth understanding precisely because they land in the space that assumption creates.
Read the three enterprise figures together and they describe a gap rather than a rollout. Sixty-eight percent of organisations have deployed passkeys or are actively deploying them. Twenty-eight percent have reached fully passwordless authentication for their workforce. Fifty-seven percent still have password-based sign-in as the primary day-to-day method for employees.
The difference between the first figure and the second is not a rounding error or a reporting lag. It is a population of organisations that have introduced a strong authentication method without retiring the weak one, and in almost every case the weak one is still reachable. A passkey and a password on the same account are not two layers. They are two doors, and the attacker picks.
This is the condition the rest of this blog assumes, because it is the condition most readers are actually in. The interesting question is not whether passkeys are secure. It is what an attacker does with an account that has one.
A passkey that only exists on one device is a support problem, so the major implementations synchronise credentials through the user’s platform account, protected by a master secret held by that account. That fabric is now the highest value target in the system. An attacker who reaches it does not need to defeat any individual authentication; they inherit the credentials themselves.
The practical consequence is a change in blast radius. Compromising a password gets an attacker one account. Compromising the platform account that holds the sync fabric gets them every passkey that account has ever synchronised, across every relying party, with no further phishing required. The control that made the credential unphishable is the same control that concentrated it.
Passkey authentication asks the device to confirm a human is present and consenting, usually with a biometric or a device PIN. That confirmation is a local decision made by software on the device. Attacks published this year work by influencing that local decision rather than by forging anything cryptographic, which is why they leave the signature scheme entirely intact.
For a defender this is an uncomfortable category, because the authentication event that results is genuine. The assertion is correctly signed by the correct key on the correct device. Nothing in the authentication log distinguishes it from the legitimate sign-in it imitates. The signal, if there is one, sits on the endpoint rather than in the identity provider.
Every deployment needs an answer for the person whose phone is at the bottom of a lake. That answer is almost always a fallback, and a fallback is by definition weaker than the thing it replaces. Where the fallback is a code, a link or a help desk conversation, the phishing resistance of the primary method does not extend to it.
Enrolment deserves the same attention as recovery, and usually gets less. Adding a new passkey to an account is a high privilege operation that most identity stacks treat as a routine settings change. An attacker who reaches the account once, by any means, can enrol a credential of their own and from that point holds an authenticator that looks exactly as legitimate as the user’s. Revoking the original device does not revoke theirs.
The device targeting attacks published this year share a precondition that changes how they should be prioritised: they assume code is already running on the victim’s machine. That is not a small assumption, and it means these are post compromise techniques rather than remote credential theft.
It also means the honest reading is neither dismissal nor alarm. Dismissal is wrong because malware on an endpoint is an ordinary condition rather than an exotic one, and these techniques describe what an attacker does after that condition is met. Alarm is wrong because nothing here lets an attacker reach a passkey from the outside with nothing but a convincing email.
The correct conclusion is narrower and more useful: passkeys move the endpoint from being one factor among several to being the trust anchor for the whole identity. Endpoint compromise and identity compromise, which used to be separable problems, become closer to the same problem.
The techniques above are the interesting ones. They are not the common ones. The account takeover that actually happens to an organisation six months into a passkey rollout usually runs through the part of the estate the rollout did not reach, and none of its steps involve the passkey.
It starts with a credential that was harvested before the migration and never expired in the places that matter. Infostealer output and combolists do not get retracted when a company changes its primary authentication method, and the accounts in them stay valid wherever a password path is still accepted.
It continues on a host the migration did not cover. Large organisations do not have one login page; they have the one everybody uses and a long tail of others, including legacy portals, staging environments, vendor-hosted sign-in pages and applications that authenticate against a directory directly. A passwordless programme that covered the main identity provider may have left several of these answering to a password.
It ends at enrolment. Once inside the account by the legacy path, the attacker enrols their own passkey through the normal settings flow, and the account is now phishing resistant on their behalf. The organisation’s own security control has become the persistence mechanism.
Every step in that chain is observable from outside the network before it is used. The circulating credential is observable. The forgotten login page is observable. The page built to imitate the recovery flow is observable while it is being staged. The enrolment itself is the only step that is purely internal, and by then the useful warnings have already been available for weeks.
Detection signals for account takeover after a passwordless migration (Disclaimer: tune in a non-production environment and validate against your own baseline before enabling automated response)// Rule 1: credential enrolment shortly after an account recovery event |
Stop reporting the migration as a closed risk. A passkey rollout is a large reduction in phishing exposure and it is not the end of account takeover work. Board reporting that frames it as completion removes the budget line for everything described above, usually at the exact moment the estate is at its most mixed.
Instrument the recovery and enrolment paths as carefully as the primary path. Enrolment and recovery are where a passwordless system is at its weakest, and they are usually the least monitored parts of the identity stack. Anomalous enrolment of a new credential deserves the alerting that a suspicious login used to get.
Measure how much of the estate the migration actually reached. The gap between deploying passkeys and being passwordless is the whole subject of this blog, and most organisations cannot state where they sit in it. A login page inventory that includes the pages nobody remembers is the honest version of that measurement.
Assume old credentials remain in circulation. A passwordless migration does not retract the passwords already harvested from your organisation over previous years, and it does not close every legacy authentication path in every system. Those credentials continue to be traded regardless of what your primary method is today.
Treat endpoint integrity as identity infrastructure. Once the device holds the trust anchor, device compromise and account compromise stop being separate incidents, and the response plan should say so before the first one happens.
Four of the five steps in the chain above happen outside the network, before the account is touched. That is the part an external view can see and an identity log cannot.
| Where to look | What it shows about post-passwordless account risk |
| Breach Monitoring, Compromised Devices | The machine profile, source IP and country, the accounts leaked from that host and the URLs a stealer recorded it signing into, which is the record that matters once the device holds the trust anchor rather than one factor among several |
| Breach Monitoring, Leak Table | Employee and client credentials still circulating for your domains, with breach date and incident date held separately so you can tell what predates the migration from what does not |
| Entity Discovery, Web Sites filtered to Login Page | The internet facing sign-in and enrolment pages discovered against your domains, including the legacy portals a passwordless programme did not retire and nobody listed |
| Phishing Monitoring, Findings and Takedowns | Pages built to imitate your recovery and enrolment flow, carrying a confidence level and a website status rather than a raw match, with the takedown raised from the same screen |
| Executive Monitoring, Credential Breach and Registered Platforms | Which platforms a named executive actually holds accounts on and which of those already appear in a credential breach, since device targeted techniques are spent on a small number of specific people |
RELATED READING
Device-Code Phishing Jumped 1,380%: The MFA Bypass Method Nobody’s Training Employees On : how an attacker defeats a strong factor without ever touching the cryptography behind it https://brandefense.io/blog/device-code-phishing-mfa-bypass/
Phishing-as-a-Service 2.0: The Kits That Bypass MFA Without a Fake Login Page : what the commodity end of the market already does to multi-factor deployments https://brandefense.io/blog/phishing-as-a-service-mfa-bypass-device-code/
Why Your CISO Is Your Organization’s Highest-Value Attack Target : why device targeted techniques get spent on a small number of specific people https://brandefense.io/blog/why-your-ciso-is-your-organizations-highest-value-attack-target/
How Spear Phishing Campaigns Target C-Suite Executives: Tactics, Tools, and Defense : the reconnaissance that decides whose device is worth compromising in the first place https://brandefense.io/blog/spear-phishing-c-suite-executives/
Take control of your digital security with an exclusive demo of our powerful threat management platform.
