Notifications
Clear all
Topic starter
09/06/2026 11:47 pm
TL;DR: Credential reuse, weak authentication, and shadow SaaS keep turning stolen logins into account takeovers, with Push citing that 1 in 4 observed logins were password-based, 2 in 5 lacked MFA, and 1 in 5 used weak, breached, or reused passwords. The governance problem is no longer awareness, but that identity controls still cannot distinguish active risk from historical exposure.
NHIMG editorial — based on content published by Push Security: Troy Hunt on why credential attacks keep working
By the numbers:
- Of the last million logins observed by Push, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA, and 1 in 5 used a weak, breached, or reused password.
- The average employee maintains around 15 SaaS accounts, and only a fraction of those sit behind SSO.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: What breaks when credential exposure data is not matched to live authentication behaviour?
A: Breach intelligence becomes too noisy to support action, because it cannot distinguish a live account from a departed employee, a false address, or a credential that is no longer in use.
Q: Why do shadow SaaS apps make identity risk harder to contain?
A: They create login paths that sit outside the IdP, so central policy, MFA assumptions, and access reviews only cover part of the real attack surface.
Q: How do security teams know whether MFA is actually reducing takeover risk?
A: MFA is working when password replay falls, phishing-resistant methods replace phishable factors, and post-authentication abuse metrics decline.
Practitioner guidance
- Correlate breach exposure with live login telemetry Join breach notification feeds to browser-observed authentication events so that stale, departed, or fabricated identities do not consume response effort.
- Eliminate local password paths in SaaS apps Find every application that still permits direct password login after SSO is enabled, then disable the fallback or force migration.
- Treat MFA as a baseline, not a finish line Enforce MFA everywhere, then add session controls for token replay, OAuth consent abuse, and browser-based hijacking.
What's in the full article
Push Security's full webinar covers the operational detail this post intentionally leaves for the source:
- Browser-level detection logic for matching breached credentials to active logins
- MFA enforcement and session-hijack detection workflows across SaaS applications
- Examples of how ghost logins persist after SSO adoption in real enterprise environments
- Practical response patterns for token replay, consent abuse, and credential stuffing
👉 Watch Push Security's webinar on credential compromise, ghost logins, and MFA gaps →
Credential compromise and ghost logins: what IAM teams are missing?
Explore further
10/06/2026 2:16 am
Credential exposure data has limited value until it is joined to live authentication behaviour. Breach notifications by themselves create a false sense of visibility because they do not show whether a credential is still active, whether the account still exists, or whether the login path is even governed by SSO. The field keeps treating compromise data as if it were a response trigger, when in practice it is only a lead. Practitioners should treat exposure data as an enrichment layer, not a control.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
A question worth separating out:
Q: Who is accountable when a stale password login path is still available after SSO adoption?
A: Accountability sits with the team that owns application access governance, because the control failure is not user behaviour alone. If a SaaS app still accepts a local password, the organisation has accepted a parallel identity model that defeats central policy. Access ownership must include every live authentication method, not just the directory record.
👉 Read our full editorial: Credential compromise and ghost logins keep bypassing IAM controls
