Microsoft entra ID protection alert ingestion into sentinel

This is expected if the workspace was onboarded to the Defender portal and the tenant is licensed for Defender XDR; stopping it requires disconnecting the unified Defender XDR incident-and-alert integration, which stops all Defender XDR alerts rather than only Microsoft Entra ID Protection alerts.

Why the alerts appeared automatically

When Sentinel is onboarded to the Defender portal:

• The Microsoft Defender XDR data connector is configured automatically.
• Standalone connectors, including Microsoft Entra ID Protection, are disconnected.
• Alerts from Microsoft security products are then routed through the unified Defender XDR connector into the Sentinel workspace. ^1^

This flow does not depend on an Entra diagnostic setting. Diagnostic settings control Entra logs such as sign-in and audit logs; these Identity Protection alerts arrive through the security-alert connector pipeline.

To verify the source, run this in Microsoft Sentinel → Logs:

SecurityAlert
| where ProductName has_any ("Azure Active Directory Identity Protection",
                             "Microsoft Entra ID Protection",
                             "Microsoft Defender XDR")
| summarize Alerts=count() by ProductName, ProviderName
| order by Alerts desc

SecurityAlert is associated with both the Microsoft Defender XDR and Microsoft Entra ID Protection connectors. ^2^

Stopping the ingestion

There is no documented per-product switch to exclude only Entra ID Protection alerts from the unified Connect incidents & alerts stream. That connection carries Defender XDR incidents and their associated alerts collectively. ^3^

Before changing it, the account needs:

• Security Administrator or equivalent tenant permissions.
• Read/write permissions on the Sentinel workspace.
• Membership in the same Entra tenant as the workspace. ^3^

Choose the path matching the workspace deployment:

• Workspace automatically onboarded to the Defender portal: manage the integration from the Defender portal. The Azure portal’s manual connector procedure does not apply to an already-onboarded workspace. To remove the unified connection completely, offboard the Sentinel workspace from Microsoft Defender; offboarding also disconnects the Microsoft Defender connector. ^4^
• Workspace still managed through the Azure portal: go to Microsoft Sentinel → Configuration → Data connectors → Microsoft Defender XDR → Open connector page, and disconnect the incidents-and-alerts integration. The control being removed is the same integration enabled by Connect incidents & alerts. ^3^

This is a broad change: Defender XDR incident synchronization and alerts from the other integrated Microsoft security services will also stop flowing into Sentinel. It should not be used merely to reduce ingestion charges.

Cost consideration

SecurityAlert (IPC) data from Microsoft Entra ID Protection is listed as a free Sentinel data type. Defender XDR SecurityAlert and SecurityIncident ingestion is also free; raw Entra and Defender logs can still be chargeable. ^5^

The XDR path also filters Entra alerts by severity by default: alerts below High severity are not ingested unless ingestion is configured to include all severities. ^6^ Therefore, if the concern is cost rather than unwanted incidents, retaining the connection is normally preferable because these alert-table records are not billed.

References

1. Microsoft Defender XDR integration with Microsoft Sentinel
2. Microsoft Sentinel tables and associated connectors
3. Stream data from Microsoft Defender XDR to Microsoft Sentinel in the Azure portal
4. Transition your Microsoft Sentinel environment to the Defender portal
5. Plan costs and understand Microsoft Sentinel pricing and billing
6. Alert schema differences: Standalone vs. Microsoft Defender XDR connector