What happens when users create separate accounts instead of using SSO?

When users bypass SSO and create separate accounts, the organization accumulates unmanaged identities across work resources. That expands the attack surface, increases the chance of credential reuse, and makes incident response harder because compromise in one account can spill into others. It also forces users to store more passwords, which often leads to insecure workarounds and weaker overall security.

Why separate accounts erode the value of SSO

Single sign-on is meant to create one governed access path per user, with a central place to enforce authentication, session policy, and account lifecycle. When people create separate accounts instead, that control plane fragments. You lose the ability to consistently apply sign-in policy, and the user experience starts to reward bypasses rather than approved access paths. That is why Identity Provider and SSO Security Guide and OpenID Connect Core 1.0 both matter here: they frame SSO as a trust and session management problem, not just a login convenience.

In practice, separate accounts usually appear when users need a quick workaround, a shadow account for a vendor portal, or a login that was never federated in the first place. The result is duplicated identity records, inconsistent recovery paths, and more places where password policy and MFA can drift. For workforce identity programs, the operational question is whether the organisation can still see, govern, and revoke access across all those accounts, which is exactly the kind of lifecycle problem covered by the Workforce Identity Security Guide.

SSO also reduces the number of credentials users must remember and store. Once that benefit is removed, users often compensate by reusing passwords, writing them down, or creating predictable patterns across services. That does not just weaken a single login, it connects unrelated applications through the same weak secret. Guidance from Passwordless and Passkeys Guide reinforces the broader lesson: reducing password load is a security control, not only a usability improvement.

Where the identity risk accumulates

Separate accounts turn one user into several independently exposed identities. That expands attack surface because each account can be phished, guessed, reused, or recovered differently. It also weakens incident containment, since a compromise in one account may not be visible in the others and may not be centrally revocable. The exposure is often worse when a user has one federated account and one or more unmanaged local accounts in parallel.

Failure mechanism: The organisation loses a single authoritative record for authentication, access, and lifecycle changes, so account sprawl builds outside central governance. Attackers and careless users both benefit from the gaps: credentials get reused, stale accounts remain active, and compromised sessions can persist without the normal SSO controls that would have constrained them.

Impact: Incident response slows, access reviews become incomplete, and compromise can spread laterally across work resources through shared passwords, overlapping recovery paths, or linked SaaS accounts. In higher-friction environments, this also creates support burden because IT must investigate and reset multiple identities instead of one governed login path.

Why separate accounts make governance harder, not easier

From an operations perspective, the main cost is not the extra password. It is the loss of reliable control over provisioning, deprovisioning, and ownership. If a person changes role or leaves, every unmanaged account becomes a potential residual access path. That is why identity governance and recovery processes have to be designed around the whole user population, not only the officially federated majority. The practical lesson in IAM and Identity Provider Buyer’s Guide is that an identity platform should centralise access, lifecycle, and recovery rather than leave exceptions scattered across business applications.

Separate accounts also complicate assurance. Security teams can no longer assume that one login event, one MFA policy, or one session control covers all meaningful access. That matters during an investigation because account provenance, recent activity, and recovery history must be checked per account, not per person. Central federation and token handling guidance in Identity Provider and SSO Security Guide is useful precisely because it shows how much easier it is to detect and contain anomalies when the access model stays unified.

Risk and Threat Considerations

Separate accounts create a classic control gap: the attacker only needs one weak or forgotten login to gain a foothold, then can test whether the same person has other accounts elsewhere. Password reuse, weak recovery questions, and stale entitlements all become more dangerous when SSO is bypassed. The danger is not abstract, it is the accumulation of small exceptions that remove central visibility.

Failure mechanism: Multiple accounts break the clean relationship between identity, authentication, and revocation. That makes credential stuffing, phishing, and recovery abuse more effective because each unmanaged account is another chance to succeed without triggering the controls attached to the primary SSO path.

Impact: A single compromise can escalate into broader account takeover, cross-application access, or slower containment during an incident. The organisation may also underestimate how much shadow access remains after offboarding if local accounts were created outside the main identity process.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Separate accounts weaken centralized user authentication and lifecycle control.
	IA-5 — Authenticator Management	Separate accounts increase password sprawl and credential reuse risk.
	AC-2 — Account Management	Bypassed SSO creates unmanaged accounts that must still be provisioned and revoked.
Recommendation — Centralize user authentication under IA-2 to reduce unmanaged login paths. Enforce IA-5 controls to manage authenticators and limit password reuse. Use AC-2 to inventory, approve, and disable all accounts consistently.
NIST SP 800-63	Digital Identity Guidelines	Federated sign-in and authenticator assurance are central to reducing password sprawl and account duplication.
Recommendation — Align federated sign-in and recovery practices to the guideline's assurance model.

Practitioner Guidance

What to prioritise: Inventory the applications and portals where users are allowed to create local accounts and classify them by business criticality, recovery method, and offboarding risk. The highest-risk exceptions are the ones that support admin functions, sensitive data, or password-based recovery outside the IdP.

What to verify: Confirm that every user-facing app either federates to the central identity provider or has a documented exception with ownership, MFA requirements, and deprovisioning coverage. If you cannot prove where an account came from or how it is revoked, treat it as unmanaged access.

Practitioner takeaway: SSO is valuable because it collapses identity, authentication, and lifecycle control into one governed path; every separate account is a deliberate loss of that control and should be treated as an exception, not a convenience.