What Is UEBA? User and Entity Behaviour Analytics Explained

User and Entity Behaviour Analytics (UEBA) is a detection method that builds a statistical model of how each user and system normally behaves, then flags meaningful deviations from that baseline. Unlike rule-based detection, which fires when activity matches a known-bad pattern, UEBA fires when activity is simply abnormal for that particular actor — even when every individual action is technically permitted.

That distinction matters because the most damaging security incidents rarely involve malware that a signature can catch. They involve legitimate credentials being used illegitimately.

Why rule-based detection alone leaves a gap

A correlation rule is a hypothesis written in advance: if authentication fails ten times in sixty seconds, raise an alert. Rules are precise, fast, explainable, and cheap to run. They are also, by definition, limited to attacks somebody has already characterised.

Consider an attacker who has phished a valid credential. They log in successfully on the first attempt. They browse a file share the account is authorised to read. They copy documents the account is permitted to copy. No rule fires, because no rule has been violated. From the log's point of view, this is a Tuesday.

What is anomalous is not any single event but the pattern: this user has never logged in at 03:00, never connected from that geography, never touched that file share, and has never moved two gigabytes in an afternoon. Detecting that requires knowing what normal looks like.

The prerequisite nobody mentions: identity resolution

UEBA cannot baseline a user it cannot identify. This is the step most teams underestimate.

Raw security telemetry is full of machine identifiers — hostnames, IP addresses, process IDs, session tokens, SAM account names, UPNs. The same human being might appear as DESKTOP-4471 in one log, [email protected] in another, and 10.20.4.88 in a third. Before you can say "this user is behaving oddly," something has to establish that all three refer to one person.

That means an identity layer that:

• Pulls canonical user records from a directory service — Active Directory, Entra ID, Okta, Google Workspace
• Assigns each person a stable identifier that survives a name change or a device swap
• Binds devices to users, typically from interactive logon events such as Windows Event ID 4624
• Carries department, role and manager, which later enables peer group comparison
• Tracks account state, so a login on a disabled account is immediately visible

A useful rule of thumb: if your alerts show hostnames rather than people's names, you are not ready for UEBA yet. Identity resolution is the work that has to happen first.

What gets baselined

Behavioural baselines are built per entity across a handful of dimensions. In practice most implementations track some combination of:

Dimension	Example signals
Authentication	Login hours, source geography, source device, success and failure rates, authentication method
Resource access	Which systems and file shares are touched, first-time access to a resource, volume of data read or written
Lateral movement	Which hosts a user connects to, remote session creation, use of administrative protocols
Privilege	Group membership changes, privilege escalation, use of administrative tooling by non-administrative accounts
Process behaviour	Which executables run under a user context, scripting interpreters, unusual parent-child process chains

Baselines need a learning window — typically two to four weeks of representative activity. Deploy UEBA in December and you will baseline a holiday period, then generate false positives for the whole of January.

Risk scoring, and why it beats binary alerts

UEBA usually expresses its output as a continuous risk score rather than a fired-or-not alert. This suits the problem: a single mild anomaly is rarely worth an analyst's time, but five mild anomalies converging on one account in one afternoon usually is.

A typical model works like this. Each detected anomaly contributes points weighted by severity and confidence. The score decays over time as behaviour normalises, so a user who once logged in late does not carry that forever. When the score crosses a threshold, it escalates into an investigation — and critically, it feeds the same correlation engine handling the rest of your detections, so behavioural risk becomes one more signal alongside the rule-based ones rather than a separate console nobody watches.

Personal baseline versus peer group

Comparing a user only against their own history has a blind spot: if an account was compromised before baselining began, the malicious behaviour becomes the baseline.

Peer group analysis addresses this by clustering users with similar roles and comparing across the group. A finance analyst accessing source code repositories may be perfectly consistent with their own history, yet wildly inconsistent with every other person in finance. That comparison catches what personal baselining misses.

More advanced implementations add unsupervised techniques such as Isolation Forest to identify outliers without predefining what an outlier looks like, and sequence models to detect anomalous chains of events — a login, followed by an unusual query, followed by a bulk download — where each step alone looks unremarkable.

What UEBA realistically catches

• Account takeover. Valid credentials used from an unfamiliar location and device, accessing unfamiliar resources.
• Insider misuse. An employee accessing systems outside their function, often shortly before resignation.
• Service account abuse. An account that normally runs scheduled tasks at 06:00 suddenly performing interactive logins — a classic lateral movement signature.
• Slow data exfiltration. Volume that stays under any fixed threshold but sits far above the user's own norm.
• Dormant account reactivation. Accounts that should have been deprovisioned suddenly showing activity.

The honest limitations

UEBA is often oversold, so it is worth being clear about where it struggles.

It needs time. No useful output on day one. Budget weeks before signal quality is acceptable.

It is probabilistic. A UEBA finding says "this is unusual," not "this is malicious." Every finding needs human judgement, and organisations without analyst capacity to investigate will simply accumulate ignored scores.

It struggles with genuinely irregular users. Executives, contractors, travelling staff and on-call engineers have inconsistent patterns by nature. Their baselines are wide, so their anomalies are weak.

It is only as good as its identity data. A stale directory produces meaningless entities and unusable baselines.

Privacy and employment law apply. Behavioural monitoring of named individuals is regulated in most jurisdictions. Under Malaysia's PDPA, Indonesia's PDP Law, Singapore's PDPA and the GDPR, monitoring employees requires a lawful basis, transparency, and usually consultation. This is not a purely technical deployment — get it reviewed before you switch it on.

Where UEBA sits in a security programme

UEBA is not a replacement for rule-based detection, endpoint protection or threat intelligence. It is the layer that covers what those miss: threats that use legitimate access rather than defeating it.

The sensible sequence is to get log collection reliable, get rule-based detection tuned, get identity resolution accurate — and then add behavioural analytics on top of that foundation. Deployed in the other order, UEBA produces noise nobody can act on.

For organisations under data residency obligations there is one further consideration. Behavioural baselines are derived from detailed records of what named employees do, hour by hour. That is among the most sensitive data any security platform holds. Where it is processed and stored is a compliance question as much as a technical one, which is a strong argument for keeping behavioural analytics inside infrastructure you control.

---

Read how nPro approaches identity resolution and behavioural analytics in the nPro documentation, including the Identity Sync setup guide for Active Directory and Entra ID.