What Happens When Identity Becomes a Login

The email said his account had been "flagged for a possible violation" and gave no further detail. By the time he'd finished reading it, he was already locked out — not just of Gmail, but of the Google Photos library holding a decade of family pictures, the Google-authenticated two-factor codes protecting his banking app, the smart home system he'd set up through a Google-linked hub, and — this was the part he hadn't anticipated — nine or ten other services entirely unrelated to Google, all of which he'd set up years earlier using the convenient "Continue with Google" button, because typing a new password felt like unnecessary friction at the time.

He hadn't lost one account. He'd lost the master key to a life he hadn't realised was this centrally wired.

Single sign-on solved a real problem, honestly

It's worth being fair to the feature before criticising its consequences: password fatigue is real, password reuse across services is a genuine security risk, and "Log in with Google" (or Apple, or Facebook) does solve both problems for the individual service that offers it. From the perspective of any single sign-up moment, choosing the convenient option is a reasonable decision, and framing users as careless for making it misses how genuinely sensible the trade-off looks in isolation, one login at a time.

The risk was never visible in any single instance of this choice. It accumulated the same way platform dependency accumulates generally — invisibly, through individually reasonable decisions, until enough of them stacked up onto the same underlying account that the account itself became a single point of failure for a large, previously uncorrelated set of separate services.

What "identity as a login" actually concentrates

The deeper issue isn't simply inconvenience if locked out — it's what gets concentrated into a single point of control that most people never explicitly decided to concentrate. Authentication (proving who you are) and authorisation (proving you're allowed to do a specific thing) both end up flowing through the same provider, for services that have nothing to do with that provider's actual business, and no direct relationship with the person affected by an account suspension beyond an automated appeals form and an indeterminate wait.

This is a meaningfully different risk profile than a single service losing your account. A suspended streaming subscription is an inconvenience. A suspended identity provider that also controls your two-factor authentication, your email-based password resets, and your login to a dozen other services is closer to a sudden, total loss of digital personhood, with an appeals process typically calibrated for a free consumer product, not for something that has quietly become critical infrastructure for a person's entire online life.

Nobody decided, in one moment, to make a single company's account status a precondition for their entire digital existence. It happened one convenient login at a time.

Why the appeals process is structurally mismatched to the stakes

The mismatch here is worth naming specifically: identity providers generally offer free consumer accounts, supported by advertising or a broader business model, with correspondingly limited customer support — a reasonable trade-off for a genuinely free product. But as that same free account becomes, functionally, critical authentication infrastructure for a person's entire digital life, the stakes of an error rise dramatically while the support resources available to correct that error do not rise to meet them. A billing dispute with a bank comes with a legally mandated resolution process. A wrongful account suspension from an identity provider often comes with an automated form and no guaranteed timeline at all.

What reduces this specific risk, practically

The most direct mitigation is also the least convenient one, which is precisely why it's underused: maintaining independent, non-federated logins (a real password, stored in a password manager, not "Continue with X") for anything genuinely important — financial accounts, primary email, anything holding irreplaceable data like photos. This sacrifices some convenience at each individual sign-up in exchange for ensuring that a single provider's decision can't cascade across services that have no actual relationship to that provider.

A second, structural mitigation, still emerging rather than mainstream: identity systems built specifically so that no single provider holds this much concentrated control — credentials a person holds themselves, verified cryptographically rather than through a continuous relationship with a company able to revoke access unilaterally. This doesn't yet exist widely enough to be a practical recommendation for most people today, but it's the direction the underlying problem points toward, for anyone building identity infrastructure with this specific failure mode in mind.

He got his account back, eventually, after weeks of appeals and a small amount of media attention that probably helped more than the appeals process itself did. He hasn't used "Continue with Google" since. Not out of general suspicion of the company — out of a specific, hard-earned understanding of exactly how much he'd concentrated into one login, without ever deciding to.

Frequently asked questions

What is single sign-on (SSO), and why do so many services offer it?
It lets you log into a service using an existing account (Google, Apple, Facebook) rather than creating a new password. It genuinely reduces password fatigue and reuse risk, which is why it's so widely offered and adopted.

What's the actual risk of using "Log in with Google" everywhere?
If that central account is suspended, locked, or compromised, every service you've linked to it through SSO can become inaccessible simultaneously, turning one account issue into a cascading loss across unrelated services.

Why are appeals processes for these suspensions often so slow or difficult?
Because free consumer accounts are typically supported at a scale and cost structure suited to a free product, even as they've quietly become critical authentication infrastructure with much higher real-world stakes than that support model was designed for.

How can I reduce this specific risk?
Use independent, non-federated logins (a unique password stored in a password manager) for your most important accounts — banking, primary email, anything with irreplaceable data — rather than "Continue with" buttons, even though it's less convenient at sign-up.

Are there emerging alternatives to centralised SSO?
Yes — self-sovereign and cryptographic identity systems, where you hold verifiable credentials directly rather than depending on a continuous relationship with a single provider, are an active area of development, though not yet mainstream enough for most people to rely on today.