Solution — Peer group analytics
Peer group analytics that catches what per-entity baselines silently allow
Dynamic peer clusters built from HRIS role, access-graph proximity, and behavioural similarity — so a user or service account is measured against the crowd it belongs to, not just its own drifting history.
24h
Peer groups recomputed as joiners, movers, and leavers reshape the org
4 signals
Role, org unit, access-graph proximity, temporal-behavior similarity
P95+
Divergence threshold surfaces the tail without drowning the queue
Day 1
New joiners inherit a peer-group baseline instead of waiting for one
Compare identities to their peers, not just to themselves
A per-entity baseline can only tell you if something is unusual for this account. Peer-group analytics tells you if something is unusual for accounts like this account — which is the question you actually needed to ask.
Dynamic peer clustering
Peers are derived continuously from HRIS role, org unit, manager chain, AD/Okta group membership, access-graph proximity, and observed application usage — not from a static list an admin has to maintain.
Access-graph proximity
Two identities become peers when they touch the same repos, S3 prefixes, SaaS objects, and production hosts. The graph is rebuilt nightly so joiners, movers, and leavers reshape peer groups without manual re-tagging.
Temporal-behavior similarity
Session cadence, working-hours envelope, geographic pattern, and command-verb mix are embedded per identity. Cosine-similar identities form a behavior peer group that catches deviations a role-only cluster would miss.
Deviation scoring against the group
Each event is scored against the peer distribution — not the individual's own history. An action common for the identity but unheard of in its peer group surfaces as a signal instead of being smoothed away by personal baseline drift.
Explainable peer context on every alert
Every detection carries the peer set that was used, the metric that diverged, and the percentile the entity landed on. Analysts see why the signal fired, not just a black-box anomaly score.
Feeds the SOC alert queue directly
Peer-group signals land in the same triage queue as rule-based detections, with severity derived from the divergence magnitude and the sensitivity of the resource touched. Suppression, tuning, and case linkage work identically.
Per-entity baselines vs peer-group analytics
| Per-entity baseline only | Peer-group analytics |
|---|---|
| Per-entity baseline learns whatever the user has done before | Peer-group baseline learns what similar users do, catching first-time-but-suspicious actions |
| Static peer lists maintained by IAM administrators drift immediately | Peer groups recomputed from HRIS, IdP, and access-graph signals every 24 hours |
| Insider slowly expanding access looks normal to their own baseline | The same expansion looks anomalous relative to same-role, same-tenure peers |
| Anomaly scores are opaque — analysts cannot defend them in review | Every score ships with the peer set, the diverging metric, and the percentile |
| New joiners have no baseline for weeks and generate false positives | New joiners inherit the peer-group baseline on day one |
| One-off admin action from a rarely-active account is invisible | Rare-account activity is compared to the admin peer group, not to itself |
Example detections a peer group surfaces
- Engineer pulls a repo their squad peers have never cloned
- Support-tier account runs a privileged action no other support tier runs
- Service account command-verb mix drifts away from same-class services
- Off-hours SaaS activity from an identity whose peer group is tightly 9-to-5
- Elevated privilege use in a role whose peers never elevate
- First-week joiner activity outside the onboarding cohort envelope
- Admin executes an operation no other admin has ever executed
- Contractor identity accessing systems outside their engagement scope peers
Peer group analytics — buyer questions
What is peer-group analytics in UEBA?
Peer-group analytics is a User and Entity Behavior Analytics (UEBA) technique that compares an identity or asset to a dynamically-clustered group of similar entities — same role, same department, same access patterns — instead of comparing it only to its own historical baseline. It catches deviations that per-entity baselines miss, such as a user accessing files that peers in the same role never touch, or an admin account performing an operation that no other admin has ever run.
Why isn't a per-entity baseline enough?
Per-entity baselines learn whatever the entity has done in the observation window, which means a slowly-scoping insider, a compromised service account with irregular usage, or a new joiner with no history all evade detection. Peer-group analytics answers a different question: given what identities like this one do, is this action normal? That question surfaces first-time-but-suspicious behavior that a self-referential baseline literally cannot see.
How does ManySignal decide who is a peer?
ManySignal builds peer groups from four sources composed together: HRIS and IdP structure (role, org unit, manager chain, AD/Okta group membership), access-graph proximity (which repositories, buckets, SaaS objects, and hosts the identities actually touch), temporal-behavior similarity (session cadence, working hours, geographic pattern, command-verb mix), and observed application usage. Peer sets are recomputed on a 24-hour cadence so joiners, movers, and leavers reshape the groups without a human curating a list.
What kinds of detections does peer-group analytics produce?
Typical detections include: an engineer pulling from a repository their team peers have never touched, a support-tier account performing a privileged action that no other support-tier account has ever performed, off-hours SaaS activity from an identity whose peer group has a tight 9-to-5 envelope, and a service account whose command mix has quietly drifted away from other service accounts of the same class. The signals are strongest exactly where signature-based rules and per-entity baselines are weakest.
How do peer-group signals plug into the SOC alert queue?
Peer-group detections enter the same triage queue as signature and correlation rules. Severity is derived from the magnitude of divergence and the sensitivity of the resource touched. Each alert carries the peer set that produced it, the specific metric that diverged, and the percentile the entity landed on — so an analyst or the AI triage agent can review the finding with full context, apply suppression, or promote it to a case identically to any other detection.
See peer-group analytics against your own data
Bring a week of IdP, EDR, and SaaS audit logs. We will show you the peer groups ManySignal derives and the detections a per-entity baseline was quietly missing.