A per-identity baseline is the normal behavioural profile for a specific user, service account, or application token. It is used to compare current activity against expected cadence, sequence, and volume so that anomalous access patterns can be detected with more precision than aggregate thresholds provide.
Expanded Definition
A per-identity baseline is a behaviour model anchored to one identity rather than to a population average. That identity may be a human user, a service account, a workload identity, an API token, or an application credential, provided the security team can consistently distinguish its normal cadence, sequence, source, and volume of activity. In identity-heavy environments, the baseline helps separate expected variation from meaningful deviation, especially where shared thresholds create too much noise or miss low-and-slow abuse.
Unlike static allowlists or simple anomaly thresholds, a per-identity baseline is comparative and context-aware. It is typically built from historical access patterns, resource use, timing, geolocation, device posture, and privilege scope, then continuously refined as legitimate behaviour changes. Its value is strongest where identities are dynamic, such as cloud workloads, privileged sessions, or automation pipelines, and where NHI governance matters because service identities can be overused, cloned, or silently repurposed. For security programmes that align to the NIST Cybersecurity Framework 2.0, the baseline supports detection and response by making unusual identity behaviour measurable rather than intuitive. The most common misapplication is treating a per-identity baseline as a one-time profile, which occurs when teams fail to retrain it after role changes, seasonal workflow shifts, or new automation paths.
Examples and Use Cases
Implementing per-identity baselines rigorously often introduces tuning overhead, requiring organisations to weigh better detection fidelity against model maintenance and review effort.
- A finance analyst normally accesses one ERP application during business hours, so a midnight burst of exports to a new host becomes a meaningful deviation.
- A service account usually calls a narrow API set from one orchestration cluster, so requests from a different region or a different sequence indicate possible credential misuse.
- A privileged admin logs in occasionally and performs a small set of change actions, so a sudden increase in failed logons or broad object enumeration stands out quickly.
- An application token is expected to perform short, machine-to-machine transactions, so persistent interactive-like access patterns suggest token replay or abuse.
- Security teams can compare identity telemetry against policy expectations and detection logic described in NIST-aligned monitoring practices, including the NIST Cybersecurity Framework 2.0, to improve alert relevance.
Why It Matters for Security Teams
Per-identity baselines matter because they reduce blind spots created by coarse thresholds. Aggregate rules may flag legitimate peak activity while missing targeted misuse that stays under the global line. A per-identity approach gives defenders a practical way to spot account takeover, insider misuse, credential stuffing against a single account, and compromised NHI behaviour that blends into normal machine traffic.
For identity and NHI teams, the concept also improves privilege governance. A service account with standing access may look harmless until its behaviour changes in ways that indicate lateral movement or automation abuse. That is why baseline-driven detection works best when paired with NIST Cybersecurity Framework 2.0 practices for continuous monitoring, access control, and incident response. The same logic is increasingly relevant for agentic AI systems that hold tool access, because their activity should be evaluated against the identity-specific tasks they are authorised to perform.
Organisations typically encounter the cost of weak baselines only after an identity is abused without triggering broad alerts, at which point per-identity baseline analysis becomes operationally unavoidable to reconstruct what changed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring uses detected anomalies to identify changes in identity behaviour. |
| OWASP Non-Human Identity Top 10 | NHI governance emphasizes knowing normal service identity behaviour to detect abuse. | |
| NIST SP 800-63 | AAL2 | Identity assurance informs how strongly an identity's activity can be trusted. |
| NIST Zero Trust (SP 800-207) | §3.2 | Zero trust continuously evaluates identity and session signals rather than assuming trust. |
Define and monitor expected NHI activity so abnormal token or service-account use is surfaced quickly.
