This chapter covers Microsoft Entra Identity Protection, a key service for securing identities in the cloud. For the AZ-900 exam, this topic falls under Domain 2: Azure Architecture and Services, Objective 2.5: Describe identity, governance, privacy, and compliance features. Identity Protection is a moderate-weight topic, typically appearing in 2-4 questions. You'll need to understand its purpose, how risk detection works, and the remediation options. We'll break down the mechanisms, walk through a real-world scenario, and highlight exactly what the exam tests—including the common traps that trip up candidates.
Jump to a section
Imagine you run a large international airport. Every passenger (user) who wants to board a plane (access a resource) must pass through security. But you don't just check IDs at the door once and let everyone roam freely. Instead, you have a multi-layered system: a ticket scanner at the entrance (initial authentication), random bag checks (continuous verification), and a behavior-monitoring AI that watches for someone sprinting toward a gate without a ticket (real-time risk detection). Microsoft Entra Identity Protection is that AI-powered security system for your organization's digital identities. It continuously analyzes every sign-in attempt and user behavior, assigning a risk score (low, medium, high) based on factors like impossible travel (a login from New York and then London within 5 minutes), anonymous IP addresses, or leaked credentials. When a risk is detected, it can automatically trigger actions: require multi-factor authentication (like a secondary ID check), block the sign-in (like denying boarding), or force a password reset (like confiscating a fake passport). Just as airport security doesn't stop after you're through the gate—they monitor you until you board—Identity Protection continuously evaluates risk throughout a session, not just at login. It learns from global threat intelligence (Microsoft's network of billions of signals) to adapt to new attack patterns, much like airports share intelligence about new security threats across the globe.
What is Microsoft Entra Identity Protection and What Business Problem Does It Solve?
Microsoft Entra Identity Protection is a feature of Microsoft Entra ID (formerly Azure Active Directory) that detects, investigates, and remediates identity-based risks. It addresses a fundamental problem: passwords are weak, and even with multi-factor authentication (MFA), attackers can compromise accounts through phishing, credential stuffing, or session hijacking. Traditional security assumes that once a user authenticates, they are trustworthy for the entire session. Identity Protection challenges that assumption by continuously evaluating the risk of each sign-in and user behavior.
For a business, the cost of a compromised account is massive—data breaches, ransomware, regulatory fines. Identity Protection helps reduce that risk by automating detection and response. For example, if an employee's credentials are leaked on the dark web, Identity Protection can detect that and force a password reset on their next sign-in. If a user signs in from an unusual location or device, it can prompt for MFA or block the attempt. This reduces the burden on IT teams, who no longer need to manually review every suspicious sign-in.
How It Works: Step-by-Step Mechanism
Identity Protection works by analyzing every authentication event and user behavior against a set of risk detection algorithms. These algorithms are powered by Microsoft's threat intelligence, which aggregates signals from billions of daily sign-ins across Microsoft services.
Risk Detection Types: Identity Protection categorizes risks into two main types: sign-in risks and user risks. Sign-in risks are associated with a specific authentication attempt (e.g., the sign-in is from an anonymous IP address). User risks are associated with the user account (e.g., the user's credentials have been leaked). The system assigns a risk level: low, medium, or high.
Risk Scoring: Each detection type has a predefined risk score. For example, a sign-in from a known malicious IP address might score 60 (high), while a sign-in from an unfamiliar location might score 20 (low). These scores are aggregated to produce an overall risk level. The exact algorithms are proprietary, but Microsoft provides documentation on the relative severity of each detection.
Policies: Administrators configure conditional access policies that use Identity Protection risk signals. For example, a policy might say: 'If sign-in risk is medium or high, require MFA.' Or: 'If user risk is high, block sign-in and require password reset.' These policies are enforced at the time of authentication and can also apply to active sessions.
Remediation and Investigation: When a risk is detected, administrators can review the details in the Azure portal. They can confirm a sign-in as safe or confirm it as compromised. The system can also automatically remediate: for user risk, it can force a password reset; for sign-in risk, it can block the attempt or require MFA.
Integration with Other Services: Identity Protection integrates with Microsoft Defender for Cloud Apps (for session risk) and Microsoft Sentinel (for advanced threat hunting). It also feeds risk signals into Microsoft Entra ID's Conditional Access engine.
Key Components, Tiers, and Pricing
Risk Detections: A list of all risk types, including:
- Leaked credentials (user risk) - Impossible travel (sign-in risk) - Anonymous IP address (sign-in risk) - Malicious IP address (sign-in risk) - Unfamiliar sign-in properties (sign-in risk) - Malware-linked IP address (sign-in risk) - Password spray (sign-in risk) - Atypical travel (sign-in risk) - New country (sign-in risk) - Activity from anonymous IP (sign-in risk) - Suspicious browser (sign-in risk) - Token issuer anomaly (sign-in risk) - Suspicious inbox forwarding (user risk) - Mass access to sensitive files (user risk)
Risk Reports: Two main reports in the portal:
Risky sign-ins: shows sign-ins flagged as risky.
Risky users: shows users with elevated user risk.
Policies:
User risk policy: automatically remediates user risk (e.g., require password reset).
Sign-in risk policy: automatically responds to sign-in risk (e.g., require MFA, block sign-in).
Tiers: Identity Protection is available with Microsoft Entra ID P2 license. Some features (like risk detection reporting) are available in P1, but automated remediation policies require P2. Without P2, you can only view risks manually.
Pricing: Microsoft Entra ID P2 is approximately $9/user/month (as of 2024). It includes Identity Protection, Privileged Identity Management, and other premium features. There is no additional cost for Identity Protection beyond the P2 license.
Comparison to On-Premises Equivalent
In an on-premises environment with Active Directory, you might have tools like Microsoft Identity Manager (MIM) or third-party solutions for identity protection, but they lack the cloud-scale intelligence. On-premises solutions typically rely on static rules (e.g., lock account after 5 failed attempts) and do not have access to global threat intelligence. They cannot detect leaked credentials from the dark web or analyze impossible travel across geographic regions. Identity Protection leverages Microsoft's cloud infrastructure to process billions of signals and adapt in real time. The on-premises equivalent would require significant investment in threat intelligence feeds, custom scripting, and manual analysis.
Azure Portal and CLI Touchpoints
Azure Portal: Navigate to Microsoft Entra ID > Security > Identity Protection. Here you can view risky users, risky sign-ins, risk detections, and configure policies. You can also investigate specific detections and confirm compromise.
Microsoft Graph API: You can programmatically access Identity Protection data. For example, to list risky users:
GET https://graph.microsoft.com/v1.0/identityProtection/riskyUsersPowerShell: Using the Microsoft Graph PowerShell SDK:
Connect-MgGraph -Scopes 'IdentityRiskyUser.Read.All'
Get-MgIdentityProtectionRiskyUserAzure CLI: There is no direct Azure CLI command for Identity Protection; it is managed via the portal or Microsoft Graph API.
Concrete Business Scenario
Contoso, a global company, uses Microsoft Entra ID P2. They configure a sign-in risk policy: if sign-in risk is medium or high, require MFA. They also configure a user risk policy: if user risk is high, block sign-in and require password reset. One day, an employee named Alice tries to sign in from a new device in a country she's never visited. Identity Protection flags this as 'unfamiliar sign-in properties' with low risk. Because the risk is low, no action is taken. Later, Alice's password is leaked in a third-party breach. Identity Protection detects the leaked credentials and assigns high user risk to Alice's account. On her next sign-in, the user risk policy triggers: she is blocked and forced to reset her password. The IT team reviews the risky user report, sees the detection, and confirms it as compromised. Alice resets her password and signs in successfully. This automated response prevented a potential breach.
Enable Identity Protection
To start using Identity Protection, you need a Microsoft Entra ID P2 license. In the Azure portal, navigate to Microsoft Entra ID > Security > Identity Protection. The first time you access it, you'll see a dashboard with risk detection summaries. No additional setup is required—Microsoft automatically enables risk detection for all users in the tenant. However, you must configure policies to automate remediation. Behind the scenes, Azure begins collecting and analyzing sign-in data from all users, comparing it against global threat intelligence. By default, risk detections are stored for 30 days for sign-in risks and 90 days for user risks.
Review Risk Detections
Go to the 'Risky users' or 'Risky sign-ins' report. You'll see a list of users or sign-ins with risk levels. Click on any entry to see details: the type of risk (e.g., leaked credentials), the risk level (low, medium, high), the date/time, and the location. You can also see the risk history for a user. This step is crucial for understanding what Identity Protection is detecting. The exam may ask you to identify which report to use for a given scenario. For example, if you want to see all sign-ins from anonymous IP addresses, you'd look at 'Risky sign-ins' and filter by risk detection type.
Configure User Risk Policy
Under 'Identity Protection' > 'User risk policy', click 'Create policy'. Give it a name, then set the user risk level threshold (low and above, medium and above, or high). For remediation, you can choose 'Block sign-in' or 'Allow sign-in' with the option to 'Require password change'. Typically, you'd set it to high risk and require password change. This policy automatically forces a password reset when a user's risk reaches the threshold. The policy applies to all users or selected groups. Note: The policy does not affect users who are already signed in; it triggers on their next sign-in attempt.
Configure Sign-In Risk Policy
Similarly, create a sign-in risk policy under 'Sign-in risk policy'. Set the risk level threshold (e.g., medium and above). For control, choose 'Block sign-in' or 'Allow sign-in' with 'Require multi-factor authentication'. Most organizations use 'Require MFA' for medium and above. This policy evaluates each sign-in attempt in real time. If the risk is above the threshold, the user is prompted for MFA. If they cannot complete MFA, the sign-in is blocked. The policy works with Conditional Access; you can also create a separate Conditional Access policy that uses the sign-in risk as a condition.
Investigate and Respond Manually
Even with automated policies, you may need to manually investigate. In the 'Risky users' report, you can select a user and choose 'Confirm safe' or 'Confirm compromised'. Confirming safe removes the risk and adds the user to an allow list. Confirming compromised triggers a password reset and marks the user as high risk permanently. You can also dismiss a risk detection if it's a false positive. Manual investigation is important for fine-tuning policies and reducing false positives. The exam may test that you know the difference between 'confirm safe' and 'dismiss risk'—confirm safe applies to the user, while dismiss risk applies to a specific detection.
Scenario 1: Detecting Leaked Credentials
A mid-sized law firm uses Microsoft Entra ID P2 for all 500 employees. They enable Identity Protection and configure a user risk policy to require password reset on high risk. One morning, the IT admin notices the Risky Users report shows 12 users with high risk due to 'Leaked Credentials'. These credentials were exposed in a recent third-party breach. The policy automatically blocks these users on their next sign-in and forces a password reset. The admin also sends a company-wide email advising employees to use unique passwords. The automated response prevents attackers from using the stolen credentials to access the firm's confidential case files. Without Identity Protection, the firm might not have known about the breach until it was too late. The cost: $9/user/month for P2 licenses, which is far less than the potential cost of a data breach. However, if the firm had only P1 licenses, they would only see the risk report but would need to manually reset passwords—a time-consuming process that could lead to delays and missed threats.
Scenario 2: Blocking Impossible Travel Attacks
A global e-commerce company has employees working remotely worldwide. They configure a sign-in risk policy to require MFA for medium risk or higher. An attacker in Russia obtains a user's password and tries to sign in from an IP address in Moscow. Simultaneously, the real user is actively signed in from New York. Identity Protection detects impossible travel—the time between the two sign-ins is too short for physical travel—and assigns high sign-in risk. The policy triggers: the attacker is blocked because they cannot complete MFA (they don't have the user's phone). The real user is unaffected. The IT team later reviews the detection and confirms it as a true positive. This scenario highlights the importance of global threat intelligence—the system knows the user's typical location and detects anomalies. A common mistake is thinking that Identity Protection only works with Azure AD-joined devices; actually, it works with any sign-in, including from personal devices.
Scenario 3: Managing False Positives
A university uses Identity Protection for 10,000 students and staff. They configure a sign-in risk policy to block sign-ins with high risk. However, they receive complaints from students who are blocked when traveling abroad for study programs. The IT admin investigates and finds that the 'unfamiliar sign-in properties' detection is flagging legitimate travel. To reduce false positives, they adjust the policy to only require MFA for high risk instead of blocking, and they add trusted IP addresses for the university's campus. They also use the 'confirm safe' option for known good users. This reduces friction while maintaining security. The key takeaway: Identity Protection policies should be tuned based on organizational context. The exam may test that you can adjust risk thresholds to balance security and usability.
Exactly What AZ-900 Tests on This Objective
Objective 2.5: Describe identity, governance, privacy, and compliance features. Within this, Identity Protection is specifically listed as 'Microsoft Entra ID Protection' (formerly Azure AD Identity Protection). The exam expects you to:
Understand the purpose: detect and respond to identity risks.
Know the two types of risk: user risk and sign-in risk.
Know the three risk levels: low, medium, high.
Know the remediation actions: block sign-in, require MFA, require password reset.
Know the licensing requirement: Microsoft Entra ID P2 for automated policies.
Common Wrong Answers and Why Candidates Choose Them
'Identity Protection is available with Microsoft Entra ID Free.' Candidates see that some features of Entra ID are free and assume Identity Protection is included. Reality: Only basic risk reports are available with P1; automated policies require P2.
'User risk policy requires MFA.' Candidates confuse user risk and sign-in risk policies. User risk policy remediates by requiring password reset, not MFA. Sign-in risk policy can require MFA or block.
'Identity Protection can prevent phishing attacks.' Identity Protection can detect risky sign-ins but cannot prevent phishing emails. It can detect if a user falls for a phishing link and their credentials are compromised (leaked credentials). The exam wants you to know the difference between prevention and detection.
'Risk levels are based on a single detection.' Candidates think each detection has a fixed risk level. In reality, the overall risk level is an aggregate of multiple signals. The exam may present a scenario where multiple low-risk detections combine to medium risk.
Specific Terms and Values That Appear Verbatim on the Exam
'Leaked Credentials' is a user risk detection type.
'Anonymous IP address' is a sign-in risk detection type.
'Impossible travel' is a sign-in risk detection type.
'Microsoft Entra ID P2' is the required license for automated remediation.
'Require password change' is the action for user risk policy.
'Require multi-factor authentication' is an action for sign-in risk policy.
Edge Cases and Tricky Distinctions
Confirm safe vs. Dismiss risk: 'Confirm safe' applies to a user and removes all risks for that user. 'Dismiss risk' applies to a specific detection and only removes that detection. The exam may ask which action to take for a false positive.
User risk vs. Sign-in risk: User risk is associated with the account (e.g., leaked credentials). Sign-in risk is associated with a specific authentication attempt (e.g., anonymous IP). A user can have multiple risky sign-ins but low user risk.
Policy application timing: User risk policy triggers on the next sign-in after the risk is detected. Sign-in risk policy triggers during the sign-in attempt. The exam may test this difference.
Memory Trick: 'USR' for User risk: password reSet; 'SIN' for Sign-in risk: Mfa or Block
User risk = password reSet (USR -> Reset). Sign-in risk = MFA or Block (SIN -> MFA/Block). This helps you remember which policy does what.
Microsoft Entra Identity Protection detects identity risks like leaked credentials and impossible travel.
Two risk types: user risk (account-level) and sign-in risk (session-level).
Three risk levels: low, medium, high.
Automated remediation requires Microsoft Entra ID P2 license.
User risk policy can require password reset; sign-in risk policy can require MFA or block.
Risk detection is enabled by default; only policies need configuration.
Identity Protection integrates with Conditional Access policies.
Common exam terms: 'Leaked Credentials', 'Anonymous IP', 'Impossible Travel'.
These come up on the exam all the time. Here's how to tell them apart.
User Risk Policy
Targets the user account (e.g., leaked credentials)
Remediation actions: Block sign-in or Require password change
Triggers on the next sign-in after risk is detected
Risk levels: low, medium, high (user risk)
Typical use: compromised credentials
Sign-In Risk Policy
Targets a specific sign-in attempt (e.g., anonymous IP)
Remediation actions: Block sign-in or Require MFA
Triggers during the sign-in attempt
Risk levels: low, medium, high (sign-in risk)
Typical use: suspicious sign-in behavior
Mistake
Identity Protection is only for cloud-only accounts.
Correct
Identity Protection works with both cloud-only and synchronized on-premises accounts (via Microsoft Entra Connect). It can detect risks for hybrid identities as well.
Mistake
You need to manually enable risk detection.
Correct
Risk detection is enabled by default for all tenants with Microsoft Entra ID P2. You only need to configure policies to automate remediation.
Mistake
Identity Protection can block a sign-in after it has occurred.
Correct
Sign-in risk policy evaluates risk during the authentication attempt. If the risk is high, the sign-in is blocked in real time. It cannot retroactively block a sign-in that already happened.
Mistake
All risk detections are equally weighted.
Correct
Different risk detections have different severity levels. For example, 'leaked credentials' is typically high risk, while 'unfamiliar sign-in properties' may be low or medium.
Mistake
Identity Protection requires Azure AD Premium P1 for automated policies.
Correct
Automated policies (user risk and sign-in risk policies) require P2. P1 only provides risk reports without automated remediation.
You need Microsoft Entra ID P2 (or Azure AD Premium P2) for automated user risk and sign-in risk policies. With P1, you can view risk reports but must manually remediate. Free tier does not include Identity Protection. The exam often tests this licensing requirement, so remember: P2 for automation, P1 for reports only.
User risk is associated with the user account itself, such as when credentials are leaked. Sign-in risk is associated with a specific authentication attempt, such as signing in from an anonymous IP address. User risk policy triggers on the next sign-in, while sign-in risk policy triggers during the sign-in. The exam may ask you to choose the correct policy for a scenario.
A user risk policy can either block sign-in or allow sign-in but require a password change. It cannot require MFA; that's for sign-in risk policy. The recommended action for high user risk is to require password change to force the user to update their compromised credentials.
Microsoft continuously monitors the dark web and other sources for leaked credential lists. When a username and password combination appears in a breach, Microsoft correlates it with your tenant's users. If a match is found, Identity Protection assigns high user risk to that account. This detection is automatic and does not require any configuration.
Yes, if you synchronize your on-premises AD with Microsoft Entra ID using Microsoft Entra Connect. Identity Protection works with hybrid identities. However, the risk detection and policies apply to cloud-based sign-ins. On-premises authentication is not covered unless you use Microsoft Entra ID for authentication (e.g., with pass-through authentication or federation).
Impossible travel detects sign-ins from geographically distant locations within a time frame that makes physical travel impossible. For example, a sign-in from New York and then from London 10 minutes later. This indicates that the second sign-in is likely from an attacker. It is a sign-in risk detection type and is considered high risk.
In the Azure portal, go to Microsoft Entra ID > Security > Identity Protection > Risky users. Select the user and click 'Confirm safe'. This removes all risk from the user and adds them to an allow list. Use this when you have investigated and determined the risk was a false positive. Confirming safe is a manual action and cannot be automated.
You've just covered Microsoft Entra Identity Protection — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?