Individual and peer-group baselines: the model learns what is normal for each entity and for its peer group (department, role, server type). Bulk queries from a database administrator are normal; the same queries from someone in marketing are not.
What is UEBA?
UEBA (User and Entity Behavior Analytics) is a detection technology that builds a statistical baseline of normal behaviour for every user and entity —accounts, hosts, applications, service identities— and raises alerts when activity deviates significantly from that pattern. Instead of fixed rules like "three failed logins = alert", it applies machine learning models to weeks of telemetry: login times, download volumes, resources accessed, geographies, sequences of actions. It is the layer that surfaces what no signature ever fires on: compromised credentials used patiently, or an employee exfiltrating data little by little.
Why does it matter?
The two hardest incident categories to detect share one trait: every action involved is technically legitimate. An insider threat uses their own permissions; an attacker with stolen credentials signs in exactly like the account owner. Classic SIEM correlation rules have nothing to correlate, because there is no malware, no exploit and no known indicator of compromise. UEBA changes the question: instead of "does this match a known attack pattern?", it asks "is this normal for this person, this server or this service account at this hour?". A sales rep downloading 4 GB from a repository they have never touched, on a Tuesday at 03:14, breaks no rule — but it does break their baseline. That is why vendors have made it a native module: Microsoft Sentinel UEBA, Splunk UBA, Exabeam and Securonix use it to risk-score what the SOC should investigate first, and modern XDR engines increasingly embed equivalent behavioural analytics.
Key points
Cumulative risk scoring instead of binary alerts: each anomaly adds points to the entity's score (unusual login +10, first access to a resource +15, anomalous volume +25). The SOC investigates high-score entities, not every isolated event, which drastically reduces alert fatigue.
Core use cases: insider threat detection (pre-departure exfiltration, privilege abuse), accounts compromised through phishing, lateral movement with valid credentials and anomalous privilege escalation.
It also covers non-human identities: service accounts, service principals and API tokens behave in highly stable ways, so any deviation (a backup account suddenly reading mailboxes) is a strong signal. See NHI.
It does not replace the SIEM, it amplifies it: UEBA consumes the telemetry the SIEM already centralises (authentication, EDR, proxy, cloud, DLP) and returns risk context that feeds response, including automation through SOAR.
It needs data and patience: a learning period of at least 2 to 4 weeks, well-connected identity sources (Active Directory, Entra ID) and continuous tuning. Without quality telemetry, the model learns noise.
Example: the compromised account no rule ever catches
A finance employee falls for a reverse-proxy phishing kit that steals their session, MFA included. The attacker deploys no malware: they sign in with the stolen cookie and simply read. No classic rule fires, because every individual action is valid.
The UEBA module, however, starts adding up: a session from a residential ASN in a country never seen for this user (+15), at 02:40, outside their usual window (+10), first-ever access to a SharePoint site belonging to the legal department (+20), 600 files downloaded in 20 minutes against a daily average of 12 (+30), and a new mailbox forwarding rule (+25). The entity's score crosses the threshold and the SOC receives a single, prioritised investigation with the whole chain of anomalies already reconstructed. The analyst revokes sessions, resets credentials and triggers incident response before the attacker monetises the access. Without a behavioural baseline, this incident would have surfaced weeks later — probably through the fraud invoice.
Common mistakes
- Buying UEBA as a silver bullet without fixing telemetry first: if authentication, EDR and cloud logs arrive incomplete or with poorly resolved identities, the model scores partial data and the output is noise with a scientific veneer.
- Skipping the learning period, or training the model on an already compromised environment: if the attacker has been inside for months, their activity becomes part of the baseline and turns 'normal'.
- Treating every anomaly as an incident: UEBA is designed to accumulate weak signals into a score, not to open a ticket for every odd login. Using it as a binary alert generator recreates the fatigue it was meant to solve.
- Restricting the analysis to human users and ignoring service accounts, tokens and machines — precisely where behaviour is most predictable and deviation most meaningful.
- Deploying employee behaviour analytics without a legal framework: under GDPR it requires prior information to staff, proportionality and a lawful basis. Doing it covertly invalidates evidence in dismissal proceedings and exposes the company to fines.
Related terms
Frequently asked questions
We already run a SIEM with correlation rules — what does adding UEBA actually give us?
Coverage of the attack category rules cannot see: those using valid credentials and legitimate permissions. A rule needs a pattern known in advance; behavioural analytics detects deviation from normal even when the attack is brand new. In practice it is rarely a separate purchase: Microsoft Sentinel, Splunk and Exabeam offer it as a module on top of the SIEM your team already operates, and its output (per-entity risk scores) is used to prioritise the SOC's investigation queue, not to replace your existing rules.
How do I detect an employee copying data before leaving for a competitor?
This is the classic UEBA use case, combined with DLP. The typical pattern —growing access to repositories outside their area, bulk downloads, USB or personal email use, off-hours activity— rarely breaks a specific rule, but it clearly separates from the user's baseline and their peer group's. Many organisations also raise scoring sensitivity for employees serving notice or under disciplinary proceedings. Important: do it under a policy communicated to staff and proportionate monitoring, or the evidence will not stand up in court.
Does UEBA work for service accounts and other non-human identities?
Yes — and it is where it works best. A service account always does the same thing: same servers, same schedule, same volumes. When such an identity deviates —a backup service principal that starts reading mailboxes, a CI/CD token used from a new IP— the probability of compromise is very high and false positives are minimal. Since non-human identities already outnumber human ones in most cloud environments and rarely have MFA, a behavioural baseline is often the only real detective control over them.
We are a mid-sized company without our own SOC — does UEBA make sense for us?
The capability makes sense; operating it yourselves may not. UEBA without analysts investigating the scores is a dashboard nobody looks at: the value appears when someone reviews high-risk entities daily and acts. For a mid-sized company the sensible route is consuming it through a managed SOC or an MSSP whose platform already includes behavioural analytics, with thresholds tuned to your business. You get mature detection from month one instead of spending years building a 24x7 team of your own.