Most detection solutions have the same prerequisite: if you want to detect on it, you need to ingest it first. That (mostly) worked when data volumes were smaller and security telemetry lived in fewer places. It breaks down in modern environments.

Today, security-relevant data is spread across SIEMs, identity providers, cloud services, IT systems, security point products, data lakes, line of business apps and more. Some of it is high volume. Some of it is high value. Some of it is contextual. Most of it never makes it into a central system because the cost and operational overhead are too high.

Over time, security teams have had to adapt. They make tradeoffs about what gets ingested, how long it’s retained, and what gets sampled or dropped. Those decisions are rational. They are also the reason detection coverage quietly narrows and blind spots grow.

This is the gap Query Federated Detections are designed to address.

Detection Coverage Is an Architecture Problem

Most detection engines work well within the boundaries they define. The issue is that those boundaries are created by ingestion.

If data is ingested, detections can run. If it is stored elsewhere, it might as well not exist. As technology environments expand, that line becomes harder to manage. New tools appear, data volumes spike and retention gets shortened. Engineering teams are asked to build and maintain pipelines that were never meant to scale indefinitely.

The result is uneven coverage. Not because teams do not care, but because architecture constraints  force the tradeoffs. At some point, detection logic stops being the constraint. The data model and ingestion strategy take over.

Data Reach Changes What Is Possible

Decoupling detection logic from storage is necessary, but not sufficient. What actually changes the equation is reach – the ability to execute detections across all the security-relevant data a team relies on, regardless of where that data lives.

When reach is limited, detections are portable in theory but constrained in practice. When reach is broad, detection logic can stay consistent while the execution surface grows alongside the environment. This is the core idea behind Federated Detections.

The Security Data Mesh as the Foundation

Federated Detections are built on the Query Security Data Mesh. The mesh connects to security-relevant data where it already lives. It does not assume a single destination, schema, or system of record. Data stays in place and Query provides a consistent way to access and work with it.

This matters because detection, investigation, threat hunting and incident response all rely on fragmented data spread across systems that were never designed to work together.

By establishing a federated access layer, the mesh creates a unified execution surface without forcing data movement first.

A New Detection Architecture

With Federated Detections, detection logic is defined once and executed across all connected data sources in the data mesh. If a source is connected to Query, detections can run against it, with no requirement to ingest data.

Detections run on a defined schedule with explicit evaluation windows. Each execution records what data was evaluated and how the detection criteria were met ensuring results are predictable and explainable.

As new sources are connected, detection coverage expands automatically. The logic does not need to be rewritten, pipelines do not need to be built, and coverage grows with the environment instead of fighting it.

Context-rich Findings for Investigation

Detection is only useful if it leads to clarity.

When a federated detection fires, Query allows analysts to replay the detection logic against the same time window that produced the result. Results are normalized across all contributing sources, making it possible to reason across systems without constantly translating schemas or switching tools.

From there, analysts can pivot into related entities, events, and context across the data mesh. Investigations proceed wherever the analyst’s experience and judgement lead, unconstrained by the boundaries of individual products.

The goal is to give teams broader coverage, deeper context and a more direct path to understanding what actually happened.

Beyond Detections

The constraints that limit detection coverage also affect investigations, threat hunting, incident response and compliance. SecOps teams spend too much time working around where data lives instead of using it.

Federated Detections are an example of what becomes possible when access to security data is consistent across systems. They reflect a broader shift away from ingest-first assumptions toward architectures that prioritize flexibility and reach.

We’ve seen too many teams that have had to accept blind spots they did not want because the alternatives were too costly or complex. Over time, those compromises become normal.

Federated Detections represent a different approach: detection logic is no longer constrained by where data happens to be stored. Coverage can expand as environments grow, without forcing teams to rebuild their data stack along the way.

This is one step in our mission to give security teams a more durable foundation for working with their data and better security outcomes.

If you’re looking to expand your detection coverage and capabilities there’s a good chance we can help. 

You can dig into more details here and reach out if you’d like to see it in action. Your feedback will shape what comes next.