A lean team choosing a SIEM needs to match the platform to its daily work, not just its license price. A SIEM, or security information and event management system, centralizes security data so teams can search it, detect suspicious activity, and investigate alerts. The right choice depends on whether your main need is endpoint telemetry, broad search and analytics, or log management. It also depends on licensing, detection work, and the time your team can spend running the system. A free license removes one bill, but it does not pay for infrastructure or engineering. A small security team still needs to collect useful data, tune detections, review alerts, and keep storage healthy. The key first distinction is whether the team starts with endpoint security, broad search or log centralization.
Key Takeaways
- Wazuh is the clearest fit for free, endpoint-led monitoring and compliance.
- Elastic Security suits teams that value deep search and can manage its tiers.
- Graylog Open handles log centralization; security detection features sit in Graylog Security.
- Licensing is only one part of cost. Storage, staff time, and tuning count too.
- A short pilot with real data can expose gaps before a team commits.
Which platform fits each team’s main job?
For an SMB that needs host security without a license bill, Wazuh is the clearest starting fit. Endpoint-first Wazuh brings endpoint agents, file integrity monitoring (FIM), and compliance tools together. Elastic Security starts with search and analytics, while Graylog starts with log collection and management.
A Wazuh vs Elastic vs Graylog 2026 review is most useful when it separates these starting jobs instead of naming one universal winner. Choose by the work your team must do every day, not by a feature checklist alone. Elastic Security combines Elasticsearch and Kibana with a security application. Graylog can centralize logs, while Graylog Security adds a paid SIEM path.
| Platform | Primary focus | Strongest starting point | Main trade-off |
|---|---|---|---|
| Wazuh | Endpoint security | Endpoint telemetry and FIM | Behavioral detections need more work |
| Elastic Security | Search and analytics | Search and detection rules | Pipeline and cluster work |
| Graylog | Log management | Log ingestion and pipelines | Security features need a paid tier |
Pick the platform that matches the team’s main security job. A broad feature list cannot replace a workable daily process.
Teams can also collect endpoint events with Wazuh and analyze them in Elastic. That setup can pair host coverage with flexible search, but staff must operate two systems and maintain their data flow. The difference resembles choosing between a password manager and a security monitoring tool: one cannot replace the other, as this password manager security comparison explains.
Wazuh, Elastic Security, and Graylog each address a different starting need. Wazuh supports teams that need free endpoint coverage and compliance reporting. Elastic fits teams that put search-led analytics first and can budget for advanced features. Graylog suits teams that need to bring scattered application and network logs into one searchable place.
Wazuh is endpoint-first and Graylog is log-first, a distinction that helps keep the choice practical. A team whose urgent problem is making scattered application and network logs searchable should put Graylog ahead of an endpoint-led deployment.
What do the licenses actually allow?
Wazuh is the simplest of these three to classify: its GPLv2 platform has no paid tier or feature gate. Free to use does not mean every platform uses an open-source license, or that every security feature costs nothing. A source-available license lets people inspect code, but its terms differ from an OSI-approved open-source license.
Check the license and the feature tier separately. Wazuh uses GPLv2 and has no agent or log-volume cap. Graylog Open uses the Server Side Public License (SSPL), which is source-available but not OSI-approved. Graylog Security is its paid SIEM tier.
| Platform | License status | Paid feature tiers |
|---|---|---|
| Wazuh | GPLv2, OSI-approved | No paid tier |
| Elastic Stack | AGPLv3 option, SSPL, Elastic License | Paid Security features |
| Graylog Open | SSPL source-available | Graylog Security |
| OpenSearch | Apache 2.0, OSI-approved | No license tier for Security Analytics |
Elastic added AGPLv3 as a license option for Elasticsearch in September 2024. Its other license options include SSPL and the Elastic License. The Elastic Stack can still have paid Security features, even when a license permits source access.
Wazuh, OpenSearch, and OSSEC are OSI-approved open-source projects. Graylog Open is not. OpenSearch is an Apache 2.0 fork of Elasticsearch and Kibana, while Elastic has its own license choices and paid tiers.
For teams comparing fully open source tools, the label alone does not settle the issue. A license can allow source access while feature access depends on a subscription. Check both the project license and the feature-tier matrix before treating a platform as fully open source.
What does Wazuh do well, and where does it need help?
Wazuh is a strong first choice when a small team wants endpoint agents, FIM, and compliance capabilities in one free platform. Its endpoint focus gives a team a place to collect host data, track file changes, and review vulnerability findings.
Wazuh bundles useful endpoint controls, but teams still own detection quality. Its manager processes agent data, an OpenSearch-based indexer stores it, and a dashboard helps analysts review alerts. Agents on endpoints send telemetry to the manager.
Endpoint telemetry, file integrity and compliance
FIM watches chosen files and folders for changes, including new, changed, or deleted items. It can help a team spot unexpected edits to key system settings. Wazuh can also show who and what process made a change through its who-data feature.
Wazuh adds vulnerability detection and compliance dashboards for CIS, PCI-DSS, and GDPR. Those dashboards can help a lean team check its status against common requirements. The Wazuh FIM guide for NIST 800-53 shows how file checks can support change controls.
Use these fit checks before rollout:
- Do your endpoints need agent-based coverage?
- Must the team watch changes to key files?
- Do you need vulnerability monitoring on hosts?
- Would compliance dashboards help your reporting work?
Detection content and rule format
Wazuh’s native rules use XML rules and decoders, not Sigma. Its default content is stronger in compliance and vulnerability signatures than in behavioral detections mapped to MITRE ATT&CK. Teams seeking more behavior-based alerts need to build, test, and maintain rules.
That work may fit a team with clear host use cases and staff who can tune alerts. A team mainly seeking network visibility may need another platform alongside Wazuh. Endpoint agents do not replace network sensors.
What changes with Wazuh 5.0
Wazuh 5.0 was in beta in mid-2026. Planned changes include clustering by default and removing the Filebeat dependency. Those changes were plans, not shipped features at that time.
Wazuh’s coverage can be a helpful base, though no install can guess which local behaviors matter most. Teams should map their key risks to specific rules and alert tests. Treat Wazuh’s behavioral detection coverage as a content-engineering responsibility, not an automatic result of installing the platform.
When is Elastic Security the stronger choice?
Elastic Security is the better fit when search depth and analytics matter more than getting a preconfigured endpoint-first platform. Search-led work suits teams already using the Elastic Stack or teams that need flexible queries across many data types.
Elastic’s flexibility brings pipeline, tuning, and cluster work. Elasticsearch stores and searches data, while Kibana gives analysts a place to query and investigate. Beats or Elastic Agent can ship data into the platform.
Search and prebuilt detections
Elastic supports Lucene, EQL, and ES|QL query options. These let teams search data in different ways and build searches around their events. Elastic Security also offers prebuilt rules that can give a team a useful head start.
On the Basic self-managed tier, Elastic Security includes Elasticsearch, Kibana, Elastic Common Schema, and prebuilt SIEM detection rules mapped to MITRE ATT&CK. That mapping helps teams connect detections with known attack behaviors, but each rule still needs to match their data.
What Basic includes
Basic includes a usable search and security base for self-managed teams. Elastic Common Schema helps align event fields across sources. That can make cross-source searches easier when teams map their data consistently.
Teams with Elastic skills may find the platform easier to adopt because they already know its query tools and data flow. The same flexibility can create extra work when data fields, pipelines, and rules need tuning.
Which capabilities require a higher tier
Machine-learning anomaly jobs, prebuilt-rule customization workflows, and alert suppression require the Platinum subscription tier. These features can matter when a team needs to spot unusual activity or reduce repeat alerts.
Elastic’s feature list changes by subscription and deployment. The Elastic subscription feature list shows tier limits, including rules tied to anomaly detection. A team should factor those gates into its design before building a workflow around a feature.
Elastic Security can be a strong choice when the team has time to manage queries, fields, and cluster health. A small group without those skills may spend more time tuning than investigating. Before choosing Elastic for a detection feature, confirm which subscription tier enables it.
What can Graylog Open do without a paid tier?
Graylog Open is useful for free log collection and search, but Graylog Security is the tier that adds its security detection features. For log management, the free edition can collect, parse, route, and search events, then show them in dashboards.
Graylog Open has basic triggers and notifications, not the paid security detection set. It also includes streams and pipelines, which can help route events by their content. A team can use it to get scattered logs into one place.
Basic triggers can flag conditions and send notifications. They are not the same as the detection rules and Sigma support in Graylog Security. The paid tier also adds rules mapped to MITRE ATT&CK, machine-learning anomaly detection, risk triage, and automatic case creation.
A team that needs log centralization but not security alerting may find Graylog Open sufficient. It can help make application and infrastructure events easier to search. That is a useful role for a log-management platform, especially when teams need a shared view of system activity.
Teams that expect full SIEM detection from the free edition may be disappointed. Graylog separates log management from its paid security path, so users should not assume basic triggers provide those advanced features.
The difference matters for teams with a limited budget. Graylog Open can cover collection and search, while security detections call for a paid plan and a separate budget decision. Decide whether you need log visibility or security detection before treating Graylog Open as a complete SIEM.
Wazuh vs Elastic vs Graylog 2026: Which One Costs Less?
Wazuh has no license charge, while Graylog and Elastic costs depend on the tier and billing model a team needs. The true cost includes more than the subscription: data volume, retention, compute, and staff time can change the bill.
Compare the billing unit and the minimum commitment, not just a starting rate. Graylog charges by processed data in the active data tier. Elastic offers metered cloud options and Hosted plans, each with different cost drivers.
Graylog subscription units and minimums
Graylog Security starts at $18,000 per year. Its entry points are 10 GB per day under daily-volume licensing or 100 GCUs under annual-consumption licensing. A GCU is a consumption unit.
Graylog Enterprise starts at $15,000 per year, with entry points of 10 GB per day or 100 GCUs. One GCU redeems for 20 GB of Graylog Security data or 25 GB of Graylog Enterprise data.
Graylog counts processed data in the active data tier, not devices, users, total stored data, or connected sources. Annual subscriptions use one- to five-year contract terms. The Graylog minimums and GCU redemption rates make the edition difference clear.
Elastic’s metered and hosted options
| Product or tier | Starting rate | Billing unit | Important condition |
|---|---|---|---|
| Graylog Security | $18,000 per year | 10 GB/day or 100 GCUs | One- to five-year annual term |
| Graylog Enterprise | $15,000 per year | 10 GB/day or 100 GCUs | One- to five-year annual term |
| Elastic Security Serverless | $0.09 ingest, $0.017 retained | Per GB; retention per month | Rates listed in October 2026 |
| Elastic Cloud Hosted | $99 Standard, $114 Gold, $131 Platinum, $184 Enterprise | Per month | 120 GB storage, two availability zones |
| Elasticsearch Serverless | $0.14 ingest, $0.09 search, $0.07 ML | Per VCU hour; storage $0.047/GB monthly | Rates listed in October 2026 |
Compare the bill drivers, not just the starting price
Graylog’s entry price is a substantial annual commitment. Elastic’s metered and Hosted costs rise with data volume, retention, compute, and configuration. Its Hosted production starting point uses 120 GB of storage across two availability zones.
The Hosted starting price is not a full production estimate for every workload. Higher RAM, more storage, or extra availability zones raise costs. A team should estimate its own daily ingest and search needs before comparing plans.
Model ingest, retention, search, and availability-zone needs before comparing any starting price.
How do detection rules work across the three platforms?
Sigma rules are portable between tools, but most SIEMs still need a conversion or integration step before they can alert on them. Sigma is a shareable detection format, not a query language that every platform runs in the same way.
A rule bundle only helps when its fields match the team’s real log sources. Detection engineering includes mapping data, testing rule logic, and tuning noisy results. Each platform handles that work differently.
Wazuh and Elastic need rule conversion
Wazuh uses XML rules and decoders as its native format. Teams can convert Sigma rules through a community backend, but the result needs review and testing. The conversion step does not ensure that local logs contain the needed fields.
Elastic Basic includes prebuilt MITRE ATT&CK-mapped SIEM rules. Custom rules need to use Elastic’s query format. Teams should plan to map their data and adjust queries to fit their event fields.
Graylog separates free logs from paid detection
Graylog Open supports log management, but it has no supported Sigma alerting path. Graylog Security supports Sigma import and adds security detection features. The paid tier is the route for teams that want those features inside Graylog.
OpenSearch is the closest native Sigma path
OpenSearch Security Analytics offers a more direct Sigma workflow. It includes roughly 2,200 prepackaged Sigma rules and a detector framework that maps rules to log sources.
| Platform | Sigma path | Main work |
|---|---|---|
| Wazuh | Community conversion | Convert to XML rules and decoders |
| Elastic | Query-format conversion | Map fields and tune custom rules |
| Graylog Open or Security | Security tier supports import | Use paid tier for Sigma detection |
| Security Onion | Suricata uses separate rule syntax | Manage network rules in parallel |
| OpenSearch | Native Sigma workflow | Map detectors to log sources |
Even prepackaged rules need testing against local logs and tuning for false positives. A detector mapped to the wrong source may miss events or create noise. Verify the rule’s data-source mapping and test alerts in your own environment before relying on a converted rule.
Which platform covers endpoints, integrity and compliance?
Choose Wazuh first when file integrity monitoring and bundled endpoint security are non-negotiable. Its agent-based approach ties endpoint telemetry to FIM, vulnerability visibility, and compliance dashboards.
A log platform can receive endpoint logs without providing the same endpoint controls. Elastic Security can collect endpoint data through Elastic Agent, while Graylog focuses on receiving and managing logs.
Use this checklist to compare what your controls require:
- Agent-based endpoint coverage
- File integrity monitoring
- Vulnerability visibility
- Compliance dashboards
Wazuh bundles the four needs most directly. Its compliance dashboards include CIS, PCI-DSS, and GDPR. Elastic can bring endpoint data through its agent and offers prebuilt MITRE ATT&CK-mapped rules on Basic self-managed.
Graylog can accept logs from endpoint sources, but its main role is log management rather than endpoint controls. A stream of endpoint logs may help investigations, yet it does not give the same agent functions as a platform designed for host monitoring.
Check which events your compliance controls expect to see, then confirm that the agent can report them. A dashboard is only useful when its underlying events match the control. Confirm that an agent reports the endpoint events your compliance controls actually require.
Which log sources and data pipelines can each platform handle?
Graylog is a natural fit when a team needs to bring many kinds of logs into a common pipeline. Log collection is more than storage: it includes sending, parsing, routing, searching, and keeping data for a set period.
Inconsistent fields make searches and detections less reliable. Graylog accepts Syslog, CEF, GELF, Beats, and NetFlow inputs. It has also offered an OpenTelemetry gRPC input for OTLP logs since version 6.2.
The OTLP input handles logs, not a full metrics-and-traces platform. That distinction matters if your team wants one system for observability signals beyond security events.
Elastic Stack includes Elasticsearch and Kibana, with Beats or Elastic Agent available to ship data. Wazuh collects endpoint telemetry through its own agents. Each route has a different starting point, so teams should map important sources before expanding their pipeline.
NIST’s log management planning guide describes planning for log generation, transfer, storage, access, and disposal. Those tasks support incident review, troubleshooting, and records needs. Log planning also helps a team decide what data to keep and who needs access.
Normalize important fields before adding every source. A firewall, server, and cloud service may name the same user or IP field differently. Test parsing and field normalization on the noisiest source before routing every log into long-term storage.
How much hardware and operating effort should teams plan for?
A small self-hosted deployment still needs enough memory and staff time to keep indexing and detection healthy. Planning estimates can help a team start, but actual needs rise with ingest, retention, agent count, and network traffic.
These are starting points, not guarantees. A busy environment or production deployment may need more resources. The team also needs time for upgrades, storage care, tuning, and alert review.
Use these rough estimates for early planning:
- Wazuh single node: about 4 vCPU and 8-16 GB RAM.
- Elastic self-managed single node: about 4 vCPU and 8-16 GB RAM; Elasticsearch heap uses roughly half the RAM.
- Graylog Open: about 4 vCPU and 8 GB RAM.
- OpenSearch Security Analytics: about 4 vCPU and 8-16 GB RAM.
- Security Onion evaluation: commonly 12 or more CPU cores and more than 20 GB RAM.
Production Security Onion deployments need more resources than a modest evaluation setup. Its needs also track network traffic, so endpoint count alone cannot predict hardware use.
Hardware is only part of the operating load. Staff must tune pipelines, plan upgrades, keep storage healthy, and review alerts. A free license can still place a real burden on a team with little time.
NIST log guidance also stresses the value of planning how an organization creates, stores, accesses, and retires log data. That work can support incident response and records needs. Recheck current deployment guidance against expected ingest and retention before committing hardware.
When does Elastic Cloud or a self-hosted deployment make sense?
Choose managed Elastic Cloud when reducing cluster operations matters more than controlling every infrastructure detail. Managed hosting can reduce the work of maintaining the underlying service, while self-hosting gives your team direct control.
Managed service does not mean every Security feature comes with Basic. Elastic Security offers self-hosted Basic, paid Platinum and Enterprise tiers, and managed Elastic Cloud. The feature tier and deployment model are separate choices.
Self-hosting puts capacity planning, upgrades, and maintenance on your team. It can suit groups that have staff to manage the stack or need control over where and how it runs.
Elastic Cloud Hosted and Serverless have different billing models. Hosted gives teams a managed cluster configuration, while Serverless uses metered service units. Either approach still needs planning for data volume, retention, and the Security tier.
A cloud deployment can reduce infrastructure work, but it does not remove the need to choose the right subscription. Teams should know which Security features they need before designing around them. Confirm both deployment model and feature tier before moving security data into a hosted environment.
Can Wazuh and Elastic work together, and what is OSSEC’s role?
Yes, Wazuh agents can feed endpoint data into Elastic, but the combined setup adds another pipeline to operate. The pairing can bring host telemetry into Elastic search and analytics, though it creates more moving parts.
Set clear ownership for data flow, storage, and detection rules. Wazuh began as an OSSEC fork, and its current indexer is based on OpenSearch rather than Elastic Stack.
Teams can forward Wazuh agent data to Elastic Security, then use Elastic to search and investigate it. Wazuh documents routes using its indexer or the server’s alerts.json file. Its integration guide explains the Logstash setup and related data views.
Plan who normalizes the data, where copies are stored, and which team maintains each rule. Rules may need to exist in both tools if both systems raise alerts. That can lead to duplicated work and competing signals during an investigation.
For teams seeking open-source alternatives to Wazuh, OSSEC remains an OSI-approved project. Elastic and Graylog use different license and feature-tier models, so they are not direct license matches.
Running both Wazuh and Elastic can make sense during a pilot or validation effort. It is not automatically a simpler permanent design, especially for a lean team. Pick one primary system of record for detections so investigators do not have to reconcile competing alerts.
When is Security Onion a better fit than either platform?
Security Onion is the stronger fit when a team needs network evidence as well as host and log monitoring. Network visibility comes from combining sensors and analysis tools, not simply adding another log input.
Security Onion asks more of both hardware and analysts. Its Linux distribution brings together Suricata, Zeek, Elastic Stack, and Wazuh, along with TheHive and CyberChef.
Network visibility with host monitoring
Suricata provides network monitoring, while Zeek gives teams another way to inspect network activity. Elastic Stack supplies storage and search, and Wazuh adds host monitoring. TheHive and CyberChef are also part of the distribution.
This mix can help a team connect network evidence with endpoint events. It is more than a log platform, so the team needs a clear reason to collect and analyze network traffic.
Hardware and analyst skills
Analysts need to interpret network telemetry and connect it to other events. The deployment also needs dedicated resources; the sizing estimates earlier provide a rough evaluation starting point.
A 2026 intrusion-software comparison rated Wazuh 8.5 out of 10 and Security Onion 7.2 out of 10. That score is a comparative rating, not proof that one platform suits every team better.
Do not collect network telemetry unless the team can investigate it. Extra data without analyst time can create noise instead of useful evidence.
Security Onion can be excessive when the actual need is only endpoint telemetry or centralized logs. Choose it only when the team can investigate the extra network telemetry it collects.
Is OpenSearch Security Analytics worth considering?
OpenSearch Security Analytics is worth shortlisting when native Sigma-driven alerting matters more than a built-in endpoint agent. Its direct rule path can suit teams that want Sigma content and detector mapping without a paid license tier.
OpenSearch has no built-in endpoint agent. Security Analytics can alert on collected data, but another agent or shipper must provide endpoint telemetry.
Sigma rules and detector mapping
OpenSearch Security Analytics includes roughly 2,200 prepackaged Sigma rules. Its detector framework maps rules to log sources, which gives teams a direct route from rule content to alerts.
That mapping can save conversion work, but it does not prove that each rule fits local data. Teams still need to confirm field names, source types, and alert quality.
What the team must assemble
Teams need to supply endpoint events through another agent or shipper and assemble the wider platform around OpenSearch. That includes setting up useful sources, storage, dashboards, and the work needed to review alerts.
Native Sigma support does not remove the need to validate log mappings or tune rules for local data. Confirm the data sources you can collect before treating a rule bundle as usable detection coverage.
When do CrowdStrike Falcon or CrowdSec belong in the shortlist?
Add Falcon to the shortlist when the goal is paid endpoint protection, not simply a different way to manage SIEM logs. Falcon is endpoint security, while CrowdSec focuses on intrusion prevention through behavior analysis and shared threat signals.
Neither tool replaces centralized search, compliance reporting, or a SIEM detection workflow. Falcon is a commercial endpoint-security option, not a like-for-like SIEM replacement.
Falcon Go costs $7.99 per device per month or $59.99 per device per year in the United States. Falcon Pro costs $14.99 per device per month or $99.99 per device per year. Falcon Enterprise costs $19.99 per device per month or $184.99 per device per year.
Falcon Pro adds centralized host firewall management to Falcon Go. Falcon Enterprise adds EDR, threat intelligence, and hunting. That makes the tier choice depend on the endpoint functions a team needs.
CrowdSec is a free, open-source intrusion-prevention system. It analyzes behavior and can use community-shared IP threat signals to automate blocking. That role differs from searching and investigating events across a company.
Prevention can help stop some unwanted traffic, but it does not replace a record of system activity or a full detection workflow. Compare endpoint protection and SIEM capabilities separately when deciding whether either tool fills a gap.
Conclusion
Wazuh is the most direct fit for free endpoint-led security, while Elastic and Graylog win when search or log management is the primary need. Security Onion suits teams that need network visibility, and OpenSearch Security Analytics deserves a look for native Sigma workflows.
Choose Elastic when your team can manage its tiers, and budget deliberately for Graylog security features. A short pilot should use representative endpoint, network, and application data. Before committing, run a pilot against representative data and confirm that the team can maintain its detections.
FAQ
Is Wazuh really free to use in production?
Yes, Wazuh is GPLv2 and has no paid tier, agent cap, or log-volume cap. That means you can use its platform without a license bill, but the system still needs servers, storage, and staff time. Teams must plan for upgrades, detection tuning, alert review, and data retention. Free software can still create meaningful operating costs.
Does Graylog Open include security alerts?
Graylog Open includes basic triggers and notifications, but it does not include the full security detection set. Sigma support and Graylog Security detection features belong to the paid Security tier. Open can still work well for log collection, pipelines, dashboards, and search. A team should not mistake a basic trigger for a full SIEM detection workflow.
Can I run a Sigma rule directly in Wazuh?
No, Wazuh does not have a built-in Sigma engine. Wazuh uses XML rules and decoders, so teams need to convert Sigma rules through a community backend before using them. The converted rule still needs testing against local event fields and tuning for false alerts. A successful conversion does not prove the rule will detect the intended behavior.
How does Graylog calculate its license size?
Graylog calculates license size from processed data in the active data tier, not device count, users, total stored data, or connected sources. Its GCU redemption differs by edition: one GCU covers 20 GB of Graylog Security data or 25 GB of Graylog Enterprise data. That makes the edition and processing volume key parts of a cost estimate.
Can Wazuh agents send data to Elastic Security?
Yes, Wazuh agents can provide endpoint telemetry that teams forward into Elastic Security. The combined setup needs a plan for forwarding, normalization, storage, and detection ownership. Teams may also need to maintain similar rules in both systems, which adds work. It can help during a pilot, but two platforms do not automatically make operations simpler.
Is OpenSearch Security Analytics a complete endpoint security platform?
No, OpenSearch Security Analytics does not include a built-in endpoint agent. It provides Sigma-oriented analytics and alerting, so teams need another agent or shipper to collect endpoint data. It can then analyze supported sources through its detector framework. Teams still need to map their logs and tune rules for their environment.
