What breaks when organisations do not monitor non-user activity between applications?

Why This Matters for Security Teams

Non-user activity is where application-to-application trust becomes operational risk. When teams only watch human logins, they miss service accounts, API keys, automation tokens, and connectors that can move data or call privileged functions without ever touching a user session. That blind spot is a major reason NHI Mgmt Group found that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs. NIST control guidance also treats system interactions as first-class security objects, not background noise, because they shape access, auditability, and incident response. See NIST SP 800-53 Rev 5 Security and Privacy Controls for the control expectations around access enforcement and monitoring.

The practical consequence is that attackers can hide inside legitimate automation. A stale integration may keep working long after the owning team has changed, while an over-permissioned connector can be abused to pivot across environments. Monitoring non-user activity is therefore not only a detection problem but also a governance problem: it reveals where trust is being extended, where secrets persist too long, and where application behaviour no longer matches intended design. In practice, many security teams encounter the abuse of app-to-app trust only after lateral movement has already occurred, rather than through intentional monitoring of automation paths.

How It Works in Practice

Effective monitoring starts by treating each application, workload, and connector as an identity-bearing actor. Logs need to capture who or what initiated the request, which token or certificate was used, what API was called, what data was accessed, and whether the action matched the expected service-to-service pattern. That means correlating identity telemetry with network traces, secrets usage, and privileged access events so unusual non-user behaviour stands out quickly.

Current guidance suggests focusing on a few operational controls:

• Map every non-user identity to an owner, purpose, and expiry date.
• Track issuance and use of API keys, certificates, OAuth tokens, and service account credentials.
• Alert on new destinations, unusual call volume, privilege changes, and cross-environment access.
• Review automation paths after deployments, vendor changes, and incident response actions.
• Rotate or revoke credentials when usage no longer matches the declared workload.

This is where lifecycle discipline matters. The NHI Lifecycle Management Guide emphasises that visibility, rotation, and offboarding are continuous tasks, not one-time setup work. The same principle shows up in incident reporting: the Schneider Electric credentials breach illustrates how credential exposure can turn routine automation into a persistent access path when monitoring and revocation lag behind reality. Non-user activity should be baselined per application and reviewed against that baseline, not against human-user expectations. These controls tend to break down in highly dynamic CI/CD and multi-cloud environments because short-lived deployments, ephemeral containers, and third-party integrations constantly change the expected access pattern.

Common Variations and Edge Cases

Tighter monitoring of application activity often increases telemetry volume and operational overhead, requiring organisations to balance visibility against alert fatigue and engineering friction. That tradeoff is real, especially when systems generate large numbers of routine machine calls that look noisy at first glance.

There is no universal standard for this yet, but current guidance suggests prioritising the flows that can change trust most quickly: production APIs, administrative connectors, secrets stores, CI/CD pipelines, and third-party integrations. Some environments can rely on narrow audit logs, while others need full request context, including token subject, source workload, and downstream tool invocation. The right level depends on blast radius, regulatory exposure, and how easily a compromised integration can move laterally.

One common edge case is delegated automation. A scheduler, workflow engine, or RPA platform may legitimately act on behalf of many services, which makes simple allowlists too blunt. Another is shared service accounts, where multiple apps reuse the same identity and destroy attribution. Best practice is evolving toward per-workload identity, short-lived credentials, and policy decisions made at request time, because static trust models fail when application behaviour changes faster than security teams can review it. For teams formalising governance, the Top 10 NHI Issues is a useful reference for the failure patterns that usually surface first.

Related resources from NHI Mgmt Group

• What breaks when organisations do not monitor private collaboration channels for secret leakage?
• What breaks when organisations do not monitor identity abuse across both workforce and customer accounts?
• What breaks when organisations do not monitor access and audit activity for ePHI?
• What breaks when organisations monitor AI activity without correlating identity and threat context?