UEBA Guide: Baselines for Users and Service Accounts

Attackers who log in with valid credentials look like employees and service accounts doing their jobs, and signature rules rarely see them. User and entity behaviour analytics (UEBA) builds a picture of what normal looks like for each account, device and application, then scores deviations from it so analysts can find misuse of legitimate access. This guide covers how baselines are built for human users and for service accounts and workload identities, how peer groups and risk scores work, how to keep false positives under control, and how to roll UEBA out in stages. It is for SOC, detection and identity teams running or evaluating UEBA in a SIEM, identity platform or cloud service. AI agent behaviour and insider risk governance have their own guides, linked below.

Key takeaways

UEBA answers one question: is this account behaving the way it, and accounts like it, normally behave? It complements rules; it does not replace them.
Service accounts are the easiest identities to baseline because their behaviour should be narrow and repetitive, yet many programmes only model human users. Bound every automated account by time, source host, destination and action.
Peer groups make baselines meaningful for new or rarely active accounts, but only if the HR and directory data that defines the groups is accurate.
A risk score is a prioritisation aid, not a verdict. Aggregate scores per entity over a window, explain every contributing anomaly, and tune thresholds against real investigations.
Most UEBA failures are data failures: missing log sources, unresolved identities, short retention and unlabelled automation produce noise that buries the real signal.

What UEBA is and where it fits

UEBA grew out of user behaviour analytics (UBA), which profiled people. The "entity" part extends the model to hosts, IP addresses, applications, service accounts and cloud workload identities. Microsoft's documentation for its Sentinel UEBA feature, for example, describes behavioural profiles for users, hosts, IP addresses and applications, built with behavioural modelling, peer group analysis and blast radius evaluation. The same pattern appears in cloud-native services: Amazon GuardDuty's anomaly detection model evaluates API requests and tracks factors such as the identity that made the request, where it came from and which API was called.

The joint CISA, NSA, FBI and international partner guidance on living off the land (LOTL) techniques explains why this matters. Attackers using built-in tools and valid accounts blend into normal administration, so it tells defenders to baseline network, user, administrative and application activity and to use UEBA to correlate sources and profile behaviour. NIST SP 800-207 (section 3.3.1) makes the same point for access decisions: "contextual" trust algorithms that consider a subject's recent history can spot an account acting inside its permissions but outside its pattern.

Approach	What it detects well	What it misses	Typical owner
Signature and correlation rules	Known techniques with stable indicators (for example a specific LSASS access pattern, T1003.001)	Valid-account misuse that uses normal tools and permitted actions	Detection engineering
UEBA (statistical and ML baselines)	Valid Accounts (T1078) abuse, unusual data volumes, new access paths, rare tools per user	Attacks that match the baseline, slow drift, entities with no history	SOC content or platform team
Identity risk engines (IdP-native)	Sign-in anomalies, leaked credentials, token replay at the identity provider	Activity after sign-in in other systems	Identity team

See the Detection Engineering Guide for rule development and the Threat Hunting Guide for using UEBA output as hunt leads.

Data sources that make baselines possible

A model is only as good as its inputs. The LOTL guidance stresses centralised, tamper-resistant ("write once, read many") logging and longer retention, because short local logs roll over before a slow intrusion is noticed. For UEBA, prioritise sources that carry identity, action, object and context in each event.

Source	Key events and fields	Behaviours it supports
Identity provider sign-in logs (Entra ID, Okta, Google Workspace)	User or service principal, IP, ASN, device, client app, MFA result, conditional access result	Impossible travel, new location or device, MFA fatigue (T1621), password spraying (T1110.003)
Active Directory domain controllers	4624/4625 logons with logon type, 4768/4769 Kerberos tickets, 4728/4732/4756 group changes	Admin accounts on unusual hosts, Kerberoasting (T1558.003), privilege changes
Endpoint telemetry (EDR, Sysmon)	Process creation with command line and parent, network connections, user context	Rare tools for a user, Office spawning scripting engines, admin commands by standard users
Cloud control plane (CloudTrail, Azure Activity, Google Cloud Audit Logs)	API name, caller identity, source IP, user agent, resource	New API families for an identity, credential creation (T1098.001), logging changes
SaaS and data platform audit logs	File access, downloads, sharing, query and export events	Bulk collection from repositories (T1213) or cloud storage (T1530)
HR and directory context	Department, manager, role, location, start and leave dates, account owner	Peer groups, leaver and notice-period risk, ownership of service accounts
Network (proxy, DNS, NetFlow)	Destination, bytes out, protocol, raw IP connections without DNS	Exfiltration volume, new external destinations, unusual internal paths

Identity resolution comes first: the same person may appear as a UPN, a SAM account name, an email address, an AWS role session name and a SaaS user ID. If the platform cannot join them into one entity, each fragment gets its own thin baseline and cross-system patterns disappear. Microsoft's IdentityInfo table, built from Entra ID and optionally on-premises AD, is one example of a resolved identity profile that analytics join against. See the SIEM Guide for log onboarding and the Cloud Logging and Audit Trail Guide for cloud sources.

Baselining human users

A user baseline is a set of distributions, not a single profile. Useful dimensions are:

Time: typical working hours and days, adjusted for time zone, shift patterns and planned leave. The LOTL guidance lists access that conflicts with work schedules or leave as an anomaly worth reviewing.
Place and device: countries, ASNs, managed versus unmanaged devices, client applications. Concurrent sign-ins from distant locations ("impossible travel") are the classic case.
Access paths: which hosts, applications and file shares a user normally touches. SMB access to servers unrelated to a user's role, or a workstation querying a backend database directly, are examples the joint guidance gives.
Volume: records read, files downloaded, bytes sent, mailbox items accessed. NIST SP 800-207 uses the example of an HR user suddenly accessing far more records than usual.
Tools and commands: processes and command lines per user. A standard business user running administrative commands is a deviation; for privileged users, the guidance suggests documenting which tools they use, which commands they run, when and from which devices.

Models typically combine "first seen" rarity with time series analysis; Microsoft's InvestigationPriority score (0 to 10), for example, combines an entity rarity score with a time series score such as a spike in failed sign-ins. Ask any vendor how long the learning period is and how new accounts are treated.

D3FEND catalogues these analytics under User Behavior Analysis (D3-UBA), with child techniques that make good design checklists: Authentication Event Thresholding (D3-ANET), Authorization Event Thresholding (D3-AZET), Job Function Access Pattern Analysis (D3-JFAPA), Resource Access Pattern Analysis (D3-RAPA), Session Duration Analysis (D3-SDA), User Data Transfer Analysis (D3-UDTA), User Geolocation Logon Pattern Analysis (D3-UGLPA) and Web Session Activity Analysis (D3-WSAA). See the MITRE D3FEND Guide.

Baselining service accounts and workload identities

Service accounts, managed identities, IAM roles, service principals and API keys outnumber people in most estates, and they are attractive because they are often over-privileged, rarely have MFA and are watched by nobody. The good news is that their behaviour should be narrow. The joint LOTL guidance says to define expected behaviour for automated tools and service accounts so their use is bounded by time of day, source and destination hosts, and account, and to investigate deviations. That converts a vague anomaly problem into an explicit allow model.

Dimension	Expected for a well-run service account	Deviation to score highly
Logon type	Service or batch logon (Windows logon types 5 and 4), non-interactive sign-in, workload federation	Interactive or Remote Desktop logon (types 2 and 10), sign-in through a browser
Source	A fixed set of hosts, subnets, clusters or CI runners	New IP or ASN, residential or VPN ranges, a workstation
Destination and API set	The same few resources and API calls every run	New API families (identity, logging, key management), enumeration calls
Schedule	Fixed cadence tied to a job or deployment window	Activity outside job windows, bursts with no deployment
Credential use	One credential type and client	New secret or certificate added, new user agent, token used from two places
Data volume	Stable per run	Bulk reads or exports well above historical runs

Platform features already exist for this. Microsoft Entra ID Protection offers workload identity risk detections including Suspicious Sign-ins (it learns a service principal's normal sign-in properties over 2 to 60 days and flags new IPs, ASNs, target resources, user agents or credential types), Anomalous service principal activity and Suspicious API Traffic. Note the documented limits: the detections are offline, full detail and risk-based Conditional Access need the Workload Identities Premium licence, and managed identities are not currently in scope. Amazon GuardDuty raises AnomalousBehavior findings for IAM identities, such as CredentialAccess:IAMUser/AnomalousBehavior and Persistence:IAMUser/AnomalousBehavior, when API calls are unusual for the calling identity. MITRE ATT&CK's detection strategy for Valid Accounts (DET0560) includes a Linux analytic for service account anomalies and a container analytic for Kubernetes service accounts used from unexpected nodes or IPs.

Ownership is the prerequisite: an alert on a service account is only actionable if someone knows what it is supposed to do. Tie every baselined account to an owner and a documented purpose from your inventory. See the Service Account Security Guide, and the Service Account Inventory Template. AI agents behave less predictably than scripted workloads and need different techniques; see the AI Agent Behaviour Baselining and Anomaly Detection Guide.

Peer groups

An individual baseline cannot judge a new joiner, a contractor on day three or an account that logs in twice a year. Peer groups fill that gap by comparing an entity with others who should behave similarly. Microsoft's UserPeerAnalytics, for example, ranks up to 20 peers per user from security group membership, mailing lists and similar associations, weighting smaller groups more heavily (a TF-IDF approach), so membership of a ten-person finance team says more than membership of "All staff".

Sources for peer groups: HR department and job code, manager hierarchy, directory group membership, application entitlements and, for workloads, the application, environment (production, test) and deployment pipeline.
Static versus dynamic: HR-defined groups are explainable but go stale after reorganisations; behaviour-derived clusters adapt but are harder to explain to an investigator. Many teams use HR groups for reporting and dynamic groups for scoring.
Size matters: groups that are too small (one or two members) make every action rare; groups that are too broad hide outliers. Review distribution of group sizes before go-live.
Service accounts need their own peers: comparing a backup account with human administrators produces nonsense. Group workloads by function and platform.

Risk scoring and alerting

UEBA platforms usually produce two layers: individual anomalies (each scored, for example Microsoft's 0 to 1 AnomalyScore) and an entity-level risk that accumulates anomalies over a window. NIST SP 800-207's distinction between criteria-based and score-based trust algorithms is a useful frame: a score-based design weights many signals and compares the total with a threshold, which is flexible but must be calibrated.

Scoring element	Good practice
Anomaly weight	Weight by asset and privilege: the same rarity on a Tier 0 admin or a production deployment role scores higher than on a kiosk user
Accumulation window	Sum over hours to days so a chain of small deviations (new country, then new tool, then bulk download) surfaces as one entity
Decay	Let scores decay so a one-off event does not keep an entity on the board for weeks
Context boosts	Add weight for leaked-credential matches, threat intelligence hits, notice period or recent privilege change
Explainability	Every alert lists the anomalies, the baseline it was compared with and the peer group used
Output	Route high entity scores to triage, feed medium scores to hunting and conditional access, keep low scores as context only

Risk can also drive access decisions: identity providers can step up or block risky sign-ins, and Entra ID Conditional Access can block at-risk single-tenant service principals. Automated response needs a tested exception path for critical workloads.

Managing false positives

The LOTL guidance warns that untuned detection tools can produce an unmanageable level of alerts, and UEBA is especially prone to this because "unusual" is not "malicious". The fixes are mostly operational:

Label routine automation: the guidance specifically recommends categorising routine automated activity, such as service accounts and vulnerability scanners, so it does not overwhelm analysts. Tag scanners, backup jobs, EDR agents and SOAR identities as known entities with their own expectations.
Feed change context in: deployments, migrations, travel bookings and organisational changes explain many anomalies. Microsoft notes that sign-ins after an authorised configuration change can trigger its service principal detection.
Prefer scoped suppressions: suppress a specific anomaly for a specific entity and time period, never a whole model. The joint guidance cautions against overly broad rules and exclusions.
Reduce the noise at source: fewer admin tools, fewer remote access tools and fewer permitted logon types make baselines tighter. The guidance encourages working with IT to restrict them.
Close the loop: record a disposition (true positive, benign true positive, false positive) for every UEBA alert and review the top false-positive models each month.

How to implement UEBA in phases

Define use cases first: pick five to eight scenarios tied to ATT&CK, for example compromised cloud account (T1078.004), service account used interactively, bulk download before leaving, new admin tool on a server, and new credential added to an application (T1098.001).
Onboard and resolve data: connect identity provider, directory, endpoint and cloud audit logs; join identities; import HR attributes and service account ownership. Confirm retention covers at least the learning period plus investigation look-back.
Learn in silent mode: let models train without alerting for the vendor's stated learning period (ask what it is). Review anomaly volumes per model and per entity type.
Pilot with a small population: start with privileged users and a ring of production service accounts. Analysts review every alert and record dispositions.
Test with known activity: use a purple team or controlled exercise to replay scenarios, such as a service account logging in interactively from a workstation or a test user downloading unusual volumes, and confirm the expected anomalies fire. See the Purple Teaming Guide.
Tune and widen: adjust peer groups, weights and suppressions, then extend to all users and workloads in rings.
Connect response: route high scores to triage playbooks and, once stable, to conditional access or session revocation. Keep a documented rollback: switch a model or automated action back to monitor-only if false positives spike or a critical workload is blocked.

Decision guidance: build, buy or use what you have

Small organisations: start with native analytics you already license (identity provider risk, cloud threat detection) plus a few explicit service account rules, rather than a full UEBA platform.
Mid-sized organisations: SIEM-bundled UEBA gives cross-source correlation; the real cost is analyst time for tuning and peer group upkeep.
Large or regulated organisations: combine SIEM UEBA, identity-native risk and custom models for crown-jewel systems, and fund identity resolution and a service account inventory first.
Rules versus models: if the expected behaviour can be written down (most service accounts), write a rule. Use statistical models where behaviour legitimately varies (people, administrators, data access).
Black-box scoring: if analysts cannot see why an entity scored high, they stop trusting it. Explainability is a selection criterion, not a nice-to-have. See the SIEM Buyer's Guide and ITDR Buyer's Guide.

Detection and measurement

Monitor the health of the UEBA pipeline as well as its output: connector lag, the share of events with a resolved identity, model training status and the number of entities with no baseline. Then track:

Coverage: percentage of privileged users and of inventoried service accounts with an active baseline and a named owner.
Precision: share of UEBA alerts closed as true positive or benign true positive, by model.
Analyst load: UEBA alerts per analyst per shift and median triage time.
Detection of exercises: percentage of purple team valid-account scenarios detected, and time from activity to alert.
Contribution: number of confirmed incidents where UEBA produced the first or a key signal.
Freshness: age of HR and peer group data, and number of service accounts without a current owner.

Where it maps in frameworks

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	AC-2(12) Account Monitoring for Atypical Usage	Directly requires monitoring accounts for atypical use and reporting it
NIST SP 800-53 Rev. 5	AU-6(3) Correlate Audit Record Repositories; AU-6(5) Integrated Analysis of Audit Records	Cross-source correlation that UEBA depends on
NIST SP 800-53 Rev. 5	SI-4 System Monitoring; SI-4(2) Automated Tools and Mechanisms for Real-time Analysis; IR-4(13) Behavior Analysis	Automated monitoring and behaviour analysis in incident handling
NIST CSF 2.0	DE.CM-03; DE.AE-02; DE.AE-03; DE.AE-07	Monitoring personnel activity and technology usage, analysing and correlating events, adding threat intelligence and context
MITRE ATT&CK v20	T1078 Valid Accounts (T1078.002, T1078.003, T1078.004); T1098.001; T1213; T1530	Behaviours UEBA is best placed to detect
MITRE D3FEND	D3-UBA User Behavior Analysis and its child techniques	Defensive technique taxonomy for UEBA analytics
ISO/IEC 27001:2022 Annex A	A.8.16 Monitoring activities	Requires monitoring networks, systems and applications for anomalous behaviour

Common failure patterns

Only people are modelled. Service accounts and integrations are excluded "because they are noisy", which leaves the most predictable and most over-privileged identities unwatched. The Okta support system breach used a support service account whose credentials had been saved in an employee's personal browser profile; activity from such an account outside its normal sources is exactly what a service account baseline should flag.
Logins are judged, actions are not. Some deployments score only authentication. In the Snowflake customer breaches attackers signed in with stolen credentials and then ran ordinary-looking queries from commercial VPN addresses and unfamiliar client tools before copying whole tables out; the lesson the case teaches is to baseline client tools, sources and data volumes, not just sign-in success.
Stale peer groups. After a reorganisation, whole departments become "anomalous" and analysts learn to ignore the model.
Global suppressions. One noisy week leads to a model being disabled or a broad exclusion that attackers can hide inside.
Retention shorter than the threat. Baselines learned on 30 days of data cannot see a dormant account's annual pattern, and investigations cannot look back far enough.

Practitioner checklist

Write five to eight UEBA use cases mapped to ATT&CK techniques and agree who triages each.
Onboard identity provider, directory, endpoint and cloud audit logs, and confirm identities resolve across them.
Import HR attributes and service account ownership; schedule refreshes and alert on stale data.
Define explicit expected behaviour (hosts, schedule, logon type, APIs) for every privileged service account and workload identity.
Enable native workload identity and cloud identity anomaly detections you already license, and note their documented gaps.
Run models in silent mode, then pilot on privileged users and a ring of service accounts with full disposition tracking.
Validate detections with controlled purple team scenarios before enabling automated response.
Use entity-scoped, time-limited suppressions only, and review the top false-positive models monthly.
Report coverage, precision, analyst load and exercise detection rates to SOC leadership each quarter.

UEBA Guide: Behaviour Baselines for Users and Service Accounts