Because the same activity can be normal for one entity and suspicious for another. A workstation that rarely contacts a destination should be judged differently from a monitoring server that does it constantly, and a process common on one host may be a first sighting on another. Entity-relative scoring preserves context that fleet-wide thresholds erase.
Why fleet-wide thresholds miss entity context
detection engineering works best when it measures behaviour against the right peer group. A single threshold across all entities assumes that users, hosts, services, and workloads behave alike, but they do not. Entity-specific baselines preserve the local pattern of activity that tells an analyst whether an event is ordinary, unusual, or likely worth escalation. That reduces noisy alerts without removing the context needed to spot genuine deviations. In practice, many security teams discover the value of this approach only after fleet-wide logic has already produced repeated false positives on entities with naturally different behaviour.
Entity baselining also aligns with the way modern environments are actually structured: monitoring servers, build systems, jump hosts, and user endpoints each have different norms, and those norms can change over time. A broad control framework such as the NIST Cybersecurity Framework 2.0 is useful for governance and continuous improvement, but the detection engineer still needs entity-level context to make alerts operationally meaningful.
How entity-specific baselines change the signal
An entity-specific baseline compares an event to historical behaviour for the same host, user, workload, application, or account rather than to the whole estate. That shifts detection from “does this activity exist anywhere?” to “is this activity normal for this entity?” The practical effect is fewer alerts on entities whose roles naturally create exceptions, and better sensitivity where deviations really matter.
The method is especially useful when the environment contains stable patterns that differ by role. A database server may legitimately connect to a narrow set of peers at high frequency, while a user laptop may not. A service account may run the same script on a schedule, while the same script from an interactive account may be unusual. Baselines therefore help distinguish expected repetition from anomalous novelty.
- Use entity type and function to define the comparison group before setting thresholds.
- Prefer relative change, rarity, and deviation from history over one-size-fits-all counts.
- Weight first-seen combinations differently from long-established behaviour.
- Rebuild or age baselines when roles, tooling, or infrastructure change materially.
Good engineering also means recognizing where the signal is weak. If the baseline window is too short, the model learns noise. If it is too broad, it erases the very differences you were trying to preserve. The same is true when entities are grouped too aggressively. The more heterogeneous the group, the more false positives you will keep. For identity-heavy environments, the NIST SP 800-63 Digital Identity Guidelines are relevant when entity trust and assurance are part of the detection context, but the detection rule still has to respect the entity’s actual operating pattern. The guidance breaks down when baselines are used as a substitute for ownership, scoping, or review logic rather than as a contextual signal.
Where entity baselines help most, and where they need guardrails
Tighter baselines usually reduce noise, but they also increase maintenance overhead, so organisations have to balance precision against operational cost. The best results usually come from entities with stable roles and clear behavioural boundaries. Shared infrastructure, ephemeral workloads, and heavily automated platforms are harder to baseline because their “normal” shifts quickly or differs by phase.
There is also a genuine trade-off between sensitivity and specificity. An overly strict per-entity model may suppress unusual but important activity if the baseline becomes too narrow. An overly loose model may behave little better than a fleet-wide rule. The practical answer is to use entity-specific baselines as one layer in a detection stack, not as a standalone truth source.
Guidance-vs-consensus matters here: there is broad agreement that contextual baselining reduces false positives, but there is no single standard for the best entity granularity, window length, or deviation score. Those choices depend on asset criticality, data quality, and how much behavioural drift the team can tolerate. Detection logic should be tested against known role differences, and alert reviewers should be able to explain why a baseline exists for that entity at all.
Once a team cannot reliably define the entity, the behaviour, or the expected drift, the baseline becomes too weak to trust and should be treated as advisory rather than authoritative.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.AE-1 — Anomalies and Events | Entity baselines improve anomaly detection by defining what is unusual for a specific asset or user. |
| DE.CM-1 — Monitoring for Unauthorized Activities | Baseline-driven detection supports continuous monitoring without over-alerting on expected variation. | |
| Recommendation — Tune anomaly logic to entity context so unusual behaviour stands out against a relevant peer history. Align monitoring thresholds to entity behaviour so recurring legitimate activity does not trigger needless alerts. | ||
| CIS Controls v8 | 8 — Audit Log Management | Log analysis relies on contextual thresholds to separate expected entity behaviour from suspicious deviation. |
| Recommendation — Use contextual log baselines to reduce alert noise and focus review on meaningful deviations. | ||
| MITRE ATT&CK | T1036 — Masquerading | Entity-relative baselines help spot abnormal process or activity patterns that hide in ordinary-looking behaviour. |
| Recommendation — Map entity-specific deviations to ATT&CK techniques and investigate first-seen or out-of-pattern activity. | ||
Practitioner Guidance
What to prioritise: Start with entities whose role is stable and whose false positives are most expensive to investigate, such as critical servers, service accounts, and high-value user groups. Those are the places where contextual baselines usually create the clearest operational win.
What to verify: Confirm that the entity really is comparable to its historical self. If the host is repurposed, the user changes teams, or the workload changes release cadence, the baseline should be reset or re-scoped rather than silently retained.
Common mistake: Teams often treat a baseline as a permanent truth instead of a living reference. That creates either alert fatigue, when the model is too broad, or blind spots, when it is too narrow and stale.
What practitioners underestimate: The biggest value is not just fewer alerts. It is better explanation quality, because analysts can ask why this entity behaved differently instead of arguing with a threshold that never understood the entity in the first place.
Practitioner takeaway: Entity-specific baselines work when they encode real operational context, not when they merely localise a noisy threshold. If the entity boundary is weak, the baseline will be weak too.
Related resources from NHI Mgmt Group
- How do organisations reduce false positives in secret detection pipelines?
- How should teams reduce false positives in identity detection without missing real attacks?
- How should IAM teams reduce false positives in identity detection?
- How should security teams reduce false positives in cloud detection workflows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
