Open-source alternatives to Microsoft Sentinel

Which open-source alternative to Microsoft Sentinel fits your situation

Choose the option by the problem you are solving. Wazuh fits teams that want an XDR and SIEM platform with file integrity monitoring, vulnerability detection and compliance support for PCI DSS and GDPR, using lightweight agents on endpoints and servers. OpenSearch fits teams that already have log pipelines and want a search and analytics layer they operate themselves, with detection logic built on top. Graylog fits teams whose main need is log management with SIEM and threat detection added later. Security Onion fits teams whose priority is network monitoring, since it bundles Suricata, Zeek and the Elastic Stack for threat hunting. Most Sentinel customers will find that one platform covers the core need, with the others as complements. The usual trigger is the Defender portal transition. Microsoft states that Sentinel will no longer be supported in the Azure portal after March 31, 2027, and that moving to the Defender portal has no extra cost. The cost question is therefore not the migration itself but what changes once Sentinel runs there. When it does, Microsoft Defender XDR data privacy and retention policies apply instead of Sentinel's, and the Fusion analytics rule is replaced by Defender XDR correlation. Before you renew or plan the move, ask your Microsoft account team to confirm in writing which retention periods, data residency terms and correlation behavior will apply to your workspace. For each workload, run a short check before deciding. List the data sources you ingest, the retention each regulator or internal policy requires, and the detections that depend on Fusion or Defender correlation. Those detections are the ones that will need rebuilding in an open-source platform, and they should be costed separately from ingestion. If data residency is the driver, confirm where each option will store data in your own cloud account or data center, since self-hosting moves that decision to your team.

Which self-hosted platform replaces which part of Sentinel

Sentinel bundles log collection, search, analytics rules, case handling and threat intelligence into one cloud service. No single open-source product copies all of that, so most teams combine a collector, a search backend and a detection layer. The cards below describe where each candidate fits and what it gives up.

Wazuh as an endpoint-led XDR

Wazuh combines lightweight agents, a server for log analysis, the Wazuh indexer, and a dashboard, and it is licensed under GPLv2. Its agents cover file integrity monitoring, vulnerability detection and compliance support for PCI DSS and GDPR, which makes it a close functional match for Sentinel's host-centric detections. The trade-off is that Wazuh is opinionated about its own agent and rule model, so existing KQL analytics rules must be rebuilt as Wazuh rules rather than copied. Confirm agent coverage for every operating system in your estate before committing.

OpenSearch as the storage and query layer

OpenSearch is Apache 2.0 licensed and was forked from Elasticsearch 7.10.2 and Kibana 7.10.2. It keeps wire compatibility with the Elasticsearch 7.10 REST APIs, which helps teams reuse existing ingestion pipelines and dashboards. It is a search and visualization foundation rather than a finished SIEM, so detection content, case management and correlation logic must be built or supplied on top. Confirm which query and alerting features your team needs before choosing it as the sole layer.

Graylog for log management and detection

Graylog Open is free to self-manage under the Server Side Public License and has no ingestion caps. Graylog Enterprise adds data lake and storage options with support, and Graylog Security adds SIEM, threat detection and anomaly detection. This suits organizations that want log search, alerting and a single console without running a separate Elastic-style stack. Expect to pay for the higher tiers if you need the security content or vendor support. Have counsel review SSPL terms if you plan to offer Graylog as a managed service.

Security Onion for network visibility

Security Onion is a free Linux distribution that bundles Suricata, Zeek and the Elastic Stack for threat hunting and security monitoring. It fits teams that need network traffic analysis alongside logs, a gap that Sentinel covers mainly through connectors and Defender signals. The repository is licensed under the Elastic License 2.0, and a paid Security Onion Pro tier exists for additional features. The main trade-off is that it is a full sensor and monitoring platform, so sizing and sensor placement need planning. Have counsel confirm Elastic License 2.0 terms for your use case.

How Sentinel capabilities map to open-source options

This table maps each major Microsoft Sentinel capability to Wazuh, OpenSearch, Graylog and Security Onion, with the gaps marked in each cell. Read the cells as starting points to confirm in a proof of concept, since no open-source platform reproduces Sentinel's Defender XDR correlation or its managed connector catalog one for one. The main takeaway is that log collection and retention map well, while KQL rules, multi-signal correlation, UEBA and SOAR need deliberate rebuilding.

Sentinel capability	Wazuh	OpenSearch	Graylog and Security Onion
Log collection and data connectors	Lightweight agents collect endpoint and host logs. Network and cloud sources need custom decoders or collectors, so confirm each source.	Ingests through Logstash, Data Prepper or Beats-style shippers. Connector coverage is built by your team rather than provided as a catalog.	Graylog accepts syslog, GELF and inputs for many sources. Security Onion bundles Suricata and Zeek sensors for network telemetry.
KQL analytics rules	Not native. Detection rules use Wazuh XML rule syntax, so KQL logic must be rewritten by hand and retested.	Not native. Query and alerting features use OpenSearch query DSL or PPL, so each KQL rule needs translation and validation.	Not native. Graylog uses its own search language and Security Onion uses Elastic-based queries, so expect manual conversion.
Scheduled and near-real-time detections	Real-time analysis of incoming events is a core function. Scheduled correlation across longer windows needs custom work.	Alerting monitors run on schedules you define. Confirm latency and resource use at your expected event rate.	Graylog event definitions and streams support real-time and scheduled alerting. Security Onion alerting depends on its bundled Elastic components.
Fusion correlation (replaced by Defender XDR correlation)	Gap. Multi-signal correlation across identity, endpoint and cloud must be rebuilt as composite rules.	Gap. Cross-source incident grouping must be designed as monitors, correlation rules or custom pipelines.	Gap. Graylog Security may add correlation features, so confirm the tier and capabilities before relying on it.
UEBA and anomaly detection	Confirm coverage. Baselining is limited compared with Sentinel's built-in entity analytics.	Anomaly detection plugins exist in the ecosystem. Confirm maturity and licensing for your use case.	Graylog Security is described as including anomaly detection. Confirm which features are in the tier you select.
SOAR playbooks	Active response can run scripts on agents. Multi-step orchestration is not a built-in playbook engine, so confirm integration options.	No built-in playbook engine. Automation usually runs through external workflow tools you select and maintain.	Confirm integrations for Graylog and Security Onion with your existing SOAR platform before planning cutover.
Threat intelligence feeds	Confirm which feed integrations are available and how indicators are matched against events.	Indicator matching is built with queries or pipelines. Feed ingestion is handled by your team.	Lookup tables and feeds can be configured in Graylog. Security Onion bundles some intelligence tooling, so verify its current contents.
Workbooks and dashboards	Dashboard component is included. Rebuilding Sentinel workbooks as Wazuh dashboards is manual.	OpenSearch Dashboards is a Kibana-derived interface. Workbook layouts must be recreated, not imported.	Graylog dashboards and Security Onion Kibana-style views both need manual rebuilding from existing workbooks.
Long-term retention	Retention depends on indexer storage sizing and index lifecycle settings you configure.	Index lifecycle and snapshot repositories control retention. Storage cost depends on your chosen tier and volume.	Graylog Enterprise adds data lake and storage options with support. Confirm retention tiers with the vendor for your volume.

How to translate KQL analytics rules without losing detection logic

Translating KQL analytics rules is a rewrite, not a copy, and the first task is an inventory. Export every scheduled and near-real-time rule from the Sentinel workspace, then group them by the tables they query (for example, SigninLogs, SecurityEvent, CommonSecurityLog or DeviceProcessEvents) and by severity. Record the query, the schedule, the lookback window, the entity mappings, the alert grouping settings and the automated response attached to each rule. Mark which rules depend on Fusion or Defender XDR correlation, because those will not translate into a single query. A rule that exists only as a combined incident pattern needs to be redesigned as separate detections in the target platform.

Next, map every field the rules reference to its equivalent in the target. In OpenSearch, that means the index mappings and query DSL, so a KQL where clause on a field such as ResultType becomes a bool filter against the field name your ingestion pipeline actually writes. In Graylog, the same logic moves into search queries and alert conditions. In Wazuh, detections become decoders and rule XML, and fields are extracted at decode time. Field names that differ by source, such as user principal names versus local account names, are the most common cause of silent gaps. Confirm the tooling you intend to use for conversion in your own environment, since no supplied fact guarantees that KQL converts automatically, and expect manual review of every rule that uses joins, summarize or time windows.

Validate each translated rule by replaying the same historical events through both platforms and comparing results. Run the two stacks in parallel for a period agreed with your SOC, and compare alert counts, the entities flagged and the time to alert for each rule. Investigate every difference in either direction: a missing alert means a coverage gap, and an extra alert usually means a field or threshold mismatch. Keep the Sentinel rules enabled until the parallel run confirms equivalence for high and critical rules, and record the sign-off for each rule so your auditors can trace the evidence.

What Sentinel versus self-hosted costs include over several years

This table lists each cost component of staying on Sentinel and of self-hosting Wazuh or OpenSearch, showing who is paid, whether the cost is one-time or recurring, and what drives it up or down. No prices are shown because they depend on your volume, region, retention and scope, so use the rows to build the questions you send in a quote.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Sentinel ingestion and retention charges	Microsoft, through your Azure billing	Recurring	Daily ingested volume, retention period and the tables you send to analytics tiers versus lower-cost tiers
Azure consumption (log storage, queries, related services)	Microsoft, through your Azure billing	Recurring	Query frequency, workbook and rule load, and cross-region data movement
Self-hosted compute, storage and network	Your cloud account or data center provider	Recurring	Indexed volume, hot versus cold storage tiers, replica count and egress from collectors
Backups and disaster recovery for self-hosted indexes	Your infrastructure team and storage provider	Recurring	Retention period, snapshot frequency and whether backups are kept in another region or site
Licensing for Wazuh, OpenSearch, Graylog Open and Security Onion	No license fee for the open-source editions	Recurring only if you buy a paid tier	Choice of Graylog Enterprise or Security, Security Onion Pro, or support contracts; confirm terms with each vendor
Implementation and rule translation	Internal staff or an implementation partner, under a written scope	One-time	Number of analytics rules, custom parsers and dashboards, and how many KQL rules need manual rewriting
Data migration and parallel running	Internal staff or an implementation partner	One-time	Historical data you keep, and how long Sentinel and the new platform run side by side during cutover
Support retainers, upgrades and security testing	Internal team, an implementation partner or a support vendor	Recurring	Upgrade cadence, on-call expectations, and the SLA level you require in writing
Internal skills and staffing	Your employees or contractors	Recurring	Team familiarity with Elastic-style query languages and Linux operations versus existing KQL and Azure skills

What you give up when you leave Defender XDR correlation

Moving Sentinel analytics to a self-hosted platform means taking on work that Microsoft currently carries. Each item below is a capability that Defender XDR or Microsoft's cloud services provide today, with the usual way teams replace it and the questions to settle before cutover.

Cross-product incident graph

In the Defender portal, alerts from endpoint, identity, email and cloud sources are grouped into one incident graph. Self-hosted Sentinel alternatives do not reproduce this automatically. Teams usually rebuild it with correlation rules in Wazuh or OpenSearch that join events on user, host and session identifiers, and they document which entity keys each rule uses. Confirm which of your current incidents depend on that grouping before you choose a platform.

Fusion correlation replacement

When Sentinel runs in the Defender portal, the Fusion analytics rule is replaced by Defender XDR correlation. Fusion multi-stage detections will not carry over as written. Plan to translate the attack chains you rely on into explicit rules, and test each against recorded attack sequences from your own environment. Expect a period where some chains are detected by fewer rules than before.

Microsoft-managed threat intelligence

Microsoft updates detection content, threat intelligence and analytics templates on its own schedule. A self-hosted deployment receives only what you import or subscribe to. Plan a feed for indicators, such as a commercial or community STIX/TAXII source, loaded into OpenSearch or Wazuh lookups. Ask each provider for update frequency, licensing terms for commercial use, and how expired indicators are removed.

Managed platform availability

Microsoft operates the Sentinel service, its scaling and its patching. Under a self-hosted model, your team or a partner owns cluster availability, indexer capacity, certificate rotation and upgrades. Write a runbook for node failure, disk pressure and failed log ingestion, and decide who is on call for each. Your recovery objectives should be set before the platform goes live.

Native Entra ID and Microsoft 365 connectors

Sentinel ships with built-in connectors for Entra ID sign-in and audit logs and for Microsoft 365 activity. Self-hosted platforms collect the same data through API polling, Graph exports or event forwarding, which need credentials, scopes and parsing maintained by your team. Inventory every Microsoft data type currently ingested, then confirm for each whether a supported agent, integration or custom collector exists and who will maintain it.

Vendor-managed retention and privacy

Inside the Defender portal, Microsoft Defender XDR data privacy and retention policies apply instead of Sentinel's own settings. Outside it, retention, storage tiers and deletion are yours to set. Map each log source to a retention period required by your policies and regulators, and decide where archives sit and who can query them. Confirm these settings with your compliance lead before the portal move, since they change how historical data is searched.

How a Sentinel migration runs from inventory to decommission

This sequence moves detections, data and collectors from Microsoft Sentinel to a self-hosted platform in an order that keeps alerting intact until the new stack is proven. Each step produces a record that the next step depends on, so the team can show what moved, what was validated and what was retired. The March 31, 2027 date for Sentinel in the Azure portal sets the outer boundary for planning.

Inventory connectors, tables and rules
Your security engineering lead and the Sentinel workspace owner list every data connector, Log Analytics table, analytics rule, hunting query, workbook, playbook and watchlist, and record the retention period and compliance reason for each data type. Include Fusion and any Defender XDR incident correlation that currently produces incidents, because that logic has no direct one-to-one equivalent on a self-hosted stack. The step is complete when the inventory has an owner, a data volume estimate from your own billing data, and a retention requirement for every item. Confirm with your compliance lead which retention obligations apply before anything is switched off. Mark the March 31, 2027 Azure portal cutoff on the plan so every later milestone is measured against it.
Confirm retention and export needs
Your compliance lead and platform engineers decide which historical data must be kept, in what format and for how long, and whether it moves to the new platform or stays in archived storage. Vendor export paths differ, so verify what Log Analytics and Sentinel allow you to export, in what format, and at what cost in your own tenant. Plan any historical exports as separate jobs, not as part of the live pipeline. The step closes when the retention decision is signed off and every dataset has a named destination, either a migrated index in OpenSearch or Wazuh, an archive, or a documented deletion date.
Map KQL rules and workbooks to the target
Detection engineers translate each KQL analytics rule into the query language and alerting model of the target platform, whether Wazuh rules and decoders, OpenSearch alerting monitors or Graylog streams and pipeline rules. Workbooks are rebuilt as OpenSearch Dashboards or Wazuh dashboard views, and playbooks are re-expressed as response scripts or SOAR integrations you choose. Each translated item is tagged with its source rule ID and a status of ready, rewritten or retired. Expect some KQL functions to have no direct equivalent, so record those as gaps rather than forcing a poor match. The step is done when every item has a status, and the gap list has been reviewed by the people who own those detections.
Pilot on one data source
Choose one low-risk connector, such as a firewall or identity log source, and route it to the self-hosted platform while Sentinel continues to ingest it as before. Platform engineers configure the collector, parsing and index mappings, and detection engineers run the translated rules against known test events. The pilot is complete when parsed fields match the Sentinel schema closely enough for the translated rules to fire on the test events and the team has confirmed storage growth and query speed with its own data. Record the findings, including any field-name differences, as inputs to the next wave.
Run in parallel and compare alerts
For a defined period agreed in advance by the SOC lead, both platforms receive the same sources. Analysts review alerts from each side and log every difference: alerts present in Sentinel but missing in the new platform, extra alerts, and changes in severity or entity mapping. Each gap must be explained as a rule fix, a parsing fix, or an accepted difference signed off by the SOC lead and compliance owner. This step produces a comparison log that shows which detections are proven. Do not start cutover until the log has no unexplained gaps for in-scope rules.
Cut over collectors and forwarders
Platform engineers re-point agents, syslog forwarders, API pollers and cloud log export pipelines from the Sentinel data connectors to the self-hosted collectors, one source group at a time. Each change is recorded in a change ticket with a rollback path, and the SOC confirms that events are arriving and that the matching detections are firing. Retire the Sentinel connector only after the replacement has run cleanly for the agreed observation window. The step closes when every in-scope source reports to the new platform and the Sentinel connector list is empty or documented as intentionally retained.
Decommission Sentinel and Log Analytics data
After the retention obligations confirmed in the earlier steps are met, the workspace owner exports any data that must be kept, removes analytics rules and connectors, and deletes or archives the Log Analytics tables and workspace according to the retention plan. Confirm that the Defender portal change, if you are still on Sentinel, has no residual dependency on the workspace. The step is complete when a signed decommission record lists what was deleted, where archived data sits and who approved the deletion. Keep that record with your audit evidence, because an independent auditor will ask for it.

Which option fits your situation: cost, residency, regulation or customization

Teams leaving Sentinel most often do so because ingestion charges grow faster than the detections they buy. Wazuh and Graylog Open both remove license fees for the core platform, which moves your spend to infrastructure, storage, and the people who run them. Graylog Open is free to self-manage under the Server Side Public License with no ingestion caps, and it can use OpenSearch as its storage backend. Wazuh is free under GPLv2 and bundles its own indexer, server, dashboard and agents.

Recurring costs shift to you: storage, compute, backups and retention become your bill, and they scale with event volume.
One-time costs are engineering time: rebuilding analytics rules, dashboards and collector configuration.
Support is optional and priced separately: Graylog Enterprise and Graylog Security add support and detection features on top of Graylog Open.
Retention drives the bill: keeping logs for compliance periods costs more than keeping them for active hunting.
Ask for a quote with volume assumptions: request a written scope that states daily ingest, retention period and hot versus cold storage.

Confirm first: your current daily ingest by log source, and which sources you can drop or sample without losing detections.

Questions teams ask before replacing Microsoft Sentinel

How much does it cost to move off Microsoft Sentinel?

The cost depends on the components you would own after the move, not on a single license swap. Expect four cost groups: infrastructure to run the platform (compute, storage and network in your own cloud account or data center), the one-time engineering effort to rebuild analytics rules, dashboards and collectors, the recurring operating effort to patch, back up and tune the stack, and any external services you buy. Storage is usually the largest recurring line because self-hosted retention is paid directly. Costs go down when you cut noisy sources and shorten hot retention, and up when you need long retention or high event volumes. Ask any quote to separate one-time migration work from recurring run costs, and to state its assumptions about daily ingestion and retention. Microsoft states that moving to the Defender portal has no extra cost, so a Defender portal move is a separate decision from a replacement project.

How long does a Sentinel migration take?

No fixed duration applies to every environment, so treat any single number with caution. The timeline is set by how many log sources you onboard, how many analytics rules you translate and validate, how much historical data you need to keep searchable, and how much of your SOC process depends on Sentinel-specific features such as automation playbooks and workbooks. Parallel running, where the old and new detections both alert for a period, usually lengthens the schedule but lowers cutover risk. Ask any provider for a written scope that lists the source count, rule count and retention target, and a plan that names the cutover criteria. A fixed-scope agreement gives you the deliverables and timeline in writing before work starts.

What does the migration need from our internal team?

The work needs named people from four functions: security operations engineers who own detection content, platform or infrastructure engineers who run the hosts and networks, data owners who confirm which logs matter and how long they must be kept, and compliance staff who define the evidence auditors will request. The most time-consuming internal task is usually validating that translated detections fire on the same test cases as before. Your team will also need to decide who patches, monitors and restores the platform after go-live, because that becomes a permanent duty. Confirm these commitments with your own managers before you accept a schedule, since the migration will stall if these people are unavailable.

Can our own team migrate off Sentinel without outside help?

A capable platform team can do it without outside help, provided it has the skills and time. The skills include Linux and container operations, index and storage tuning, log parsing, detection engineering, and experience with the Kusto Query Language used by Sentinel analytics rules. Teams that have never run a self-hosted SIEM often underestimate the operating workload after go-live. An outside partner can plan, implement, harden, document and support the platform inside your own environment, which can reduce that risk, but the decision should rest on an honest skills inventory. Ask any partner to state which tasks it will hand over to your staff and which it will keep.

Can Defender XDR correlation be replicated in open-source tools?

Only partly, and the gap should be measured before you commit. When Sentinel runs in the Defender portal, Microsoft replaces the Fusion analytics rule with Defender XDR correlation, which links signals across endpoint, identity, email and cloud products that Microsoft already collects. An open-source stack such as Wazuh can cover endpoint, file integrity, vulnerability and compliance use cases, and Security Onion adds network monitoring with Suricata and Zeek. Cross-product correlation of Microsoft-native signals is not something those tools reproduce out of the box. You would need to ingest the equivalent telemetry yourself, write correlation rules, and accept that some Microsoft signals may be unavailable. Map each Defender XDR detection your SOC relies on to a specific open-source source and rule before you decide.

Does the March 31, 2027 date force us to move?

No. The date changes where Sentinel is managed, not whether you can keep using it. After March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal. Your decision is therefore whether to adopt the Defender portal, whether to replace the platform, or both. If you stay on Sentinel, your data privacy and retention policies will follow Microsoft Defender XDR rules, and Fusion will be replaced by Defender XDR correlation. Review those policy changes with your compliance team before you decide. Plan the Defender portal transition on its own timeline, and treat any replacement as a separate project with its own business case.

How do open-source licenses affect commercial use?

Each platform carries different terms, so check each component you plan to deploy. Wazuh is free and open source under GPLv2. OpenSearch is licensed under Apache 2.0. Graylog Open is free to self-manage under the Server Side Public License with no ingestion caps, while Graylog Enterprise and Graylog Security are paid products. Security Onion is free, but its repository is licensed under the Elastic License 2.0, and Security Onion Pro is a paid tier. Those terms govern redistribution, modification and hosting differently, so your legal team should confirm how each applies to your use, particularly if you offer the platform to customers or build products on it. Ask your partner and your counsel to list every component and its license in writing before deployment.

What should we export from Sentinel before we leave?

Export the items you would otherwise lose: analytics rule definitions in their query form, the log data you must keep for investigations or regulators, incident history, and any workbooks or automation logic your analysts use. Log data is usually the largest and most sensitive item, so define retention targets first and export only what those targets require. Keep an inventory that links each exported item to its owner and its destination. Confirm with your compliance team which records must be retained and in what format before you delete anything from the Azure environment.

Official Sentinel and open-source sources to read first

Start with the two Microsoft Learn pages before you size any alternative. The first, Microsoft Sentinel in the Microsoft Defender portal, explains what changes when Sentinel runs in the Defender portal. The second, Transition your Microsoft Sentinel environment to the Defender portal, covers the transition steps. Two items in these pages drive the decision: after March 31, 2027, Sentinel is available only in the Defender portal, and Microsoft Defender XDR data privacy and retention policies replace Sentinel's own. Note which of your retention and residency commitments depend on the current Sentinel settings, and confirm with Microsoft how those commitments map to the Defender XDR policies before you plan a migration.

Next, read the project sources for the open-source options. The Wazuh GitHub repository documents the indexer, server, dashboard and agent components, along with the log analysis, file integrity monitoring and compliance features that a Sentinel replacement would need to match. The OpenSearch FAQ explains the license and the compatibility background, which matters if you plan to run your own search layer. The Graylog Open page lists which features sit in the free tier and which belong to paid editions. The Security Onion GitHub repository describes a bundled monitoring stack and its licensing, which you should review with your legal team before deployment.

Confirm licensing, feature coverage and support terms directly with each vendor and project before you commit. Ask Microsoft which Sentinel analytics, connectors and workbooks carry over to the Defender portal, and which depend on Defender XDR. Ask each open-source project which features are in the community edition and which require a paid tier, and get written answers on the license terms that apply to your intended use. Record the answers in your migration plan so that the decision rests on current vendor documentation rather than on this page or on secondhand summaries.