Identity threat detection is the missing gap in mature stacks

At a glance

What this is: This is a Blackpoint Cyber analysis of why mature security stacks still miss identity abuse and why ITDR exists as a separate detection-and-response discipline.

Why it matters: IAM, MFA, SIEM, EDR, and SOAR do not automatically detect valid credentials being misused, so identity coverage has to be measured as its own control layer.

By the numbers:

• Microsoft reported a 32% surge in identity-based attacks in the first half of 2025.
• More than 97% of identity attacks are password attacks, according to Microsoft’s Digital Defense Report 2025 cited by Blackpoint Cyber.

Context

Identity threat detection and response, or ITDR, is the discipline for spotting when a legitimate login is not legitimate in context. The core problem is not exploitation of a vulnerability but misuse of a valid credential, which lets identity attacks slip past controls that are tuned for malware or endpoint compromise.

For IAM and PAM teams, the question is whether the programme only governs who may sign in or also detects what happens after authentication succeeds. In hybrid and cloud-first environments, that distinction decides whether identity is protected as a live attack surface or treated as a finished control event.

Key questions

Q: What breaks when a security stack relies on MFA but does not monitor identity behaviour after login?

A: The control fails at the point where authentication succeeds but trust should be re-evaluated. Attackers with stolen credentials or hijacked sessions can act as legitimate users, so the absence of post-login monitoring leaves account takeover, inbox manipulation, and cloud abuse effectively invisible.

Q: Why do valid credentials and session tokens remain such an effective attack path?

A: Because they let attackers operate inside trusted access paths instead of breaking in noisily. Once a token is accepted, downstream applications often treat it as legitimate until revocation occurs. That creates a wide detection gap when session lifetimes exceed the time it takes an attacker to move, persist, and exfiltrate.

Q: How do you know if identity threat detection is actually working?

A: Look for shorter mean time to detect and mean time to respond, plus fewer incidents where suspicious sessions persist for hours. Successful programmes also show accurate correlation between behavioural anomalies and real misuse, not just alert volume. If detection cannot trigger containment before damage spreads, the programme is still mostly observational.

Q: What should teams do immediately when they confirm a compromised cloud identity?

A: They should terminate active sessions, suspend the account, force a credential reset, and review linked grants or inbox rules before the attacker completes follow-on actions. The goal is containment before the compromise expands into payments, data access, or business email compromise.

Technical breakdown

Why valid credentials bypass traditional security signals

Identity attacks do not need an exploit chain in the classic sense. If an attacker signs in with stolen credentials, the authentication system sees a successful login, the endpoint may remain untouched, and the activity can look normal to tools focused on malware or device compromise. Session hijacking is even harder to see because the attacker reuses an already-issued token, which preserves the appearance of a trusted session. ITDR exists because the security event is not failed access, it is misuse after access has already been granted.

Practical implication: build detections around identity behaviour after authentication, not just login failure or malware telemetry.

How session tokens and OAuth grants expand identity risk

Session tokens keep users logged in, but they also extend the life of a compromise if the token is stolen through phishing, malware, or adversary-in-the-middle techniques. OAuth grants create a second trust path because third-party applications can keep accessing account data even when the user is not actively present. Inbox rules add persistence by hiding mail, forwarding messages, or deleting evidence. These are identity-native indicators, not endpoint indicators, so they require identity-layer telemetry and response logic.

Practical implication: monitor token use, OAuth authorisations, and mailbox rule changes as first-class identity signals.

Why SIEM, EDR and SOAR still leave an identity gap

A SIEM can ingest identity logs without actually detecting identity misuse. EDR watches endpoints, not cloud logins from unmanaged devices, and SOAR only automates playbooks that have already been defined. That leaves a structural gap between access being granted and misuse being acted on. ITDR is meant to own that middle state, correlating identity, cloud, and endpoint signals so a compromise is recognised before an attacker has time to redirect payments or deepen access.

Practical implication: validate whether your stack correlates identity events into a response path, or only stores them for later investigation.

Threat narrative

Attacker objective: The attacker aims to operate as a trusted user long enough to move money, manipulate communications, or persist inside cloud identity systems.

1. Entry occurs when an attacker authenticates with stolen credentials obtained from phishing, infostealer malware, or credential theft.
2. Escalation follows when the attacker reuses a live session token, creates suspicious inbox rules, or leverages OAuth grants to maintain access.
3. Impact emerges when the attacker acts as the user to redirect payments, hide messages, or sustain business email compromise without triggering endpoint alerts.

Breaches seen in the wild

• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
• Scania insurance portal breach 2025: An attacker used an external user login, likely stolen by infostealer malware, to take insurance claim documents from a Scania portal.

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

Identity misuse is now a post-authentication problem, not a perimeter problem. Once a valid credential gets through IAM or MFA, the security question changes from access approval to misuse detection. That shift matters because most control stacks still treat authentication success as the end of the identity decision. Practitioners need to govern the session, not just the login.

ITDR fills the ownership gap between IAM and the SOC. IAM decides who may enter, while the SOC investigates what went wrong after the fact. Identity abuse falls into neither ownership model cleanly, which is why it is so often under-instrumented. The discipline only makes sense when identity telemetry is treated as an operational security stream, not a passive audit trail.

Identity blast radius is the right named concept for this category. A single stolen credential can expose mail, SaaS data, session state, and downstream workflows without any malware being present. The blast radius is defined by what the account can reach after authentication, not by the original compromise vector. That means governance must measure reachable privilege, not just enrolled accounts.

MFA remains necessary, but it does not answer the detection question. The article is correct to separate prevention from response because a successful MFA challenge tells you that authentication happened, not that the authenticated actor is trustworthy. That distinction is now central to identity governance across human and non-human access, especially where sessions, tokens, and delegated grants outlive the initial login. Teams should treat post-authentication monitoring as a separate control family.

Correlation is the difference between isolated events and an intrusion story. An inbox rule, a foreign sign-in, and an unusual OAuth grant may each look tolerable in isolation. Together they form a compromise pattern that traditional point tools often miss. The practitioner implication is straightforward: identity security must be correlated across cloud, endpoint, and response workflows, or it remains fragmented by design.

What this signals

Identity threat detection has to be treated as an operating layer, not a point feature. The article’s real message is that IAM and MFA still matter, but they do not solve post-authentication abuse. Teams that do not instrument sign-in anomalies, token activity, and mailbox or grant changes are still operating with an identity blind spot.

Identity blast radius is the control issue most programmes still miss. A valid credential can reach email, SaaS data, payment workflows, and delegated applications long after authentication has succeeded. Practitioners should map where that reach exists and then decide which identity signals can interrupt it before the session becomes an incident.

For practitioners

• Instrument post-authentication identity telemetry Alert on unusual sign-in geography, unexpected hours, suspicious infrastructure, and active sessions that move from their origin point.
• Track mailbox and grant abuse signals Monitor new inbox rules, auto-forwarding changes, deletions, and OAuth grants as indicators of account takeover rather than nuisance noise.
• Separate detection from prevention in your control design Validate that your programme can detect a misused valid credential after MFA succeeds, not just block unauthorised logins.
• Test response for compromised cloud identities Confirm that a confirmed takeover can trigger session termination, account suspension, and forced credential reset without waiting for manual triage.
• Correlate identity, endpoint, and cloud activity Use cross-layer analysis so a credential misuse on one service is seen as part of one attack chain rather than isolated benign events.

Key takeaways

• A mature stack can still leave identity abuse visible only after the attacker is already inside the account.
• The article shows that credential theft, session hijacking, and business email compromise all exploit the gap between authentication and detection.
• Teams need identity-layer telemetry and response that can act on suspicious sessions, grants, and inbox rules before the compromise expands.

Key terms

• Identity Threat Detection and Response: Identity threat detection and response is the practice of finding misuse of credentials, unusual access patterns, and compromised identities across human and machine actors. For NHIs, it relies on telemetry from code, vaults, cloud services, and pipelines to detect abuse early enough to contain it.
• Session Hijacking: Session hijacking is the takeover of an authenticated session after the original login has completed. The attacker does not need to know the password if they can use the active session token, which is why session monitoring and revocation are essential controls in SaaS identity governance.
• OAuth Grant Abuse: OAuth grant abuse happens when a previously approved third-party application or integration is used in ways that exceed the original access intent. The grant remains technically valid, which makes misuse harder to spot unless teams monitor consent patterns, scope creep, and downstream access paths.
• Business email compromise: A form of social engineering where an attacker impersonates a trusted person or domain to manipulate payment, change banking details, or extract sensitive information. It often succeeds without malware because the attacker targets process trust and human judgement instead of technical controls.

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 building or maturing an IAM programme, it is worth exploring.