NOTE: This analysis is based on real tenant observations and controlled experiments documented on f11.ca (Experiment ID: EID-EXP-006).
Microsoft Entra Identity Protection is widely deployed, yet many organisations underutilise it by not operationalising its detection capabilities.
In practice, risky sign-ins and users are detected, but notifications are often not sent. This leads to a detection-only approach and delayed response.
This technical deep dive (EID-EXP-006) explains how Identity Protection alerting functions, where to configure notifications, how thresholds operate, and how to validate detection and alert delivery.
Why This Matters (Engineer View)
Identity Protection produces actionable signals:
- leaked credentials detection
- password spray detection
- unfamiliar sign-in properties
- anonymous IP address
- impossible travel
- atypical travel
- malicious IP address
However, the platform does not automatically notify your SOC unless notification recipients are explicitly configured. This often leads to a common failure mode:
- Detections exist
- Alerts are never sent.
- Engineers may assume Microsoft will send email notifications
- Incidents are discovered only after user reports or SIEM correlation.
Lab Scope (EID-EXP-006)
This experiment focuses on configuring and validating:
- Users at risk detected alerts.
- Risky sign-ins detected alerts.
- Weekly digest
- Recipient behavior (security admins vs custom recipients)
- Threshold behavior (Medium vs High)
- Portal validation and timing expectations
Requirements
Licensing
Identity Protection alerting requires:
- Microsoft Entra ID P2
or - Microsoft 365 E5
Without these licenses, the Identity Protection UI may be limited, and risk policies or alerting features may be unavailable.
Roles
Recommended roles:
- Security Administrator
- Global Administrator
Where Alerting is Configured
In the Entra admin center:
Microsoft Entra admin center → Protection → Identity Protection → Notifications
This is separate from:
- Conditional Access policies
- Microsoft Defender alerts
- Microsoft Purview alerts
- Sentinel analytics rules
Engineers often overlook this, expecting alerting to be included in:
- “Risky sign-ins” report
- “Risk detections” view
- CA policy configuration
Notification Types in Identity Protection
Identity Protection supports:
1) Users at risk detected alerts
Triggers when:
- A user is classified as risky (User risk)
- based on risk detections and correlation
This differs from a risky sign-in alert.
2) Risky sign-ins detected alerts
Triggers when:
- A sign-in is evaluated as risky (Sign-in risk)
This alert is event-based.
3) Weekly digest
This is a periodic summary email for reporting purposes.
Understanding Risk Thresholds
Both risky-user and risky-sign-in alerts support risk thresholds.
Typical options:
- Low and above
- Medium and above
- High only
Lab Recommendation
For testing:
- Medium and above
Production Consideration
Many organizations default to High only, which often results in:
- no false assumption that there is no risk.”
In practice, Medium is often a more effective operational threshold for:
- SMB tenants
- MSP-managed environments
- early-stage Identity Protection rollouts (Microsoft Entra ID Protection overview, 2025)
Step-by-Step Configuration (EID-EXP-006)
Step 1 — Confirm Identity Protection Availability
- Open Entra admin center
- Go to:
Protection → Identity Protection Validate:
- dashboard loads
- Risk reports exist
- no licensing warnings
Step 2 — Configure Users at Risk Detected Alerts
- Go to:
Identity Protection → Notifications - Under:
Users at risk detected alerts Enable:
- Send email notifications
Select recipients:
- Security admins
Add additional recipients:
- SOC shared mailbox
- ticketing system mailbox
Set threshold:
- Medium and above
- Save
Step 3 — Configure Risky Sign-ins Detected Alerts
- In the same Notifications page
- Under:
Risky sign-ins detected alerts - Enable email notifications
Select:
- Security admins
- Add additional recipients
Set threshold:
- Medium and above
- Save
Step 4 — Enable Weekly Digest (Optional)
- Enable weekly digest
- Add recipients
- Save
Validation and Expected Behavior
Important: Risk detections are not immediate.
Identity Protection risk evaluation is not always real-time.
Observed latency can be:
- 5 minutes
- 15 minutes
- 30 minutes
This impacts the timing of alerts. (Log latency in Microsoft Entra ID, 2023)Engineers should not assume the following:
hat the configuration did not work if an alert does not arrive immediately.
Practical Ways to Trigger Risk (Lab Scenarios)
In lab environments, risk events can be difficult to trigger consistently.
Common test methods:
- Sign in from a new country (VPN)
- Use anonymous IPs
- sign in from a new device + new location
- impossible travel patterns
However, risk signals depend on Microsoft detection pipelines and may vary between environments.
Observed Behavior (EID-EXP-006)
What worked as expected
- Notification configuration saves correctly.
- Both risky sign-in and risky user alerts can be enabled simultaneously.
- Security admins and custom recipients can be used together.
- Weekly digest delivers a summary report.
What engineers should expect
Alerting only occurs when:
- A risk event occurs
- The event meets the threshold.
- Some events show in the portal before the email is delivered.
- Risk classification may be updated after the sign-in
Common Issues Engineers Hit
1) No emails received
Check:
- threshold set too high (High only)
- recipients not configured
- security admins not present / not assigned
- Email going to junk/spam.
2) Risk detections not showing up
Check:
- licensing
- tenant too “quiet.”
- Risk signals not triggered
3) Confusion between User risk and Sign-in risk
This distinction is a significant operational gap. (Security guidance - Monitor and detect cyberthreats - Microsoft Entra | Microsoft Learn, 2025)
- Sign-in risk = this login attempt is suspicious (Microsoft Entra ID Protection, 2023)
- User risk: the identity account is compromised or is likely to be compromised.
Both types of risk should be monitored. (Microsoft Entra ID Protection, 2023)
Engineering Best Practices
1) Route alerts to operations, not individuals
Avoid sending alerts to a single administrator mailbox.
Recommended:
- shared SOC mailbox
- ticketing system email connector
- SIEM ingestion
2) Pair notifications with Conditional Access
Alerts are for detection.
Conditional Access is enforcement.
A strong pattern:
- medium sign-in risk → require MFA
- high sign-in risk → block
- high user risk → require password reset
3) Document your risk thresholds
Clearly document the rationale for selecting the Medium threshold over the High threshold.
Conclusion
Identity Protection detections without notifications create a silent detection gap.EID-EXP-006 confirms that Entra Identity Protection can deliver meaningful email alerts for:
- risky users
- risky sign-ins
However, this is effective only when notifications are configured, thresholds are set appropriately, and recipients are actively monitored.
Related Evidence & Guidance
About the Author
Author: Jaspreet Singh
Platform: ITBlogs.ca
References
(2025). Microsoft Entra ID Protection overview. Microsoft Entra ID Protection dashboard. https://learn.microsoft.com/en-us/azure/active-directory/identity-protection/id-protection-dashboard
(2023). Log latency in Microsoft Entra ID. Microsoft Entra ID. https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-log-latency
(2025). Security guidance - Monitor and detect cyberthreats - Microsoft Entra | Microsoft Learn. Microsoft Learn. https://learn.microsoft.com/en-us/entra/fundamentals/zero-trust-monitor-detect
(2023). Microsoft Entra ID Protection. Microsoft Security. https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-id-protection
(2023). Microsoft Entra ID Protection. Microsoft Entra ID Protection Datasheet. https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-id-protection