Why do IdP-only metrics understate account takeover risk?

Why IdP-only metrics miss the actual attack surface

IdP telemetry is useful, but it measures only the part of the journey that passes through the identity provider. The risk gap appears when valid access is obtained through other session paths or trust edges, so a clean IdP dashboard can coexist with active account takeover. That is why coverage has to be session-centric, not IdP-centric.

Browser-mediated access is the blind spot. An attacker can arrive through direct SaaS authentication, consent prompts, device code flows, or a stolen browser session without producing the same signals that IdP-only reporting expects. For a broader view of the failure mode, the issue is similar to what shows up in Identity Provider and SSO Security Guide and Customer IAM (CIAM) Guide, where sessions, federation trust, recovery, and consent are all part of the control surface, not just the login page.

The practical consequence is that a metric can look healthy while the real exposure is growing elsewhere. If you only count IdP logins, failed MFA at the IdP, or federation events, you will miss attacks that exploit alternative entry points or reuse an already-issued session. That is why account takeover analysis has to include endpoint, browser, SaaS, and token behaviour, not just identity-provider events.

Where the missing signals usually come from

The gap usually comes from paths that create valid access after the IdP has already done its part. A user may approve a malicious OAuth app, complete a device code phishing flow, authenticate directly to a SaaS application, or keep using a browser session that the IdP never sees again. In each case, the attacker is not defeating the IdP metric, they are routing around it.

These paths matter because they often preserve legitimacy at the protocol level. A consent grant can look like user-approved access, a device code flow can look like ordinary enrollment, and a session cookie can look like the real user. That makes detection dependent on correlating app-level, token-level, and device-level evidence, not only identity events. Guidance on federation and token security in Identity Provider and SSO Security Guide is relevant here because the weak point is often the trust relationship after initial authentication.

IdP-only metrics also undercount abuse that starts outside the IdP boundary and ends inside a SaaS tenant. Consent phishing, extension-driven access, and refresh-token theft can all produce valid activity without an obvious spike in IdP failures. That is why a strong account takeover model needs signals from browser posture, consent events, OAuth app grants, and suspicious session reuse, not just the upstream directory.

What practitioners should measure instead

Measure the paths that attackers can actually use, not only the control point that policy prefers. If the SaaS layer supports direct login, track it. If consent grants are possible, track them. If device code or browser sessions can be abused, those events need to be visible and attributable. A useful control set is to compare IdP activity with application-session creation, token issuance, consent approvals, and anomalous access from unmanaged browsers or devices.

• Track direct SaaS authentication separately from IdP-mediated SSO.
• Monitor OAuth app consent, especially new grants and high-privilege scopes.
• Correlate browser session creation, refresh-token use, and device context.
• Review recovery flows, because takeover often succeeds when recovery is easier than login.

For teams that manage customer or partner access, the prevention and detection model in Customer IAM (CIAM) Guide is useful because it treats account takeover as a lifecycle problem, not a single authentication event. That is the right mental model for any environment where a valid session can be created or reused outside the IdP.

Risk and Threat Considerations

IdP-only metrics create a false sense of coverage because they assume the attacker must pass through the monitored login path. In practice, adversaries prefer the shortest route to a valid session, which may be a consent grant, a direct SaaS login, a token replay, or a browser-based session theft. The result is undercounted compromise and delayed response.

Failure mechanism: The monitoring model is anchored to identity-provider events, while the compromise happens in downstream session, browser, or application layers. That mismatch hides takeover activity until the attacker is already operating with valid access.

Impact: Teams miss early warning, underestimate exposed accounts, and can fail to revoke the right token or session. The practical effect is longer dwell time and a larger blast radius even when IdP metrics appear stable.

Practitioner Guidance

What to prioritise: Treat IdP metrics as one control-plane input, not the risk metric. The more direct measure of takeover exposure is whether you can explain how a valid session was created, not whether the IdP logged a failed sign-in.

What to verify: Confirm that your telemetry covers consent grants, direct SaaS auth, device code flows, browser sessions, and token use. If those sources are absent, the account-takeover picture is incomplete by design.

Common mistake: Teams often tune dashboards around login failures and MFA prompts, then assume they are measuring takeover risk. That approach misses the cases where the attacker never needs to break the IdP policy model.

Practitioner takeaway: The right question is not “Did the IdP block the login?” but “Could an attacker still obtain a valid session elsewhere?” If the answer is yes, IdP-only metrics are undercounting the real risk.

Related resources from NHI Mgmt Group

• How should teams use IdP risk scores in suspected account takeover cases?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?