Data reach turns security investigations into fragmented puzzles

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Query's report: Security investigations break when identity and telemetry data are scattered across tools that an agent cannot reach in one sweep.

Why it matters: IAM, SOC and NHI teams need governed cross-source reach because incomplete data access can hide compromised service accounts, delay containment and distort automated decisions.

Context

Security investigations depend on reach, meaning the ability to query the systems that hold relevant evidence at the moment the question changes. When identity, firewall, DLP, directory and data warehouse records live in different places and use different query models, automated analysis can miss the one record that changes the case. This is especially relevant where service account security intersects with investigation workflows, because one missed login can be the difference between clean activity and compromise.

A common assumption in security operations is that the SIEM is the place where all useful evidence converges. In practice, many sources remain outside that boundary, so the investigation becomes a manual pivot exercise across consoles, exports and API calls. That is a normal limitation of the current operating model, not an edge case.

Key questions

Q: How should teams investigate a service account login from an unexpected device?

A: Treat the login as a potential account compromise and validate the device, source IP, geolocation, authentication method, and session history against the service account's approved use. Check whether the account used a certificate, key, or token from an unmanaged host, then revoke the credential, rotate secrets, and review downstream actions for abuse or lateral movement.

Q: Why do security investigations fail when sources are spread across tools?

A: They fail because analysts cannot correlate events across identity, endpoint, cloud, and application records quickly enough to build a complete timeline. When identity and telemetry sources are fragmented, gaps appear in entity resolution, device attribution, and session reconstruction, so suspicious activity is missed or misread.

Q: How does federated search improve security investigations?

A: Federated search lets an analyst run one query across multiple connected tools, such as SIEM, EDR, cloud logs and ticketing data, without first copying all records into one place. It improves investigations by reducing missed evidence, preserving source context and speeding correlation across alert trails, endpoint telemetry and authentication logs.

Q: What signals indicate that a service account has been abused?

A: Interactive logons, unfamiliar source hosts, atypical time-of-day use, and sudden access bursts are the most useful signals. A service account should have a narrow behavioural pattern. When it starts acting like a person, or begins touching mailbox or cloud resources it never used before, treat that as compromise until proven otherwise.

Technical breakdown

Why federated search still misses identity evidence

Federated search gives one interface over multiple data sources, but that does not mean every source is equally reachable or queryable. Some systems expose rich APIs, some only support ingest, and some return data in different shapes or time formats that break comparison. In security work, the issue is not just finding data but making it queryable with enough context to support an investigation. When identity records, such as sign-in logs and directory data, sit outside the federated boundary, the analyst still has to pivot manually.

Practical implication: Treat reach as a control requirement and verify that critical identity sources are queryable before you rely on automated investigation results.

Why normalisation matters more than prompt quality

A query planner can translate one predicate into several source-specific queries only if it first normalises time, fields and entity identifiers into a shared model. Without that layer, the same question can return empty results, partial matches or inconsistent counts depending on source syntax. Prompting cannot repair that because the failure is structural: the agent may ask correctly but still never ask the right source in the right form. In operational terms, the quality of the answer is bounded by the weakest connector and the least compatible schema.

Practical implication: Standardise time, identity and asset fields across connectors before you judge whether an investigation workflow is effective.

Why service account logins are a high-value investigative signal

Service accounts often authenticate on a predictable schedule, which makes an unexpected interactive login highly suspicious even before deeper correlation. The problem is that the signal may live in one identity store, the host evidence in another, and the corroborating network or DLP events in a third or fourth system. A useful investigation therefore needs both source coverage and correlation depth. If the analyst can only see the login event but not the surrounding context, the environment is still vulnerable to missed compromise or delayed response. See the Non-Human Identity (NHI) Guide.

Practical implication: Correlate service account activity across identity, endpoint and network sources so an out-of-pattern login cannot be dismissed as routine.

Threat narrative

Attacker objective: The objective is to use a valid service account login to blend into normal activity long enough to evade detection and complicate investigation.

1. Entry occurred when a backup service account authenticated from a laptop instead of its normal server-based source, creating an anomalous access event.
2. Credential abuse followed because the account retained enough valid access to log in interactively and continue operating across days.
3. Impact emerged as the investigation depended on five sources, two of which were outside the SIEM boundary, leaving analysts exposed to incomplete evidence and delayed response.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Data reach is now a first-class security control: investigations fail when the right evidence cannot be queried where it lives, even if each individual tool is functioning. Query shows that the problem is not simply more data, but the ability to reach identity, network and endpoint sources in one investigation path. That makes reach a governance issue, not just a tooling convenience. Practitioners should treat source accessibility as part of detection design, not as an afterthought.

Service account activity exposes the blind spot most teams miss: an interactive login from a backup service account is exactly the kind of event that demands cross-source correlation. The account may authenticate normally in one store while the host, DLP and firewall clues sit elsewhere, which means the investigation can fragment before a human ever sees the full picture. Service account security and investigation coverage should be designed together, because one without the other leaves a false sense of visibility.

Partial visibility creates false confidence: when an agent can answer from only one or two sources, it can sound decisive while remaining wrong. That is a governance failure in the data layer, because the system rewards completion over completeness. Security programmes need to define what “enough evidence” means across sources, not just what a model can retrieve from one connector.

Reach is the missing concept in AI-assisted security operations: the field has spent too much time discussing model performance and not enough time discussing source coverage. A strong model with weak reach still produces brittle outcomes, because the investigation is only as complete as the sources it can query and the schemas it can reconcile. Practitioners should measure reach as explicitly as they measure alert fidelity.

The named concept here is investigation reach gap: the distance between where relevant security evidence lives and where an agent can actually query it. That gap widens as source count grows and as identity, telemetry and case context spread across systems with incompatible access methods. The practical consequence is slower triage, weaker confidence and more manual work for the SOC.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Read next: Service Account Security Guide

What this signals

Investigation reach will become a measurable SOC control: security teams will increasingly judge automation by how many relevant sources it can actually query, not by how fluent its summaries sound. That shift matters because a system that cannot reach the identity store, the DLP feed or the firewall log is still operating with blind spots, no matter how polished the response appears.

Service accounts remain the easiest place to hide in plain sight: the moment a non-human identity can authenticate from the wrong device, the investigation problem turns into a cross-system correlation problem. That is why the source coverage question belongs in identity governance as much as in SOC engineering.

Investigation reach gap: when evidence is scattered across systems that an agent cannot query consistently, confidence rises faster than completeness. Security programmes should watch for workflows that close cases before they have touched every source that could alter the outcome.

For practitioners

• Map investigative reach across critical sources Inventory which identity, endpoint, network, DLP and data warehouse sources are queryable by your SOC workflows, then mark any source that is ingest-only or unreachable by API.
• Validate cross-source field normalisation Test whether time, host, IP and identity fields resolve to one shared format before the query leaves the agent layer, especially for sign-in, firewall and DLP logs.
• Escalate anomalous service account logins Treat interactive logins from service accounts as high-priority investigative events and require correlation with endpoint, directory and network telemetry before closure.
• Measure evidence completeness, not only answer rate Track how often an investigation touches every relevant source, how many follow-up queries it required and whether gaps were reported as missing data or cleaned away.

Key takeaways

• Security investigations can look complete while still missing the sources that would change the answer, especially when identity and telemetry data live in separate systems.
• Query's example shows that an unexpected service account login only becomes actionable when the SOC can pivot across multiple stores and correlate them quickly.
• The practical control is not another prompt or model tweak, but governed reach into the identity and telemetry sources that matter most.

Related NHI Mgmt Group resources: Ultimate Guide to NHIs · Guide to NHI Rotation Challenges · Service Account Security Guide · Dropbox Sign breach 2024

Key terms

• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• Federated Search: Federated search is a query method that looks across multiple data stores without first copying everything into one central repository. In identity security operations, it helps teams preserve context across live, cold, and distributed sources while reducing duplication and storage lock-in.
• Sign-In Logs: Sign-in logs are records of authentication events, including successful and failed logins, device context, and access location details where available. They help detect account compromise, unusual access patterns, and policy failures. Security teams should retain them, alert on anomalies, and correlate them with changes to accounts and privileges.
• Data reach: The sensitive information an identity can actually access once direct and indirect permissions are followed through connected systems. It is a stronger governance measure than assigned access because it captures the practical result of entitlement chains, not just the policy record.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security and identity practitioners build the controls that keep service accounts visible and governable.