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.
Why This Matters for Security Teams
SSO and local logins are not interchangeable controls when stolen credentials are in play. SSO concentrates authentication and policy at the identity provider, which improves visibility, conditional access, and rapid revocation. Local logins remain embedded in the app, so if they are left active they can outlive the central control plane and become a quiet bypass path. That gap is exactly why credential theft turns into account takeover even after “SSO rollout” is declared complete.
For defenders, the real risk is not just phishing or password reuse. It is inconsistent enforcement across two login paths that look similar to users but behave very differently to attackers. A central IdP can force stronger checks, step-up authentication, and faster lockout, while local credentials may still accept old passwords, stale MFA states, or inherited access that no longer matches policy. The result is fragmented assurance. Current guidance suggests treating local login as a separate risk surface, not a legacy convenience.
NHIMG’s analysis of breaches shows how often hidden authentication paths remain exploitable long after teams believe a migration is complete. Related examples appear in the 52 NHI Breaches Analysis and the Cisco Active Directory credentials breach. In practice, many security teams discover ghost logins only after a stolen password has already been used to re-enter an application through the back door.
How It Works in Practice
Defending against stolen credentials starts by separating identity authority from application-local authentication. In an SSO model, the app trusts the identity provider for sign-in and session issuance, then applies app-level authorization after the user is authenticated. That gives security teams one place to enforce MFA, device checks, risk scoring, and session revocation. Under a local-login model, the application stores or validates its own credentials, which means the app may continue to accept access even when the central directory has been hardened or the account has been disabled elsewhere.
For business apps, the practical migration pattern is straightforward:
- Inventory every login path, including break-glass, service, admin, and tenant-specific accounts.
- Disable local passwords where SSO is the intended control, not just hide the button in the UI.
- Map local accounts to owners and remove orphaned or duplicate identities.
- Test whether password resets, MFA changes, and lockouts propagate across all paths.
- Review logs for sign-ins that bypass the IdP entirely.
Framework guidance reinforces this model. NIST SP 800-53 Rev 5 Security and Privacy Controls supports centralized access control and account lifecycle management, while NIST SP 800-63 Digital Identity Guidelines provides a baseline for authentication assurance. NHIMG’s Guide to the Secret Sprawl Challenge is also relevant because stale local passwords behave like untracked secrets: they persist, they spread, and they are hard to retire cleanly.
Operationally, teams should treat every local login as a parallel trust boundary and verify that it cannot be used once SSO is mandated. These controls tend to break down in older line-of-business applications that support local fallback accounts because the vendor does not expose complete disablement or audit trails.
Common Variations and Edge Cases
Tighter centralisation often increases operational overhead, so organisations have to balance security consistency against recovery and support needs. Not every local login should disappear immediately. Break-glass admin accounts, offline access, regulated workloads, and vendor-managed support paths may require exceptions. The key is to make those exceptions explicit, time-bound, and heavily monitored rather than letting them become permanent shadow access.
There is no universal standard for every migration pattern yet. Some platforms support true SSO-only enforcement, while others use SSO for most users but retain local authentication for administrators or API-driven workflows. In those cases, best practice is evolving toward strong compensating controls: separate admin namespaces, phishing-resistant MFA, scoped privileges, and frequent review of dormant local accounts. For deeper context on real-world credential abuse patterns, see the The 52 NHI breaches Report and the Anthropic report on AI-orchestrated cyber espionage, which shows how quickly automated operators exploit weak identity edges.
One important edge case is federation failure. If the IdP is unavailable and the application silently falls back to local credentials, the fallback becomes a security decision, not just a resilience feature. That is acceptable only when the fallback is designed, documented, and tested as part of the threat model. Otherwise, local login becomes the weakest surviving path after the strongest one is compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Centralized authentication and account lifecycle management reduce stolen-credential risk. |
| NIST SP 800-63 | AAL2 | SSO strength depends on authentication assurance and MFA quality. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Ghost logins behave like unmanaged identities outside the intended control plane. |
| NIST AI RMF | Identity governance for autonomous systems depends on resilient, accountable access paths. |
Apply AI RMF governance to document fallback access, revocation, and monitoring for every login path.
Related resources from NHI Mgmt Group
- What is the difference between proxy-based access for on-prem apps and direct native integration?
- Why do stolen credentials create such high risk in cloud identity attacks against SaaS and IdPs?
- What is the difference between defending a SaaS account with MFA and defending it with phishing-resistant identity controls?
- What is the difference between an IAM project and a business transformation initiative?
