Identity attack detection fails when legitimate activity hides malicious intent

At a glance

What this is: This is an analysis of why identity attack detection fails when malicious activity looks operationally normal and each control plane sees only part of the story.

Why it matters: It matters because IAM, NHI, and security operations teams need context-aware investigation to judge whether valid access still represents legitimate behaviour.

Context

Identity attack detection breaks down when valid authentication, authorised actions, and familiar devices create the appearance of normal work. The core issue is not whether a single event was allowed, but whether the behaviour still fits the identity’s role, recent changes, and business purpose.

In identity security, the necessary evidence is usually already present across the identity provider, SaaS apps, endpoint tooling, tickets, HR systems, and ownership records. The challenge is that each system can explain only its own fragment, so security teams have to reconstruct intent from distributed signals rather than from one clear alert.

Key questions

Q: How should security teams detect attacks that look like normal user activity?

A: Teams should combine identity context, session analysis, and behavioural baselines instead of relying on static signatures alone. The goal is to identify when access, timing, and action sequences diverge from what is normal for that user, workload, or service identity. This works best when SOC and IAM teams share telemetry and investigate anomalies together.

Q: Why do normal-looking actions still create identity risk?

A: Because attackers can reuse legitimate sessions, approved permissions, and routine workflows to avoid creating obvious anomalies. The action may be allowed, but the intent can still be malicious. Risk rises when teams rely on single-event alerts instead of asking whether the behaviour makes sense across the surrounding context.

Q: What are the signs that identity detection is missing malicious intent?

A: Look for actions that are individually permitted but not explainable by recent change, ticketing, device, or ownership context. Examples include privileged changes outside an approved project, data exports that do not match the role, or OAuth access that expands beyond the original purpose. Those are investigation signals, not proof on their own.

Q: How do teams know whether identity-based detection is working?

A: Look for detections that correlate identity, behaviour, and privilege changes across environments, not just isolated alerts. A working programme should identify unusual pivots between identity types, flag access that no longer matches historical behaviour, and reduce time spent stitching together events after the fact.

Technical breakdown

Why valid authentication is not proof of legitimate intent

Authentication confirms that an identity or session met access controls. It does not prove the activity was consistent with the person, service account, or integration that owns it. That distinction matters because compromised employee accounts, stolen sessions, and abused OAuth applications can all reuse valid entitlements while behaving outside the normal intent of the identity. In practice, a successful login can be the least interesting part of the incident. The harder question is whether the action fits the identity’s purpose, timing, and surrounding workflow. Security teams therefore need to treat access success as an input to investigation, not as evidence that the behaviour is benign.

Practical implication: build investigation logic that evaluates intent and context after authentication succeeds, not just whether the login passed.

How context stitching changes identity detection

Identity investigation becomes useful when separate signals are correlated into one narrative. The identity provider shows authentication, the endpoint tool shows the device, the SaaS application shows the action, the ticketing system shows expected change, and HR or ownership records show whether the actor should still have that responsibility. None of those systems alone can determine whether an export, token creation, privileged change, or new OAuth permission is legitimate. Context stitching closes that gap by combining access, activity, ownership, approval state, and recent change history. That is why the boundary between detection and investigation keeps disappearing in mature identity programmes.

Practical implication: correlate identity, device, ticket, and ownership signals before triaging high-risk activity as malicious or benign.

Why unusual activity is a weak signal on its own

“Unusual” is not a reliable control test because normal work is messy. Engineers may enter production during incidents, finance teams may pull large datasets at quarter-end, and administrators may touch systems they rarely use because a project now requires it. Attackers exploit that ambiguity by blending into ordinary patterns, especially when they use valid credentials or a stolen session. A better test is whether the action makes sense for the identity’s role, current project, recent access changes, and business purpose. That framing reduces false confidence from rule-based anomaly alerts and forces the analyst to ask whether the behaviour is expected, not merely different.

Practical implication: replace simple anomaly triage with role, project, and change-aware investigation criteria.

Threat narrative

Attacker objective: The attacker wants to use legitimate-looking identity activity to avoid detection while reaching sensitive data, privileged settings, or persistent access.

1. Entry occurs through a legitimate login, a valid session, or a permitted OAuth integration rather than an obviously suspicious access event.
2. Credentialed access is then used to perform actions that are individually authorised, such as exports, token creation, application connection, or privileged changes.
3. Impact comes from the attacker blending into normal operational behaviour long enough to evade single-system detection and reach data or administrative objectives.

Breaches seen in the wild

• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
• 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.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Context is now the control plane for identity detection: Valid authentication and authorised actions are not enough to judge legitimacy when intent is the real question. Identity programmes that stop at event-level rules miss the operational meaning of the activity, which is where malicious use hides. The practical conclusion is that detection quality now depends on reconstruction of purpose, not just confirmation of access.

Identity activity that looks normal is often the hardest malicious activity to prove: Attackers do not need to create noisy anomalies when they can reuse an employee session, an OAuth grant, or routine admin behaviour. That collapses the value of isolated alerts and elevates cross-system correlation across access, device, ownership, and business context. Practitioners should treat context stitching as part of the control model, not an optional investigation aid.

Unusual behaviour is a poor primary test for modern identity abuse: Normal operations create plenty of legitimate exceptions, and adversaries deliberately hide inside them. The field needs a stronger standard: does the action make sense for this identity at this time, on this device, under this approval state? That shifts identity security from rule matching to reasoned judgement, which is where the meaningful risk signal lives.

Compromised sessions and long-lived permissions make behavioural ambiguity durable: A stolen session may never trigger a new login, and an OAuth app can keep operating against permissions granted months ago. That means the relevant security question is often not whether access is valid, but whether the current use still aligns with the identity’s authorised business purpose. Teams that ignore that distinction will keep missing real compromise inside apparently normal operations.

Identity investigation is becoming the operating model, not a follow-on task: The line between detection and investigation is fading because the alert alone rarely answers the decision question. Security teams need workflows that surface explanation, not just events, so analysts can judge whether the behaviour fits the identity’s role and recent change history. That is the governance shift the article points to: identity security is moving toward context-based adjudication.

What this signals

Context-aware identity monitoring is becoming a governance requirement, not a luxury: The article’s core point is that valid authentication is no longer a sufficient security test when attackers can hide inside approved activity. Programmes need to move beyond isolated alerts and treat context stitching as part of the control surface.

Identity security teams should expect investigation to absorb more of the detection function: When single-system signals cannot distinguish routine work from malicious intent, the operating model shifts toward correlation, adjudication, and explanation. That has implications for IAM, SOC, and NHI governance teams because the decision point moves closer to the business context.

For practitioners

• Build context-aware detection rules Test identity activity against role, device, recent change, ownership, and approval context before deciding whether it is suspicious.
• Correlate identity and business evidence Join identity provider, SaaS, endpoint, HR, and ticketing signals so analysts can reconstruct intent from the full activity chain.
• Prioritise session and OAuth monitoring Watch for valid sessions and application grants that continue to operate after access changes, since they can hide malicious use without a fresh login.
• Rewrite alerts as investigation questions Express detections in plain language that asks whether the behaviour still makes sense for that identity in that moment, not just whether it was unusual.

Key takeaways

• Valid authentication and authorised access can still conceal malicious intent when context is missing.
• Identity detection becomes weaker when teams rely on unusualness instead of asking whether the action makes sense for the role, device, and business purpose.
• The practical answer is cross-system investigation that correlates identity, endpoint, SaaS, approval, and ownership signals before making a judgment.

Key terms

• Context-aware identity detection: Detection that combines identity, device, approval, ownership, and business-purpose signals before judging whether activity is suspicious. It is less about spotting one bad event and more about testing whether the behaviour still fits the identity’s legitimate role and current situation.
• Legitimate-looking abuse: Malicious activity that uses valid credentials, approved permissions, or normal workflows to blend into routine operations. The event may be allowed in isolation, but the surrounding context reveals that the intent or purpose is inconsistent with legitimate use.
• Investigation stitching: The practice of joining fragmented telemetry from identity providers, SaaS applications, endpoints, tickets, and ownership records into one usable narrative. It matters because no single control plane usually has enough information to judge intent on its own.

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.