Microsoft Sentinel vs Wazuh: when each fits and what decides it
If you are reading this during a Sentinel renewal, you are probably facing a combination of pressures: a commercial contract that comes up for review, the Azure portal retirement scheduled after March 31, 2027, and in some cases a data residency or air-gap requirement that the current setup does not meet. Sentinel fits teams that already run most of their security telemetry through Microsoft sources such as Entra ID, Microsoft 365 and Defender, accept Azure hosting, and are comfortable with per-GB billing and the Microsoft Defender portal as the place where they work. Wazuh fits teams that need security data stored on their own servers, want lightweight agents on Linux, Windows and macOS endpoints, and prefer a cost profile driven mainly by infrastructure and staff time rather than by ingested volume.
Before you compare prices, confirm four things. First, data location: list which regulated data must stay in a specific country, network segment or facility, and whether Sentinel's Azure hosting satisfies that requirement under your own legal and contractual review. Second, Microsoft connector dependence: count how many of your detections depend on Microsoft-native connectors and Fusion correlation, because Wazuh replaces those with its own agents, syslog collection and rules, and that rebuilding is real work. Third, in-house operating capacity: confirm who will patch the Wazuh indexer, server and dashboard, size the cluster, and tune decoders and rules. Fourth, migration budget: separate the one-time work of rebuilding detections and playbooks from the recurring cost of running the platform.
If the answer to the first question is that data must stay on your own infrastructure, the decision narrows quickly, and Sentinel's move to the Defender portal changes which retention and privacy policies apply to your data. If Microsoft sources dominate your telemetry and your team is already staffed around Azure, a move may still be justified by the retirement date, but the case for Wazuh is strongest where residency, air-gap needs or a predictable infrastructure budget outweigh that convenience. Ask your DeployOpen or internal team for a written scope that covers both paths so the comparison rests on your environment rather than on assumptions.
Which fits by environment and situation
If your SOC already runs most detections, hunting and case work inside Microsoft tools, Sentinel keeps the Microsoft data connectors, analytics rules and Defender XDR correlation in one operating model. Wazuh is the better fit when the main goal is to own the collection path and detections yourself, with agents that cover Linux, Windows and macOS endpoints and agentless syslog for firewalls and other devices.
- Connector depth: Sentinel's prebuilt Microsoft connectors are the shortest path for Entra ID, Defender and Microsoft 365 signals. With Wazuh you rebuild that collection with agents, syslog and API polling.
- Detection rewrite: Sentinel analytics rules written in KQL do not port directly to Wazuh decoders and rules, so plan a rewrite cycle.
- Defender portal change: After March 31, 2027, Sentinel runs only in the Microsoft Defender portal, where Defender XDR retention and privacy policies apply and the Fusion rule is replaced by Defender XDR correlation. If your rules depend on Fusion, Wazuh becomes more attractive.
- Dual operation: Some teams keep Sentinel for Microsoft telemetry and run Wazuh for endpoints and devices. Confirm which signals must stay in one console.
Check which Sentinel features your analysts use daily and how many detections depend on Microsoft-only signals before you choose.
Organizations with data residency or sovereignty requirements often need to know exactly where security logs are stored, who can access them and how long they are kept. Sentinel stores data in the Azure region you select, under Microsoft's retention and privacy controls, and the Defender portal move changes which policies govern that data. A self-hosted Wazuh deployment keeps alerts in the Wazuh indexer inside infrastructure you control, which gives direct control over location and access.
- Location control: Wazuh runs in your data center or your cloud accounts, so you choose the storage location and backup targets.
- Retention policy: Set retention in your own configuration rather than inheriting Defender XDR policy changes.
- Compliance views: The Wazuh dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53, which help evidence work, though auditors and certification bodies make the final determination.
- Access control: Wazuh supports single sign-on, so confirm the identity integration your assessors expect.
- Vendor review: Sentinel may still be acceptable under your residency rules. Ask your legal and compliance teams to review Azure region choices and Defender portal policies in writing.
Before deciding, confirm the exact residency clause, the data classes in scope and who must approve a cloud SIEM.
A small platform team usually weighs operating effort more heavily than license terms. Sentinel is managed by Microsoft, so the team runs ingestion configuration, rules and workbooks but not the search cluster. Wazuh is free under GPLv2, but your team operates the indexer, server, dashboard and agents, and upgrades them as releases arrive. Wazuh's 4.14 line has seen regular patch releases, which means a recurring upgrade task.
- Staffing: Sentinel shifts infrastructure work to Microsoft, while Wazuh adds server, indexer and agent operations to your team.
- Scale path: The Wazuh server supports clustering for horizontal scaling and manages agent configuration and upgrades remotely, which reduces per-endpoint touches.
- Deployment options: An OVA, an Amazon Machine Image, Docker, Kubernetes and Ansible or Puppet options help standardize the build.
- Managed option: Wazuh Cloud is available if you want the platform without running the stack, though it changes the residency analysis.
- Support: Plan for paid support or a retainer if the team cannot absorb on-call duty.
Estimate the hours your team can give to patching and tuning each month, and ask any implementation partner to price that work in a written scope.
Sentinel runs only in Azure and cannot be installed in an isolated network, so it is not an option for disconnected sites, classified environments or many operational technology networks. Wazuh is the stronger fit in this case because it documents an offline installation guide and can use an offline vulnerability repository instead of the Wazuh Cyber Threat Intelligence platform. Vulnerability detection correlates the software inventory agents collect with that offline data.
- Offline install: Follow the offline installation guide for systems without internet connectivity.
- Vulnerability feed: Build and refresh the offline vulnerability repository on a controlled schedule that matches your change process.
- Agent coverage: Confirm that the agents support every operating system on the site, including older or specialized hosts.
- Agentless devices: Syslog and periodic API probing cover firewalls and devices where no agent can be installed.
- OT limits: Passive monitoring of industrial protocols may need additional tools, so validate that gap with your OT engineers.
Before committing, test the full offline update path on a staging network and confirm how signatures and vulnerability data will reach an isolated site.
Scenario, better fit and why
This table maps five common estate types to the platform that usually fits better and the condition that makes the reason hold. Read each row against your own sources, data residency rules and team skills, because a fit that depends on one condition can flip when that condition changes.
| Scenario | Better fit | Why and the condition it depends on |
|---|---|---|
| Microsoft 365 and Defender estate | Microsoft Sentinel | Entra ID, Microsoft 365 and Defender XDR connectors are built in and maintained by Microsoft. This holds only while your team already runs Defender and accepts the Defender portal's retention and privacy policies after March 31, 2027. |
| Multi-cloud estate with non-Microsoft sources | Wazuh | Agents and syslog collection cover Linux, Windows, macOS and network devices without a per-source connector list. This holds if you can staff agent deployment and rule tuning for each cloud and SaaS source. |
| Residency-bound organization | Wazuh | Wazuh can run in your own data centers or air-gapped networks, while Sentinel runs only in Azure. This holds if your regulator accepts self-held logs and you confirm where your backups and indexer nodes sit. |
| Endpoint-heavy vulnerability program | Wazuh | Agents collect software inventory and vulnerability detection correlates it with CTI data or an offline repository. This holds if you confirm the vulnerability feed terms and how often your endpoints check in. |
| Team with no SIEM operators | Neither without a partner or managed service | Both need trained analysts and tuning work. Sentinel shifts infrastructure work to Microsoft but bills by ingestion. Wazuh removes licensing but puts cluster, upgrade and storage work on your staff. Confirm which skills you can hire or contract before choosing. |
Where your logs live and who controls them
Sentinel and Wazuh differ most in where log data sits, who sets its retention and privacy rules, and who holds the evidence an auditor asks for. The four cards below cover those decisions in order, from the Azure and Defender portal move to the Wazuh hosting models, identity options and compliance evidence.
Sentinel data location and Defender policies
Sentinel data lives in Azure Log Analytics workspaces in the regions you select. After March 31, 2027, Sentinel is available only in the Microsoft Defender portal, where Defender XDR data privacy and retention policies apply in place of Sentinel's own. Check which region your workspace uses, who in your organization can change Defender retention settings, and whether your privacy terms still match your data residency obligations after the move.
Wazuh hosting models
Wazuh runs on a virtual machine from the prebuilt OVA, on Docker, on Kubernetes, from an Amazon Machine Image, or through Ansible and Puppet automation. The server can run as a cluster for horizontal scaling. Your choice decides who patches the operating system, how backups are taken and where the indexer data sits. An offline installation guide covers networks without internet access.
Identity and single sign-on
Sentinel inherits sign-in from Microsoft Entra ID and Azure role-based access control, so conditional access and privileged identity controls already in your tenant apply to the SIEM. Wazuh has its own user administration and supports single sign-on, so you need to decide which identity provider it trusts, how roles map to analyst and administrator duties, and how accounts are removed when staff leave. Confirm these mappings with your identity team before cutover.
Compliance evidence ownership
With Sentinel, audit evidence such as access logs and retention settings sits in Azure and Defender, so you request exports from Microsoft or pull them through the portal. With Wazuh, the same evidence sits in your own indexer, dashboard and configuration files. DeployOpen prepares the controls, configuration and evidence collection for your assessment, but it does not issue audit reports or attestations; independent auditors and certification bodies do that work.
What changes after the Defender portal move
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. Microsoft states that the move carries no extra cost, so the change is about administration and policy rather than licence price. For a Wazuh evaluation, the practical question is what your team will be operating and governing once the platform changes under you, and whether that matters enough to make the move a point of decision rather than a background migration.
Two policy changes need the most attention. When Sentinel runs in the Defender portal, Microsoft Defender XDR data privacy and retention policies apply instead of Sentinel's own settings, so retention periods, data handling and access rules should be checked against your legal and regulatory requirements in the Defender configuration. Also, the Fusion analytics rule is replaced by Defender XDR correlation, which means detections that depended on Fusion's multistage attack grouping will behave differently. Export your rule inventory, record which rules are active, and map each to its replacement or to a Wazuh rule before you decide what to keep.
Confirm the current details before you plan. Ask Microsoft or your reseller which rules, connectors and workbooks are affected in your tenant, and read the current transition guide for moving to the Defender portal together with the Defender portal overview. Record the retention and privacy settings you need, then compare them with what Defender XDR enforces. If the gap is material, the retirement is a reasonable point to evaluate self-hosted Wazuh with OpenSearch against a Defender-hosted Sentinel, and to scope that work in writing before any cutover date is committed.
What each option costs to run, component by component
Sentinel and Wazuh cost different things to run. Sentinel bills mostly by the data you send and keep, while Wazuh moves the spend to servers, storage, and the people who operate them. Compare each component against your own daily volume, retention target and staffing before you decide.
Licensing and subscription
Wazuh is free under GPLv2, so its license line is zero, but the platform is not zero cost to operate. Sentinel is billed through Azure, and its charges depend on your region, tier and commitment. Ask DeployOpen for a written quote that separates the Wazuh license line from the implementation fee, and confirm with Microsoft which Sentinel charges apply after the move to the Defender portal. Wazuh has no license fee, so the cost sits in infrastructure and people.
Ingestion billing against server sizing
Sentinel charges for data ingested into its analytics tier, so cost rises with every new source you onboard. Wazuh has no per-GB charge, but the indexer and server must be sized for your event rate and alert volume. Measure your average and peak daily volume across endpoints, firewalls and cloud logs, then ask DeployOpen to size the cluster from those numbers. Sentinel cost follows ingestion, while Wazuh cost follows the hardware you provision.
Indexer and retention storage
The Wazuh indexer stores alerts and archived events, so retention is a storage decision you make on your own disks or cloud volumes. Sentinel charges separately for retention beyond its included period, which makes long retention a recurring line item there. Decide your retention period for alerts and raw events separately, then price the storage tier that holds them. Confirm the indexer sizing guidance for your event rate with DeployOpen before you buy hardware.
Staff time to run the platform
Running Wazuh requires people to tune decoders and rules, manage agent groups, watch indexer health and handle alert triage. Sentinel also needs analysts and engineers, but the platform itself is operated by Microsoft. Estimate the hours your team spends on each platform per week, and include on-call coverage. This is usually the largest recurring cost in a self-hosted deployment, so ask DeployOpen to show the operating tasks and the roles that cover them.
Patching and upgrades
Wazuh ships 4.14 patch releases roughly every one to two months, and each upgrade touches the server, indexer, dashboard and agents. You plan maintenance windows, test upgrades in a staging cluster and roll agent updates out in stages. Sentinel upgrades are handled by Microsoft, though your analytics rules and connectors still need review when the platform changes. Ask for a written upgrade runbook and a testing plan in the quote.
Support and migration effort
Sentinel support is included in your Azure agreement, while Wazuh support comes from Wazuh's paid offerings, from DeployOpen's retainers, or from your own staff. Migration adds a one-time cost to move connectors, rules and history, and it is separate from the recurring run cost. Ask DeployOpen for a fixed-scope quote that lists the migration phases, the deliverables and the support tier, and confirm which Wazuh support options your organization needs.
What a move from Sentinel to Wazuh involves
The sequence turns Sentinel's connectors, analytics rules and playbooks into an inventory, a tested Wazuh deployment and a parallel run, so the cutover happens only after detections and collection are confirmed to match.
Inventory connectors, analytics rules and playbooks
Your security engineers list every data connector feeding the workspace, every enabled analytics rule and every Logic Apps playbook, noting owner, log source and the alerts each one drives. The inventory is done when each item is tagged as keep, replace or retire, and the business owner of each detection has signed off on the list.
Export rules and historical data
The team exports analytics rules as ARM templates so the detection logic can be read and rewritten, and sets up continuous export or an export job for the history you must keep for investigations and audits. Compliance owners confirm which retention periods apply, since Sentinel retention settings do not carry over automatically. The step is complete when the exported rules and a tested copy of the historical archive are stored in a location outside the Sentinel workspace.
Stand up Wazuh in a test environment
Engineers install the Wazuh indexer, server and dashboard in a non-production environment using one of the documented deployment options that fits your platform, then size storage and retention against the inventory. The step closes when the test cluster accepts agent enrollment, shows alerts in the dashboard and passes a backup and restore check.
Replace connectors with agents and syslog
For each endpoint and server, the team deploys Wazuh agents and configures agentless collection, such as syslog from firewalls or API probing, for devices that cannot run an agent. Each source is matched against the connector it replaces, and the step is done when event volumes from every source are visible in the test dashboard and gaps are documented.
Rewrite KQL analytics rules as Wazuh rules
Detection engineers translate each retained KQL analytics rule into Wazuh decoders and rules, testing them against replayed or sample events from the test environment. Rules that depend on Sentinel-only features, such as Microsoft-specific correlation like Fusion, need a new design rather than a direct translation. The step is complete when each rule has a documented test case that fires on the expected events and stays quiet on normal traffic.
Rebuild Logic Apps playbooks
The team maps each Logic Apps playbook to an equivalent response workflow, such as the Shuffle workflows covered in the sibling playbook page, and rebuilds the connectors to ticketing, chat and identity systems. Owners test each workflow with a non-destructive action before it is allowed to change any system. The step is done when every retained playbook has a tested replacement and a named owner.
Run Sentinel and Wazuh in parallel
Both platforms receive the same log sources for a agreed observation period, and analysts compare alert volumes, false positives and missed detections on known test activity. Differences are resolved by tuning rules or adding sources, and the team records each decision. The step is complete when the team signs off that Wazuh alerts cover the agreed detection set.
Cut over and retire the Sentinel workspace
The team redirects agents and forwarders to production Wazuh, switches incident handling to the new dashboard, and keeps the Sentinel workspace read-only until the archived history and exported rules are verified. The step is done when production alerts flow through Wazuh, runbooks reference the new platform and the decommissioning record is approved.
Questions buyers ask before choosing Wazuh over Sentinel
Is Wazuh free to run in our environment?
Wazuh's software is free: it is distributed under the GNU General Public License version 2, so there is no per-GB licence fee for the platform itself. The costs move elsewhere. You pay for the servers or virtual machines for the Wazuh indexer, server and dashboard, for storage sized to your retention period, for network capacity from endpoints, and for the staff who install, tune rules, patch and watch the platform. Sentinel bills ingestion and retention through Azure, so the comparison depends on your daily volume and retention. Ask any vendor or partner for a written breakdown of hardware, storage, staff hours and support so you can compare the components side by side.
How long does a migration from Sentinel to Wazuh take?
The timeline depends on how much detection logic and history you need to carry over, not on the platform alone. The main drivers are the number of data connectors you replace with Wazuh agents or syslog collection, how many KQL analytics rules you rewrite as Wazuh rules, how many Logic Apps playbooks you rebuild, and how much history you export and whether it must remain searchable. Parallel running for a cutover period adds time as well. Your outside partner should give a fixed-scope plan with a timeline in writing before work starts, and that plan should list each data source and rule family in scope.
Can our team migrate to Wazuh without outside help?
A team with Linux administration, Elasticsearch-style search operations and detection engineering experience can run a pilot alone, and Wazuh documents several installation paths, including an all-in-one install, Docker, Kubernetes, Ansible and Puppet. Production work usually needs more: sizing the indexer cluster, hardening the stack, writing and testing detection rules, building compliance dashboards and documenting controls for audit. Be honest about your staff's time. Ask whether the people who will operate the platform after go-live can take on the build, and whether you need a fixed-scope engagement to cover the gaps.
What does our side need to provide for a Wazuh project?
Plan for four inputs. First, an inventory of log sources, endpoints and their operating systems, because Wazuh agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, and agentless devices such as firewalls connect through syslog and periodic API probing. Second, a retention and access policy that states who may search alerts and for how long. Third, the hosting target, whether that is your data center, a private cloud account or an isolated network. Fourth, named owners for alert triage and change approval. Without these, sizing and rule scope will drift during the project.
Does Wazuh cover Microsoft 365 and Defender data sources?
Confirm this against the current Wazuh documentation for your exact data sources before you commit, because connector coverage changes between releases. Wazuh collects logs through agents, syslog and API-based collection, so Microsoft sources that expose logs through an API or a forwarded syslog stream can usually be brought in. Sentinel's native connectors for Microsoft 365, Entra ID and Defender products will need to be replaced by a collection path you build and maintain. Also note that Defender XDR retention and privacy policies apply to Sentinel once it moves to the Defender portal, so your data governance review should cover both platforms.
Can Wazuh run in an offline or air-gapped network?
Yes, Wazuh publishes an offline installation guide for systems without internet connectivity. For vulnerability detection, you can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform, which means you must maintain that repository yourself and update it through an approved transfer process. Sentinel runs only in Azure and cannot be installed in an isolated network, so this is often the deciding factor for classified, operational technology or disconnected sites. Confirm the offline update procedure with your security team before you design the architecture.
Which Wazuh release should we plan around?
The current release line is 4.14, and the most recent patch in the researched facts is 4.14.9, released on 14 October 2026. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, so expect patching on a rhythm of one to two months. Your operating model should include a patch window, a test environment and a rollback plan. Check the release notes on the day you plan your build, because a newer patch may have replaced the one you studied.
How DeployOpen evaluates, implements and migrates Wazuh
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Microsoft Sentinel vs Wazuh, we start with the written scope of your detection, retention and data source requirements, then build and test the Wazuh deployment in your environment before handover.
How we scope
- Inventory current Sentinel data connectors, analytics rules, workbooks and playbooks so the scope lists every detection to be rebuilt.
- Confirm which log sources need Wazuh agents, which need syslog collection, and which need agentless API probing.
- Agree retention, data residency and offline requirements in writing, including whether any site needs the offline installation guide.
How we build
- Deploy the Wazuh indexer, server, dashboard and agents using the installation method your environment supports, such as Docker, Kubernetes, Ansible or the OVA.
- Rewrite priority analytics rules as Wazuh decoders and rules, then test each rule against replayed sample events before it goes live.
- Configure vulnerability detection with either the Wazuh Cyber Threat Intelligence platform or an offline repository, as your network permits.
How we hand over
- Document the architecture, agent configuration, rule inventory and the mapping from each retired Sentinel rule to its Wazuh replacement.
- Provide runbooks for upgrades, certificate rotation, backup and restore of the indexer, and cluster scaling of the Wazuh server.
- Run knowledge transfer sessions with your security operations and platform engineering staff, and record which items remain with your team.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial fixed-scope engagement.
- Plan patch adoption against the Wazuh 4.14 release line, which has shipped patch releases roughly every one to two months.
- Confirm with your team which compliance dashboards, such as PCI DSS, GDPR, HIPAA or NIST 800-53 views, need evidence prepared for your independent auditors.
