What do identity teams get wrong about unusual activity alerts?

Why This Matters for Security Teams

Unusual activity alerts are useful only when they help identity teams separate genuine risk from normal operational noise. A job that runs at an odd hour, rotates credentials after a deployment, or accesses a new resource after an approval can all look suspicious in isolation. The real mistake is to treat anomaly as a verdict, rather than a signal that needs identity context, recent change history, and business intent.

This matters more for non-human identities because service accounts, API keys, automation runners, and agentic workloads can generate highly variable patterns by design. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which means many alerting programs are built on incomplete identity inventory. When visibility is weak, anomaly tooling tends to overfit to volume and timing instead of ownership, purpose, and privilege boundaries. In practice, many security teams encounter meaningful alert fatigue only after a noisy deployment, a failed rotation, or a lateral movement event has already blended into normal operational churn.

How It Works in Practice

Effective alert triage starts with identity baselining, not pattern matching alone. The alert should be evaluated against what that identity is supposed to do, what changed recently, and whether the action was approved. For NHIs, that usually means correlating role, workload, token scope, secret age, source system, and execution context before escalating.

Current guidance from NIST SP 800-53 Rev. 5 emphasizes control over account activity, logging, and least privilege, but it does not turn every unusual event into a security incident. Identity teams should therefore combine policy, telemetry, and lifecycle state. For example, a credential used from a new region may be benign if it was just issued to a CI/CD runner, while a routine API call may be high risk if it comes from an identity that should have been decommissioned. NHI Mgmt Group’s Top 10 NHI Issues highlights how excessive privileges and weak rotation practices inflate the alert surface and make it harder to distinguish compromise from expected change.

• Validate ownership first: which team, pipeline, or agent is responsible for the identity.
• Check recent state changes: rotations, deployments, approvals, secret updates, or policy changes.
• Compare to expected scope: resource targets, time windows, and allowed source locations.
• Escalate only when the activity is both unusual and inconsistent with purpose or entitlement.

That approach reduces false positives while improving detection quality, because it focuses on whether the activity makes sense for the identity, not whether it merely looks different from yesterday’s traffic. These controls tend to break down when telemetry is fragmented across cloud, CI/CD, and SaaS environments because the alert lacks the full identity context needed for reliable triage.

Common Variations and Edge Cases

Tighter alert thresholds often increase analyst workload, requiring organisations to balance faster detection against operational noise. That tradeoff is especially sharp when automated systems are involved, because legitimate behaviour can shift rapidly and still be safe. Best practice is evolving, but current guidance suggests that identity teams should treat “unusual” as a prompt for contextual review, not as proof of compromise.

One common edge case is break-glass access. A highly unusual action may be entirely appropriate during an incident response window, yet still deserve review if the approval chain is weak or the session is not time-boxed. Another is lifecycle drift: an identity may appear anomalous simply because it was never formally offboarded. The same issue shows up in stale secrets and orphaned service accounts, which are frequently flagged only after damage has already occurred. The 52 NHI Breaches Analysis shows that compromised non-human identities often blend into normal operations until the underlying governance gap is exposed.

For mature programs, the goal is to tune alerts to identity posture, not just behaviour. That means using approvals, secret age, access scope, and workload ownership to decide whether an alert is actionable. Where agents, automation, or third-party integrations are involved, anomaly-only detection is especially fragile because behaviour changes with the task and the environment.

Related resources from NHI Mgmt Group

• What do security teams get wrong about authentication controls and trust?
• What do security teams get wrong about workload identity in cloud and CI/CD environments?
• What do security teams get wrong about MFA in identity attacks?
• What do security teams get wrong about Zero Trust and identity governance?