SSO stands for Single Sign-On: the authentication pattern where one identity provider authenticates the user, and that authentication is accepted by multiple downstream services. Consumer SSO (“Login with Google,” “Login with Apple,” “Login with Facebook”) is the most familiar implementation; enterprise SSO (Okta, Azure AD, Google Workspace) is the structural foundation of corporate identity management. Reduces password proliferation but creates cascade-compromise risk where the SSO account becomes the master key.
What it means in practice
The structural trade-off of SSO: convenience versus blast radius. Convenience is real (one set of credentials, faster signup, no password reuse for the SSO-protected services). Blast radius is also real: compromise of the SSO account compromises every service that uses it. The 2022 Okta breach and the broader pattern of identity-provider compromise illustrate the cascade structure. The consumer-SSO concerns add a privacy dimension: “Login with Facebook” tells Facebook every site you log into; “Login with Google” creates a similar visibility for Google; “Login with Apple” added the email-relay feature that addresses some privacy concerns but still routes authentication through Apple’s identity infrastructure. The Predaxia operational position: SSO is appropriate for low-stakes services where the convenience compounds across many sites, inappropriate for high-value services where the cascade risk and the identity-provider visibility outweigh the convenience benefit.
Where it shows up
Used in: nearly every modern consumer service (the SSO option is standard in 2026 signup flows), enterprise identity management for the Fortune 500 (Okta, Azure AD, Ping, ForgeRock dominate), developer tooling (GitHub SSO is the most consequential single integration in the developer ecosystem), and the broader category of any context where identity needs to flow across multiple services. The privacy implications: every consumer SSO use tells the identity provider one more service the user uses, building a cross-service profile that the provider can monetize directly (Google, Facebook) or aggregate into the broader ad-targeting graph. Apple’s Sign In with Apple includes the optional email-relay feature that addresses the cross-service email-as-identifier matching, partially mitigating the identity-provider visibility concern.
What you can change today
Three operational guidelines. First, use direct password+2FA (or passkey) rather than SSO for high-value accounts: financial, primary email, password manager, code repositories, critical work tools. The SSO cascade risk is unacceptable for accounts whose individual compromise is consequential. Second, where SSO is used, prefer Sign In with Apple with email relay enabled (Apple, Settings, Apple ID, Sign In with Apple, manage relay options) over Sign In with Google or Sign In with Facebook; the email-relay defeats the cross-service email-as-identifier matching. Third, for the SSO accounts you do maintain, harden the underlying identity provider: hardware-key 2FA on Apple ID, Google account, Microsoft account; the master account requires master-key protection. The cascade risk is structural; the only meaningful defense is to strengthen the identity provider and limit which services depend on it.
Related articles
- Three breaches in ten days. In two of them, the attacker never wrote a line of code.
- You don’t have to be a suspect. You just have to have been there.
- Digital security for journalists in 2026: the complete operational guide.
- A journalist was arrested in Kuwait for reposting a CNN video. The law used to charge him didn’t exist yet when he posted it.