Microsoft Sentinel or Elastic Security: which fits your SOC
If your renewal is pushing you to consolidate on Azure, or your residency rules say the SIEM must run inside your own network, the answer depends on where your logs come from and where they are allowed to sit. Microsoft Sentinel fits Azure-centric estates that rely on Microsoft data sources, while self-managed Elastic Security fits teams that must run the SIEM in their own infrastructure. Elastic ships under the Elastic License 2.0 by default, with AGPLv3 also offered for the source code. ELv2 is not an OSI-approved open source license, so confirm with your legal team whether AGPLv3 is the license you need to rely on for your procurement or policy.
Four drivers should decide this. First, list your data sources: if most telemetry comes from Microsoft Defender, Entra ID and Azure resources, Sentinel's connectors cover it with less build work, while Elastic Security relies on Elastic Agent and Elastic Defend for endpoints and ingest pipelines you configure for everything else. Second, map where data may reside, since Sentinel runs only in Azure and Elastic can run in your data center or cloud account. Third, match the features you need to an Elastic subscription tier: the self-managed page places machine learning anomaly detection and case management under Platinum, which is no longer sold to new customers, and endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on under Enterprise, so confirm current pricing and availability directly with Elastic. Fourth, assess staff capacity to operate Elasticsearch clusters, including at least three master-eligible nodes for high availability, upgrades and storage tiers.
Ask Microsoft to confirm the Defender portal transition timeline and how Defender XDR retention and privacy policies apply to your tenant, and ask Elastic which tier includes each feature on your list. Run a short proof of concept that ingests one representative data source into both platforms and rebuilds one detection rule, then compare the effort and the results. Your quote should itemize the Elastic subscription, infrastructure, storage, and the operating hours needed to run the cluster.
Which option fits which scenario
This table maps common buying scenarios to the platform that usually fits better, along with the condition that tips the decision. Read each row against your own estate, licensing rules and data location before choosing, because the answer often depends on one or two constraints rather than overall preference.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Microsoft 365 and Defender-heavy estate | Microsoft Sentinel | Most identity, email and endpoint telemetry already flows through Defender XDR, and your team is staffed for the Defender portal after the March 31, 2027 transition. |
| Multi-vendor endpoints and mixed telemetry | Elastic Security | You need one pipeline for Windows, Linux, macOS and non-Microsoft sources, and you are prepared to run Elastic Agent and Fleet across them. |
| Air-gapped or on-premises requirement | Elastic Security (self-managed) | Sentinel runs only in Azure, so the deployment must be self-managed Elastic inside your isolated network. Confirm which Elastic features your tier includes offline. |
| Need for OSI-approved licensing | Elastic Security under AGPLv3, or a different platform | Elastic's default distribution is Elastic License 2.0, which is not OSI-approved. Choose the AGPLv3 option for the source code and confirm with counsel whether it meets your policy. |
| Teams that want Elastic's prebuilt rules | Elastic Security | You want a large, maintained library of prebuilt detection rules delivered to the Kibana detection engine, and you can review rules for tuning in your own environment. |
| Advanced security features on self-managed Elastic | Confirm before choosing | Malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit in the Enterprise tier. Platinum is no longer sold to new customers, so ask Elastic which tier includes each feature you need. |
Where the data lives and who controls it
Microsoft Sentinel runs only in Azure, so your log data is stored in the Azure regions you select for the workspace and is operated by Microsoft. After March 31, 2027, Sentinel will be available only in the Microsoft Defender portal. Microsoft says that move has no extra cost, but it changes the governing policies: when Sentinel runs in the Defender portal, Microsoft Defender XDR data privacy and retention policies apply instead of Sentinel's own, and the Fusion analytics rule is replaced by Defender XDR correlation. Your retention and privacy posture therefore needs to be re-read against Defender XDR terms, not the Sentinel documentation you may have approved earlier.
- Data location: Confirm the Azure region of each Log Analytics workspace and whether any data is replicated or exported to other regions or storage accounts.
- Policy change: Review Defender XDR retention and privacy terms before the Azure portal retirement date, and record the new policy as the controlling document.
- Sign-in: Access runs through Microsoft Entra ID and Azure role assignments, which your existing identity controls already govern.
- Export paths: Any continuous export to Blob Storage or Event Hubs creates a second copy that needs its own retention and access rules.
- Operator access: Ask Microsoft for the documents describing its support access and customer-managed key options for your tenant.
Before committing, confirm with your Microsoft account team which Defender XDR policy versions apply to your tenant and how they map to your current data classification.
Elastic Cloud is Elastic's hosted service for Elastic Security, and it moves operation of the cluster to Elastic while you keep the same product features. You choose the cloud provider and region when you create a deployment, and the data sits in that deployment rather than in your data center. This model suits teams that want Elastic to handle upgrades and patching, but it still places security data with a third party, so you need to review Elastic's hosting terms, sub-processors and support access before approval. Elastic's own subscriptions page directs new customers who want paid self-managed security features toward Elastic Cloud, so this model also carries the commercial terms that come with that path.
- Region selection: Pick the provider and region at deployment creation and record them in your data flow diagram.
- Operator access: Ask Elastic which staff can reach your deployment, under what approval, and how that access is logged.
- Sign-in: Confirm which single sign-on options your subscription level enables for your users.
- Encryption keys: Ask who holds the keys for data at rest and whether you can bring your own key.
- Shared responsibility: Document which controls Elastic operates and which remain yours, such as user access, detection content and alert handling.
Ask for Elastic's current hosting and security documentation in writing and attach it to your third-party risk file.
Self-managed Elastic Security runs on servers you control, in your data center, your cloud accounts, or an air-gapped network. Elasticsearch and Kibana are distributed under the Elastic License 2.0 by default, with SSPL 1.0 and AGPLv3 also offered for the source code, and ELv2 and SSPL are not OSI-approved open source licenses. Elastic added AGPLv3 in September 2024, before the 8.16 release, to give an OSI-approved option. You are responsible for every layer: storage, backups, patching, and the Elastic release line you run. Elastic's current release lines are 9.5.5 and 9.4.8, released on October 6, 2026, with 8.19.23 still maintained, and Elastic lists end of maintenance for the 8.x line on January 15, 2027.
- Deployment shape: A highly available cluster needs at least three master-eligible nodes, and Elastic Cloud on Kubernetes can manage components on Kubernetes.
- Licensing: Free and open (Basic) covers the basic security features, while Platinum is no longer sold to new customers, so new buyers of paid features choose between Basic and Enterprise.
- Air-gapped operation: Confirm which packages, rule updates and license files you must import manually, since the detection rules are delivered to the detection engine automatically only when the cluster can reach the source.
- Ownership: Name who runs upgrades, certificate rotation and backups, because these duties land on your team.
Confirm the exact release and license terms you plan to deploy against Elastic's current subscriptions page before you finalize the architecture.
Identity and encryption controls depend on the subscription tier, so they belong in the hosting decision rather than being added later. Elastic's self-managed subscriptions page lists SAML, OpenID Connect, Kerberos and JWT single sign-on, attribute-based access control, field- and document-level security, encryption at rest support and FIPS 140-3 mode among its security features. The page also states that alerting rules based on anomaly detection are only on Platinum and Enterprise, and that SAML or OpenID Connect single sign-on sits under Enterprise. Basic includes TLS, file and native user realms and role-based access control, which Elastic made free in 2019. Sentinel inherits Entra ID sign-in, while Elastic Cloud and self-managed deployments need you to connect your own identity provider.
- Single sign-on: Map SAML or OpenID Connect groups to Elastic roles, and confirm which tier includes the connector you need.
- Anomaly alerts: Check whether your planned machine learning alerting depends on Platinum or Enterprise.
- FIPS mode: If you need FIPS 140-3 operation, confirm the tier, the build and the cryptographic module with Elastic before design sign-off.
- Encryption at rest: Decide who manages keys, where they are stored and how rotation is handled.
- Role scoping: Use field- and document-level security where analysts should see only some indices.
Verify each tier-dependent control against Elastic's subscriptions page and written confirmation from Elastic before relying on it in an audit scope.
Whichever model you choose, an auditor will ask for evidence that the controls work, and that evidence must come from your own records and from the platform. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. For a Sentinel environment, the evidence set includes Azure role assignments, Defender XDR policy records and workspace configuration. For Elastic, it includes the tier and license file, role mappings, index lifecycle settings, encryption configuration and audit logging output. Self-managed deployments produce the most evidence, but your team must collect and retain it.
- Access records: Export role assignments and sign-in logs for each hosting model and keep them for your retention period.
- Configuration baselines: Store the deployment and tier settings in version control, with dated approvals.
- Vendor documents: Keep Elastic's and Microsoft's hosting, support access and policy documents as third-party evidence.
- Change history: Record upgrades and rule changes, including the release lines you ran.
- Auditor scope: Agree with your auditor which controls are inherited from the provider and which are your responsibility.
Ask your auditor and your provider which evidence they accept in what form, before you build the collection process.
Elastic licensing, subscription tiers and end-of-life dates
Elastic's license choice, subscription tier and support calendar decide what you can run, what you pay for and when you must upgrade. Read these four points together before comparing Elastic Security with Sentinel, because a self-managed deployment inherits every one of them.
Elastic License 2.0 by default
Elasticsearch and Kibana ship under the Elastic License 2.0 unless you choose otherwise, and Elastic also offers SSPL 1.0 and AGPLv3 for the source code. The detection rules repository is licensed under the Elastic License v2 as well. ELv2 and SSPL are not OSI-approved open source licenses, so legal and procurement teams should confirm which license covers the exact build they plan to run before they describe the stack as open source. Ask counsel to review the terms against your internal policy.
AGPLv3 as the OSI option
Elastic added AGPLv3 to Elasticsearch and Kibana to offer an OSI-approved open source choice, a step it took in September 2024 before the 8.16 release. Using AGPLv3 carries obligations that differ from using the default license, particularly if you modify the software and make it available to users over a network. Confirm with your legal team which license applies to the packages your engineers download, and record that decision in your architecture file.
Basic is free, Platinum is closed
The Free and open (Basic) tier covers the core stack, and Elastic made TLS, file and native realms and role-based access control free in Basic back in 2019. Platinum is no longer sold to new self-managed customers, so a new buyer chooses between Basic and Enterprise or moves to Elastic Cloud. Anyone reading older Elastic comparisons that mention Platinum should check the current subscriptions page before costing a deployment.
Enterprise carries endpoint and SSO
Endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit in the Enterprise tier on the self-managed subscriptions page. Anomaly detection alerting rules also require a paid tier. If your Sentinel use depends on Defender-based endpoint response or Entra sign-in, compare that dependency against what Enterprise provides, and ask Elastic for a written tier matrix that matches your planned feature set.
Support windows for 9.x and 8.x
Elastic's end-of-life page lists end of maintenance for the core stack 9.x line on October 15, 2027 and for 8.x on January 15, 2027, with 8.x support ending July 15, 2027. Current release lines named in the Elastic releases page include 9.5.5 and 9.4.8, with 8.19.23 still maintained. Plan your upgrade path from 8.x to 9.x before the 2027 dates, and budget engineering time for testing detection rules against each new release.
Upgrade planning and rule testing
Because prebuilt rules reach the Kibana detection engine automatically, an upgrade can change alert behavior without a change request in your own system. Build a staging cluster, replay representative events, and compare alert volumes before promoting a new version. Ask your partner or internal team to document rollback steps, and confirm that Elastic Agent and Fleet versions remain compatible with the server release you choose.
What Sentinel costs compared with running Elastic yourself
Sentinel and self-managed Elastic Security bill different things, so compare them by component rather than by headline figure. Sentinel charges for data ingested and retained, billed through Azure, with Log Analytics ingestion and retention as the main recurring lines. Self-managed Elastic has a subscription fee for the features you need (the Basic tier is free, while endpoint prevention, host isolation and SAML or OpenID Connect single sign-on sit in Enterprise), plus the servers, storage and hot and warm node tiers that hold the data. Staff time and support contracts apply to both. Ask Microsoft's pricing team for the current per-GB rates in your region, and ask Elastic for a written quote that separates subscription fees from infrastructure you pay for yourself.
The one-time work is the same kind on both sides: designing the index and node layout, porting analytics rules, validating detections against your own logs, and running a cutover. On Elastic, the detection porting is partly eased because the elastic/detection-rules repository delivers prebuilt rules to the Kibana detection engine, but you still review and tune them against your environment. On Sentinel, the cost sits in the rules and workbooks you have already built in KQL. Recurring costs on the Elastic side include the subscription, hardware or cloud capacity, storage growth, Elastic Stack upgrades (the 8.x line reaches end of maintenance on January 15, 2027, and the 9.x line on October 15, 2027, according to Elastic's end-of-life page), and on-call coverage for the cluster. Ask who patches the cluster, who handles snapshot restores and who carries the pager if a node fails.
Microsoft states that moving Sentinel to the Defender portal carries no extra cost, so do not budget for the move itself, but do budget for the Defender XDR retention and privacy policies that replace Sentinel's own. For an Elastic quote, request the subscription tier and its term, the number of nodes and their roles, the expected ingest and retention volumes you used to size them, support response terms, and whether Elastic Cloud pricing is shown as an alternative. Also confirm which features you need are included in the tier you are quoted, since some security capabilities are not in Basic.
Cost components, one-time and recurring
Sentinel bills mostly by the data it ingests and keeps, while self-managed Elastic bills for a subscription tier plus the infrastructure and people you run. The cards separate the one-time work of moving from the recurring charges that follow you for as long as you run the platform.
Sentinel analytics ingestion charges
Sentinel's main recurring charge is the per-GB fee for data ingested into the analytics tier, so every new connector, verbose Windows event or firewall feed adds to the bill each month. Your own ingestion volume is the figure to measure first, by table, over a representative period. Ask Microsoft or your reseller which tier applies to each table and what changes if you filter at the source before ingestion.
Sentinel commitment tiers and retention
Commitment tiers reduce the per-GB rate in exchange for a committed daily volume billed whether or not you reach it, so they lower cost only when your volume is steady and well forecast. Retention beyond the default period is billed separately and recurs for as long as data stays in the workspace. Confirm the commitment term, the overage rate and the retention rate for each table in writing before you compare totals.
Defender portal transition effects
Moving Sentinel into the Defender portal is one-time planning work, and Microsoft states it carries no extra cost. The bigger effects are that Defender XDR data privacy and retention policies replace Sentinel's own, and that Fusion rules are replaced by Defender XDR correlation. Each rule you rely on needs a review for coverage, and your retention assumptions must be checked against Defender XDR policy.
Elastic subscription tier
Self-managed Elastic Security is licensed by tier. Basic is free, while Enterprise adds features such as endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on. Platinum is no longer sold to new customers, so a new self-managed buyer chooses between Basic and Enterprise or moves to Elastic Cloud. Subscription pricing is recurring and should be quoted by Elastic or a reseller against the node count you plan to run.
Elastic cluster nodes and storage
Infrastructure is your largest recurring Elastic cost, and it grows with volume and retention. A highly available cluster needs at least three master-eligible nodes, and data nodes span hot, warm, cold and frozen tiers, so storage cost depends on how long data stays on fast disks. Ingest and machine learning roles add compute that must be sized for your detection workload. Ask your team to model each role against your daily volume before buying hardware or cloud instances.
Backup, upgrades and staff time
Backup storage, snapshot retention and the people who run them are recurring costs that Sentinel's managed model largely absorbs. On Elastic you pay for the snapshot repository, for regular upgrade windows and for engineers who tune detection rules, manage Fleet policies and respond to incidents. Support contracts are a separate line item. Check how long each major version stays maintained, because upgrades to stay supported are recurring work.
How a move from Sentinel to Elastic Security unfolds
The sequence turns Sentinel's connectors, analytics rules and stored history into a documented Elastic Security baseline that runs in parallel before the cutover. Each step produces an artifact the security team can check before the next one starts.
Inventory connectors, rules and data sources
The security engineering lead lists every Sentinel data connector, every enabled analytics rule, every automation rule and every workbook, along with the owner and the log tables each one reads. Map each Microsoft source to an Elastic Agent integration, a syslog input or an agentless option, and flag sources with no clear replacement. The step is complete when the inventory is signed off and every table has a named target index in Elastic.
Export rules, history and retention settings
Export analytics rules as ARM templates so the logic, severity, entity mapping and MITRE tags survive the move as reference material, and set up Log Analytics data export rules where history must leave Azure. Record retention periods per table, because the export charges and the storage you need in Elastic depend on them. The check is a folder of exported rules and a tested export of one table that can be read back.
Translate KQL queries and rebuild detections
Rewrite each KQL analytics rule and hunting query as an Elastic detection rule, using the correlation, indicator match or threshold types in the detection engine where they fit. Prefer prebuilt rules from the Elastic detection rules repository for common techniques, then customize them to your environment and tune suppression. The output is a rule set in version control, with each rule mapped back to its Sentinel source so reviewers can confirm the detection intent is kept.
Rebuild Logic Apps playbooks separately
Sentinel playbooks run as Azure Logic Apps workflows, so they do not move with the rules. List each playbook's trigger, enrichment calls, ticket updates and notifications, then rebuild them in the response tooling you choose, which may be a separate SOAR platform or Elastic's own response features where they meet the need. The step closes when every playbook has a replacement, a named owner and a tested run against a non-production alert.
Stand up Elastic Security and access controls
Deploy Elastic Security on your chosen infrastructure, with the node roles and cluster sizing set for your ingest volume and a high availability design that includes the required master-eligible nodes. Configure single sign-on, role-based access and case management against the subscription tier you selected, and confirm each feature you depend on is included in that tier. The check is a working cluster that passes your access review and has Elastic Agent enrolled through Fleet on a test group of hosts.
Run Sentinel and Elastic in parallel
Send the same sources to both platforms for a period the security team agrees in writing, and compare alert volumes, false positive rates and investigation times rule by rule. Analysts work cases in Elastic Timeline and Cases while keeping Sentinel as the system of record for response. The step is done when each rule has a documented comparison result and every gap has an owner and a fix or an accepted risk.
Cut over and retire Sentinel
Switch alert routing, playbook triggers and on-call escalation to Elastic, confirm that the on-call runbooks name the new console, and freeze Sentinel rule changes. Keep the exported rules, the exported history and the validation records for your retention obligations, then remove connectors and disable the workspace once the agreed review passes. The closing check is a signed cutover record and an archive that a future auditor or responder can read.
Questions buyers ask before switching from Sentinel to Elastic Security
Is self-managed Elastic Security cheaper than Microsoft Sentinel?
It depends on which costs you compare, so build the comparison by component rather than by headline price. Sentinel bills ingestion and retention through Azure, so its cost moves with log volume. Self-managed Elastic Security moves the cost into infrastructure you size (compute, storage, network), the staff who run the cluster, and any Elastic subscription you need for paid security features. Ask for a written quote that separates one-time work (design, rule migration, onboarding) from recurring items (infrastructure, subscription, support, patching). Your own daily volume and retention period are the main drivers, and both should be measured before you compare.
How long does a migration from Sentinel to Elastic Security take?
The timeline depends on how many analytics rules, data connectors and playbooks you rely on, and how much history you need to keep. Teams usually run both platforms in parallel for a period, move data sources in stages, and rebuild detections against Elastic's detection engine before they retire Sentinel rules. No supplied figure sets a duration, so ask any implementation partner for a timeline tied to a written inventory of your Sentinel rules, connectors and retention requirements. Fixed-scope engagements agree deliverables and dates in writing before work starts.
What does my security team need to supply for the move?
Your team supplies the knowledge of its own environment, and the migration depends on it. You will need an inventory of analytics rules, data sources, saved queries, workbooks and response automations, plus the retention and access requirements that auditors or your policies set. Your team also needs to own decisions about the Elastic subscription tier, sizing, identity integration and who triages alerts after cutover. Expect to spend time validating that detections fire on the same test events before you turn off Sentinel rules.
Can our own engineers run the migration without an implementation partner?
A capable team can do it in-house if it has Elasticsearch and Kibana operations experience, time to rebuild detections, and a plan for patching and capacity. Elastic publishes detection rules in the elastic/detection-rules repository, which gives a starting point, but you still need to test and tune them against your data. Bringing in an implementation partner makes sense when the team lacks cluster operations skills, when the rule set is large, or when audit evidence must be prepared. Ask for a fixed-scope proposal so responsibilities and deliverables are clear.
Which Elastic subscription tier covers the features we need?
Start from the features your detections depend on, then map them to tiers on Elastic's subscriptions page. Free and open (Basic) covers the core Elasticsearch and Kibana functions, and the security detection engine, machine learning anomaly detection and case management are listed under Platinum, which Elastic no longer sells to new customers. Enterprise lists endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on. New self-managed buyers of paid security features therefore choose between Basic and Enterprise, or move to Elastic Cloud. Confirm the current tier terms with Elastic before you commit.
Should we choose the Elastic License 2.0 or AGPLv3 for the source code?
Elasticsearch and Kibana are distributed under the Elastic License 2.0 by default, and Elastic also offers SSPL 1.0 and AGPLv3 for the source code. Elastic added AGPLv3 to provide an OSI-approved open source option, while ELv2 and SSPL are not OSI-approved. If your policy requires OSI-approved licenses, you need to check which option covers the exact components and features you plan to run, and have your legal team review the terms. Note that the detection rules repository is licensed under the Elastic License v2. Treat licensing as a legal question to confirm with counsel, not a technical setting.
Does the move to the Microsoft Defender portal change the decision?
Yes, it changes the timing. After March 31, 2027, Microsoft Sentinel is available only in the Microsoft Defender portal, and Microsoft says the move has no extra cost. When Sentinel runs in the Defender portal, Microsoft Defender XDR data privacy and retention policies apply instead of Sentinel's, and the Fusion analytics rule is replaced by Defender XDR correlation. If you are already rebuilding detections, compare that rework against a move to Elastic Security. Review your retention and correlation dependencies first, because they determine how much of your current logic carries over.
How DeployOpen helps you evaluate and move
If you are weighing self-hosted Elastic Security against Microsoft Sentinel, DeployOpen can run the evaluation as a fixed-scope engagement inside your own cloud accounts, data centers or air-gapped network. The work starts with a written scope that names the Elastic Stack version and deployment model (Elastic Cloud on Kubernetes or another self-managed layout), the Elasticsearch node roles and sizing for your daily volume, the data sources to onboard, and the detection content to port from Sentinel. DeployOpen plans and implements that environment, integrates Elastic Agent and Fleet with your identity provider, hardens the cluster, sets up backups and snapshots, and documents the result. Before you commit to a subscription tier, ask us to map which features you need, including Elastic Defend, host isolation and single sign-on, against the tier that carries them.
Deliverables depend on the scope you agree, but a typical written statement covers architecture, build and configuration records, the detection rules deployed and their tuning, runbooks for Timeline investigations and cases, and an operating handover. DeployOpen can also run security testing against the new platform, including application and API testing, infrastructure testing and red teaming, and can build a private cyber range so your analysts can rehearse detections before production. For compliance work, we prepare systems, controls and evidence for an assessment. We do not issue audit reports, attestations or certifications; your independent auditor or certification body does that. Most engagements are fixed-scope, and a quote follows directly from the written scope, so the statement of work should list what is in and out before work begins. Ongoing support, upgrades and continuous testing are available as retainers.
