Detection Engineering Without Vendor Lock: Wazuh Stack 2026
8 min. read
The SIEM contracts of major providers are up for renegotiation in many DACH security teams over the next two years. Those who use the renewal date as an opportunity are looking not only for a cheaper vendor but also for an architecture that avoids vendor lock-in. Wazuh, Sigma, and Shuffle are not a marketing stack, but a serious option—provided the team puts the trade-offs honestly on the table.
Key Takeaways
- Detection engineering is not a tool question, but a discipline. Wazuh + Sigma + Shuffle do not replace a SIEM; they replace a specific operating model. Those who fail to build the discipline will face the same problems as they did with the more expensive vendor.
- NIS2 requires auditability, not vendor conformity. Open-source stacks meet the requirements if the audit trail is documented. The hurdle lies in the internal effort, not in the choice of tools.
- The TCO calculation is not trivial. License costs drop, but FTE effort rises—often not a net gain for small teams. From three senior detection engineers onwards, the stack becomes economically viable.
RelatedNIS2 Audit: Vendor list breaks in 2h / Adaptive MFA: NIS2 pressure as a lever
Why vendor lock-in in the SIEM market is becoming an operational risk
SIEM renewals in DACH mid-sized companies and corporations have followed a pattern over the last 18 months. License costs are rising by double digits, EPS limits are tightening, and logging volume is growing faster than budgets due to cloud workloads. Those who signed a contract in 2018 are often paying double in 2026 for nominally the same architecture.
Vendor lock-in is not just a cost issue. Once you have maintained 2,000 detection rules in a proprietary query language, you cannot switch without friction. This is precisely what makes detection engineering a discipline that must be anchored in the operating model, not in a vendor contract. Those who postpone this will pay for three years of negligence at renewal time.
Hybrid cloud is not an architectural pattern, but the consequence of two teams failing to talk to each other in time. Vendor lock-in in SIEM is the consequence of no one treating detection rules as an independent asset.
The stack at a glance: Wazuh, Sigma, Shuffle, DFIR-IRIS
The open-source stack discussed here consists of four components that cover distinct functions. While they can be tuned to work together, they do not constitute an integrated platform in the sense of a commercial SIEM. That is precisely their strength and, simultaneously, their hurdle.
Wazuh serves as the detection platform. It combines HIDS functionality, log analysis, and compliance reporting based on Elasticsearch, providing a web UI for alert triage. Sigma is the detection rule standard, formulated to be platform-independent and capable of being translated into Wazuh rules, Elastic detection rules, or Splunk queries. Shuffle is the SOAR component that orchestrates workflows between detection, enrichment, and response. DFIR-IRIS is the case management tool for incident response workflows.
Anyone hearing the term “agentic-AI-ready” should be cautious. While the components have integration points for LLM-based enrichment, that does not yet make the stack an autonomous security platform. Those who deploy AI agents in Shuffle workflows also assume responsibility for the hallucinations that every agent brings with it. Anyone who treats KMS keys like a drop-down menu has either never experienced an audit or has never had a good one. The same applies to AI agents in the detection pipeline.
Pros and cons in an honest table
An honest comparison between a commercial SIEM and a Wazuh-centric open-source stack reveals clear trade-offs that are missing from most marketing decks. Anyone who puts this table on the table before a renewal deadline will at least gain a solid basis for discussion.
| Dimension | Pro open-source stack | Pro commercial SIEM |
|---|---|---|
| License costs | No per-EPS fees, no cap on data volume. Often 70 percent cheaper in license line items for cloud-heavy setups. | Predictable, with a support backstop. Vendor quarterly reports automatically include most audit requirements. |
| FTE effort | Higher. 2–3 detection engineers on the line, one senior for the architecture owner role. | Lower in day-to-day operations, higher during vendor escalations. Power-user skills are vendor-specific. |
| Detection logic portability | Sigma rules are platform-agnostic. Switching to Elastic, Splunk, or Sentinel is possible without total loss. | Proprietary query languages. Migration typically costs 6–12 months per detection portfolio. |
| Audit / NIS2 compliance | Achievable if the audit trail is documented. More self-effort required for verification. | Vendor provides audit modules as standard. Compliance status available on a dashboard. |
| Support escalation Sev-1 | Community + paid Wazuh subscription. Self-effort required for deep architectural questions. | 24/7 vendor support, contractually defined service-level agreement. Escalation path is established. |
This table has one important consequence. Open-source stacks are not primarily worthwhile for financial reasons, but for strategic ones. Anyone who views vendor lock-in as a greater risk than FTE dependency has an answer. Anyone who weighs vendor support higher than portability has a different answer. Both are legitimate, and both have their consequences.
Three figures every CISO should bring to the steering committee
In steering committees, open-source discussions often fail due to a single figure that no one has calculated properly. Three sober metrics help to paint a clearer picture of reality.
Operational Reality
3 FTE
Detection engineering threshold. Below three senior detection engineers, the open-source stack becomes economically risky. Above that, it becomes productive.
~ 70 %
Average license savings. For cloud-heavy log profiles. Half of this goes into FTE effort, the rest is net savings.
12 M
Migration window. Realistic duration from architecture decision to production with full rule coverage. Anyone planning for less is being dishonest.
These figures are not a study; they are empirical values from productive migrations. If you cannot measure them in your own setup, you don’t have a robust proposal for the steering committee. That is the uncomfortable truth. The difference between “security by design” and “security by incident” is roughly a week of sleep. The difference between “we are thinking about open source” and “we are migrating in 12 months” is three solid figures.
How Sigma is changing the standard for rules
The most important conceptual shift is not Wazuh, but Sigma. Detection rules are becoming a portable asset rather than a vendor artifact. A team that works “Sigma-first” can run its detection logic in Wazuh, Elastic, Splunk, or Sentinel without having to repeat 80 percent of the work.
In practice, this requires a disciplined approach to maintenance. Detection rules are versioned in Sigma YAML, managed in Git, validated against test logs using CI pipelines, and only then translated into the respective platform language. This pipeline is rarely found in classic SIEM stacks because it doesn’t seem necessary. It becomes necessary the moment you switch vendors.
“We rewrote the playbook twice because the first draft at 3:40 AM sounded like something a marketing department invented. We only try to write Sigma rules once now.”
Senior Detection Engineer, DACH industrial group, 2026
When the stack is worth it, and when it isn’t
From a practical perspective, the stack is worth it in three scenarios. First: for security teams with at least three senior engineers who want to practice detection as a discipline rather than viewing it merely as a tooling issue. Second: for mid-sized companies that have cloud-heavy logging and are suffocating under SIEM EPS caps. Third: for corporations that have made supplier diversification a strategic goal and do not want to be dependent on a single vendor for every tool category.
It is not worth it if the team has fewer than two senior engineers, if audit requirements demand a turnkey compliance report that must be generated with four clicks, or if the operating model views detection as a pure vendor delivery. Anyone who forgets this is building a second full-time job that was never commissioned by the steering committee.
Frequently Asked Questions
Is Wazuh sufficient as a standalone SIEM for companies subject to NIS2?
Technically yes, provided you put in the necessary effort. Wazuh meets most detection, logging, and compliance requirements. However, NIS2 compliance is not achieved through the tool itself, but through documented processes: audit trails, reporting cadence, and incident escalation. If you already have these in place, you save money. If you don’t, you shouldn’t combine a vendor switch with building these processes from scratch.
How demanding is Sigma rule maintenance compared to a commercial SIEM?
Initially, it is significantly more demanding because you have to set up the CI pipeline and test logging. After 6–9 months, the ongoing maintenance effort is comparable, as test coverage catches regressions earlier than a vendor update cycle would.
What does a realistic Wazuh stack cost to operate?
For mid-sized setups (5,000 EPS, 50 sensors), infrastructure costs range from 30–60,000 Euro per year, plus 3 FTEs for detection engineering. A comparable commercial SIEM often falls into the low six-figure license range, plus 1–2 FTEs. The math shifts in favor of the open-source stack as soon as the EPS volume or audit depth increases.
What role does DFIR-IRIS play compared to commercial case management tools?
DFIR-IRIS covers 80 percent of what a mid-market case management tool provides. The missing 20 percent usually consists of reporting templates and pre-configured SLA logic. For enterprise setups with strict audit requirements, commercial tools retain the advantage, but for mid-sized companies, DFIR-IRIS is highly productive.
Can Shuffle workflows be combined with commercial SOAR tools?
Yes, via REST APIs on both sides. In practice, however, this rarely makes sense—the hybrid architecture creates more escalation paths than it saves. Either the team decides on Shuffle as the primary SOAR, or it sticks with the commercial tool. Hybrid is a transition phase, not a target architecture.
More from the MBF Media Network
