Identity attack detection fails when legitimate activity hides malicious intent

At a glance

What this is: The article argues that identity attack detection fails when malicious activity looks operationally normal and only becomes clear after correlating identity, device, access, and business context.

Why it matters: For IAM, IGA, PAM, and security teams, this matters because contextual investigation is now the difference between an allowed action and an abused identity, especially across NHI, human, and delegated access paths.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Offroad AI's analysis of identity activity in context

Context

Identity attack detection is increasingly a context problem, not a simple alerting problem. The same successful login, API call, admin change, or data export can be either legitimate work or an abuse of access depending on who is acting, what changed recently, and whether the surrounding systems support the story.

For NHI, human IAM, and delegated access programmes, the weakness is that each control plane sees only part of the behaviour. The identity provider sees authentication, the SaaS app sees authorisation, the endpoint sees the device, and the business owner sees intent, but none of them alone can prove whether the activity still makes sense.

That is why the current model of treating “unusual” as the primary signal is too weak for modern identity security. Security teams need correlated evidence that connects access, ownership, device posture, approvals, and recent changes before they can separate normal operational activity from identity abuse.

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 successful logins not prove identity behaviour is legitimate?

A: Because authentication only proves that a session was accepted, not that the intent behind the session is valid. Compromised accounts, stolen sessions, and abused OAuth grants can all act through trusted access paths and look operationally normal unless teams correlate context and purpose.

Q: What do identity teams get wrong about unusual activity alerts?

A: They often treat anomaly as the same thing as risk. In reality, many legitimate operational actions are unusual, and many malicious actions look normal. The better test is whether the activity makes sense for that identity given its role, approvals, and recent state changes.

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.

Technical breakdown

Why legitimate sessions can still hide identity abuse

A valid session is not proof of legitimate intent. Attackers increasingly rely on compromised employees, stolen sessions, or abused OAuth permissions because the resulting activity can inherit the same access patterns and trusted context as the real user or integration. The identity provider may record a normal login, while the SaaS platform sees only an authorised action. That split is why identity security needs behavioural context, not just authentication outcomes. The investigative question is not whether the event was allowed, but whether the action fits the expected identity, device, and business purpose.

Practical implication: investigate post-authentication behaviour against ownership, approvals, and access purpose rather than treating successful login as a trust signal.

Why disconnected telemetry weakens identity detection

Identity detection fails when every control plane reports truthfully but incompletely. HR knows whether a person is active, the endpoint tool knows the device posture, the IdP knows the session, and the business system knows the action, but those signals are usually not joined into one decision. That creates blind spots for compromised accounts, stale OAuth applications, and stolen sessions that never reauthenticate. This is especially acute in NHI environments, where long-lived permissions can continue to operate long after the original approval context is gone.

Practical implication: correlate identity, device, ownership, and business context into one investigation workflow before deciding whether access is still valid.

Context-based detection changes the meaning of anomalous activity

Anomalous activity is only useful when the baseline is credible. Engineers may access production during incidents, finance may pull large datasets at quarter-end, and administrators may make changes during approved migrations. Those actions look risky in isolation but make perfect sense in context. The reverse is also true: a familiar API call, admin action, or token creation can be malicious if the surrounding conditions no longer fit the identity's purpose. This is why detection increasingly behaves like investigation, especially across privileged human access and NHI-driven workflows.

Practical implication: build detection around context drift and intent mismatch, not just deviation from historical frequency.

Threat narrative

Attacker objective: The attacker aims to exploit trusted identity context so that harmful actions blend into ordinary work and avoid timely containment.

1. Entry begins with a legitimate login, valid session, or abused OAuth grant that does not appear malicious at first glance.
2. Escalation occurs when the actor uses the trusted identity to export data, create tokens, change settings, or add privileges within the permissions already granted.
3. Impact follows when the organisation accepts isolated signals as normal and misses the full pattern of identity abuse until sensitive actions are complete.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Identity detection is now a context-validation problem, not an alert-volume problem. The article is right that a successful login or authorised API call rarely answers the security question on its own. What matters is whether the action still fits the identity's purpose, device, access history, and recent changes. That is as true for human accounts as it is for service accounts and OAuth integrations, because the analyst's task is to prove behavioural coherence, not merely to spot deviation.

The strongest named concept here is identity context drift. Context drift occurs when an identity continues to operate inside its nominal permissions after the surrounding facts that justified trust have changed. A contractor may leave, a project may close, a token may outlive the deployment, or a device may change posture while the access remains technically valid. Practitioners should treat drift as the real failure mode, because abuse often begins when trust is stale but still operational.

“Unusual” is a weak governance threshold because identity abuse is often ordinary on the surface. Finance, engineering, and administration all have legitimate spikes, exceptions, and maintenance windows. The problem is not whether activity is rare. The problem is whether the environment can explain it with ownership, approvals, and business purpose. That shifts identity governance from frequency-based screening to evidence-based adjudication, which is the only defensible model when attackers deliberately mimic normal work.

Disconnected control planes create a false sense of certainty. IdP success, SaaS authorisation, endpoint posture, and HR status each represent a fragment of truth, but none of them is the complete answer. In practice, this means security teams often overtrust the control that is easiest to query and underweight the business context that actually resolves intent. The implication is that identity governance must be measured by how well it reconstructs the full story, not by how many events it logs.

NHI governance is especially exposed because machine access often looks like predictable automation. An OAuth app, service account, or API key may keep calling the same APIs for months, which makes malicious reuse hard to distinguish from routine operation. That does not make the risk unique to machines, but it does make lifetime management, ownership, and offboarding central to the problem. Practitioners need to treat long-lived machine context as an investigation dependency, not a comfort signal.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• That context makes 52 NHI Breaches Analysis the natural next resource for understanding how exposed credentials turn into real incidents.

What this signals

Identity context drift will become a more useful programme concept than anomaly alone because it captures the gap between a technically valid action and a behaviourally valid one. Teams that can join identity, device, change, and ownership evidence will spend less time chasing routine exceptions and more time isolating real abuse, which is where investigation value now sits.

A practical signal to watch is whether your IAM and SOC teams can answer “does this make sense?” without opening six different consoles. If they cannot, the environment is already teaching attackers how to hide inside legitimate work, and that problem scales across human accounts, service accounts, and delegated access paths alike.

The next maturity jump is not more alerts but better adjudication. Organisations should align this with the NIST Cybersecurity Framework 2.0 by improving identity evidence quality in detection, response, and recovery workflows, then measure how often an alert becomes a context-driven investigation rather than a rule match.

For practitioners

• Correlate identity with business context before triage Join IdP, SaaS, endpoint, ticketing, and ownership data so analysts can test whether an action still makes sense before escalating it as an incident. The key is to move from isolated event review to context reconstruction.
• Define behavioural exceptions by role and process Document the legitimate patterns that create false positives, such as incident response access, quarter-end exports, and approved migrations, then encode them as contextual exceptions rather than broad allowlists. This keeps the investigation model aligned with real work.
• Review OAuth and service account purpose regularly Confirm that long-lived applications, service accounts, and tokens still map to an active business purpose, current owner, and approved system relationship. Offboarding should include revoking access that no longer matches the original use case.
• Tune detections for intent mismatch, not just anomaly Build alerts around actions that are inconsistent with an identity's role, device, or change history, such as a familiar account creating new tokens outside an approved project. That approach catches abuse that looks normal at the event level.

Key takeaways

• Identity attacks often succeed by looking operationally ordinary, which makes context richer than anomaly for detection.
• The most useful evidence comes from correlating identity, device, ownership, approvals, and business purpose across systems.
• Practitioners should optimise for intent mismatch and context drift, not for more alerts or narrower rules.

Key terms

• Identity-context drift: The point at which a message, request, or interaction still looks normal to users but no longer matches established identity behaviour. In practice, this is where phishing becomes dangerous because the attacker borrows familiarity while changing the underlying intent or action path.
• Behavioural Coherence: A judgment about whether an action still matches the identity's expected role, purpose, and surrounding conditions. It is stronger than anomaly detection because it asks whether the activity makes sense, not merely whether it is rare or different from history.
• Contextual Investigation: The process of joining identity, device, approvals, ownership, and business purpose into one analysis so analysts can determine whether an action is legitimate. For modern IAM and NHI programmes, it is the bridge between raw telemetry and defensible response.
• Intent Mismatch: A situation where the observed action is permitted by policy but inconsistent with the identity's expected purpose or recent state. It is a practical signal for abuse because attackers often reuse valid access paths while changing the meaning of the activity.

What's in the full article

Offroad AI's full article covers the operational detail this post intentionally leaves for the source:

• How its agents connect identity activity with access, device, ownership, approvals, recent changes, and business purpose.
• The exact investigative workflow used to decide whether a suspicious action still makes sense for the identity involved.
• How the platform turns contextual investigation into response when policy permits action.
• Why the vendor believes traditional detection and investigation are converging in identity security.

👉 The full Offroad AI article expands on the investigative model, contextual signals, and response handoff.

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.