Passkeys Secure Login, Not the Recovery Path

In May 2026, several gaming industry figures had their PlayStation Network accounts hijacked despite having both two-factor authentication and passkeys enabled. The exploit had reportedly been circulating since November 2025. The reason it worked is straightforward once you see it: passkeys and two-factor codes protect the login step. Neither was ever designed to protect the account-recovery step, and a recovery flow that accepts low-entropy information — a phone number, a partial email match, a support-ticket answer — as proof of account ownership is a door that a strong login can't lock.

Password theft is losing value, so fraud is moving one step over

Passkey adoption has genuinely worked at what it set out to do: 75% of consumers globally have now enabled a passkey on at least one account, and the credential itself is close to phishing-resistant compared to a password. That success has a predictable side effect. When the front door gets harder to pick, attackers don't give up, they move to the door that's still weak — and in most account systems, including the ones running under a mobile game's login flow, that's the "I lost access to my account" path, not the normal sign-in path.

Account recovery exists because it has to: players lose devices, switch phones, forget which email they used to sign up years ago. A recovery flow that's too strict locks out real players and generates support load a small team can't absorb. A recovery flow that's too permissive is a bypass for the exact authentication a studio spent engineering time hardening. Most studios have thought carefully about the first problem and not at all about the second, because the login flow is the part that gets built with security review and the recovery flow is the part that gets built to reduce support tickets.

SIM-swap fraud is the concrete version of this gap

The mechanism attackers actually use is well documented outside gaming and applies identically inside it: convince a mobile carrier to port a victim's phone number to a new SIM, then use that number to pass an SMS-based recovery check or a phone-verification step that a game's account system treats as sufficient proof of identity. SIM-swap fraud drained more than $72 million from victims in a recent multi-year reporting period across thousands of complaints, and in nearly every case the loss entered through the recovery or verification path, not through a compromised login credential. A player's phone number, which feels like a natural piece of identity to verify against, is controlled by a third party — the carrier — that an attacker can social-engineer independently of anything the player or the game did wrong.

For a mobile game, the stakes of this gap are proportional to what an account actually holds: a hijacked account with real-money purchase history, a whale-tier spend profile, or valuable in-game inventory is worth more to an attacker than a fresh account, and the account-recovery flow is very often the cheapest way in precisely because it wasn't built with the same scrutiny as the login flow.

What actually closes the gap, since passkeys alone don't

The fix isn't abandoning passkeys or SMS-based recovery outright — both remain useful pieces of a layered system. The fix is treating recovery as its own security-critical flow rather than a convenience feature bolted onto login, which means a few specific changes most game account systems don't yet have:

Require more than one independent recovery signal before granting access, so a single compromised channel — a hijacked phone number, a guessed security answer — isn't sufficient on its own. Two weak signals combined are meaningfully harder to fake than one weak signal alone, even if neither is individually strong.

Add friction and a cooling-off window specifically to high-value account changes made through the recovery path — a payment method change, an email change, a large in-game transfer — so a successful recovery bypass doesn't immediately translate into a drained account before the real owner has a chance to notice and intervene.

Log and alert on recovery attempts the same way you'd log a suspicious login, rather than treating recovery as an unmonitored side door. A player who didn't request a recovery flow and gets notified that one started has a chance to stop it; a recovery flow that completes silently gives them none.

This is an SDK and account-layer decision, not just a platform one

Most mobile games don't build their own authentication stack from scratch — they lean on a platform login (Google Play Games, Game Center, a first-party account system) or a third-party auth SDK, and the recovery flow's actual security properties are usually inherited from whichever of those a studio chose without much scrutiny of the recovery path specifically. Before wiring up an integration that handles player identity, it's worth asking the same question of the recovery flow that you'd ask of the login flow: what's the weakest single piece of information that gets someone in, and is that piece of information something a stranger could plausibly obtain about one of your players.