Microsoft Sentinel

Microsoft Sentinel is a cloud-native, AI-driven security analytics and threat monitoring service built on Azure Data Explorer (Kusto) and integrated with the Microsoft Defender security ecosystem. It is a product of Microsoft Corporation (NASDAQ: MSFT), the company that produces Windows, Azure, Microsoft 365, Entra ID (formerly Azure Active Directory), Defender for Endpoint, Defender for Identity, Defender for Cloud, and the Microsoft threat intelligence program.

The strategic context that a CISO must understand before evaluating this platform is that Microsoft Sentinel is not competing on the same axis as the other eleven platforms in this review. The other eleven are security companies selling a SIEM. Microsoft is a platform company selling a security layer on its existing cloud and productivity stack. The SIEM is not the product. The SIEM is the telemetry correlation layer for a stack that the customer has already purchased: Microsoft 365, Entra ID, Defender for Endpoint, Azure, and the Microsoft threat intelligence program.

This produces a deployment dynamic that is different from every other vendor in this review. A significant portion of organizations running "Microsoft Sentinel" are not running it as their primary SIEM. They are running it as the ingestion and correlation layer for Microsoft-native telemetry — Entra ID sign-in logs, Exchange Online audit logs, Microsoft 365 admin activity, Defender for Endpoint detections, Defender for Identity alerts, Azure Activity Logs — while their primary SIEM for non-Microsoft telemetry (network, on-prem, third-party cloud, WAF, identity from Okta or Ping) remains Splunk, Elastic, Chronicle, or QRadar. Sentinel is the Microsoft data layer. The other SIEM is the correlation center of gravity.

Microsoft's long-term strategy is to make this two-SIEM architecture unnecessary. The path is: (1) the customer already uses Microsoft 365, so Sentinel ingests that telemetry for free or at a negligible incremental cost within the M365 E5/G5 bundle; (2) Defender for Endpoint replaces the third-party EDR (CrowdStrike, SentinelOne), bringing endpoint telemetry into the Microsoft stack; (3) Entra ID replaces or supplements the third-party identity provider, bringing identity telemetry into the Microsoft stack; (4) the customer's non-Microsoft telemetry (AWS, GCP, on-prem, network) is ingested into Sentinel via connectors, gradually consolidating all data into one platform; (5) the third-party SIEM becomes redundant. The EOL of IBM QRadar on-prem, the deprecation pressure on legacy Splunk on-prem, and the natural refresh cycle of EDR contracts are the accelerants. Microsoft does not need to out-detect Splunk or out-correlate Chronicle. It needs to make the switching cost of not consolidating on its stack higher than the switching cost of moving to it.

For a CISO evaluating Sentinel, the honest question is not "is Sentinel the best SIEM?" The question is "what is my current Microsoft telemetry volume, what is my non-Microsoft telemetry volume, and does consolidating both into Sentinel reduce my total cost of ownership and operational complexity versus maintaining a Microsoft-telemetry layer in Sentinel and a non-Microsoft layer in my primary SIEM?" The answer depends on the ratio. If 70% of the organization's telemetry is Microsoft-native, the consolidation is rational. If 20% is Microsoft-native and 80% is non-Microsoft, the consolidation is a migration project with a high friction cost and a modest benefit.

Expanded to ten entries per category. Items marked with † are particularly relevant to Microsoft Sentinel's Microsoft-native strengths.

A. Identity & Access Control Events

1. Login success and login failure (Entra ID, Okta, Ping, SAML/OIDC)
2. Account lockout, MFA push rejection, or FIDO2® authentication bypass
3. Password change, reset, and password policy violation
4. Role, permission, or group assignment and revocation
5. Privileged service account activation or JIT access grant without change-management ticket
6. † Entra ID: risk detection (atypical travel, leaked credentials, suspicious sign-in, token forgery) — native, lowest-latency ingestion
7. † Microsoft 365: conditional access policy evaluation, enforcement, or bypass (native)
8. MFA registration, re-registration, recovery code reset, or authentication method change
9. Privileged session initiation via PAM, jumphost, or bastion
10. † Service account interactive session, correlated with a Defender for Endpoint process execution event on the source host

B. File, Application & Cloud Storage Access Events

1. File or folder creation, modification, rename, or deletion
2. API key creation, rotation, scope expansion, or expiration
3. Cloud bucket or container policy change (S3, GCS, Azure Blob)
4. Database query execution on restricted tables; DLP block
5. Privileged session initiation (PAM, jumphost, DBA tool)
6. Object storage access by an identity with no prior access history
7. Mass file download or API bulk-read exceeding baseline
8. Container image pull from non-approved registry; AKS K8s RBAC change
9. Git repository permission elevation (GitHub native) or secret key commit
10. † Microsoft 365: SharePoint/OneDrive external sharing, sensitivity label removal, or DLP policy bypass (native)

C. Network Flow Records

1. Source/destination IP, port, protocol, duration, bytes transferred
2. DNS query and response: domain, TTL, response time, NXDOMAIN frequency
3. TLS handshake: cipher suite, certificate validity, handshake failure, protocol downgrade
4. HTTP transaction: method, URI path, status code, content-type
5. † Azure NSG Flow Logs, VPN Gateway logs, Azure Front Door logs (native)
6. DNS tunneling indicators: high subdomain entropy, long query strings
7. Connection to non-standard TLS ports from internal hosts
8. Multi-connection fan-out (botnet, DDoS staging)
9. Cross-AZ or cross-region data transfer exceeding baseline
10. † Azure Virtual Network peering anomaly: unexpected traffic flow between VNs that have no business justification

D. Endpoint, Email & Gateway Threat Events

1. Executable or file hash detection and block by Defender for Endpoint or third-party EDR
2. Macro-enabled document via email; Microsoft Defender for Office 365 sandbox detonation
3. Payload download or C2 beacon from known-bad domain (Microsoft threat intel)
4. Fileless or memory-only execution: PowerShell, WMI, .NET injection
5. Sandbox or EML attachment rejection with telemetry (Defender for Office 365 native)
6. New or modified scheduled task, cron job, or service on endpoint
7. Unauthorized SUID binary creation, /etc/passwd modification, kernel module load
8. Registry modification: Run/RunOnce, IFEO, WMI persistence
9. † Microsoft 365 email: SPF/DKIM/DMARC failure, impersonation detection, zero-hour auto purge (native)
10. † Defender for Endpoint: process injection, credential dumping (lsass), or security tool tampering (native)

E. Exploit & Attack Pattern Events

1. Buffer overflow or stack smash attempt (EDR syscall monitoring)
2. SQL injection or XSS in WAF logs (CRS 4.25 rule hit)
3. Exploit kit landing page hit + payload delivery
4. RCE via known CVE (CVE-to-asset mapping)
5. Lateral movement via SMB, WMI, PSExec, RDP
6. † Cloud metadata service access (169.254.169.254) from AKS pod, correlated with Entra ID token acquisition
7. † Entra ID privilege escalation: admin consent grant → application role assignment → data access (native correlation)
8. Container escape: privileged container, host filesystem mount, /proc access
9. DNS-based data exfiltration
10. † Ransomware precursor: mass file encryption, shadow copy deletion, backup termination, correlated with a Defender for Endpoint alert and a Microsoft 365 DLP policy breach (three-source native correlation)

F. Behavioral & UEBA Anomaly Alerts

1. Impossible travel
2. Egress volume spike exceeding 3σ baseline
3. Off-hours access to PII or privileged infrastructure
4. Privilege escalation without ITSM ticket
5. Service account interactive session
6. † New Entra ID application registration or API permission grant by a user with no prior app development activity
7. † Microsoft 365: inbox rule creation by a user that forwards mail to an external domain (mail forwarding attack pattern, native)
8. Authentication method change
9. Data access breadth expansion across Azure subscriptions
10. Session behavior deviation: command sequences inconsistent with role, correlated with Defender for Endpoint process chain

Source Collectors. For Microsoft-native telemetry (M365, Entra ID, Defender, Azure), the data connectors are native. No forwarder, no agent, no pipeline. The data flows from the Microsoft service into Sentinel's Log Analytics workspace via the data connector. For non-Microsoft sources, the Azure Monitor Agent (AMA) or standard protocols (syslog, HTTP, Kafka, CEF, LEEF) are used. For AWS and GCP, native log exporters push to Sentinel via the relevant data connector.

Agent-Level Filtering. AMA supports source-side filtering by log type, table name, log level, and custom fields. Microsoft-native data connectors support filtering at the connector configuration level (e.g., ingest only Entra ID sign-in events, not all Entra ID audit events). Non-security-relevant events are excluded before ingestion.

Deduplication Strategy. No pre-ingest semantic or string-based deduplication. Brute-force sequences are preserved. Repetition is handled via analytic rule thresholds, ML baselining, and correlation grouping.

Storage and Compute. Azure Data Explorer (Kusto) backend. Columnar storage. Compute scales independently of ingestion. Retention governed by hot/cool storage policies. No indexer licenses.

Scale: >10K EPS. AMA handles high-velocity ingestion with async batching, TLS multiplexing, and compression. The Azure Data Explorer backend auto-scales. Microsoft's internal security operations (protecting 300K+ Microsoft employees and Azure's global infrastructure) operates at volumes far beyond typical enterprise ingestion. The platform is operating within its design envelope at enterprise scale.

Failure Modes. The primary risk is not throughput. It is the licensing complexity: ingestion costs, hot/cool retention costs, and per-user analytics licenses are three separate cost lines that must be modeled together. A CISO who models only the ingestion cost will understate the TCO by 30–50%. The secondary risk is the KQL learning curve for analysts who are not data engineers.

Parser Framework. Dynamic field extraction, JSON/XML parsing, CEF/LEEF normalization, custom parsing via data connectors. Microsoft-native data is natively structured. Non-Microsoft logs are parsed via connector configuration.

Normalization Engine. Translates vendor-specific formats into Sentinel's internal schema using the Open Cybersecurity Schema Framework (OCSF). Microsoft is a primary contributor to OCSF. This is a genuine standardization advantage: the schema is not proprietary. It is an industry framework that Microsoft helped design.

Schema Model. OCSF-aligned. Also supports CIM mapping for organizations that have standardized on Splunk CIM. Custom field mappings via data connector transformation rules. In a multi-tool SOC, the OCSF alignment is a reduce-friction advantage versus Datadog's or Securonix's proprietary schemas.

Query Language. KQL (Kusto Query Language). Expressive, SQL-like, supports full-text search, joins, aggregations, subqueries, and recursive CTEs. More expressive than Datadog's log search. Less verbose than SPL. The learning curve is 2–4 weeks for analysts without a data engineering background. For analysts with SQL or data engineering experience, the adjustment is 1–2 weeks.

Hunting Workflows. Analytic rule templates, ML-assisted anomaly detection, manual hypothesis building with the Entity view (user, device, IP, file, URL relationships), and the Investigation graph. The Investigation graph is a genuine hunting advantage: it visualizes the relationship between entities in an incident, not just a flat list of log events.

Dashboard Builder. Drag-and-drop, role-based templates, real-time streaming, alert-linked auto-refresh. The dashboard ecosystem is shared with Azure Monitor and Power BI.

BI and Reporting. Native Power BI integration. For a Microsoft-centric organization, security data flows into Power BI dashboards without a separate BI tool. Scheduled reports, executive summaries, compliance exports.

Where Detection Comes From. The same architectural reality. WAF detection is CRS 4.25. Endpoint detection is Defender for Endpoint (or a third-party EDR). The Microsoft-native detection (Entra ID risk detections, Microsoft 365 threat detections, Defender for Cloud misconfigurations) is native to the platform and is the deepest Microsoft-specific detection in this review.

The Microsoft Threat Intelligence Advantage. Microsoft's threat intelligence is derived from the Windows, Office, Azure, Bing, LinkedIn, and GitHub user bases. The volume of observed malicious activity across that surface is the largest in the industry. The IOCs, TTP mappings, and threat actor profiles are informed by that data. This is a genuine differentiator. A CISO evaluating threat intel quality should weight the Microsoft intel feed accordingly.

SOAR Depth. Sentinel SOAR playbooks are Logic Apps-based. They support conditional branching, API actions, and ITSM integration. The native containment path (playbook → Defender for Endpoint API → host isolation, process kill, file quarantine) is faster than a SOAR calling a third-party EDR API. For multi-system orchestration, the depth is comparable to other platforms. The Logic Apps integration means that the SOAR workflows can call any Azure service, any HTTP API, or any Logic Apps connector, which is a broader integration surface than a purpose-built SOAR's fixed connector library.

The Free-Stack Context. Same as every other platform. The detection primitives are commodity. The Microsoft-specific value is the native integration with the M365/Entra/Defender stack, the scale of the threat intel, and the OCSF standardization. For an organization already in the Microsoft stack, the integration value is real. For an organization that is not, the integration value is limited to the Azure and non-Microsoft connector surface.

The SIEM Administrator Question. Same transformation. The remaining role is security data architecture: KQL query design, analytic rule tuning, OCSF mapping, compliance evidence management, integration architecture, vendor management.

Pricing Model. Three separate cost lines: (1) log ingestion ($/GB), (2) data retention (hot vs. cool, $/GB/month), (3) per-user analytics license. This three-line model is the most complex in this review. A CISO who models only the ingestion cost will understate the TCO.

Estimated Monthly Platform Costs. Projections based on Azure Sentinel pricing benchmarks. Actual pricing requires a Microsoft quote.

Base ingestion: ~$2.75–$4.00/GB at enterprise tiers. Hot retention: $0.10–$0.18/GB/month. Cool retention: $0.02–$0.05/GB/month. Per-user analytics license: $3–$6/user/month (often bundled in M365 E5/G5 or Defender licensing).

The M365 E5/G5 Bundle Effect. For organizations already licensed for M365 E5 or G5, Sentinel ingestion is included. The incremental cost is the hot/cool retention beyond the included volume and the per-user analytics license (also included in E5/G5). For those organizations, the marginal cost of Sentinel is significantly lower than the list price. This is the Microsoft strategy in action: the SIEM is already paid for. The question is whether to use it.

Search Economics. Unlimited within retained volume. No per-query, per-result-set, or per-GB-scanned fees. Compute auto-scales. Search costs are included.

Storage Tiers

User Seats

Volume Scaling. Multi-year commitments. Volume discounts at enterprise tiers. M365 E5/G5 bundling reduces marginal cost.

Microsoft Sentinel Pricing

Microsoft Sentinel is billed based on the volume of data ingested for analysis in Microsoft Sentinel. Microsoft Sentinel offers a flexible and predictable pricing model.

There are two ways to pay for the Microsoft Sentinel service: Commitment Tiers and Pay-As-You-Go. The cost for Microsoft Sentinel depends on the pricing tier selected. Learn more about Microsoft Sentinel pricing.

This workspace is in the simplified pricing tier experience. The pricing tiers shown below include the total cost for Azure Monitor Log Analytics data ingestion and Microsoft Sentinel analysis of all analytics logs in this workspace. Learn more

50 GB/day

25% discount over Pay-as-you-go | $161.25 per day

100 GB/day

31% discount over Pay-as-you-go | $296.00 per day

200 GB/day

36% discount over Pay-as-you-go | $548.00 per day

300 GB/day

38% discount over Pay-as-you-go | $800.00 per day

400 GB/day

40% discount over Pay-as-you-go | $1,037.33 per day

500 GB/day

41% discount over Pay-as-you-go | $1,265.00 per day

1,000 GB/day

42% discount over Pay-as-you-go | $2,480.00 per day

2,000 GB/day

44% discount over Pay-as-you-go | $4,800.00 per day

5,000 GB/day

46% discount over Pay-as-you-go | $11,550.00 per day

10,000 GB/day

48% discount over Pay-as-you-go | $22,240.00 per day

25,000 GB/day

50% discount over Pay-as-you-go | $53,450.00 per day

50,000 GB/day

52% discount over Pay-as-you-go | $102,600.00 per day

Pay-as-you-go

$4.30 per GB

The FedRAMP High authorization is the strongest government compliance posture among the twelve platforms. For federal, state, and defense contractor deployments, this is a differentiator that no other platform in this review matches at the High level.

Ecosystem Context. The Microsoft ecosystem integration is the broadest in this review. Windows, M365, Entra ID, Defender (Endpoint, Identity, Cloud, Office 365), Azure, GitHub, Power BI, Logic Apps, Function Apps, Power Automate. For a Microsoft-centric organization, the integration surface eliminates the need for most third-party connectors. For a non-Microsoft organization, the integration surface is competitive but not differentiated.

Named Enterprise Customers (Microsoft Sentinel-Specific, Primary or Significant SIEM Role):

• HSBC
• Ford Motor Company
• T-Mobile US
• State Farm
• Lowe's
• PepsiCo
• Shell
• Samsung Electronics
• Volkswagen
• Unilever
• TD Bank Group
• Xerox

Public customer lists are restricted by NDA. A significant portion of Microsoft Sentinel deployments are M365 E5/G5 shops ingesting Microsoft-native telemetry as a supplementary data layer alongside a primary SIEM. The named customers above represent organizations where Sentinel is a significant or primary component of the security architecture. Order does not indicate deployment scale.

Deployment Context. The CISO evaluating Sentinel should ask: of the vendor's named customers, how many are running Sentinel as their primary SIEM, how many are running it as a Microsoft-telemetry layer alongside another primary SIEM, and how many are using it exclusively for M365/Defender telemetry ingestion without active SOC investigation? The ratio of those three categories determines whether the customer base validates Sentinel as a SIEM or as a Microsoft data layer.

MSSP Note. Excluded per standardized format.

Analyst Positioning. Microsoft Sentinel is a leader in Gartner's SIEM and cloud security market guides. It is the default choice for Microsoft-centric and Azure-centric organizations. It is a strong #2 for multi-cloud organizations. It is not the default for on-prem-centric or non-Microsoft environments.

Where Microsoft Sentinel Competes Effectively:

• Microsoft-native integration depth. For organizations running M365, Entra ID, Defender, and Azure, the native telemetry ingestion, detection, and correlation is the deepest in this review. The M365 E5/G5 bundling makes the marginal cost of Sentinel significantly lower than the list price.
• FedRAMP High. The strongest government compliance posture in this review. For federal, state, and defense contractor deployments, this is a differentiator.
• Threat intelligence scale. The Windows, Office, Azure, and Bing observation surface generates threat intel that is informed by the most widespread enterprise software in the world.
• KQL expressiveness. More expressive than Datadog's log search. More approachable than SPL. Adequate for complex forensic queries.
• OCSF standardization. Microsoft is a primary OCSF contributor. For organizations standardizing on OCSF across multiple tools, Sentinel's alignment is native.
• Logic Apps SOAR surface. The SOAR workflows can call any Azure service, any HTTP API, or any Logic Apps connector. The integration surface is broader than a purpose-built SOAR's fixed connector library.

Where Microsoft Sentinel Is at a Disadvantage or Requires Diligence:

• Licensing complexity. Three separate cost lines (ingestion, retention, per-user) produce the most complex TCO model in this review. A CISO who models only ingestion will understate the cost by 30–50%. The M365 E5/G5 bundle effect is real but requires careful modeling of what is included and what is incremental.
• KQL learning curve. 2–4 weeks for analysts without a data engineering background. In a multi-SIEM environment, maintaining KQL alongside SPL or ESQL is a cognitive cost.
• Non-Microsoft detection depth. For AWS-centric, GCP-centric, or on-prem-centric environments, the detection depth and integration surface are competitive but not differentiated. The Microsoft-native depth does not apply.
• Ecosystem lock-in. The Microsoft stack integration is the advantage and the risk. The M365, Entra ID, Defender, and Azure integrations are the deepest, but they are also the lock-in. Exiting Sentinel means migrating the Microsoft telemetry layer, which is entangled with the M365 and Azure infrastructure.
• Vendor strategy risk. Microsoft's long-term strategy is consolidation: one stack, one agent, one platform. The CISO should evaluate whether that consolidation aligns with the organization's strategic direction or whether it creates a single-vendor dependency that the organization does not want.
• SOAR depth for non-Microsoft containment. The native containment path (Defender for Endpoint) is fast for Microsoft-stack endpoints. For non-Microsoft endpoints (Linux servers running Falco and Wazuh, or endpoints running CrowdStrike), the containment path is an API call to a third-party EDR, which is the same path as every other platform on this list.

Microsoft Sentinel is the strongest platform in this review for organizations that are Microsoft-centric (M365, Entra ID, Azure, Defender) and that require FedRAMP High or CMMC compliance. The native integration depth, the M365 E5/G5 bundle effect, the threat intelligence scale, and the OCSF standardization are genuine differentiators. The KQL query language is expressive and well-suited for complex forensic queries.

For organizations that are not Microsoft-centric, Sentinel is competitive but not differentiated. The non-Microsoft detection depth, the licensing complexity, and the KQL learning curve are friction points that do not exist for the Microsoft-centric buyer.

The CISO's decision framework is the ratio: what percentage of the organization's telemetry is Microsoft-native? If the answer is 50% or more, the consolidation into Sentinel is rational and the M365 bundle effect makes the marginal cost attractive. If the answer is 20% or less, the consolidation is a migration project with high friction and modest benefit, and the existing primary SIEM with a Microsoft telemetry connector is operationally simpler.

Ideal buyer profile: Microsoft-centric organization (M365, Entra ID, Azure, Defender), 5,000–50,000 endpoints, federal/state/defense (FedRAMP High, CMMC) or commercial, SOC team of 10–100 analysts, seeking to consolidate Microsoft-native telemetry into a single correlation platform with minimal incremental cost. Ingestion volume 1–5 TB/day.

Key RFP questions:

1. What is the total 3-year TCO including ingestion, hot retention, cool retention, per-user licenses, SOAR, and support, at the organization's actual volume and seat count? Model the M365 E5/G5 bundle effect explicitly.
2. What percentage of your named enterprise customers are running Sentinel as their primary SIEM versus as a Microsoft-telemetry layer alongside another primary SIEM?
3. For non-Microsoft log sources (AWS, GCP, on-prem, WAF, third-party EDR), provide a detection rule count and MITRE ATT&CK® coverage comparison against your top two competitive alternatives.
4. Demonstrate the UEBA baselining period in a 30-day proof-of-concept. Measure false-positive rate at day 1, 7, 14, and 30.
5. Execute the organization's top-10 incident response scenarios in Sentinel SOAR. Identify which require external orchestration for non-Microsoft endpoints.
6. Confirm FedRAMP High authorization scope, region, and the specific Azure region where the authorization is scoped. Obtain the authorization letter.
7. Provide the data export and egress costs for a 7-year compliance retention requirement.
8. Detail the KQL training and certification path for the SOC team. What is the estimated time-to-productivity for an analyst transitioning from SPL or ESQL?
9. Provide 3–5 referenceable enterprise customers in the organization's industry vertical at comparable scale, with the deployment context (primary SIEM vs. Microsoft telemetry layer vs. M365-only ingestion).
10. What is the contractual commitment for the security vertical's R&D investment over the contract term? Is Sentinel a strategic priority for Microsoft, or a product line within Azure?

Red flags to watch for:

• A TCO model that only includes ingestion and omits hot retention and per-user licenses. The three-line model is the most common source of cost surprise in Sentinel deployments.
• A sales presentation that leads with "AI-powered" without specifying what the AI does. The detection is from Defender for Endpoint, M365 threat protection, CRS 4.25 in the WAF, and upstream EDR. Sentinel correlates, enriches, and routes.
• Bundling pressure: attempts to lock Sentinel into a broader Azure commitment that includes compute, storage, and networking.