Detection engineering is leaving the SIEM
How detection engineering is becoming embedded across multiple non-traditional layers.
Shaun Archer
7/17/20268 min read
Detection engineering is leaving the SIEM
For the best part of twenty years, detection engineering meant one thing: write a correlation rule, ship it to the SIEM, wait for the logs to land, tune it, repeat. That model is coming apart at the seams. Detection logic is now getting embedded at almost every layer of the pipeline — before data ever reaches a central store, inside the store itself, and inside whatever's replacing the SIEM this quarter. What's emerging isn't consolidation. It's five genuinely different bets on where detection ought to live, and each one trades off latency, cost, explainability, extensibility and maintainability in a different way.
Here's how I'd map the field at the moment.
1. Behavioural models on first-party data
This approach more or less skips log correlation. Rather than ingesting security telemetry after the fact, the vendor sits directly in the data path — an API integration with mail flow, the identity provider, the SaaS platform — and builds a behavioural baseline per identity, per relationship, per organisation. The more advanced products in this space now train large behavioural foundation models on billions of derived signals, fusing identity, content and behaviour into a single model instead of treating them as separate streams to be stitched together later in a SIEM.
What you get for this is context. A first-party integration sees the whole object — an email, an OAuth grant, a login — at the moment it happens, not a flattened log line three hops downstream. That's what lets it catch a novel account takeover or vendor email compromise without anyone having written a rule for that specific pattern.
What you give up is generality. These models are deep in one domain — email, identity, SaaS — and simply don't extend to network or endpoint telemetry. You're buying a narrow but genuinely deep capability, not a general-purpose detection layer.
Where this approach has no real competition. There's a specific class of attack where none of the other four patterns can plausibly keep up, and it's worth being precise about why. Business email compromise and vendor email compromise carry no malware, no known indicator, no signature to match — the "attack" is a plausible email asking for something slightly wrong, and the only tell is that it deviates from how this person, or this vendor, normally communicates. Low-and-slow account takeover using stolen but genuine credentials looks the same way: MFA is satisfied, the login parameters are each individually unremarkable, and the only anomaly is that this identity doesn't usually log in from here, at this time, and then set up a forwarding rule five minutes later. Payment and invoice fraud is the same pattern again, just dressed as a finance workflow.
What links all three is that there's no artefact to write a rule against, and the deviation is only visible against a long, rich, per-identity baseline built from full-fidelity data. That's precisely what the other four approaches structurally lack. Edge filtering and SIEMless sensors only pass along signals someone predefined as worth emitting — and nobody predefines "this specific phrasing from this specific vendor is 4% off their usual pattern." Detection libraries in next-gen SIEMs and data lakes are written in response to known attack patterns, which is the opposite of what a first-time novel BEC attempt is. And even a data lake's own cross-domain ML loses the full-fidelity object — the actual email text, the actual OAuth scope requested — once it's been flattened and normalised into a common schema. For this narrow but expensive category of attack, first-party behavioural depth isn't just the better option, it's close to the only option.
2. Edge filtering and pipeline-embedded detection
Telemetry pipeline products exist to solve a cost problem first: route, reduce and reshape data before it hits an expensive destination like a SIEM. The more capable ones now do that reduction on the source host itself, so only the useful bits ever leave. A recent wave of acquisitions in this space is pushing further still — pairing the pipeline with AI that assesses detection coverage against real adversary behaviour (mapped against frameworks like MITRE ATT&CK) and flags gaps in existing rule logic, rather than just trimming volume.
In other words, detection engineering becomes a by-product of data engineering. Because the pipeline already touches every event on its way through, it's a sensible place to ask "does this matter, and do we actually have a detection for it?" before you pay to store or query it further down the line.
It's efficient — you cut ingest cost and noise right at the point closest to the source, and increasingly you can sanity-check your detection coverage in the same layer. The catch is that a pipeline doesn't own long-term context; it's a conduit, not a store, so anything requiring cross-session or long-horizon correlation still needs a home somewhere else.
3. "SIEMless" architectures
This pattern flips the traditional model on its head: instead of hoovering up terabytes of raw logs centrally and mining them for the handful of alerts that actually matter, lightweight sensors at the edge emit only high-confidence signals — a dodgy login here, a firewall hit there, a cloud config change somewhere else — and a thin correlation core stitches those into campaigns. Vendors in this space claim it cuts infrastructure footprint and cost by well over 90% compared with a log-everything SIEM, since you're now moving megabytes of signal rather than terabytes of raw log.
The obvious win is cost and scale — it sidesteps the SIEM's core economic problem, where spend tends to track ingest volume fairly directly. Because the noise has already been filtered before it's centralised, behavioural analytics also gets a much cleaner signal to chew on.
The trade-off is retrospective visibility. If a sensor didn't judge something worth emitting at the time, it's gone for good — you've swapped the SIEM's brute-force "store everything, ask questions later" approach for efficiency. That's a real cost during an incident, when it's often the boring event you didn't think mattered yesterday that turns out to be the one you need.
4. Security data lakes with embedded detection
Here, detection engineering moves into the storage layer itself. The newest entrants in this category run detections as code — YAML or Python notebooks, version-controlled, tested and deployed through ordinary CI/CD — directly against a layered lakehouse of normalised telemetry, with agentic AI sat on top for triage and hunting at petabyte scale. Others take a similar bet from the endpoint side: OCSF-normalised first- and third-party data in one high-speed store, with AI pipelines filtering and enriching telemetry before it's even ingested, and an agentic layer acting as the analyst on top of it all.
The appeal here is unification: one normalised dataset, proper long-term retention, and detections that behave like software artefacts you can review, test and roll back rather than a pile of hand-tuned rules nobody remembers writing. Because everything sits in one schema, cross-domain correlation — endpoint to cloud to identity — doesn't mean stitching several tools together.
The price is architectural commitment. You're betting your detection logic on one platform's compute economics and normalisation schema, and petabyte-scale storage plus AI compute still isn't cheap, even when it beats legacy SIEM ingest pricing. Explainability tends to hold up well for the code layer — you can just read the rule — but gets fuzzier once you're relying on the agentic hunting layer above it.
5. Next-gen SIEMs with an AI SOC bolted over the top
The incumbents, unsurprisingly, are defending the centre. The larger endpoint-and-SIEM vendors now ship thousands of prebuilt, high-fidelity detections out of the box, so customers get value without writing a single rule, and layer AI across the analyst's whole workflow — including agents that translate legacy query languages into the vendor's own, presumably to make migration hurt a bit less. Several of the mid-market SIEM vendors have released comparable AI-native offerings that fold SIEM, SOAR, attack surface management and threat intel into a single interface, with AI trained on the vendor's own managed-detection operations data doing the triage.
The strength here is breadth and turnkey value. These platforms already sit on deep endpoint, cloud and identity telemetry, plus a large detection library the vendor's own threat research team keeps current, so time-to-value is short and the ongoing maintenance burden mostly sits with the vendor rather than you. Explainability is generally solid for the prebuilt library — the detections are documented — and, much like the data lake pattern, a bit murkier once the AI triage layer starts making judgement calls.
The cost that hasn't gone away is the old one: you're still paying for centralised ingest and still fairly tied to the vendor's own telemetry and schema, even where "AI-native" branding is doing its best to paper over the fact that, underneath, it's still a SIEM.
The best case for behavioural models isn't standing alone — it's feeding the AI SOC
It's tempting to frame this as five competing architectures and ask which one wins. That's the wrong question for behavioural models specifically, and it's worth saying so plainly rather than overselling it: their strongest role isn't as a self-contained SOC, it's as a high-confidence signal generator that feeds into the broader correlation layer underneath a data lake or next-gen SIEM.
The logic holds up. A behavioural model produces a narrow but very high-precision verdict — "this identity's financial-instruction email deviates from its relationship history, 97% confidence" — grounded in full-fidelity context the downstream platform will never see directly, partly because it shouldn't (raw email content and OAuth payloads generally have no business leaving the environment that generated them, for privacy and data-residency reasons as much as anything else). If that distilled, high-confidence event is exposed as a structured signal — via API or webhook rather than locked inside a vendor's own console — a lakehouse or AI SOC can correlate it against everything else it holds: an anomalous OAuth grant, a login from an unfamiliar geography, a spike in data exfiltration from the same identity. Any one of those signals alone might be too weak to act on. Together, they're a campaign. That's the same "stitch weak signals into a high-confidence event" logic the SIEMless pattern uses internally, just applied one layer up, across vendors rather than within one.
The caveat is real, though, and it's the reason this is a best case rather than a default: it only works if the behavioural vendor actually exports its detections as clean, queryable events, and if the receiving platform can resolve that identity against its own data without a manual mapping exercise. Plenty of behavioural tools still keep their verdicts inside their own UI. Where that integration exists and is done properly, this is genuinely the strongest architecture on the table. Where it doesn't, you've just got five separate silos that all happen to be quite good at their own narrow job.
Comparing the five approaches
Where this leaves detection engineers
None of these five properly replaces the others, and that's really the point. Behavioural models and edge filtering win on latency and cost because they act before or right at the point data is created, but each is either narrow to one domain or dependent on something else handling long-term storage and cross-domain correlation. The data lakes and next-gen SIEMs win on breadth, retention, and explainability of "the rule that fired," but they still inherit the underlying cost of storing a lot of data — even where they've genuinely improved on legacy SIEM economics.
The shape that's actually emerging looks more like a stack than a straight swap: first-party behavioural models and edge filtering doing cheap, high-confidence detection close to the source; a lakehouse or next-gen SIEM underneath handling retention and cross-domain correlation for the detections that need the full history; and a growing share of the AI budget going not into writing new detections but into checking the ones you've already got still work — coverage assessment, agentic hunting, AI-driven triage, whatever form it takes. Detection engineering as a discipline is shifting from "where do I write this rule" to "which layer should own this signal, and whose job is it to prove it still holds up."