What breaks when application behaviour is not baselined and monitored continuously?

Without baseline visibility, defenders struggle to tell normal service-to-service activity from malicious change. That creates blind spots for insider misuse, abnormal logins, data exfiltration, and attacks that hide inside distributed microservices. In practice, teams react later, investigate with less context, and miss the runtime signals that reveal exploitation before it spreads.

Why This Matters for Security Teams

When application behaviour is not baselined, defenders lose the reference point needed to separate expected service-to-service chatter from suspicious change. That matters because microservices, API-driven workflows, and NHI-driven automation can look normal right up until they are not. Without continuous monitoring, teams miss abnormal token use, unusual east-west movement, and exfiltration patterns that only become obvious in hindsight.

This is why NHI governance and runtime visibility belong together. The NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which makes baselining more than a nice-to-have. If security teams cannot see which identities, services, and secret use patterns are normal, they cannot reliably detect what is wrong. That gap also weakens alignment with the NIST Cybersecurity Framework 2.0, which expects continuous monitoring as part of effective risk management. In practice, many security teams encounter compromise only after logs are incomplete, alerts are late, and the application has already spread the impact across dependent services.

How It Works in Practice

Effective baselining starts by defining what normal looks like for each application, not for the enterprise as a whole. A payment service, for example, may normally call three internal APIs, use one workload identity, and exchange short-lived secrets on a fixed schedule. Baselines should capture identity, request rate, token issuance, data volume, destination, geolocation where relevant, and timing. They also need periodic recalibration as releases, seasonality, and architecture change.

Continuous monitoring then compares live behaviour against that baseline in near real time. The strongest programs combine application telemetry, identity telemetry, and secret events so that defenders can see when a workload changes its access pattern, touches a new resource, or starts calling tools it never used before. This is where NHI-specific guidance matters. The Top 10 NHI Issues highlights the operational risk of weak visibility, while NIST Cybersecurity Framework 2.0 reinforces detection and response as an ongoing discipline rather than a periodic audit.

• Baseline by workload identity, not by application name alone.
• Track service-to-service trust paths and alert on new peers.
• Correlate secret use, token creation, and data access in one timeline.
• Distinguish expected deployment churn from risky runtime drift.
• Relearn baselines after major releases, not only after incidents.

Teams get the best results when baselines are paired with automated detections for privilege escalation, anomalous access frequency, and unusual data movement. These controls tend to break down in highly elastic environments with frequent autoscaling and unmanaged service accounts because the signal changes faster than static thresholds can keep up.

Common Variations and Edge Cases

Tighter monitoring often increases noise and operational overhead, requiring organisations to balance detection quality against alert fatigue and engineering effort. There is no universal standard for baselining thresholds yet, so current guidance suggests starting with the highest-risk services and the identities that can reach sensitive data first.

Some environments need different treatment. Batch jobs may legitimately spike at predictable times, so volume alone is a weak indicator. Development and testing systems can also distort baselines because they change more frequently than production. In containerised and serverless estates, short-lived workloads create another problem: a baseline can go stale before the next review if runtime identity and telemetry are not collected continuously. The safest pattern is to baseline behaviour at the level of workload identity and dependency graph, then flag meaningful drift rather than every change.

For deeper operational context, the NHI Management Group’s NHI Lifecycle Management Guide is useful for aligning visibility with identity lifecycle controls, especially when secrets, rotation, and offboarding all affect what “normal” should look like. That same lifecycle perspective helps explain why poor baselining often shows up first in environments with long-lived credentials and weak ownership, not in mature estates with disciplined telemetry.

Related resources from NHI Mgmt Group

• What breaks when segregation of duties is not continuously monitored?
• What breaks when agent behaviour is monitored only at the platform layer?
• What breaks when AI agent behaviour is only monitored at the prompt layer?
• What breaks when BNPL partners are not continuously monitored?