UEBA, user and entity behavior analytics, adds real value to detection engineering, but only for one specific class of problem. It answers questions your rules cannot phrase, the ones that begin with “unusual for this account”. If your threat model includes stolen credentials, insider misuse or lateral movement with legitimate tools, that class is where your worst misses live, and a baseline engine is the only honest way to cover it. Everywhere else, UEBA is expensive noise, and the vendors who sold it as a replacement for detection rules have mostly stopped selling it at all.
We should say up front what we mean by value, because the marketing definition and the engineering definition disagree. A capability adds value to a detection program when it produces coverage you could not build with the tools you already run, at an alert quality your triage queue survives. Measured that way, UEBA earns its place as an input to detections rather than a source of them. The rest of this article is the case for that position, and the queries to act on it.
What UEBA adds that detection rules cannot express
A detection rule is a predicate over fields you can name in advance. That makes rules the right tool for behavior that looks the same in every environment, an encoded PowerShell download cradle, a known exploit path against a KEV entry, a service writing to another service’s credential store. Detection engineering is largely the craft of finding those fixed observables and encoding them, and nothing in this article argues against it.
The problem is the attacker who brings no fixed observable. Take T1078, valid accounts, where MITRE’s own detection strategy is written entirely in baseline language. Its analytics look for “anomalous logon patterns”, logins “at unusual times”, “unexpected child process activity”, “geographic anomalies, impossible travel”. Read that list as a rule author and the difficulty is obvious. Unusual is not a predicate. No static threshold for “this login is strange” is true for both the developer who works from three countries a month and the finance clerk who has never left one. Any hardcoded approximation rots the week the org chart changes. ATT&CK describes the adversary who uses legitimate access precisely so that no malware artifact exists to match on, which means the only thing left to detect is distance from an account’s own history.
That distance is what a baseline engine computes, per user, per host, per application, continuously. UEBA is not a smarter rule. It is the infrastructure that makes “unusual for this identity” a queryable field, and that is a genuinely different capability from anything a rule can encode. We made the same point from the identity side in our non-human identity post, where the Drift breach went unflagged because almost nobody baselines what their OAuth integrations normally do. The tenants that got burned did not lack rules. They lacked a definition of normal.
UEBA vs SIEM: the market already answered
If UEBA were a product you needed, the standalone market would have survived. It did not. Splunk, which sold one of the best known standalone platforms, announced end of sale for Splunk UBA on December 12, 2025, with support ending January 31, 2027 and the capability folded into Enterprise Security Premier. Anton Chuvakin, then at Gartner, called this collision in November 2016, predicting a SIEM versus UEBA confrontation within two years that not every vendor would survive. A decade on, that is exactly what shipped. Microsoft Sentinel includes UEBA at no extra licence cost, and Splunk’s replacement for its standalone product lives inside its flagship SIEM.
Read both halves of that history, because each one settles a different argument. The product category died, which tells you standalone UEBA never justified its own procurement cycle, its own data pipeline and its own console. And yet the capability was absorbed rather than abandoned, which tells you the SIEM vendors concluded baselining is table stakes for the detection problems their customers actually have. The practical consequence for a detection team is pleasant. The “should we buy UEBA” debate is mostly obsolete. You likely already own it, and the real question is whether you use what it emits.
UEBA use cases that hold up, and the one that does not
The use cases that survive contact with a real triage queue are the ones where the attacker’s advantage is looking legitimate. Compromised accounts, insider activity and lateral movement are the three Microsoft names for Sentinel UEBA, and they match what we see teams struggle to cover with rules alone. Sentinel’s implementation scores each event against the account’s own history, against a peer group computed from group memberships and weighted by TF-IDF so small specialized teams count more than company-wide lists, and against the organization as a whole. A workload that suddenly reads a repository no peer touches is invisible to a rule and obvious to that comparison.
The use case that does not hold up is UEBA as an alert source, where every anomaly opens a ticket. Anomalies are facts about rarity, not verdicts about intent, and most rare behavior is a re-org, a new hire or a vacation. Even vendor primers concede that immature baselines flood queues with false positives while undertrained models miss real attacks, and that tuning demands skilled staff. Our advice is blunt. Never page a human on an anomaly score alone. Use the score to rank, enrich and gate the detections you already trust. That is exactly how Microsoft positions it, shipping a curated UEBA Essentials query pack and prompting analysts who write hunting queries to join the anomaly tables rather than alert on them.
UEBA detections in practice: three ways to query the tables
On Sentinel, UEBA writes to a handful of documented tables, and two fields carry most of the value. BehaviorAnalytics holds per-event deviations with an InvestigationPriority score from 0 to 10, computed in near real time from entity rarity and time-series shifts. Anomalies holds batch ML findings scored 0 to 1, in the table’s Score column. They disagree on purpose. Microsoft’s own example is a user’s first Azure operation, which scores high for investigation priority because it is a first, and low for anomaly because occasional firsts are normal. One caveat before the queries, and it matters for portability. There is no Sigma rule in this post because UEBA output is vendor-specific by nature; the concepts transfer to Splunk ES Premier or Exabeam, the field names do not.
The highest-return integration is triage enrichment, one join that re-orders your existing alert queue by behavioral context instead of static severity.
Data source: SecurityAlert, BehaviorAnalytics (Microsoft Sentinel)
SecurityAlert
| where TimeGenerated > ago(1d)
| extend Account = tostring(parse_json(Entities)[0].Name)
| join kind=leftouter (
BehaviorAnalytics
| where TimeGenerated > ago(1d)
| summarize MaxPriority = max(InvestigationPriority) by UserName
) on $left.Account == $right.UserName
| extend MaxPriority = coalesce(MaxPriority, 0)
| sort by MaxPriority desc, AlertSeverity
| project TimeGenerated, AlertName, Account, MaxPriority, AlertSeverityThe second pattern turns first-time privileged activity into a detection you can actually ship. ActivityInsights flags firsts and rarities per account, so the rule fires on the combination, a first for this user that the model also scored unusual, rather than on either signal alone.
Data source: BehaviorAnalytics (Microsoft Sentinel)
BehaviorAnalytics
| where TimeGenerated > ago(1d)
| where InvestigationPriority >= 6
| where tostring(ActivityInsights.FirstTimeUserPerformedAction) == "True"
or tostring(ActivityInsights.ActionUncommonlyPerformedByUser) == "True"
| project TimeGenerated, UserName, ActivityType, ActionType,
SourceIPAddress, SourceIPLocation, InvestigationPriority
| sort by InvestigationPriority descThe third pattern closes the loop on T1078. When an identity alert fires, pull every anomaly the ML engine holds for that account over the trailing week, which is the difference between arguing about one login and seeing a fortnight of drift.
Data source: Anomalies (Microsoft Sentinel)
Anomalies
| where TimeGenerated > ago(7d)
| where UserName has "<account under investigation>"
| project TimeGenerated, AnomalyTemplateName, RuleName,
Score, Tactics, Techniques
| sort by Score descTune all three the same way. Expect the first weeks after enablement to be worthless while baselines converge, expect re-orgs and mergers to reset them, and treat autoscaling infrastructure and travel-heavy roles as standing false-positive sources to suppress with allow-lists rather than threshold changes. Baselining and tuning this class of signal is routine work inside our AI-driven SOC engagements, and the honest summary of that work is that the queries are the easy part. The discipline of refusing to page on raw anomalies is the hard part.
When UEBA is not worth your time, and what to do instead
A capability that is free in your SIEM still costs ingestion, storage and attention, so the decision deserves a rubric rather than a default yes. Skip UEBA when your telemetry cannot feed it, because a baseline built on partial identity logs is a random number generator with a dashboard. Skip it when nobody owns tuning, since an unowned anomaly feed decays into a muted channel within a quarter. And skip the standalone procurement entirely unless you have a documented detection gap your bundled SIEM capability cannot close, a bar that Splunk’s own exit from the standalone market suggests few buyers were clearing.
Run it, and rely on it, when identity is your attack surface. If valid-account misuse, insider risk or living-off-the-land lateral movement sits near the top of your threat model, rules alone leave a structural hole there. ATT&CK’s baseline-phrased detection guidance for those techniques is the standards body telling you the same thing.
Frequently asked questions
What is the difference between UEBA and anomaly detection?
Anomaly detection is the statistical family, any method that flags deviation from an expected pattern, and it applies to metrics as readily as to people. UEBA is a security-specific application of it that builds per-identity and per-entity baselines, adds peer-group and organizational comparison, and scores events for triage. Every UEBA engine does anomaly detection; most generic anomaly detection has no notion of an identity’s history, which is the part detection engineering actually needs.
Does UEBA replace detection rules?
No, and teams that tried ended up drowning in unexplainable alerts. Rules encode known attacker behavior with high precision and clear response playbooks. UEBA scores how far activity sits from an account’s normal, which is evidence rather than a verdict. The working pattern is rules for decisions, behavioral scores for ranking and enrichment, joined in the queries above.
Is UEBA included in a SIEM or a separate product?
In 2026, check your SIEM before you shop. Microsoft Sentinel ships UEBA at no additional licence cost, and Splunk folded its standalone UBA into Enterprise Security Premier after the December 2025 end-of-sale notice. A standalone purchase now needs a documented gap the bundled capability cannot close.
How long does UEBA baselining take?
Plan for a learning period measured in weeks, not days, before scores mean anything, and longer in environments with strong seasonality. The baseline also resets in practice after re-orgs, migrations and mergers, so treat convergence as a recurring state to monitor rather than a one-time setup step. Alerting on anomaly scores during a learning window is the fastest way to teach your analysts to ignore the feed.
Bottom line
Rules decide, baselines rank. Enable the UEBA capability your SIEM already includes, join its scores into the detections you trust, and refuse to page anyone on a raw anomaly. Do that and you get the value the standalone UEBA market promised and never delivered, without buying anything.