Almost every SIEM, XDR, identity and insider risk product now claims behaviour analytics, so the hard part of buying UEBA is not finding it but telling real, tunable baselining apart from a few static rules with a risk score on top. User and entity behaviour analytics builds a profile of normal activity for people, service accounts, devices and applications, and flags meaningful deviations such as impossible travel, unusual data transfer or a service account used interactively. It is sold as a standalone product, as a module of a SIEM or XDR platform, or inside identity threat detection and insider risk tools. This vendor-neutral buyer's guide helps SOC leads, detection engineers and procurement define requirements, compare offerings on evidence and run a proof of concept. For how UEBA works, read the UEBA Guide first; this page assumes that background.
Key takeaways
- Start from your data, not the feature list. UEBA can only baseline what it ingests: identity provider, directory, endpoint, cloud, SaaS and data access logs decide what it can see.
- Non-human identities are the real test. Ask how the product baselines service accounts, workload identities, API keys and AI agents, which outnumber people and behave very differently.
- Demand explainability. An analyst must see which behaviours raised a score, against which baseline and peer group, or alerts will be ignored.
- Measure in your environment. Judge on detection of simulated scenarios and on false positive volume over at least 30 days of your own data, not on demos.
- Avoid paying twice. Check what your SIEM, XDR, identity provider or ITDR tool already does before buying a separate analytics layer.
Define requirements
- Use cases first: rank what you need to detect: compromised accounts (ATT&CK T1078 Valid Accounts), insider data theft, privilege misuse (T1098 Account Manipulation), cloud data access (T1530 Data from Cloud Storage), exfiltration (T1567 Exfiltration Over Web Service), or misuse of service accounts and tokens (T1550 Use Alternate Authentication Material).
- Entities in scope: employees, contractors, privileged administrators, service accounts, cloud workload identities, OAuth applications, AI agents, endpoints and hosts. See the Insider Threat and Identity Guide for insider use cases.
- Data sources: list the logs you have and their retention: directory and IdP sign-ins, VPN and ZTNA, endpoint telemetry, cloud control plane, SaaS audit, email, DLP and file access, HR joiner and leaver feeds.
- Deployment model: module of your existing SIEM or XDR, standalone platform, or capability inside ITDR or insider risk management. Decide whether data may leave your region.
- Operating model: who triages (SOC, insider risk team, IAM team) and what response actions are acceptable automatically.
- Privacy and works councils: behaviour monitoring of staff is personal data processing. Involve your data protection officer and employee representatives early; the UK ICO publishes guidance on monitoring workers.
Choosing a deployment model
| Model | Suits | Watch for |
|---|---|---|
| UEBA module of your SIEM or XDR | Teams that already centralise logs in that platform; smaller SOCs that want one console | Analytics limited to sources the platform ingests; licence uplift on data volume |
| Standalone UEBA platform | Large estates with several SIEMs or data lakes, or strong in-house detection engineering | Duplicate ingestion cost; another console; integration effort for response |
| Inside ITDR or insider risk tools | Organisations whose priority is identity attacks or insider data theft | Narrower entity and data coverage; overlap with SIEM detections |
Small organisations usually get most value from the analytics already in their SIEM, XDR or identity provider, tuned well. Large organisations with mature detection engineering, many non-human identities and regulated insider risk programmes are the main buyers of dedicated platforms.
Capability areas
| Area | What good looks like |
|---|---|
| Data ingestion and normalisation | Native parsers for your identity, endpoint, cloud and SaaS sources; entity resolution that links one person's accounts, devices and identities across systems |
| Baselining | Per-entity and peer-group baselines for logon geography and time, resource access, data transfer volume, session duration and authentication patterns (the behaviours MITRE D3FEND lists under User Behavior Analysis, D3-UBA) |
| Peer groups | Groups built from HR attributes, role and observed behaviour, with analysts able to see and correct the grouping |
| Non-human identity analytics | Separate models for service accounts and workload identities: fixed source hosts, API call patterns, interactive use of a non-interactive account, new token issuers. For agents, see the AI Agent Behaviour Baselining and Anomaly Detection Guide |
| Risk scoring | Scores that accumulate over a defined window, decay over time, weight asset and privilege criticality, and show the contributing events |
| Explainability | Plain description of each anomaly, the baseline it deviated from, and a timeline of the entity's activity |
| Tuning | Analyst feedback, suppression rules, allow-lists and model sensitivity controls without vendor professional services |
| Integration and response | Enrichment of SIEM incidents, cases in SOAR, actions such as session revocation, step-up or account disable through your IdP. See the SOAR and Security Automation Guide |
| Privacy controls | Pseudonymised views for analysts, role-based de-anonymisation with audit, retention limits per data type |
Evaluation criteria
Weights are illustrative; set them from your use cases before responses arrive.
| Criterion | Weight | Evidence to request |
|---|---|---|
| Detection of your priority scenarios | 25% | PoC results against simulated scenarios mapped to ATT&CK techniques |
| False positive volume and tuning effort | 20% | Alerts per day and analyst hours over the PoC period |
| Data source coverage | 15% | List of native connectors for your sources, with field-level parsing |
| Non-human identity coverage | 10% | Demonstrated baselines for your service accounts and workload identities |
| Explainability and investigation | 10% | Analyst walkthrough of three real alerts from your data |
| Integration and response | 10% | Working integration with your SIEM, SOAR and IdP |
| Privacy, security and residency | 5% | Data flow diagram, certifications, processing locations |
| Total cost | 5% | Pricing metric (users, entities, data volume) modelled for three years of growth |
The NIST SP 800-53 Rev. 5 controls behind these criteria are AC-2(12) Account Monitoring for Atypical Usage, SI-4 System Monitoring, AU-6 Audit Record Review, Analysis and Reporting and IR-4(13) Behavior Analysis; in NIST CSF 2.0, DE.CM-03 and DE.AE-03 (correlation from multiple sources). Ask bidders which of these they help evidence.
Questions to ask vendors
- Which of our data sources do you parse natively, and which need custom work? What happens to detections when a source stops sending?
- How long does baselining take before alerts are reliable, and how do you handle new joiners, movers and seasonal patterns?
- How do you model service accounts, cloud workload identities and AI agents differently from people?
- Show the evidence behind a risk score: which events, which baseline, which peer group.
- How can our analysts tune models, and how is a tuning change tested and audited?
- What response actions can you trigger, through which integrations, and with what approval controls?
- Where is our data processed and stored, how long is it retained, and how do you support pseudonymisation and worker privacy requirements?
- How is your own platform secured: tenant isolation, support staff access, signing of model and content updates?
- What is the pricing metric, and what does our cost look like if entity counts double because we add non-human identities?
Red flags
- "Machine learning" that turns out to be fixed thresholds with no per-entity baseline.
- Risk scores with no explanation of contributing events.
- No answer for non-human identities, or service accounts treated as noisy users and suppressed.
- Tuning only possible through vendor professional services.
- Detections that only work with the vendor's own endpoint or SIEM, unless that is already your platform.
- Pricing per entity that makes adding service accounts unaffordable, which pushes you to leave the riskiest identities out.
- No pseudonymisation or access audit for analysts viewing individual employee behaviour.
Proof of concept
- Agree three to five priority scenarios and success criteria before the PoC starts, including a false positive ceiling per day.
- Connect the same data sources for every bidder, with at least 30 days of history or live collection, and include identity provider, endpoint, cloud and one SaaS source.
- Include a population of service accounts and workload identities, not just people.
- Run safe, authorised simulations: a sign-in from a new country followed by mass file download, a service account used from a workstation, a new privileged role assignment, an unusual OAuth consent. See the Detection Engineering Guide for scenario design.
- Have your own analysts triage every alert raised and record time per alert, true and false positives, and whether the explanation was enough.
- Test response integration end to end: enrich a SIEM incident and revoke a session through the IdP.
- Review privacy controls with your DPO and model three-year cost, then score against the criteria table.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support across identity threat detection, IAM, PAM and NHI security. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: UEBA Guide · ITDR Buyer's Guide · SIEM Buyer's Guide · Insider Risk Management Buyer's Guide