PSN Account Hack: Why Passkeys and 2FA Didn’t Stop It

For years, the security industry’s advice on consumer accounts has been simple: use a strong, unique password, turn on multifactor authentication, and move to passkeys where you can. That advice still holds. Passkeys remove most of the weaknesses of shared secrets, and well-implemented MFA makes unauthorized access much harder. But the PlayStation Network (PSN) reports from late 2025 through 2026 raise an uncomfortable question about where those protections end.

In December 2025, French tech journalist Nicolas Lellouche described how his PSN account was compromised even though he used access keys and two-factor authentication. Attackers had persuaded customer support to hand over control using historical purchase information. Then, in October 2026, users began reporting unfamiliar child accounts appearing in their family groups, sometimes alongside unexpected changes to their account email addresses.

Both cases point at the same gap. The mechanisms used to recover, delegate, or manage an account can be much weaker than the mechanisms used to sign in. Passkeys have not stopped working, and the FIDO2 cryptography underneath them is intact. What fails is the identity proofing and account recovery that surround them, and strong authentication cannot make up for that.

How attackers take over PSN accounts through customer support

Recovery through customer support works as a privileged administrative backdoor. In the Lellouche incident, the takeover reportedly relied on data from a previous PlayStation Store purchase. The attacker contacted PlayStation Support, gave a PSN username and a transaction identifier, and got control of the account.

The central allegation is a serious one – a support representative can be talked into transferring ownership without the attacker ever holding the victim’s password, passkey, or second factor. The support workflow treated historical purchase information as enough evidence to authorize a highly sensitive change.

A transaction ID is a poor authentication secret. It exists for billing reconciliation and customer service context, and nobody designed it to be a durable, rotatable credential. Once it leaks, you cannot change it. It also turns up in email receipts, order histories, screenshots, and public forums, so it is easy to harvest. An attacker who gets one has a permanent key to the support recovery process, and the technical checks on the main sign-in never come into play.

Account information vs. proof of authorization

Identity management draws a line between information about an account and cryptographic evidence of authorization. Knowing what someone bought, when they bought it, or the transaction ID attached to the purchase does not show that the person on the phone is the legitimate account holder, or that they hold the registered authenticators.

A support representative handling a recovery request is operating an administrative interface that can reset credentials, transfer ownership, or strip multifactor authentication. If that interface grants account-level privileges on weak, knowledge-based evidence, the guarantees of the login system stop mattering for that operation. The attacker does not have to defeat the lock on the front door when a human-operated side door opens for anyone who can recite the color of the doormat.

Modern identity guidance warns against exactly this. NIST Special Publication 800-63B says account recovery should repeat part of the original identity proofing and should not rest on weak knowledge-based authentication alone for high-assurance accounts.

What passkeys protect and what they leave open

To see why passkeys did not prevent these takeovers, you need to know what a passkey is built to protect. Passkeys rest on the FIDO2 framework and the W3C Web Authentication (WebAuthn) standard, which use public-key cryptography in a challenge-response protocol in place of shared secrets.

When a user registers a passkey, the local authenticator generates a key pair. The private key stays in the device’s hardware enclave or secure passkey provider, and the public key goes to the Relying Party, which here is PSN. At sign-in, the server generates an unpredictable challenge and the client passes it to the authenticator. The authenticator signs it with the private key, adds metadata confirming the origin and Relying Party ID, and returns the signed assertion for validation.

// Simplified WebAuthn Authentication Ceremony (Client-Side)
const credential = await navigator.credentials.get({
  publicKey: {
    challenge: new Uint8Array(serverChallenge), // Unpredictable server nonce
    rpId: "sonyentertainmentnetwork.com",
    allowCredentials: [{ id: credentialId, type: 'public-key' }],
    userVerification: "preferred", // Biometric or PIN check
    timeout: 60000,
  }
});
// The authenticator signs the challenge and client data JSON.
// The Relying Party MUST verify the signature, the origin, and the rpId.

The security properties here are strong. The server stores no secret that a database breach could leak, the challenge blocks replay attacks, and the binding to the Relying Party ID and origin shuts down traditional phishing and credential stuffing.

None of that tells a support representative how to handle a request to replace an account’s registered email address or remove a hardware security key. Authentication answers one question: does the party at the door hold the registered cryptographic credential? Identity proofing and account recovery answer different ones, such as what evidence is needed to re-establish trust when credentials are lost or when someone asks for an administrative change.

A passkey proves that whoever completed the WebAuthn ceremony controls the registered device. It offers nothing if the service lets an attacker skip that ceremony by calling a support line and reading a transaction ID off a stolen receipt. Saying the passkey was “bypassed” is technically misleading, because the passkey was never challenged. The attacker got administrative control through an identity-proofing failure outside the sign-in flow, which shows that an account is only as secure as its weakest recovery path.

Unauthorized child accounts in PlayStation Family groups

The second wave of reports gained traction in October 2026, when users found child accounts they did not recognize in their PlayStation Family groups. Some also received unexpected notifications about changes to their sign-in IDs, even with passwords and two-factor authentication ostensibly enabled. This is a different kind of problem, one about authorization and delegated permissions.

The public reports do not establish a single, reproducible exploit chain. They do point to a design issue in Sony’s relationship-based account management – family managers do not appear to get a general self-service way to remove child members once added. According to official PlayStation documentation, adult family members can be removed through the Account Management interface, while child members fall under a stricter set of rules built mainly for legitimate parental-control lifecycles.

That restriction creates a persistence problem when the addition is unauthorized. A secure delegated-access model needs two things: admission control that stops unauthorized relationships from forming, and revocation that reliably ends them when they are compromised or disputed. Suppose an attacker adds a malicious child account to a victim’s family group, through a compromised session, an authorization bypass, or a flaw in the invitation workflow. The legitimate manager then has no direct way to cut that tie. The victim depends on customer support to clean up, which stretches the time to containment and leaves the attacker a foothold inside the victim’s administrative boundary.

Why server-side authorization checks matter for family management

Every family-management operation needs a rigorous server-side authorization check. A common web application failure here is Broken Object Level Authorization (BOLA), where an API endpoint authenticates the user correctly but never verifies that the authenticated principal has management authority over the specific object being changed, in this case a particular family group ID.

# Conceptual Server-Side Authorization Check for Family Management
def add_child_to_family(authenticated_user, family_group_id, child_account_id):
    # 1. Authentication is already handled by the middleware (JWT/Session valid)
    
    # 2. Authorization: Does the user own or manage THIS specific family group?
    target_family = db.get_family_group(family_group_id)
    if target_family.manager_id != authenticated_user.id:
        raise AuthorizationException("User lacks authority over this family group.")
        
    # 3. Business Logic & State Validation
    if target_family.child_count >= MAX_CHILDREN:
        raise ValidationException("Family group capacity exceeded.")
        
    if not is_valid_child_account(child_account_id):
        raise ValidationException("Invalid child account state.")
        
    # 4. Execute the privileged operation
    db.create_family_relationship(target_family, child_account_id)
    audit_log.record(authenticated_user, "ADD_CHILD", family_group_id, child_account_id)

Hiding the “Add Child” button from unauthorized users on the client side is not enough, because attackers can craft direct API requests with manipulated parameters. The server has to check, independently, that the caller has authority over the specific relationship being modified. That way a compromised session or a poorly scoped token cannot change the administrative boundaries of an unrelated account.

It also matters because the unauthorized child accounts stay put. Even if the original intrusion vector gets closed, the attacker keeps a structural presence in the account’s ecosystem. From there they could exploit spending limits, reach shared content, or keep a backdoor open for later social engineering of support staff.

What the 2026 USENIX passkey study found

The PSN incidents are not isolated. They fit a wider pattern in how modern authentication protocols meet legacy application architectures. A 2026 USENIX Security study, “The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web,” put numbers on it. Its authors include Louis Jannett of Ruhr University Bochum.

The researchers built tooling to evaluate real-world passkey deployments and tested 103 passkey-enabled Relying Parties for protocol-handling and implementation flaws. Even with the WebAuthn standard in use, 18 of the sites were vulnerable to at least one critical-severity attack, and 53 were vulnerable to high-severity attacks.

These results say nothing against FIDO2 cryptography itself. A secure authentication standard does not make the surrounding application logic secure. The researchers found implementation errors where Relying Parties failed to validate the origin properly, mishandled credential registration, or let fallback mechanisms quietly bypass strong authentication policies.

An application can undermine a mathematically sound protocol by misreading authentication results, mishandling account state, or leaving recovery workflows poorly gated. If a service implements WebAuthn flawlessly on the login page but lets users reset a password or change their primary email with only an SMS code or a security question, the weaker fallback sets the real security level of the account. Judging a passkey-enabled account means looking at the whole application lifecycle, and a “Login with Passkey” button on the homepage settles very little.

How to fix account recovery and delegated access

Fixing these problems means treating recovery and delegation as high-assurance security boundaries instead of customer-service conveniences. If the support-side allegations reflect a real weakness in PlayStation’s recovery process, the fix starts with raising the standard of evidence for sensitive account operations.

Historical purchase data, transaction identifiers, and public profile details should help locate an account in a database. They should never be standalone proof of ownership that can override cryptographic authenticators. High-risk changes, such as transferring a sign-in email address, removing a registered passkey, or altering recovery channels, should demand evidence in proportion to the authority being handed over. That could mean a recent successful authentication with an existing trusted method, an independently secured out-of-band recovery mechanism, or a multi-step identity verification process aligned with the higher Authenticator Assurance Levels in NIST’s guidance.

Delegated permissions like the PlayStation Family system need the same attention, and revocation should count as a core security operation. There are legitimate product reasons to restrict deleting child accounts, such as preserving parental controls and purchase histories. Even so, the system needs an audited security-remediation workflow for disputed relationships. When a family manager reports an unauthorized child account, support should have an expedited procedure to review admission logs, check whether the relationship was legitimately created, and sever it safely, without sending the victim through a generic, low-assurance support queue.

Every administrative action, whether a user takes it through the API or a support representative takes it from an internal dashboard, should leave an immutable audit trail. The trail should record who initiated the request, what evidence was evaluated, and which authorization checks passed. Account-change notifications help with awareness after the fact, but they react to an incident and cannot replace preventive, cryptographically backed authorization gates.

an account is only as secure as its recovery process

The PlayStation Network incidents from late 2025 through October 2026 show that an account’s perimeter extends well past the login screen. Attackers do not need to break public-key cryptography if they can exploit human and architectural gaps in the identity lifecycle: customer support that can be manipulated with historical purchase data, and unauthorized child accounts that family managers cannot remove.

Passkeys remain a major achievement in consumer security, and they resist phishing and credential theft during the authentication ceremony better than anything before them. They cannot secure an administrative backdoor, fix a broken object-level authorization check, or make a support representative reject a socially engineered request.

For the wider industry, identity security cannot be reduced to one cryptographic protocol. An account is protected by the sum of its processes: identity proofing, server-side authorization, recovery fallbacks, and revocation. A passkey can show that the right credential was presented. The service provider still has to make sure the person asking to take over an account’s administrative boundaries is authorized to do so.