TL;DR: Credential reuse, weak MFA coverage, and shadow SaaS still let stolen logins become account takeovers, with 1 in 4 observed logins password-based, 2 in 5 lacking MFA, and 1 in 5 using weak, breached, or reused passwords, according to Push Security. Identity control only works when teams can separate active authentication risk from historical breach exposure.
At a glance
What this is: This is a webinar analysis of why credential compromise keeps bypassing IAM controls, showing that password reuse, missing MFA, and unmanaged SaaS logins turn breach data into active account takeover risk.
Why it matters: IAM teams need to treat breached credentials as an active identity-control problem, because visibility into login behaviour, MFA coverage, and shadow SaaS determines whether exposed credentials become live compromise.
Context
Credential compromise is not just a user-awareness problem. It becomes an IAM governance failure when organisations cannot tell which exposed credentials are still active, which logins bypass SSO, and which SaaS accounts exist outside the directory.
The article argues that breach data is only useful when it is correlated with observed authentication behaviour. Without that linkage, security teams end up chasing historical exposure, departed employees, and unmanaged accounts instead of the logins that attackers are actually using.
Key questions
Q: What breaks when exposed credentials are still active in shadow SaaS apps?
A: The breach signal becomes a live access path instead of a historical warning. If a reused password still works in an unmanaged SaaS app, attackers can bypass central IAM controls, and the organisation may not even know the account exists until after takeover.
Q: Why do reused credentials and MFA gaps still allow account takeover at scale?
A: Reused credentials create a direct path from one breach to many accounts, because attackers can test stolen usernames and passwords across popular services until they find matches. MFA reduces risk, but it is not a complete barrier if attackers can bypass prompts, steal session tokens, or exploit weak recovery flows. The underlying issue is credential reuse plus automated testing.
Q: How should teams use breach intelligence without drowning in false positives?
A: They should correlate exposed credentials with current login activity, current ownership, and sanctioned application use. That filters out departed employees, fabricated addresses, and stale accounts, so the team can focus on identities that are still proving active risk.
Q: When should organisations prioritise SSO cleanup over more user awareness training?
A: When local passwords still exist for production apps or when employees can authenticate outside the IdP. Training still matters, but if ghost logins remain, the control gap is technical and governance-driven, not primarily behavioural.
Technical breakdown
Why stolen credentials keep working across SaaS estates
Credential stuffing works because identity sprawl gives attackers many targets from a single breach. When employees hold dozens of SaaS accounts and only some are behind SSO, a reused password can authenticate long after the original compromise. The real issue is not just password exposure, but the mismatch between directory visibility and the wider SaaS footprint where local logins still exist. That is why breach intelligence alone is noisy unless it is tied to active login behaviour and current account status.
Practical implication: teams need visibility into the full login surface, not only the IdP directory.
Why MFA does not close the post-authentication gap
MFA raises the cost of basic compromise, but it does not stop session token replay, AiTM phishing, consent abuse, or other post-authentication attacks. Once an attacker has a valid session or a phishable second factor, authentication strength is no longer the only control that matters. This is why phishing-resistant controls, browser-level detection, and session monitoring are increasingly necessary where users can be tricked into approving or handing over a live session.
Practical implication: MFA policy should be paired with controls that detect session hijack and token replay.
How ghost logins undermine identity governance
Ghost logins are accounts that remain technically usable even when the organisation believes they have moved to central identity controls. They persist when legacy password-based access stays enabled, when employees leave but their SaaS accounts are not removed, or when sanctioned and unsanctioned apps sit outside governance. In practice, ghost logins convert old exposure into current access, which makes breach notification, deprovisioning, and access review far less effective than teams assume.
Practical implication: IAM programmes must retire local login paths and reconcile SaaS accounts against active ownership.
Threat narrative
Attacker objective: The attacker wants to turn one exposed login into durable account access that can be reused for theft, lateral abuse, or further credential harvesting.
- Entry begins when attackers obtain breached credentials from prior data exposures or phishing-led credential harvesting.
- Escalation happens when those credentials are reused against SaaS applications that still accept local logins or weak authentication.
- Impact follows when the attacker takes over the account, accesses sensitive data, or uses the compromised identity to stage further attacks.
Breaches seen in the wild
- Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Credential compromise is now an identity lifecycle problem, not a point-in-time authentication event. Breach exposure only becomes operational risk when a credential is still active somewhere in the SaaS estate. That shifts the governance question from whether a password was leaked to whether the account was ever fully removed, rotated, or invalidated across every login path.
Ghost logins are a standing-control failure, not just a legacy-technology nuisance. Local password-based access that survives after SSO rollout creates a parallel authentication plane that IAM teams often underestimate. The result is a second set of live credentials outside policy visibility, which makes account takeover more likely and access reviews less credible.
Correlating breach intelligence with observed login behaviour is the only way to make exposure data actionable. Raw breach feeds produce noise unless they are tied to real authentication events, current ownership, and active access paths. That makes identity telemetry the control plane, not the breach list itself.
Credential reuse creates identity blast radius across every unmanaged SaaS app. One leaked password can become many compromised accounts when employees reuse credentials across sanctioned and shadow applications. The practitioner lesson is that the blast radius is governed by login reuse, not by the original breach source.
Human awareness remains necessary but cannot be the primary control boundary. Even skilled users and security practitioners are vulnerable to modern phishing, token theft, and legitimate-domain abuse. Identity programmes need technical controls that assume human error and attacker industrialisation rather than relying on users to recognise every lure.
What this signals
Credential exposure only becomes governance debt when it remains usable. The operational question for IAM teams is not whether a password appeared in a breach dataset, but whether the identity can still authenticate somewhere. That makes login-path inventory, deprovisioning hygiene, and SSO enforcement the real control boundary.
Breach intelligence works best as a live signal, not a retrospective report. When exposed credentials are matched to active authentication events, teams can separate noise from immediate risk and target the identities that still matter. That is the difference between awareness and control.
For practitioners
- Map and remove ghost logins Inventory all applications that still permit local password authentication and retire those paths where SSO is supposed to be authoritative. Reconcile each login source against current ownership so departed users, old test accounts, and unsanctioned apps do not remain reachable.
- Correlate breach exposure with live login events Treat breach notification feeds as a prioritisation input, then verify whether the exposed identity is actively authenticating today. Only escalate credentials that appear in current login telemetry, because historical exposure alone does not prove present risk.
- Enforce phishing-resistant MFA on active accounts Push beyond generic MFA coverage and prioritise phishing-resistant methods on accounts that can still sign in with passwords or reusable factors. Where session theft remains possible, add controls that detect token replay and suspicious browser behaviour.
- Reduce shadow SaaS exposure through login telemetry Use observed authentication events to identify personal SaaS usage tied to corporate email addresses and to locate unmanaged applications that never entered the IdP catalogue. Bring those accounts into governance or remove their credential paths.
Key takeaways
- Credential compromise keeps bypassing IAM when organisations leave alternate login paths, reused passwords, and unmanaged SaaS accounts in circulation.
- The article’s examples show that exposure data is only useful when it is matched to current login behaviour and active account ownership.
- The practical control lesson is to remove ghost logins, tighten MFA on live accounts, and govern shadow SaaS before attackers do.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on breached credentials and exposed login secrets. |
| NHI-04 — Insecure Authentication | Password logins, weak MFA, and replayable sessions are the core failure modes here. | |
| NHI-09 — NHI Reuse | Credential reuse across multiple SaaS apps drives the account-takeover risk described. | |
| Recommendation — Scan for exposed credentials and remove any active authentication paths that still accept them. Harden authentication paths so password reuse and token replay cannot bypass central controls. Eliminate credential reuse patterns that let one breach become multiple account compromises. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about proving which accounts still have effective access and should not. |
| Recommendation — Review effective access continuously and revoke permissions that no longer match current ownership. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat pattern is stolen credentials reused to gain access and move across SaaS services. |
| Recommendation — Map exposed credentials to TA0006 and TA0008 to prioritise active takeover paths. | ||
Key terms
- Ghost Login: A ghost login is a direct authentication path that remains active after an organisation believes it has moved to central single sign-on. It creates a parallel trust model that can still accept passwords, so the identity team sees one policy posture while attackers exploit another.
- Credential Reuse: Credential reuse happens when the same password, token, or secret can unlock multiple systems or sessions. It increases breach impact because one stolen credential can become a wide-ranging access path. The control problem is not only theft, but the amount of trust packed into each reusable secret.
- Breach Exposure List: A breach exposure list is a published or circulating list of organisations, domains, or tenants believed to be affected by an incident. Security teams use it as a triage input, then validate whether the listed assets exist in their environment and whether they have active access paths that need containment.
- Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org