What breaks when organisations cannot tell whether activity in their environment is normal or anomalous?

Why normal-versus-anomalous judgment is the control that makes monitoring useful

The core issue is not simply whether telemetry exists, it is whether teams have a baseline that lets them decide what belongs in the environment and what does not. Without that reference point, alerting becomes noisy, triage becomes subjective, and “unusual” activity is easily dismissed as routine because nobody can prove otherwise.

That is why anomaly detection depends on more than tools. The control problem is defining expected users, systems, timing, volume, geographies, and sequences of action well enough that deviations are meaningful rather than just rare. Without that structure, the environment can still collect logs, but it cannot reliably interpret them.

Normality also changes over time, so the baseline must reflect current operational behaviour, not an old snapshot of the environment. A stale baseline can hide legitimate change, while an over-broad baseline can normalize risky access, misconfiguration, or automation abuse. The practical question is whether the organisation can tell the difference between legitimate drift and suspicious deviation.

What fails when baseline and context are missing

When the environment cannot distinguish expected activity from anomalous activity, several security functions degrade at once. Detection loses precision, investigation loses starting points, and response teams lose confidence in what to prioritise. That usually pushes organisations toward either alert fatigue or blind spots, both of which are operationally dangerous.

Context is especially important for access and authentication events. A login, token use, privileged action, or configuration change may be harmless in one workflow and high risk in another. If the organisation has not defined what “normal” looks like for those actions, then it cannot spot when an account is being abused, a process is misbehaving, or a control has been bypassed.

This also affects containment. If suspicious activity blends into ordinary operations, teams often wait too long to intervene because they lack a clear threshold for escalation. By the time the pattern is obvious, the activity may already have spread across more systems, more identities, or more business processes.

Why ambiguity turns into operational and security exposure

Ambiguous activity patterns create a false sense of stability. Systems may appear healthy because nothing is clearly out of place, yet the organisation is really just missing the signals that would separate harmless noise from harmful behaviour. That gap matters because many incidents begin as actions that look plausible until they are seen in sequence.

Normalisation can also become a governance problem. If nobody owns the definition of expected behaviour, thresholds drift, exceptions accumulate, and teams start accepting patterns they have never formally reviewed. Over time, that can turn a monitoring program into a record-keeping exercise rather than a detection capability.

For that reason, anomaly detection is most useful when it is tied to clear operational patterns and reviewed against real business change. NIST Cybersecurity Framework 2.0 is useful here because it frames detection as a function that depends on understanding assets, monitoring behaviour, and responding to deviations in a controlled way. Where activity can cross authentication boundaries, NIST SP 800-63 Digital Identity Guidelines helps practitioners think about how identity assertions and authenticator strength affect whether an event should be trusted.

In environments with API-heavy or service-to-service traffic, OWASP API Security Top 10 is a practical reminder that abnormal use can show up as broken authorization, unexpected resource consumption, or misuse of business flows even when the traffic itself looks technically valid.

Practitioner Guidance

What to prioritise: Define the few behaviours that matter most for detection first, such as privileged access, configuration changes, authentication anomalies, and unusual data movement. If every event is equally important, none of them is.

What to verify: Confirm that your baseline reflects current production behaviour, not last quarter’s assumptions. Review whether seasonal change, automation, admin tooling, and approved exception paths are already folded into the model so they do not get mistaken for normal risk.

Decision rule: If a behaviour is common but high impact, treat it as a monitored exception rather than as safe normality. If a behaviour is rare but expected, label it explicitly so analysts can separate it from genuinely suspicious deviation.

What good looks like: Analysts can explain why an event is normal, why it is unusual, or why it should be escalated without debating the baseline from scratch. The organisation can also show that detections are tuned to behaviour patterns that actually matter, not just to raw volume.

Practitioner takeaway: The objective is not to flag every deviation, it is to make the environment legible enough that unusual behaviour stands out early, is investigated consistently, and is not absorbed into routine operations.

Related resources from NHI Mgmt Group

• What breaks when an agent cannot tell whether it is in a live or simulated environment?
• What breaks when organisations cannot distinguish human from AI agent activity?
• How can organisations tell whether identity-driven attacks are already moving through their cloud environment?
• What breaks when organisations cannot see access activity across IT and OT?