It costs nothing extra and most Sentinel customers have never once turned it on.
It builds a picture of how each person, machine, address and application normally behaves, then raises whatever departs from that picture. It comes with Sentinel at no additional cost, with the data landing in Log Analytics tables at standard rates. We switch it on, connect the sources it depends on, and build it into the way your analysts genuinely work rather than leaving it running in a corner.
- No extra costUEBA is included with Sentinel
- 6 tablesWhere UEBA insights are stored
- Two scoresThat deliberately disagree with each other
- Top 20 peersRanked per user for peer comparison
Eight things that decide whether this ever produces anything useful.
Behavioral profiles for more than users
Machine learning constructs a moving picture of normal behavior for each person, machine, address, application and other entity, then finds what departs from it by comparing today activity against the baseline it has learned. Three use cases are named: accounts that have been taken over, attacks from inside, and movement sideways through the estate.
Peer comparison, weighted intelligently
One table ranks each person twenty closest peers, worked out from security group membership, mailing lists and other associations, weighted so that smaller groups count for more. Belonging to a specialized group of six says a great deal about somebody. Belonging to the group containing all staff says nothing at all.
Two scores measuring different things
There are two scores and they are not the same thing. Investigation priority runs from zero to ten, lives in the behavior analytics table, is calculated close to real time and measures how unusual a single event was. Anomaly score runs from zero to one, lives in the anomalies table, is processed in batches and measures behavior across many events together.
Blast radius as part of the assessment
Alongside the behavioral modeling it also compares people against their peers and works out the blast radius, meaning what the anomalous activity could actually reach. That is precisely what separates an odd action by somebody with almost no access from the identical action by somebody who can open every system in the building.
Identity context from both directories
One table holds detailed profiles of people, devices and groups, assembled from Entra and, optionally, from the directory on your own servers by way of Defender for Identity. In a hybrid estate that second source is exactly what turns a cloud-only picture into a complete one.
The behaviors layer is a separate switch
The behaviors layer is a separate thing entirely, enabled on its own rather than arriving with the rest, and its two tables do not exist at all until somebody switches it on. Querying for a table that was never created is among the most common early confusions here.
Queries you do not have to write
There is a solution package containing dozens of ready-written hunting queries, curated and kept current by Microsoft security researchers, covering anomaly detection across Azure, AWS, Google Cloud and Okta. Installing it is how a team gets something useful within days rather than months.
Embedded experiences in the Defender portal
A widget on the home page, behavioral context shown on each user page with automatic tagging where something unusual appears, a panel showing the three highest anomalies from the past month, anomaly queries launchable straight from an incident graph, and a banner in hunting prompting a join to the anomalies table.
The two scores will contradict each other, and that is the design behaving exactly as intended.
There is a worked example for this, and understanding it stops a team deciding that one of the two numbers must be broken.
- Somebody carries out an Azure operation for the first time. Investigation priority comes back high, because it has never happened before. Anomaly score comes back low, because people doing something in Azure for the first time is entirely ordinary and carries no particular risk. Both numbers are right. They are answering different questions.
- Investigation priority sits in the behavior analytics table, runs from zero to ten, is worked out close to real time for each event, and blends how rare the person, the device and the country are with a time series measure catching patterns like a sudden spike in failed sign-ins.
- Anomaly score sits in the anomalies table, runs from zero to one, is processed in batches at the level of behavior rather than individual events, and comes from a detector trained on the telemetry in your own workspace. Its purpose is spotting patterns and aggregated anomalies across time, not triaging a single event this afternoon.
- Some correlation is expected, and a high anomaly score frequently does line up with a high investigation priority, though by no means always. Each carries insight the other does not, which is exactly why using only one of them throws away half of what you have.
Four things that turn UEBA from enabled into used.
We install the queries rather than writing them
The solution package carries dozens of ready-written hunting queries, curated and maintained by Microsoft researchers, covering Azure, AWS, Google Cloud and Okta. Building anything equivalent yourself takes months and ends up worse than what you could have installed on the first afternoon.
We teach the two scores as two different tools
Investigation priority runs zero to ten, close to real time, measuring how unusual a single event was, and it exists for triage. Anomaly score runs zero to one, in batches, measuring behavior across many events, and it exists for spotting patterns. Teams that treat the two as one number invariably conclude that one of them must be broken.
We check which tables you actually have
What gets covered depends on which connectors are actually running, and the behaviors layer tables do not exist at all unless somebody enabled that separately. Half an hour spent confirming which tables hold rows saves an analyst an extremely frustrating afternoon querying one that was never going to return anything.
We connect the on-premises identity source
The identity table is assembled from Entra and, optionally, from the directory on your own servers by way of Defender for Identity. In a hybrid estate, leaving out that second source produces profiles missing precisely the context that matters for detecting movement sideways, which happens to be one of the three named use cases.
Four phases across roughly five weeks.
- 01Week 1
Enable and connect the sources it depends on
Switched on, with the sources that matter connected: Entra, Defender for Identity and Office 365 among them. How much lands in the behavior analytics table depends entirely on which connectors are running, so this step alone decides how much of your estate gets profiled at all.
- UEBA enabled in the workspace
- Entra ID, Defender for Identity, and Office 365 connected
- Multicloud sources connected where they exist
- Behaviors layer decision recorded
- 02Week 2
Install UEBA Essentials and let baselines form
The solution package installed, bringing dozens of ready-written hunting queries maintained by Microsoft researchers, with anomaly detection reaching across Azure, AWS, Google Cloud and Okta. The baselines need time to form and the queries need data underneath them before either is worth reading.
- UEBA Essentials solution installed
- Pre-built hunting queries available to analysts
- IdentityInfo populated from both directories where hybrid
- Table availability confirmed per connected source
- 03Weeks 3 to 4
Build UEBA into the triage workflow
This is the phase that determines whether any of it gets used. Investigation priority applied while triaging individual events, anomaly score used for looking at patterns over weeks, and hunting queries joined to the anomalies table so that every investigation carries behavioral context without anybody remembering to add it.
- Investigation priority incorporated into triage
- Anomaly score used in periodic pattern review
- Existing hunting queries enriched with Anomalies joins
- Analyst guidance on when each score applies
- 04Week 5
Use the embedded experiences and hand over
The portal experiences adopted on purpose rather than discovered by accident: the home page widget, the behavioral context on user pages, the three highest anomalies from the past month, and the anomaly queries launchable from an incident graph. Then a review rhythm, so that six months later somebody is still opening it.
- Defender portal UEBA experiences demonstrated to analysts
- Incident graph anomaly queries adopted
- Periodic anomaly pattern review scheduled
- Handover with query examples for the team
Six situations where behavioral context changes the answer.
A business investigating a possibly compromised account
Accounts that have been taken over are one of the three named use cases. The real question is whether this activity is normal for this particular person, and a behavioral profile alongside a peer comparison answers that directly. A threshold rule can only tell you whether something crossed a number somebody chose in a meeting.
An organization with an insider concern
Insider attacks are the second named use case, and they are the hardest to detect with rules because the activity is authorized. Deviation from an individual baseline, and from what their peer group does, is the signal that a permission check cannot produce.
A company tracking lateral movement
The third named use case, and the one that most depends on complete identity context. Where the estate is hybrid, IdentityInfo built from Entra ID plus on-premises Active Directory through Defender for Identity is what makes the movement visible across the boundary.
A regulated firm prioritizing a large alert queue
Investigation priority ranges 0 to 10 and combines entity rarity with time series patterns such as spikes in failed sign-ins. Used during triage it gives a defensible order of work, which is more useful than severity alone when everything is labeled high.
An operator with a multicloud footprint
The UEBA Essentials solution includes multicloud anomaly detection queries across Azure, AWS, Google Cloud Platform, and Okta. For estates that ended up multicloud through acquisition, that is behavioral coverage across all of it without writing separate detection for each.
A team that wants more from Sentinel without more spend
UEBA is included with Sentinel at no extra cost, with data stored in Log Analytics tables under standard pricing. For an organization already paying for Sentinel and looking for more value from it, enabling and using UEBA is among the highest return actions available.
How US organizations use behavioral analytics.
| Feature | Enabled and built into triage | Enabled, unused | Never enabled |
|---|---|---|---|
Behavioral baselines exist | Yes | Yes | No |
Investigation priority used in triage | Yes | No | Not applicable |
Anomaly patterns reviewed | Periodically | No | Not applicable |
Peer comparison available | Yes | Yes, unused | No |
Hunting queries enriched | Anomalies joined | No | Not applicable |
Pre-built queries installed | UEBA Essentials | No | No |
Hybrid identity context | Via Defender for Identity | Cloud only | None |
Insider risk signal | Present | Present, unread | Absent |
Lateral movement signal | Present | Present, unread | Absent |
Additional cost | None | None | None |
Six tables and what each is for.
Table
IdentityInfo
- What it holds
- Detailed profiles of people, devices and groups drawn from Entra and, optionally, your own directory
Table
BehaviorAnalytics
- What it holds
- Deviations from baseline with prioritization scores, enriched with geolocation and threat intelligence
Table
UserPeerAnalytics
- What it holds
- Peer groups worked out on the fly, with the closest twenty ranked per person
Table
Anomalies
- What it holds
- Events identified as anomalous, supporting detection and investigation
Table
SentinelBehaviorInfo
- What it holds
- Plain language summaries of who did what to whom, mapped to the recognized attack techniques
Table
SentinelBehaviorEntities
- What it holds
- Profiles covering the files, processes, devices and people caught up in a detected behavior
Table
Behaviors layer tables
- What it holds
- Only created if you enable the behaviors layer separately
Table
InvestigationPriority field
- What it holds
- Behavior analytics table, zero to ten, close to real time, one event at a time
Table
AnomalyScore field
- What it holds
- In Anomalies, 0 to 1, batch, behavior across multiple events
Table
Coverage of these tables
- What it holds
- Depends on which connectors are enabled
Five steps, and the last two are about habits.
- 1
Enable UEBA and connect the key sources
Microsoft Entra ID, Defender for Identity, and Office 365 are named as key sources, and coverage in the behavioral tables depends on which connectors are enabled. For hybrid estates, Defender for Identity is what brings on-premises Active Directory context into the identity profiles.
- 2
Decide on the behaviors layer explicitly
It is a separate capability enabled independently, and the SentinelBehaviorInfo and SentinelBehaviorEntities tables only exist if you enable it. Those tables translate raw logs into who did what to whom summaries with natural language explanations and MITRE ATT&CK mappings.
- 3
Install UEBA Essentials
Dozens of pre-built hunting queries curated and maintained by Microsoft security experts, including multicloud anomaly detection across Azure, AWS, Google Cloud Platform, and Okta. This is the difference between having UEBA data and being able to use it in the first week.
- 4
Put investigation priority into the triage routine
A 0 to 10 near real time score of how unusual a single event is, combining entity rarity with time series patterns. Used during triage it gives an order of work grounded in behavior rather than in a severity label everything shares.
- 5
Add a periodic anomaly pattern review
Anomaly score is processed in batches at the level of behavior across many events, so it answers a different question on a completely different rhythm. A scheduled review of the patterns, plus hunting queries joined to the anomalies table, is the only way that half of the capability ever gets used.
What organizations ask about Sentinel UEBA.
Fifteen questions about your own UEBA position.
Enablement
- Is UEBA enabled at all?It is included at no extra cost.
- Is Entra ID connected?A key source for profiles.
- Is Defender for Identity connected?It brings on-premises AD context.
- Is Office 365 connected?Named as a key source.
- Have we enabled the behaviors layer?Separate switch, separate tables.
Data
- Is IdentityInfo populated?From Entra ID and optionally AD.
- Does BehaviorAnalytics have data?It depends on connectors.
- Is UserPeerAnalytics building peer groups?Top 20 per user.
- Are multicloud sources connected?AWS, GCP, and Okta are covered.
- Have we installed UEBA Essentials?Dozens of pre-built queries.
Use
- Do analysts use investigation priority?For single event triage.
- Does anybody review anomaly score patterns?For behavior over time.
- Do hunting queries join the Anomalies table?The portal prompts for this.
- Do we use the incident graph anomaly queries?Built in, one click.
- Does anybody look at the UEBA widget?On the Defender home page.
Check whether UEBA is enabled in your Sentinel workspace.
It costs nothing extra and a large share of customers have never turned it on. If it is off, you are already paying to ingest the very data it would have profiled while receiving none of the behavioral context that data could produce.
Related Services
Explore more solutions that work great with this service
Microsoft Sentinel Analytics Rules
Sentinel detection engineering for US organizations: every enabled
Learn moreKQL Threat Hunting Enablement
Advanced hunting and KQL enablement for US security teams: permission
Learn moreMicrosoft Sentinel
Cloud-native SIEM and threat intelligence
Learn moreMicrosoft Sentinel Data Connectors
Ingestion reviewed, connectors migrated, costs controlled
Learn moreSOC-as-a-Service
24/7 security operations delivered as a service
Learn moreMicrosoft Purview
Data governance and compliance solutions
Learn more