Should organisations prioritise identity baselines or new detection rules first?

Why baselines should usually come before new detections

Identity baselines give you the reference point that makes alerting meaningful. In an immature environment, account geography, service-account behaviour, privilege shape, and normal authentication patterns are still moving, so rules built too early tend to encode noise. A baseline does not replace detections, it makes them operable by reducing false positives and exposing which deviations are actually worth a human’s time.

That matters most when organisations are still discovering what they have: dormant accounts, overprivileged service identities, shared credentials, and inconsistent environment boundaries. Without that context, a “good” detection often ends up firing on expected admin activity or legacy automation. Once the baseline is established, the same rule can distinguish ordinary variance from true drift.

A practical way to think about it is that baselines answer “what is normal here?” while detections answer “what changed that should worry us?” If the first question is unresolved, the second one becomes expensive to operate. This is why identity teams often see better signal from baselining lifecycle and usage patterns before they expand rule coverage.

What an identity baseline has to capture to be useful

Useful baselines are not abstract. They should cover the identity properties that most often drive alert quality: where accounts exist, who or what owns them, how often they authenticate, which roles they actually use, whether they are human or non-human, and what normal service-account behaviour looks like across environments. If those elements are missing, the baseline is too thin to support trustworthy detections.

For non-human identities in particular, baseline quality depends on lifecycle visibility. Service accounts, workload identities, tokens, and related secrets often fail in predictable ways when they are long-lived, reused, or poorly scoped. The baseline should therefore include rotation cadence, offboarding status, privilege boundaries, and environment segregation, because those are the patterns that later detections will need to compare against. NHIMG’s NHI Lifecycle Management Guide is useful here because it frames lifecycle and visibility as the foundation for sane operations, not an afterthought.

Good baselines also help you separate environment-specific behaviour from true outliers. For example, a release pipeline, a database service account, and an interactive administrator may all authenticate from unusual locations for different reasons. A single generic detection rule will struggle to tell those apart. A baseline that records expected patterns per identity class gives later detections the context they need to stay specific.

How to sequence baselines and detections in practice

Start with the identities that create the most operational ambiguity: privileged accounts, service accounts, shared accounts, and externally exposed access paths. Baseline those first, because they are the identities most likely to produce noisy or expensive alerts if you guess too early. Then add detections only where the baseline gives you a clear threshold for abnormality, such as impossible geography, privilege expansion, stale access, or unexpected authentication method changes.

What to prioritise: focus on inventory, ownership, and normal usage before rule volume. The fastest win is not “more detections”, it is fewer ambiguous alerts tied to the identities that matter most. NHIMG’s Identity Threat Detection and Response Guide is a strong companion because it shows how detections become more valuable when they are tied to identity context and response behaviour.

What to verify: before trusting a new rule, verify that the identity baseline already explains normal sources, normal privilege use, and normal non-human activity. If you cannot describe the expected behaviour in one sentence, the rule is probably too early. That is especially true for service accounts and automation, where “unexpected” often just means “poorly documented.”

What good looks like: baseline first, then targeted detections that are easier to tune, easier to defend, and easier to hand to operations. The end state is not zero false positives, it is a control stack where alerts are explainable because the normal state is already known.

Practitioner Guidance

Decision rule: if the identity estate is still being discovered, build the baseline before adding new detections; if the baseline is already stable and the gap is specific, add the detection where it tests a known deviation. That sequencing prevents teams from mistaking signal volume for control maturity.

What to measure: track alert precision, tuning churn, and the share of detections that map to known identity classes. If most new alerts require manual context to interpret, the baseline is still too weak to support reliable detection engineering. A mature programme should spend less time explaining why an alert fired and more time deciding whether the deviation matters.

Common mistake: teams often ship detections first because they are visible, then try to backfill context later. That reverses the dependency. The result is usually brittle rules, noisy triage, and weak trust from operations.

Practitioner takeaway: when the environment is immature, baseline the identity reality first, then turn that baseline into detections that operators can trust. Detection without context is usually just expensive noise.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• When should identity teams prioritise context integration over new detection rules?
• Should organisations prioritise IGA or identity security first?
• Should organisations prioritise token rotation or behavioural detection first?