How SIET compares.
SIET is a detection and routing layer that sits in front of the SIEM you already run. It is not a SIEM, not an endpoint agent, and not a replacement for either.
Below is an honest account of where it overlaps with the tools you already own, where it does not, and when it makes sense to run them together. Where something else is the better fit, that is said.
Where SIET sits
SIET vs SIEM
Coexist: Yes, alwaysSplunk, Microsoft Sentinel, Elastic Security, QRadar, Falcon LogScale
What it solves
Collection, storage, search and alerting across the estate. The system of record for security telemetry and the place analysts work.
Where they overlap
Both produce alerts. A SIEM produces them by evaluating rules you write; SIET produces them by measuring structural change and sends them into the SIEM.
Where they differ
A SIEM needs detection content authored and maintained for it. SIET needs none, and it does not store or search your telemetry.
SIET does not replace a SIEM and cannot. It feeds one. If you removed your SIEM you would have nowhere for cases to land and nothing to search.
SIET vs Telemetry pipeline
Coexist: Yes, though the roles overlapCribl Stream, Databahn, Edge Delta, Tenzir, Vector, Splunk Ingest Actions
What it solves
Routing, reshaping, enriching and reducing telemetry before it reaches the SIEM. Chiefly bought to control ingest cost.
Where they overlap
Both sit in front of the SIEM and both reduce what it indexes. That is the whole of the overlap.
Where they differ
A pipeline reduces by applying rules a person wrote about what is safe to discard, and whatever survives is still indexed per gigabyte. SIET evaluates every event, discards nothing, and sends what is not implicated to archive at full fidelity. Pipelines also do not detect anything.
Compared on routing alone SIET looks expensive, because a pipeline is a pipeline and SIET is a detection product that also decides tiering. The comparison worth making is a pipeline plus the detection content you still maintain, against SIET.
SIET vs EDR and XDR
Coexist: Yes, and they complement wellCrowdStrike Falcon, SentinelOne, Microsoft Defender, Palo Alto Cortex
What it solves
Deep visibility and response on the endpoint. Process lineage, memory, file activity, and the ability to isolate or kill.
Where they overlap
Both detect. EDR detects on the endpoint with agent-level visibility; SIET detects across the estate using whatever telemetry it is given, including endpoint telemetry.
Where they differ
EDR sees one machine in great depth and is strongest at local activity. SIET sees relationships between machines, accounts and services, and is strongest at movement between them. EDR can act; SIET only reports.
Feed EDR telemetry into SIET and you get both. SIET has no response capability and no endpoint agent, so it is not an alternative to EDR under any reading.
SIET vs NDR
Coexist: Yes, on different substratesDarktrace, Vectra AI, ExtraHop, Corelight
What it solves
Detecting attackers already inside the perimeter by watching east-west network traffic for behavioural anomalies and lateral movement, without endpoint agents or signatures.
Where they overlap
Substantial, and this is the closest competing claim on the market. Both detect attacks through changed relationships between machines rather than by matching known-bad.
Where they differ
NDR is bounded to the network by construction. The whole category exists because each domain got its own detector: NDR for the wire, EDR for the endpoint, ITDR for identity, CDR for cloud. SIET is not a wider-aperture NDR, it is the same method applied to whatever telemetry exists, so identity, process, service and network are the same problem rather than four products. Most behavioural NDR is also ML-trained baselining, which is exactly what SIET is not.
If a buyer already runs NDR, SIET is not a replacement: feed its output in as another source. But the deeper point is that the market has fragmented detection by domain, producing a separate product, agent and console per telemetry type. Relationships do not respect that boundary, and neither does an attacker moving from an identity to a host to a service.
SIET vs Security data lake
Coexist: Yes, and wellPanther, Anvilogic, Hunters, Amazon Security Lake, Snowflake, Databricks
What it solves
Decoupling security data storage from SIEM licensing. Keep everything cheaply in open formats, run detections against it, avoid paying per gigabyte for hot indexing.
Where they overlap
Direct, on the cost half of the argument. Both are answers to the same complaint, that the SIEM index is too expensive for what it holds.
Where they differ
A lake changes where data lives. It does not change how detection works: Panther and Anvilogic still run authored detection content against the lake, so the rules move rather than disappear. SIET makes a detection decision that produces a routing decision as a consequence, rather than a storage decision that leaves detection untouched.
These pair naturally. A lake is a good destination for what SIET routes to archive, in open formats you already query. The question a lake does not answer is which events needed indexing in the first place.
SIET vs UEBA
Coexist: Yes, with overlapExabeam, Securonix, Microsoft Defender for Identity
What it solves
Detecting when a user or entity behaves unusually for an entity of its kind, usually with statistical or ML models over peer groups.
Where they overlap
This is the closest neighbour. Both look for departure from normal rather than matching known-bad.
Where they differ
UEBA typically asks whether an entity is unusual relative to its peers, using a trained model. SIET asks whether the relationships in the estate have changed, deriving what is normal from each component’s own recorded history with no training step and no peer assumption.
Honestly the nearest thing to a competitor. The distinction is training and peer grouping versus derivation from a component’s own history, and that SIET also decides storage tier.
SIET vs MDR platforms
Coexist: Yes, and an MDR is a customerReliaQuest GreyMatter, Arctic Wolf, Expel, Red Canary
What it solves
A managed security operation: their platform, their analysts, their process, sold as an outcome rather than a tool. Several now filter or detect closer to the source to cut what reaches the SIEM.
Where they overlap
The edge-filtering capability overlaps with the routing half of SIET. Both aim to reduce what an expensive index has to hold.
Where they differ
They are buying a service relationship, not a component. Their reduction is rule-driven filtering placed earlier in the pipeline, which still requires the detection content to exist and lands in the same 30 to 50 percent band as pipeline products. SIET removes the content requirement rather than relocating it.
Not a like-for-like comparison. An MDR provider is a buyer of SIET rather than a rival to it: the indexing cost sits on their own margin across every client estate they monitor.
SIET vs AI SOC and triage
Coexist: Yes, and they are better fed by SIETQevlar, Dropzone, Prophet Security, Radiant
What it solves
Investigating alerts that already exist. Correlating related activity, gathering context, establishing blast radius, drafting the incident narrative.
Where they overlap
Very little. They start where detection ends.
Where they differ
They automate the reconstruction of context that conventional detection destroyed on the way in. SIET never loses that context, because correlation is a property of how it detects rather than a step performed afterwards.
These tools work on whatever alerts arrive. Give them 200,000 raw SIEM alerts and they are expensive triage; give them correlated cases and they do higher-value work.
SIET vs Threat intelligence
Coexist: Yes, in different placesOpenCTI, Recorded Future, MISP, commercial feeds
What it solves
Knowing which infrastructure, hashes and domains have been reported as malicious by somebody else.
Where they overlap
Both can flag an attack. One does it by recognising a reported indicator, the other by measuring change.
Where they differ
A feed answers whether anyone has reported this address. It cannot answer whether this host is behaving unlike itself. Feeds are also overwhelmingly IP-based, and addresses rotate faster than they can be reported and distributed.
Threat intelligence earns its place as a preventive control, wired into firewall and proxy blocklists where a miss costs nothing. As a detection trigger it inherits the coverage gap. Enrichment on a verdict is useful; enrichment as the verdict is not.
Why not just turn on your SIEM’s own cheap tier?
You should. It is free and you already own it. Just be clear about what it buys you: a smaller bill, and not one fewer detection rule to write.
Every major SIEM now ships an answer to index cost. Sentinel has Auxiliary and Basic logs, Splunk has SmartStore and Ingest Actions, Elastic has hot, warm, cold and frozen tiers, Graylog routes to a data lake that does not count against the licence. Reported savings from tiering alone run to 60 or 80 percent.
It is free, you already own it, and it is the first thing to try. If it gets you where you need to be, you do not need us.
But notice what it does not touch. Tiering is a storage answer to a storage question. Every rule you maintain today, you still maintain tomorrow. Every technique nobody has described yet is still invisible. The bill goes down and the detection problem is exactly where it was.
It also decides by volume rather than significance: you nominate sources and schemas, once, in advance, for every event those sources will ever produce.
Two different decisions
Native tiering decides by volume
Per source and schema, set once. The interesting event in a cheap tier is as hard to reach as the dull one beside it, because nothing looked at either.
SIET decides by significance
Per event, after evaluation. A quiet source that suddenly matters is indexed; a noisy source that does not is archived. The same feed lands in both places depending on what it did.
When SIET is the wrong choice.
Worth stating, because a tool that claims to fit everywhere fits nowhere in particular.
You need prevention
SIET reports; it does not block, quarantine or kill. If the requirement is to stop something happening, that is a firewall, an EDR or a proxy.
You need a SIEM
SIET does not store or search your telemetry and has no analyst interface. It needs a SIEM to feed. If you do not have one, buy one first.
You only want to reshape telemetry
If the requirement is enrichment, format conversion and fan-out to many destinations with no detection need, a dedicated pipeline product is the right tool.
Your estate is tiny
Below roughly 100 GB/day the indexing saving is small enough that the commercial case rests entirely on detection, and the economics are less compelling.
You need compliance reporting
SIET is a detection and routing layer. Reporting, dashboards and audit evidence come from the SIEM and the archive, not from us.
You want one console for everything
SIET has no operator console by design. Cases land in the tool your analysts already use. If consolidation onto a single vendor pane is the goal, that is a different purchase.
Already have a stack? Good.
SIET is designed to arrive alongside what you run today. Nothing is switched off, your existing detection content keeps working, and the output lands in the tool your analysts already use.