Entra ID Protection: Risk-Based Security | Guided by A Guide to Cloud

What is ID Protection?

Simple explanation

ID Protection is like a credit card fraud detection system — but for sign-ins.

When you use your credit card in a new country, the bank doesn’t just block it. It flags the transaction as risky and might ask you to confirm it’s really you (a text message, a call). If you don’t confirm, it blocks the charge.

Entra ID Protection does the same thing. It watches every sign-in and asks: “Does this look normal?” If not — unusual location, impossible travel, leaked password — it raises a risk flag. Then your policies decide what happens: ask for MFA, force a password change, or block access entirely.

Feature	User Risk	Sign-in Risk
What it measures	Probability the user's identity is compromised	Probability this specific sign-in is illegitimate
Scope	Persists across all sign-ins until remediated	Per sign-in — each sign-in has its own risk level
Example detections	Leaked credentials, anomalous user activity, threat intel	Unfamiliar sign-in properties, impossible travel, anonymous IP
Typical remediation	Require secure password change	Require MFA for this sign-in
Resets automatically?	Only after remediation (password change) or admin dismissal	After each sign-in evaluation — next sign-in gets fresh assessment
Affects future sign-ins?	Yes — until risk is cleared, every sign-in is affected	No — only the risky sign-in itself
Licence	Entra ID P2	Entra ID P2

Risk detections explained

Detection	Risk Level	What It Means
Anonymous IP address	Low–Medium	Sign-in from Tor exit node, anonymous VPN, or proxy
Atypical travel	Medium	Sign-in from a location unusual for this user
Impossible travel	Medium–High	Sign-ins from two locations too far apart for the time between them
Malware-linked IP	Medium	Sign-in from an IP known to communicate with bot servers
Unfamiliar sign-in properties	Medium	Sign-in with properties (device, location, app) never seen before
Password spray	Medium–High	Multiple accounts targeted with common passwords
Token anomaly	High	Token characteristics suggest it’s been tampered with or replayed

User risk detections

Detection	Risk Level	What It Means
Leaked credentials	High	User’s credentials found in a breach database
Anomalous user activity	Medium	Unusual behaviour patterns (mass file access, unusual admin actions)
Threat intelligence	Varies	Microsoft’s threat intelligence links the user to known attacks
Possible attempt to access PRT	Medium–High	Suspicious activity around the Primary Refresh Token

Configuring risk policies

Risk policies are implemented as Conditional Access policies with risk-level conditions.

IF: All users → All cloud apps → Sign-in risk = Medium and above
THEN: Require MFA

This means: if a sign-in looks risky, the user must prove their identity with an extra factor. If the sign-in is legitimate, the user completes MFA and continues. If it’s an attacker, they can’t complete MFA and are blocked.

User risk policy

IF: All users → All cloud apps → User risk = High
THEN: Require password change (which also requires MFA)

This means: if a user’s identity appears compromised (leaked credentials, anomalous activity), they must change their password. Requiring a password change automatically requires MFA first (you can’t change a password without authenticating).

Scenario: Priya configures risk policies for Meridian Health

Priya’s risk policy set for Meridian Health:

Sign-in risk policy:

Medium risk → require MFA (self-remediating: user does MFA, risk is cleared)
High risk → block access (admin must investigate)

User risk policy:

Medium risk → require MFA + password change
High risk → block access (admin must investigate and confirm remediation)

She excludes break-glass accounts from both policies. She also enables the policies in report-only mode first to check for false positives (e.g., nurses who sign in from multiple hospital locations might trigger atypical travel).

After 2 weeks of monitoring, she adjusts: the VPN IP ranges are added as trusted named locations in Conditional Access, and she tunes sign-in risk policies to reduce false positives for nurses who legitimately sign in from multiple hospital locations.

Exam tip: self-remediation vs admin remediation

Self-remediation = the risky user resolves the risk themselves:

Sign-in risk: user completes MFA → risk cleared for that sign-in
User risk: user changes password (after MFA) → user risk resets to none

Admin remediation = an admin manually resolves the risk:

Dismiss user risk (when it’s a false positive)
Confirm user compromised (escalates risk, blocks user)
Reset password manually

Self-remediation requires SSPR to be enabled for password changes. If SSPR is off, user risk can only be resolved by admins.

MFA registration policy

ID Protection includes a dedicated policy to enforce MFA registration:

Targets: All users or specific groups
Action: Requires users to register for MFA at next sign-in (up to 14-day snooze)
Purpose: Ensures users have MFA methods registered BEFORE a risk event occurs

This is separate from the authentication methods registration campaign (which nudges users toward Authenticator specifically). The MFA registration policy is a hard requirement — users must register, they can only delay it.

Investigating risky users and sign-ins

Entra admin center → Protection → Identity Protection → Risky users / Risky sign-ins

Risky users investigation workflow

Open the Risky users report
Filter by risk level (High, Medium, Low)
Select a user → view their risk detections
Check: What triggered the risk? (leaked credentials? anomalous activity?)
Correlate with sign-in logs — was there an actual compromise?
Take action:
- Confirm compromised — if real. Blocks user and requires admin reset.
- Dismiss user risk — if false positive. Clears the risk flag.
- Reset password — force a new password.
- Block user — if you need time to investigate.

Scenario: Anika investigates a risky sign-in

Anika’s client reports that ID Protection flagged a user with “High” user risk. She investigates:

Opens the Risky users report → finds the user flagged for “Leaked credentials”
Checks sign-in logs → sees two sign-ins:
- One from the user’s normal location (Auckland) at 9 AM ✅
- One from Lagos, Nigeria at 9:15 AM ❌
The Lagos sign-in used the correct password (leaked credential was valid)
The sign-in risk policy blocked the Lagos attempt (required MFA, attacker couldn’t complete)
But user risk is still High because the credentials are still compromised

Actions:

Reset the user’s password immediately (the leaked password is no longer valid)
Revoke all sessions (in case the attacker obtained a valid token before the block)
Check the user’s mailbox for suspicious inbox rules (common post-compromise tactic)
Risk level resets to “None” after password change

Key insight: The sign-in risk policy stopped the immediate attack, but the user risk policy ensures the underlying issue (leaked password) is fixed.

Risky workload identities

ID Protection also monitors workload identities (service principals and managed identities) — not just human users.

Workload identity risk detections:

Suspicious sign-in activity from a service principal
Credentials added to a service principal by a suspicious actor
Admin confirmed the workload identity as compromised
Anomalous activity patterns for the service principal

Why this matters: Attackers increasingly target service principals because they often have broad permissions, don’t use MFA, and are less monitored than user accounts.

Remediation: Investigate compromised workload identities, rotate credentials/secrets, review permissions, and monitor for continued suspicious activity. Workload identity risk requires Entra Workload ID Premium licences.

Exam tip: workload identity protection is separate licensing

Human user risk detection requires Entra ID P2. Workload identity risk detection requires Entra Workload ID Premium — a separate licence. The exam may test which licence covers which scenario. If the question mentions a service principal or app registration being flagged as risky, the answer involves Workload ID Premium.

🎬 Video walkthrough

🎬 Video coming soon

ID Protection: Risk-Based Security — SC-300 Module 14

~12 min