SSO shifts authentication to a central identity provider, which gives security teams more consistent policy enforcement and visibility. Local logins live inside the application and can continue operating separately, even after SSO is introduced. If those accounts are not disabled, they become ghost logins that bypass the intended control plane and create a hidden path for account takeover.
How SSO changes the authentication boundary
SSO moves the user’s primary login control to a central identity provider, so one policy plane can enforce MFA, conditional access, session rules, and anomaly detection across multiple business apps. That is a security improvement only if the application no longer accepts parallel local passwords for the same users, or if those local paths are tightly governed and eventually removed.
With SSO, the app should trust assertions from the identity provider rather than maintaining a separate password store for ordinary sign-in. That reduces password sprawl and makes it easier to apply consistent hardening, as described in the Identity Provider and SSO Security Guide and the OpenID Connect Core 1.0 specification.
SSO does not eliminate the need to authenticate users, it changes where that authentication happens and who can observe it. The security gain comes from centralising assurance, not from the label on the login screen. If the app still allows local logins, those accounts must be treated as an explicit exception class, not as harmless fallback access.
Why local logins become the weak path after SSO is added
Local logins remain dangerous because they create a second, independent control plane inside the application. If a stolen password, reset workflow, or dormant admin account can still authenticate locally, an attacker may bypass the stronger SSO policy entirely and land on the same business data through a route defenders expected to have retired.
That is why “we enabled SSO” is not the same as “we removed password risk.” In practice, many compromises succeed through the leftover path, especially where legacy users, service administrators, emergency access, or migration accounts are still enabled. The difference is not theoretical: the exposure shifts from a single federated entry point to a hidden set of application-local identities.
Stolen credential cases show the pattern clearly, including Stolen credential breaches, where missed rotation, session theft, and password-only access paths repeatedly turned valid credentials into full account compromise.
Local logins also make recovery harder. If an attacker uses a local account, identity-provider logs may show nothing useful, which slows detection and weakens containment. That creates a blind spot in incident response because the central policy engine is no longer the sole gatekeeper.
What defenders should verify before trusting SSO as the control
Defenders should verify that every business-critical app has a deliberate answer for local authentication, not just for federated authentication. Where local access remains, it should be limited to named break-glass use cases, tightly monitored, and removed once the migration is complete. The account inventory matters more than the login banner.
It is also important to check whether password reset, account recovery, or help-desk workflows can recreate local access without going back through the identity provider. That is a common way ghost logins survive. A good reference point for the broader design trade-offs is the Workforce Identity Security Guide, which covers SSO, federation, recovery, and session theft together.
When you are evaluating an app, ask three questions: can it still sign users in locally, can those accounts be disabled centrally, and can you prove those accounts are unused. If the answer to any of those is unclear, the application is not yet fully under SSO control.
Risk and Threat Considerations
Ghost logins are attractive to attackers because they often sit outside the stronger controls teams believe they have deployed. A valid password or a neglected recovery path can be enough to bypass the federated control plane, especially when the local account is exempt from modern MFA or is less visible in monitoring.
Failure mechanism: The organisation keeps a legacy authentication path alive after SSO rollout, so compromised credentials can still succeed through the application itself even when the IdP is hardened.
Impact: An attacker gains a hidden, policy-bypassing login route that can lead to account takeover, reduced visibility, and a longer dwell time before defenders realise the app was accessed outside the intended control plane.
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, NIST SP 800-63 and OWASP ASVS 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) | Covers central authentication for workforce app access via the IdP. |
| IA-5 — Authenticator Management | Applies to password, token, and recovery-material lifecycle for residual local access. | |
| AU-2 — Event Logging | Needed to detect use of residual local logins outside the SSO control plane. | |
| Recommendation — Require federated user authentication and retire parallel local sign-ins. Disable or tightly govern remaining local credentials and recovery paths. Log local-authentication events and alert on unexpected fallback use. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | Supports stronger identity proofing and authentication assurance in federated login flows. |
| Recommendation — Align the IdP sign-in flow to the required assurance level for the app. | ||
| OWASP ASVS | V6 — Authentication | Directly addresses authentication design, including federated and local login paths. |
| Recommendation — Verify that alternate authentication paths are disabled or constrained. | ||
Practitioner Guidance
What to prioritise: Inventory every local login in each app and classify it by purpose, owner, and expiry. If the account is not part of a documented exception, it should be treated as technical debt with security impact, not as an acceptable alternate path.
Decision rule: If a local account can authenticate to production data, require explicit justification, compensating monitoring, and a removal date. If it cannot be justified, disable it and confirm that no application workflow recreates it silently.
What to verify: Test both the happy path and the failure path. Confirm that federated login works, then confirm that local login is blocked for ordinary users and that break-glass access is logged, time-bound, and reviewed.
Practitioner takeaway: SSO reduces credential risk only when local authentication is deliberately retired or tightly exception-managed; otherwise, the organisation has not removed password risk, it has merely hidden part of it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org