Passkeys won’t save you from bad recovery

Passkeys promise the thing security people have begged for since forever: no passwords to phish, steal, or reuse. That’s a big win. But a new expert column points out that a perfect login still isn’t proof you should trust what happens next.

In a SecurityWeek column, Dr. Torsten George writes that passkeys “are better than passwords,” but they don’t erase identity risk across enrollment, recovery, device changes, and sessions (SecurityWeek). His take: strengthen authentication, then keep checking whether the identity is still worthy of trust.

What happened

The column explains passkeys replace shared secrets with public‑key cryptography: a private key stays on the user’s device while the service holds a public key (SecurityWeek). Because the private key never leaves the device, there’s nothing reusable to intercept or replay.

It says properly implemented passkeys are bound to the legitimate service, which makes them resistant to phishing and adversary‑in‑the‑middle kits that harvest logins and codes (SecurityWeek). That’s a material lift over passwords plus one‑time codes, SMS, or push prompts.

The author argues the improvement doesn’t answer a harder question: after a successful login, should the system still trust the identity? If the account itself was seeded by an attacker, tight authentication only locks in the wrong owner (SecurityWeek).

He highlights enrollment integrity as a first failure point. If a bad actor creates or takes over an account before a passkey is bound, all subsequent authentications will be secure—and misattributed to the attacker (SecurityWeek).

Device churn is flagged as a second weak spot. People lose phones, replace laptops, and switch ecosystems, so organizations must handle users who show up without the expected passkey (SecurityWeek). That shifts the problem from login to recovery and re‑establishing trust.

The recovery path often reintroduces old weaknesses. If fallback uses passwords, SMS codes, email links, knowledge‑based questions, or help‑desk steps, attackers target the easier path around the passkey (SecurityWeek). The authenticator isn’t broken—the process is.

Session trust is the third gap. Many architectures still follow authenticate‑grant‑trust, but attackers can hijack sessions, abuse privileges, or quietly tweak account attributes after login, the column notes (SecurityWeek). In those cases, the login worked as designed while the identity trust decays.

The proposed fix is identity threat detection layered on top of passkeys. Instead of trusting indefinitely, systems should continuously evaluate risk using device characteristics, identity attributes, behavioral anomalies, network intelligence, account change events, transaction context, and threat indicators (SecurityWeek).

A risk‑based model is emphasized as the practical way to do this. Known users on known devices behaving normally proceed without added friction, while unfamiliar devices, sensitive account changes, or anomalous activity trigger additional verification only when needed (SecurityWeek).

Finally, the author warns that as organizations eliminate passwords, attackers will adapt. The target shifts from the authenticator to the processes around it—enrollment, recovery, session integrity, and high‑risk actions—because that’s where the new leverage lives (SecurityWeek).

The background

Passwords remain a top failure because people forget, reuse, and surrender them; attackers also automate credential stuffing and tune social engineering with AI, the piece notes (SecurityWeek). Passkeys directly reduce those credential‑theft and reuse risks.

Traditional multi‑factor add‑ons don’t fully help. One‑time passcodes, SMS, and push prompts can be phished, SIM‑swapped, or abused with MFA fatigue, according to the column (SecurityWeek). That’s why binding authentication to the real origin is a leap forward.

Usability is a real upside. With passkeys, users don’t memorize complex passwords or fetch transient codes repeatedly, which the column says organizations should welcome as a net gain for both security and experience (SecurityWeek).

Recovery is where old habits return. The author points out that help‑desk procedures, knowledge questions, and email links often survive the passkey rollout and become the new primary attack paths (SecurityWeek). That’s the choke point to redesign.

Continuous verification reframes identity from a moment to a lifecycle. The piece recommends monitoring device health, network context, and account changes so trust can be raised, maintained, or revoked as conditions shift (SecurityWeek). That’s a closer fit to how attacks actually unfold.

Related attacks reinforce the need to watch after login. Our earlier coverage of AI‑made login clones and token replay in Microsoft 365 shows how criminals pivot to sessions and tokens once they pass the front door. For more on defensive basics, see our authentication hub.

What people are saying

Dr. Torsten George sums up the core risk plainly: “Authentication is not identity” (SecurityWeek). His argument is that cryptographic proof of a login doesn’t prove the account owner remains trustworthy.

He also cautions that “the stronger the authenticator becomes, the more important the integrity of enrollment becomes,” because attackers will work upstream to seed accounts before strong authenticators are bound (SecurityWeek).

On operations, he advocates a risk model that “does not require adding friction to every interaction,” reserving extra checks for unusual devices, sensitive changes, or anomalous behavior while letting normal work flow uninterrupted (SecurityWeek).

For email and collaboration admins, that framing aligns with our reporting on how attackers lean on help‑desk persuasion and device‑code flows to sidestep MFA—see our notes on help‑desk social engineering and device‑code abuse campaigns like Skyw4lker’s phishing. The shared theme: process beats prompts.

What happens next

If you’re rolling out passkeys, the column implies you’ll need a parallel track to harden three things: enrollment proofing, recovery evidence, and post‑login risk checks (SecurityWeek). That’s how you stop attacks from routing around authentication.

Design recovery as if it will be attacked first. Replace knowledge questions and SMS resets with verifiable signals and documented workflows that can’t be socially engineered as easily, the author suggests by warning about weak fallbacks (SecurityWeek).

Map sensitive identity actions—adding a new device, changing account attributes, or initiating high‑risk transactions—to adaptive checks. The piece lists device traits, behavior, network intel, and threat indicators as inputs that decide when to step up verification (SecurityWeek).

Expect attacker adaptation as passwords fade. The author’s forecast is straightforward: passkeys succeed by shrinking one attack surface, so adversaries will push on the edges—enrollment fraud, recovery abuse, session hijack, and anomalous actions—to get the same outcomes by other means (SecurityWeek).

For email teams, that translates to watching the moves that matter: forwarding rules, reply‑to changes, mailbox delegations, and bulk data pulls after an otherwise clean login. Our earlier guidance on hardening deliverability during security spikes explains how to add guardrails without hurting inbox placement.