What breaks when detections are built only around data sources?

Why This Matters for Security Teams

Detection programs often look “complete” when they are organised by source type, but source coverage is not the same as investigative coverage. A log source can be present without proving it captures the execution path, credential use, or lateral movement that matters. That gap is especially dangerous for NHIs, where compromise usually shows up as sequence and context rather than a single bad event. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why source-first programs miss attacker behaviour even when telemetry volume is high.

The practical problem is that analysts need to answer “what happened?” and “what does it mean?” not just “did this source emit data?” The NIST Cybersecurity Framework 2.0 emphasizes outcome-based risk management, which is a better fit than source inventories for this question. Source lists rarely show whether a control can confirm token abuse, privilege escalation, or persistence. In practice, many security teams encounter these blind spots only after an NHI has already been used to move from initial access into execution and long-term access.

How It Works in Practice

Effective detection starts with attacker behaviour, then maps telemetry back to the behaviours that can be observed. That means defining the detection objective first, such as detecting credential replay, token theft, anomalous API invocation, or service account abuse, and then confirming which sources can support that objective. A source may be useful for alerting, but it is only trustworthy if it has the fields, retention, and event fidelity needed to support investigation.

For NHI environments, this usually requires linking identity, workload, and control-plane signals. The Top 10 NHI Issues and the Ultimate Guide to NHIs both reinforce that visibility gaps are often rooted in poor lifecycle discipline and distributed secrets. A source-driven detector should therefore be tested against concrete questions:

• Can this telemetry show who or what used the credential, token, or key?
• Can it reveal privilege changes, unusual execution paths, or cross-system movement?
• Can it support timeline reconstruction after the initial alert fires?
• Can it distinguish routine automation from attacker-controlled misuse?

This is where detection engineering differs from log collection. Sources should be selected because they support a scenario, not because they exist. If the objective is persistence detection, for example, the team needs telemetry that can reveal secret regeneration, scheduled task abuse, webhook changes, or service account reconfiguration. The source list alone cannot tell analysts whether the signal is sufficient; the detection design must specify the behaviour, the expected sequence, and the minimum evidence required to confirm compromise. These controls tend to break down when workloads are highly distributed and ownership is fragmented, because no single team can validate end-to-end signal quality across the full execution path.

Common Variations and Edge Cases

Tighter detection coverage often increases engineering and validation overhead, requiring organisations to balance breadth against the effort needed to maintain useful signals. In mature environments, the most common mistake is assuming that one data source can support all use cases for a platform or identity type. Current guidance suggests that this is not a reliable assumption, especially when service accounts, CI/CD pipelines, and cloud control planes all participate in the same attack path.

There is no universal standard for source sufficiency yet, so teams should treat source-based detections as one layer, not the design principle. A log source may be excellent for compliance reporting but weak for behavioural detection if it lacks context, identity linkage, or preservation of request lineage. This is why alert logic should be validated against attacker paths, not against the existence of a collector. For deeper background on how poor lifecycle controls increase detection failure, the NHI Lifecycle Management Guide is a useful companion reference.

Edge cases also appear in environments with heavy automation, where “normal” activity is already noisy and source counts are misleading. In those settings, detections must prioritise correlation, entity behaviour, and confirmed evidence of misuse over raw ingestion volume. A large telemetry footprint can still hide the exact actions that matter if the detection model starts and ends with data sources instead of adversary behaviour.

Related resources from NHI Mgmt Group

• What breaks when detections are built around vendor coverage instead of attacker behaviour?
• What breaks when DLP policies are built only around data type and not workflow context?
• What breaks when phishing detections are built only around traditional email and network signals?
• What breaks when AI governance is built only around approved tools?