Passkeys Were Supposed to Kill Phishing—So Why Are Banks Still Getting Drained in 2026? The “Device‑Bound” Detail Most Rollouts Skip
Passkeys shut down classic credential phishing—but attackers are cashing out by stealing sessions and routing around weak fallbacks. The real debate is synced vs device-bound keys, and whether “rollout” actually means enforcement.
By TheMurrow Editorial
March 19, 2026
Key Points
- 1Recognize passkeys as phishing-resistant authentication via origin binding—but understand attackers increasingly win by stealing sessions after login.
- 2Differentiate synced vs device-bound passkeys: usability-driven sync fabrics vs non-exportable keys banks prefer for higher assurance requirements.
- 3Demand enforcement, not just rollout: if passwords and weak recovery remain, attackers route around passkeys through the easiest fallback path.
Passkeys were supposed to end phishing. Many companies now treat them that way: ship a passkey prompt, run a victory lap, and quietly keep the old sign-in paths around “just in case.”
The reality is more interesting—and more uncomfortable. Passkeys meaningfully raise the cost of classic credential theft, because they were designed to refuse the very thing phishing depends on: getting a user to hand over a reusable secret. But passkeys don’t automatically protect what attackers increasingly want after login: your session.
That gap—between “phishing-resistant authentication” and “still-stealable sessions”—is where the next wave of account compromise lives. It’s also where the debates inside banks, regulators, and security teams have become sharp: Which kind of passkey are we talking about? Are we rolling them out, or enforcing them? And what does “secure” mean when the web still runs on cookies and bearer tokens?
“Passkeys shut the door on classic credential phishing—but they don’t magically lock down what happens after you’re already inside.”
— — TheMurrow Editorial
Passkeys, precisely: what they are and why the standards matter
Passkeys aren’t a brand feature. They’re a consumer-friendly label for a set of standards from the FIDO2 ecosystem—specifically W3C WebAuthn (the browser/API layer) and FIDO CTAP (the protocol that lets devices and authenticators talk to each other). The FIDO Alliance describes FIDO2 as the combination of these parts. That detail matters because the protections people attribute to passkeys come from the cryptography and the way browsers enforce it—not from any single vendor promise. (FIDO2 overview: fidoalliance.org)
In FIDO terminology, what most people call a “passkey” is commonly used as shorthand for a discoverable FIDO credential—also known as a resident/discoverable credential—which enables username-less sign-in flows. In other words, a credential can live on the user’s authenticator (often a phone or platform credential manager), allowing a login experience that doesn’t require typing an identifier first. (Shibboleth documentation on discoverable credentials)
In FIDO terminology, what most people call a “passkey” is commonly used as shorthand for a discoverable FIDO credential—also known as a resident/discoverable credential—which enables username-less sign-in flows. In other words, a credential can live on the user’s authenticator (often a phone or platform credential manager), allowing a login experience that doesn’t require typing an identifier first. (Shibboleth documentation on discoverable credentials)
The key claim: “phishing-resistant” has a formal definition
Passkeys are widely described as phishing-resistant for one central reason: origin binding. WebAuthn binds a credential to a specific origin—effectively, the legitimate website identity. A passkey created for `bank.com` won’t sign a challenge for `bànk.com` or a lookalike domain. FIDO’s “Passkeys: The Journey to Prevent Phishing” series puts this at the heart of why passkeys break classic phishing flows that rely on stealing reusable secrets. (FIDO Alliance, March 2025 series)
That’s not marketing. It’s a design constraint.
That’s not marketing. It’s a design constraint.
2
Core standards underpin passkeys: WebAuthn + CTAP (together, FIDO2).
1
Critical property that makes passkeys phishing-resistant: origin binding.
2
Major deployment models shape risk: synced vs device-bound passkeys.
3
Real-world adoption stages: rollout, partial prevention (fallbacks remain), and full enforcement (fallbacks constrained).
Four practical “numbers” readers should keep in mind
Security discussions become clearer when you anchor them to a few hard counts:
- 2 core standards underpin passkeys: WebAuthn + CTAP (together, FIDO2).
- 1 critical property makes passkeys phishing-resistant: origin binding.
- 2 major deployment models shape risk: synced vs device-bound passkeys.
- 3 stages show up in real-world adoption: rollout, partial prevention (fallbacks remain), and full enforcement (fallbacks constrained). FIDO’s series explicitly describes intermediate “partial prevention” phases where old methods can still undermine gains.
Those are not trivia. They map directly to how passkeys succeed—or fail—outside a demo.
- 2 core standards underpin passkeys: WebAuthn + CTAP (together, FIDO2).
- 1 critical property makes passkeys phishing-resistant: origin binding.
- 2 major deployment models shape risk: synced vs device-bound passkeys.
- 3 stages show up in real-world adoption: rollout, partial prevention (fallbacks remain), and full enforcement (fallbacks constrained). FIDO’s series explicitly describes intermediate “partial prevention” phases where old methods can still undermine gains.
Those are not trivia. They map directly to how passkeys succeed—or fail—outside a demo.
What passkeys stop well—and what they simply don’t
Passkeys excel at preventing the kind of attack the public associates with “phishing”: a fake login page that tricks you into typing a password, or a real-time proxy that relays your credentials and one-time codes. Because passkeys don’t produce a reusable secret and won’t sign for the wrong origin, a phisher can’t merely “collect” something and replay it later. The credential never becomes a copyable string.
FIDO’s anti-phishing journey documents why this breaks many popular credential-harvesting patterns. A phisher can still build convincing pages, but the cryptographic handshake won’t complete for the wrong origin. That’s the win.
FIDO’s anti-phishing journey documents why this breaks many popular credential-harvesting patterns. A phisher can still build convincing pages, but the cryptographic handshake won’t complete for the wrong origin. That’s the win.
The hard truth: attackers move after login
Passkeys don’t end account takeover because authentication is only one step. Industry guidance from FIDO explicitly flags the next target: bearer tokens and session cookies. Once a user is logged in, attackers increasingly go after session material through:
- Infostealers on the endpoint
- Malicious browser extensions
- Device malware
- Session fixation/hijack patterns in the app layer
FIDO’s guidance calls out bearer-token theft and session hijacking as remaining vulnerabilities—even under “full” passkey anti-phishing journeys. That’s a crucial nuance: passkeys can reduce initial credential capture, but they don’t automatically bind the entire session to the legitimate user and device unless additional protections exist. (FIDO Alliance, Passkeys Journey Part 3; FIDO Authenticate 2025 recap)
- Infostealers on the endpoint
- Malicious browser extensions
- Device malware
- Session fixation/hijack patterns in the app layer
FIDO’s guidance calls out bearer-token theft and session hijacking as remaining vulnerabilities—even under “full” passkey anti-phishing journeys. That’s a crucial nuance: passkeys can reduce initial credential capture, but they don’t automatically bind the entire session to the legitimate user and device unless additional protections exist. (FIDO Alliance, Passkeys Journey Part 3; FIDO Authenticate 2025 recap)
“If a service still treats a stolen cookie as ‘proof of you,’ passkeys can’t fix that by themselves.”
— — TheMurrow Editorial
Practical implication for readers
If you’re using passkeys and still get compromised, it doesn’t necessarily mean passkeys “failed.” It may mean the attacker never touched authentication at all. They stole the session after you authenticated correctly.
That’s not a reason to dismiss passkeys. It’s a reason to stop treating them as a total security strategy.
That’s not a reason to dismiss passkeys. It’s a reason to stop treating them as a total security strategy.
The two species of passkeys: synced vs device-bound (and why banks care)
“Passkey” is one word; it covers two materially different risk models. The FIDO Alliance draws a bright line between:
- Synced passkeys: the private keys are backed up and synced across your devices through a sync fabric (often an operating system credential manager or a third-party provider).
- Device-bound passkeys: the private keys are non-exportable and never leave a single device, including hardware security keys. (FIDO2 overview: fidoalliance.org)
The difference isn’t academic. It answers a hard question: What happens if the thing that syncs your credentials is compromised?
- Synced passkeys: the private keys are backed up and synced across your devices through a sync fabric (often an operating system credential manager or a third-party provider).
- Device-bound passkeys: the private keys are non-exportable and never leave a single device, including hardware security keys. (FIDO2 overview: fidoalliance.org)
The difference isn’t academic. It answers a hard question: What happens if the thing that syncs your credentials is compromised?
Why “device-bound” is a banking phrase, not a lifestyle choice
Banks and other high-value targets often want more than “phishing-resistant.” They want non-exportable authentication keys because it reduces the blast radius of a cloud-account takeover or a sync-provider compromise. A synced passkey can be excellent for usability. But from a strict assurance standpoint, device-bound credentials offer a clearer security boundary: the key stays put.
That boundary shows up in standards language. NIST SP 800-63B-4 (July 2025) frames AAL3 as requiring a phishing-resistant cryptographic authenticator with a non-exportable private key. That’s a regulatory-grade articulation of why “device-bound” matters: it’s not only about stopping phishing; it’s about the key’s exportability. (NIST 800-63B-4, July 2025)
That boundary shows up in standards language. NIST SP 800-63B-4 (July 2025) frames AAL3 as requiring a phishing-resistant cryptographic authenticator with a non-exportable private key. That’s a regulatory-grade articulation of why “device-bound” matters: it’s not only about stopping phishing; it’s about the key’s exportability. (NIST 800-63B-4, July 2025)
“For high-value accounts, the question isn’t ‘Are passkeys modern?’ It’s ‘Can the private key be exported—yes or no?’”
— — TheMurrow Editorial
The tradeoff that adoption teams can’t wish away
Device-bound keys create recovery friction. Lose the device, lose the key—unless you’ve built careful backup and recovery processes. FIDO’s guidance on synced passkey deployment for consumer use cases discusses access-loss and lockout scenarios as a major driver behind synced implementations: people have multiple devices, devices break, phones get replaced. Synced passkeys often win because they are humane. (FIDO, Synced Passkey Deployment Emerging Practices, May 31, 2024)
Security teams may prefer device-bound. Product teams may prefer synced. Users prefer “I can log in.”
Security teams may prefer device-bound. Product teams may prefer synced. Users prefer “I can log in.”
“Rollout” isn’t “enforcement”: the dangerous comfort of fallback paths
Many organizations proudly announce passkey support while keeping passwords, SMS codes, emailed links, or other fallback methods fully enabled. FIDO’s “Journey to Prevent Phishing” series explicitly describes intermediate stages—often “partial prevention”—where passwords and other fallbacks remain. That’s common in real deployments because lockouts are expensive and customer support is real.
But from an attacker’s perspective, the weakest path is the only path that matters.
But from an attacker’s perspective, the weakest path is the only path that matters.
A real-world pattern: attackers don’t fight the best lock
If a site offers passkeys and a password reset flow that can be socially engineered, phished, or coerced, attackers will route around the passkey. If the service allows users to “try another way” and one of those ways is less resistant to phishing, the passkey becomes an optional upgrade rather than a security control.
FIDO’s series warns that leaving fallbacks open can undermine passkey security—particularly if attackers can trigger or force those paths. The risk isn’t theoretical; it’s structural: a system’s security is bounded by its least-resistant recovery and fallback mechanisms.
FIDO’s series warns that leaving fallbacks open can undermine passkey security—particularly if attackers can trigger or force those paths. The risk isn’t theoretical; it’s structural: a system’s security is bounded by its least-resistant recovery and fallback mechanisms.
The editorial tension inside companies
- Security view: enforce strong, phishing-resistant methods; reduce the surface area of phishable flows.
- Product/support view: avoid lockouts; keep escape hatches; minimize abandonment.
- Compliance view: map methods to assurance levels; justify controls; document recovery.
All three are legitimate. The mistake is pretending you can have “full passkey security” while the old doors remain propped open.
- Product/support view: avoid lockouts; keep escape hatches; minimize abandonment.
- Compliance view: map methods to assurance levels; justify controls; document recovery.
All three are legitimate. The mistake is pretending you can have “full passkey security” while the old doors remain propped open.
Sessions: the part passkeys don’t automatically protect
A passkey helps you prove you’re the legitimate user at login. After that, most web apps issue a session—often via cookies or bearer tokens—that acts like a hallway pass. FIDO’s guidance makes a blunt point: even with passkeys, bearer tokens and session hijacking remain key vulnerabilities. (FIDO Passkeys Journey Part 3)
That’s the uncomfortable center of modern web compromise. Attackers don’t always need your authentication method if they can steal the proof that you already authenticated.
That’s the uncomfortable center of modern web compromise. Attackers don’t always need your authentication method if they can steal the proof that you already authenticated.
How session theft fits into the passkey story
Consider the attacker’s options:
- Before login: steal something reusable (passwords, OTP codes). Passkeys dramatically reduce this.
- After login: steal something that grants access (session cookies/tokens). Passkeys don’t inherently stop this.
FIDO’s materials explicitly call out that passkeys don’t “magically bind” the entire session to the legitimate user/device without additional token protections. The implication is clear: services need to treat post-authentication security as a first-class design problem, not as a footnote.
- Before login: steal something reusable (passwords, OTP codes). Passkeys dramatically reduce this.
- After login: steal something that grants access (session cookies/tokens). Passkeys don’t inherently stop this.
FIDO’s materials explicitly call out that passkeys don’t “magically bind” the entire session to the legitimate user/device without additional token protections. The implication is clear: services need to treat post-authentication security as a first-class design problem, not as a footnote.
Practical takeaways for readers (and for companies)
For readers:
- Treat passkeys as a strong upgrade, not an invisibility cloak.
- Keep devices clean; infostealers and malicious extensions target sessions as much as passwords.
For companies:
- Don’t declare “phishing solved” if session tokens can be replayed from another device.
- Evaluate token-handling, session lifetimes, and hijack resistance as part of your passkey program—not after.
The promise of passkeys remains real. The myth is that authentication alone ends account takeover.
- Treat passkeys as a strong upgrade, not an invisibility cloak.
- Keep devices clean; infostealers and malicious extensions target sessions as much as passwords.
For companies:
- Don’t declare “phishing solved” if session tokens can be replayed from another device.
- Evaluate token-handling, session lifetimes, and hijack resistance as part of your passkey program—not after.
The promise of passkeys remains real. The myth is that authentication alone ends account takeover.
“Phishing-resistant” in standards language: what NIST and FIDO are signaling
Security teams often talk past each other because they mean different things by “secure.” The research here gives two useful anchors: FIDO’s framing of passkey anti-phishing maturity, and NIST’s framing of assurance levels.
FIDO’s “Journey to Prevent Phishing” series (March 2025) is instructive precisely because it doesn’t pretend passkeys are a one-step fix. It discusses stages where fallbacks remain and where attackers can still exploit non-passkey paths. That’s an industry body acknowledging operational reality.
NIST is even more explicit about the distinction between phishing resistance and key exportability. NIST SP 800-63B-4 (July 2025) frames AAL3 around a phishing-resistant cryptographic authenticator with a non-exportable private key. That has a quiet but profound implication: some passkey deployments (especially synced ones) may satisfy the “phishing-resistant” property but not the non-exportable requirement associated with higher assurance.
FIDO’s “Journey to Prevent Phishing” series (March 2025) is instructive precisely because it doesn’t pretend passkeys are a one-step fix. It discusses stages where fallbacks remain and where attackers can still exploit non-passkey paths. That’s an industry body acknowledging operational reality.
NIST is even more explicit about the distinction between phishing resistance and key exportability. NIST SP 800-63B-4 (July 2025) frames AAL3 around a phishing-resistant cryptographic authenticator with a non-exportable private key. That has a quiet but profound implication: some passkey deployments (especially synced ones) may satisfy the “phishing-resistant” property but not the non-exportable requirement associated with higher assurance.
Why this matters to anyone who logs into a bank
Banks, brokerages, and other high-value services are not being fussy when they ask about device-bound keys. They are responding to a threat model where:
- A single compromised sync account can have wide impact.
- Recovery processes can be attacked.
- Regulators care about assurance categories.
None of that means synced passkeys are “bad.” It means “passkeys” isn’t a single security level.
- A single compromised sync account can have wide impact.
- Recovery processes can be attacked.
- Regulators care about assurance categories.
None of that means synced passkeys are “bad.” It means “passkeys” isn’t a single security level.
Expert attribution, grounded in the sources
- The FIDO Alliance emphasizes that WebAuthn’s origin binding is central to phishing resistance and separately highlights bearer-token theft and session hijacking as remaining vulnerabilities in passkey journeys. (FIDO Alliance publications cited above)
- NIST explicitly ties higher assurance (AAL3) to non-exportable private keys in SP 800-63B-4 (July 2025). (NIST 800-63B-4)
Those aren’t casual blog opinions. They are standards bodies and industry consortia spelling out the boundaries.
- NIST explicitly ties higher assurance (AAL3) to non-exportable private keys in SP 800-63B-4 (July 2025). (NIST 800-63B-4)
Those aren’t casual blog opinions. They are standards bodies and industry consortia spelling out the boundaries.
What “good passkey adoption” looks like: a sober checklist
Passkeys can deliver on their promise, but only if organizations resist the temptation to treat “support” as “security.” The research points to a practical mindset: focus on the full user journey, including fallbacks and sessions.
### For organizations: design for the whole journey
A passkey program that meaningfully reduces account takeover tends to include:
- Clear migration goals: Are you merely offering passkeys, or aiming to reduce or remove phishable methods over time?
- Fallback hardening: If passwords remain, can attackers force users into that path? If recovery exists, can it be abused?
- Token/session protections: If tokens are bearer-style and replayable, can they be stolen and reused elsewhere? (FIDO flags this risk directly.)
- Assurance segmentation: For high-risk actions (payments, account changes), consider stricter authenticators—potentially device-bound passkeys aligned with NIST’s non-exportable framing for AAL3.
### For readers: how to interpret passkey claims
When a service announces passkeys, ask two questions:
1. Can I still log in with a password or another phishable fallback?
2. If someone steals my session cookie, does the service notice—or does it accept the cookie as me?
The answers determine whether passkeys are a strong layer or merely a nicer login screen.
### For organizations: design for the whole journey
A passkey program that meaningfully reduces account takeover tends to include:
- Clear migration goals: Are you merely offering passkeys, or aiming to reduce or remove phishable methods over time?
- Fallback hardening: If passwords remain, can attackers force users into that path? If recovery exists, can it be abused?
- Token/session protections: If tokens are bearer-style and replayable, can they be stolen and reused elsewhere? (FIDO flags this risk directly.)
- Assurance segmentation: For high-risk actions (payments, account changes), consider stricter authenticators—potentially device-bound passkeys aligned with NIST’s non-exportable framing for AAL3.
### For readers: how to interpret passkey claims
When a service announces passkeys, ask two questions:
1. Can I still log in with a password or another phishable fallback?
2. If someone steals my session cookie, does the service notice—or does it accept the cookie as me?
The answers determine whether passkeys are a strong layer or merely a nicer login screen.
A sober passkey program checklist
- ✓Set clear migration goals beyond “support passkeys.”
- ✓Harden or constrain fallbacks and recovery so attackers can’t route around passkeys.
- ✓Treat token/session replay resistance as part of the passkey program, not a later phase.
- ✓Segment assurance: use stricter authenticators (potentially device-bound) for high-risk actions.
The bigger picture: passkeys are a cure for one disease, not for mortality
Passkeys are a rare thing in consumer security: a genuine improvement that removes a major class of failure by design. Origin binding is a powerful idea, enforced at the protocol level. That alone deserves celebration.
But the internet’s account security problem has never been only about login prompts. It’s about the entire chain: enrollment, recovery, fallback methods, and the long-lived session artifacts that keep you logged in. FIDO’s own guidance acknowledges that session hijacking and bearer-token theft remain. NIST’s language reminds us that “phishing-resistant” doesn’t automatically mean “non-exportable.”
The next year of passkey discourse will likely split into two camps: people who want the simplest user experience, and institutions that want the strictest assurance. Both are rational. The best systems will be honest about which goal they’re optimizing for—and will stop implying that a passkey rollout, by itself, ends the story.
A passkey can stop you from handing your keys to a stranger. It can’t, on its own, prevent someone from stealing your coat once you’re inside.
But the internet’s account security problem has never been only about login prompts. It’s about the entire chain: enrollment, recovery, fallback methods, and the long-lived session artifacts that keep you logged in. FIDO’s own guidance acknowledges that session hijacking and bearer-token theft remain. NIST’s language reminds us that “phishing-resistant” doesn’t automatically mean “non-exportable.”
The next year of passkey discourse will likely split into two camps: people who want the simplest user experience, and institutions that want the strictest assurance. Both are rational. The best systems will be honest about which goal they’re optimizing for—and will stop implying that a passkey rollout, by itself, ends the story.
A passkey can stop you from handing your keys to a stranger. It can’t, on its own, prevent someone from stealing your coat once you’re inside.
T
About the Author
TheMurrow Editorial is a writer for TheMurrow covering technology.
Frequently Asked Questions
What exactly is a passkey?
A passkey is typically a consumer label for a discoverable (resident) FIDO credential used with FIDO2 standards: W3C WebAuthn and FIDO CTAP. It lets you authenticate using public-key cryptography, often with a biometric or device unlock, without sending a reusable secret like a password to the website.
Are passkeys truly phishing-resistant?
In the formal sense, yes—because WebAuthn provides origin binding. A passkey registered for `bank.com` won’t cryptographically sign challenges for a lookalike domain. That blocks classic credential phishing and many proxy-style attacks that rely on stealing something reusable. FIDO’s anti-phishing publications emphasize this property.
If I use passkeys, can my account still be hacked?
Yes. Passkeys mainly protect the authentication step. Attackers can still target session cookies or bearer tokens after you’ve logged in, via malware, infostealers, or malicious extensions. FIDO’s guidance explicitly flags bearer-token theft and session hijacking as remaining vulnerabilities even in strong passkey deployments.
What’s the difference between synced and device-bound passkeys?
Synced passkeys are backed up and synced across devices via a “sync fabric” (often an OS credential manager). Device-bound passkeys are non-exportable; the private key never leaves one device (including hardware security keys). FIDO describes both models, and the security tradeoffs differ significantly.
Why do banks care about “non-exportable” keys?
For high-value accounts, banks often want not only phishing resistance but also assurance that the private key can’t be exported or copied. NIST SP 800-63B-4 (July 2025) ties AAL3 to a phishing-resistant cryptographic authenticator with a non-exportable private key, signaling why device-bound models can matter for stricter requirements.
If a website supports passkeys, is it safe to assume passwords are gone?
No. Many deployments are “rollouts,” not “enforcement.” FIDO’s own passkey journey describes intermediate phases where passwords and other fallbacks remain enabled, which can undermine security if attackers can trigger or force those weaker paths. “Supports passkeys” often means “adds another option,” not “removes old risk.”
