What should teams do when a device is highly active but may still be legitimate?

Why This Matters for Security Teams

Highly active devices are a common source of false positives because legitimate automation, privileged administration, and power-user workflows can resemble compromise. Security teams that jump straight to blocking often create operational disruption, push users to bypass controls, and lose visibility into the behaviour they were trying to investigate. A better approach is to treat activity as a risk signal and escalate response gradually, consistent with control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls.

The real issue is not volume alone, but whether the device is acting within an expected context. Time of day, source network, identity strength, task type, and recent behavioural change all matter. If those signals are ignored, teams can end up throttling the wrong endpoint while the actual misuse continues elsewhere. In practice, many security teams encounter legitimate high activity only after service desks are flooded or critical workflows have already been interrupted, rather than through intentional risk-based policy design.

How It Works in Practice

Progressive friction works best when it is built as a sequence of response states rather than a single binary decision. The device first remains observable, then faces tighter scrutiny, and only later encounters restrictions on sensitive actions. This approach aligns with modern detection and response thinking because it preserves evidence, reduces unnecessary disruption, and gives analysts time to confirm whether the pattern is benign or malicious. Guidance from the CISA Zero Trust Architecture guidance is helpful here because trust is continuously evaluated instead of assumed.

In operational terms, teams usually define thresholds around behaviour rather than raw counts alone. A high activity event may trigger:

• increased logging and alert enrichment so investigators can see what changed and when
• step-up authentication for sensitive systems, administrative portals, or unusual transaction paths
• temporary limits on high-value actions such as bulk export, privilege changes, or token issuance
• human review before full access restoration if the behaviour remains anomalous

That sequence is most effective when paired with identity signals, device posture, and workload context. For example, a build server, an automation account, and a developer laptop can all be highly active for completely different reasons, so the policy should evaluate whether the activity matches the expected role. When teams use identity-aware telemetry, they can distinguish a burst caused by a release window from a burst caused by credential abuse or tool chaining. The common mistake is to treat every spike as an incident and every allowance as a blind spot. These controls tend to break down in environments with shared admin jump hosts and weak asset ownership because attribution becomes too ambiguous to support precise escalation.

Common Variations and Edge Cases

Tighter friction often increases user disruption and analyst workload, requiring organisations to balance stronger containment against operational continuity. That tradeoff is especially sharp for engineering teams, managed service providers, and SOCs handling legitimate automation at scale. Best practice is evolving, and there is no universal standard for exactly when a device should move from monitoring to restriction.

Some environments can support very fine-grained responses, while others need simpler rules. A mature identity stack may allow policy decisions based on role, device trust, workload sensitivity, and session history. By contrast, smaller environments may only be able to distinguish between known-good, needs-review, and block. The important point is consistency: the same activity pattern should produce the same escalation path unless context clearly changes.

For AI-driven or agentic workflows, the boundary is even less settled. An autonomous agent may generate high request volume while still acting legitimately, so teams should validate provenance, purpose, and guardrails before assuming abuse. Current guidance suggests treating these cases as policy exceptions with explicit ownership, rather than relying on ad hoc analyst judgment. NIST AI Risk Management Framework and OWASP guidance for LLM applications both reinforce the need for traceability, bounded autonomy, and output validation. Where shared credentials, unmanaged service accounts, or opaque automation are common, progressive friction becomes harder to tune and often reverts to coarse blocking.

Related resources from NHI Mgmt Group

• How do security teams know if cached code exposure is still active?
• How should security teams respond when a stolen laptop still has active cloud sessions?
• How do security teams know if unmanaged access is still active?
• How do security teams know whether SharePoint compromise is still active after patching?