Why do IAM and UEBA still miss malicious insider activity?

Why IAM and UEBA Miss Insider Intent

IAM answers a narrow question: whether an action was permitted. UEBA answers a different narrow question: whether an action looks unusual compared with a baseline. Neither layer can reliably determine intent, so a malicious insider, a careless employee, and an innocent but atypical user can all produce similar signals. That gap matters because insider cases are usually judged by context, sequence, and motive, not by a single permission check or anomaly score.

NHIMG research on non-human identity management shows why context is often missing in practice: only 5.7% of organisations report full visibility into service accounts, and 88.5% say their non-human IAM practices lag behind or merely match their human IAM efforts. The same pattern appears in insider detection when access is technically valid but behavioural meaning is unclear.

Ultimate Guide to NHIs and the control structure in NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce the same operational point: monitoring is useful, but it is not proof of legitimacy or abuse. In practice, many security teams only recognise insider intent after the activity has already blended into normal business use.

How It Works in Practice

IAM and UEBA fail together because they sit at different points in the decision chain. IAM is good at enforcing whether a user or account may access a system, while UEBA is good at flagging deviations such as unusual logins, data movement, or access timing. The problem is that malicious insiders rarely need to break either layer to cause harm. They often use permitted access, familiar tools, and legitimate workflows, which makes raw telemetry look ordinary until the broader pattern is examined.

That is why detection has to move from permission and anomaly alone to context-rich investigation. Useful context usually includes job role, recent changes in responsibility, ticket history, device posture, data sensitivity, peer-group behaviour, and whether the activity fits an expected work sequence. When those signals are absent, anomaly detection tends to overfire on harmless exceptions or underfire on well-disguised abuse.

• Permitted access does not equal trusted intent.
• Outlier behaviour does not equal malicious behaviour.
• High-value data access requires sequence and context review, not only threshold alerts.
• Long-lived access and shared accounts weaken attribution and make insider analysis harder.

This is also why teams that rely heavily on alert volume often miss the most important cases: insiders can stay inside approved access boundaries while using that access in an abusive way. NHIMG’s 2024 Non-Human Identity Security Report highlights a related governance reality, with 97% of NHIs carrying excessive privileges and 71% not rotated on time, showing how often access scope stays broader than the organisation assumes. The same structural weakness makes behaviour harder to interpret for human users too. These controls tend to break down when access is widely shared, responsibilities change quickly, or the organisation lacks enough data context to distinguish legitimate exception from intentional abuse.

Common Variations and Edge Cases

Tighter anomaly thresholds often increase false positives, so organisations have to balance sensitivity against investigation capacity. Best practice is evolving here: there is no universal standard that tells a programme exactly how much behavioural deviation is enough to label insider risk.

Some insider cases are not obviously malicious at first. A frustrated employee may move data in ways that resemble operational bulk work, while a negligent user may create the same access pattern without harmful intent. In regulated or high-trust environments, the hard part is not spotting “odd” activity but deciding which odd activity justifies escalation because it threatens confidentiality, integrity, or accountability.

Current guidance suggests treating UEBA as a triage layer rather than a verdict engine. IAM should answer whether the access path was allowed, while investigations should answer whether the access was appropriate, necessary, and consistent with role, timing, and data sensitivity. That distinction matters most when exceptions are common, privileged access is shared, or the same account can be used by multiple people.

Risk and Threat Considerations

The material risk is false assurance: organisations can believe that a logged-in, authorised, or low-anomaly action is therefore safe, when the real exposure is misuse of legitimate access. Insider abuse is attractive because it can avoid many perimeter and identity gates by staying inside approved credentials and normal channels.

Failure mechanism: The control gap emerges when IAM validates entitlement and UEBA flags deviation, but neither can reliably infer purpose. An insider can use valid access, familiar systems, and ordinary workflows to reach sensitive data, alter records, or exfiltrate information in ways that do not create a strong anomaly signature.

Impact: The result is delayed detection, weak attribution, and either excessive false positives or missed abuse. That can leave sensitive data exposed, investigations underpowered, and disciplinary or legal decisions based on incomplete evidence.

Practitioner Guidance

What to prioritise: Treat context enrichment as the first improvement, not a final tuning exercise. Add ownership, role change history, data classification, device trust, and ticket or approval context to the investigation path so alerts can be evaluated against business meaning, not just statistical deviation.

Decision rule: If the activity is permitted but touches sensitive data, privileged functions, or bulk movement, escalate to human review even when UEBA confidence is low. If the same pattern is repeated by a shared or long-lived account, treat attribution as a separate control problem rather than assuming the anomaly score will resolve it.

What practitioners underestimate: The hardest cases are often the least anomalous. Mature programmes look for inconsistent purpose, not only inconsistent behaviour, because malicious insiders usually try to look operationally normal while acting outside their legitimate need.

Practitioner takeaway: IAM and UEBA are necessary inputs, but insider detection becomes materially better only when the programme can explain why the access happened, not merely that it was allowed or unusual.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• When does a short-lived API key still create material risk?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Where does cross-environment agent discovery fit in an IAM programme?