TL;DR: User behaviour tools can surface anomalies, but they often cannot distinguish malicious, negligent, and unintentional insider activity, according to Above’s analysis. That gap matters because IAM permissions, UEBA noise, and external-threat testing still miss the intent signal that governs whether legitimate access becomes a security event.
NHIMG editorial — based on content published by Above: Insider Threat 101: Do You Know Who's Sus?
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
Questions worth separating out
Q: How should security teams reduce insider risk without relying on user behaviour?
A: Security teams should enforce policy at the endpoint so risky actions are blocked before they happen.
Q: Why do IAM and UEBA still miss malicious insider activity?
A: IAM can tell you whether access was allowed, and UEBA can tell you that activity looked unusual.
Q: What are the warning signs that insider-risk monitoring is too noisy?
A: The main signs are high alert volume, repeated false positives, and alerts that cannot be tied to a clear business process or data-flow sequence.
Practitioner guidance
- Separate access legitimacy from intent analysis Keep IAM approvals, behaviour analytics, and investigation workflows distinct so that a permitted action can still be evaluated for motive, sequence, and downstream data movement.
- Correlate events across identity, endpoint, and SaaS telemetry Build timelines that join login activity, downloads, transfers, and privilege changes across systems, because a single event rarely proves insider misuse.
- Tune UEBA around context, not raw anomaly counts Enrich alerts with role, device, location, timing, and recent access changes before escalation so analysts can separate late-night work from suspicious behaviour.
What's in the full article
Above's full blog post covers the operational detail this post intentionally leaves for the source:
- Practical examples of how the vendor correlates identity, behaviour, and data movement across systems.
- A stepwise breakdown of the analyst workflow used to infer intent from activity timelines.
- The specific alerting and response patterns the vendor recommends for malicious, negligent, and unintentional cases.
👉 Read Above's analysis of insider threat intent detection and user behaviour →
Insider threat intent analysis: what IAM and UEBA miss?
Explore further
Insider risk remains an intent problem, not just an access problem. The article is right to show that authenticated users can still be the source of harm, because the critical question is why an action happened, not whether the action was technically permitted. That makes traditional logging necessary but insufficient. The discipline now has to treat access, behaviour, and context as separate layers, with intent sitting above all three.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how quickly one identity failure can become a pattern rather than an exception.
A question worth separating out:
Q: Should organisations focus more on user intent or on activity detection?
A: They need both, but activity detection should come first because it creates the evidence trail. Intent is inferred from patterns, not read directly from logs, so organisations should build telemetry, correlation, and case review around real behaviour. Without that evidence base, intent-based decisions become guesswork and can undermine trust in the programme.
👉 Read our full editorial: Insider threat detection still fails when intent stays invisible