What Is Azure Identity Protection?
Azure Identity Protection, now Microsoft Entra ID Protection, is the risk-detection and response layer for Microsoft Entra identities. It evaluates signals that may indicate account compromise and exposes them as user risk, sign-in risk, risky users, and risk detections.
The important operational point is that detection alone does not contain an attack. A tenant can show risky users and risky sign-ins in the portal while still allowing the attacker to continue if no policy requires remediation, multifactor authentication, reauthentication, password change, or blocking. This article focuses on that gap: risk is visible, but the tenant response is missing, incomplete, or scoped too narrowly.
Microsoft's current guidance places risk-based controls in Conditional Access. Legacy Identity Protection risk policies still exist in some tenants, but Microsoft documentation says legacy user risk and sign-in risk policies should be migrated to Conditional Access and are scheduled for retirement on October 1, 2026.
How Azure Identity Protection Works
Identity Protection uses two closely related risk concepts:
Sign-in risk is the probability that a specific authentication request is not made by the legitimate identity owner. It is evaluated during sign-in and can be used as a Conditional Access condition.
User risk is the probability that the user account itself is compromised. It can persist beyond one sign-in and may require password change, session revocation, administrator investigation, or dismissal.
Microsoft documents risk detections such as leaked credentials, anonymous IP address, atypical travel, unfamiliar sign-in properties, malicious IP address, suspicious inbox rules, password spray, anomalous token, and other signals. Some detections are real-time, while others are calculated offline and can appear later. That timing matters for operations: a risk event can surface after the original authentication has already completed.
Why Risk Policies Fail in Practice
Identity Protection underperforms when teams treat the dashboard as the control. Common failure modes include:
- no Conditional Access policy uses sign-in risk or user risk conditions
- policies are left in report-only mode after testing
- risk policies cover pilot users but not privileged users or the general population
- emergency accounts are excluded without compensating monitoring
- hybrid users cannot complete self-remediation because password writeback is not available where required
- risky-user notifications go to a mailbox no one reviews
- analysts can dismiss risk without a documented evidence standard
- service principals are mistaken for user-scoped Conditional Access coverage
The last point is important. User risk and sign-in risk policies target user sign-ins. Workload identity and service-principal risk require a different control model and should not be assumed covered by human user risk policies.
The Attack Chain Without Risk Response
Scenario 1 - Leaked Credentials
A user's credentials appear in breach data or are otherwise assessed as risky. Identity Protection raises user risk, but no user-risk policy requires remediation. The account remains usable until another control blocks the attacker.
Scenario 2 - Risky Sign-in That Still Completes
A sign-in has medium or high risk because of signals such as anonymous infrastructure, unfamiliar sign-in properties, or atypical travel. If no sign-in risk policy applies, the session may still complete. A log entry exists, but the attacker has already gained access.
Scenario 3 - Password Spray Against Cloud Accounts
A password spray campaign creates broad authentication noise and may produce risky detections. If successful sign-ins are not forced through step-up authentication or blocked according to policy, the attacker keeps the successful sessions.
Scenario 4 - Risk Dismissed Without Investigation
A risky user is dismissed because the alert is inconvenient or noisy. If the dismissal process does not require evidence, the tenant can normalize real compromise and remove the signal defenders needed.
Detection
Risk Signals to Monitor
| Signal | What It Indicates | Operational Use |
|---|---|---|
| Leaked credentials | Credentials associated with the account were found in known compromised material | Treat as account-compromise evidence until reviewed |
| Anonymous IP address | The sign-in came from anonymity infrastructure | Correlate with device, location, and user history |
| Atypical travel | Sign-in geography is inconsistent with recent activity | Review for impossible or suspicious travel patterns |
| Unfamiliar sign-in properties | The sign-in differs from normal user behavior | Useful when combined with device and location context |
| Malicious IP address | Source infrastructure is associated with malicious activity | Higher urgency for privileged users |
| Password spray | Broad password-guessing behavior is detected | Correlate with lockouts, failures, and successful sign-ins |
| Anomalous token | Token behavior appears suspicious | Review session activity and revoke where appropriate |
Events and Reports to Review
Detection should include:
- risky users report
- risk detections report
- sign-in logs with risk level and risk detail
- Conditional Access results for risky sign-ins
- audit logs for risk dismissal, password reset, policy changes, and admin actions
- privileged role context for affected identities
A high-risk sign-in for a Global Administrator is not the same operational priority as a low-risk event for a dormant test account. The alert should include role, device, location, app, policy result, and session outcome.
Remediation
Identity Protection becomes useful when risk triggers a response. A dashboard without enforced Conditional Access is only visibility.
1. Configure Separate Risk Policies
Microsoft guidance warns against combining user risk and sign-in risk conditions in the same Conditional Access policy. Create separate policies so each risk condition has a clear response path.
For sign-in risk, Microsoft recommends requiring multifactor authentication for medium and high sign-in risk. For user risk, Microsoft recommends requiring risk remediation when user risk is high. Organizations can choose stricter thresholds, but they must balance security, false positives, and user interruption.
2. Use Report-Only Mode, Then Enforce
Report-only mode is useful for rollout. It is not a final state. Review which users, apps, and scenarios would be affected, fix expected breakage, then move the policy to On. Keep a dated rollout record so report-only policies do not become permanent shelfware.
3. Make Self-Remediation Work
Self-remediation depends on prerequisites. Users must be registered for Microsoft Entra multifactor authentication before they can satisfy MFA-based remediation. Hybrid users may require password writeback for secure password change scenarios. If those prerequisites are missing, users can be blocked and require administrator intervention.
4. Define the Analyst Workflow
A risk policy does not replace investigation. Define who can:
- confirm user compromise
- dismiss user risk
- reset passwords
- revoke sessions
- unblock users
- approve exclusions
- update Conditional Access risk thresholds
Each action should have an evidence standard. Dismissing risk because the user says they traveled is not the same as validating device, IP, authentication method, and session activity.
5. Review Exclusions and Service Accounts
Emergency access accounts may need special handling, but exclusions should be few and heavily monitored. Service accounts and workload identities should not be silently excluded from the risk conversation; they may need workload identity Conditional Access, managed identities, credential rotation, or different monitoring.
Safe Rollout Sequence
A safe rollout does not start by blocking the entire tenant without evidence. Start with report-only policies for the intended population, review policy impact, fix registration and password writeback prerequisites, then enforce the policy in stages. Privileged identities should be prioritized because a successful risky sign-in for an administrator has a much higher blast radius than the same event on a low-privilege account.
Keep the rollout measurable. Track how many risky sign-ins would have been blocked or challenged, how many users could self-remediate, which accounts are excluded, and which incidents required administrator action. Those numbers help distinguish a working protection program from a policy that exists but cannot be safely enforced.
Validation After Enabling Risk Response
Validate the control from both the portal and the attacker perspective:
- confirm sign-in risk and user risk policies are enabled, not only configured
- confirm target users include privileged identities and normal users in scope
- confirm excluded users are documented and monitored
- review recent risky sign-ins and verify the intended policy result applied
- confirm successful high-risk sign-ins are rare, explainable, and investigated
- confirm administrators can confirm compromise, dismiss risk, revoke sessions, and reset credentials using documented workflows
- test alert routing so risky-user notifications reach the response team
- review whether workload identities require separate Conditional Access or monitoring
If the tenant detects risk but allows risky users to continue without remediation, the control is incomplete.
How EtcSec Detects This
EtcSec audits whether risk detections are tied to an enforced response path.
The Risk Protection category highlights missing sign-in risk policy, missing user-risk policy, and weak tenant response where risky activity is visible but enforcement is absent or incomplete.
That is the operational gap this article is concerned with: risk detections without containment.
Related Controls
Identity Protection works best when it is paired with Azure Identity Security: Why MFA Alone Is Not Enough, Azure Conditional Access: MFA Bypass With Stolen Passwords, Azure Privileged Access: Too Many Global Admins, Azure Guest Accounts: The Forgotten Attack Surface in Your Tenant, and Azure App Registrations: Over-Privileged Tenant Apps. Otherwise the tenant may detect risk but still leave adjacent privilege and application paths easy to exploit.
Primary References
Continue Reading
Kerberos RC4 Fallback in Active Directory: How to Detect It, Why It Still Happens, and How to Remove It
CVE-2026-31431 (Copy Fail): What the Linux Kernel Vulnerability Affects and How to Mitigate It
