Microsoft SC-500: Entra ID Protection Risk Policies
Microsoft Entra ID Protection turns risk signals into access decisions. It evaluates user risk—the likelihood that an identity is compromised—and sign-in risk—the likelihood that a specific authentication attempt is unauthorized—then feeds those levels into Conditional Access. The design goal is to make access requirements adaptive instead of requiring the same control for every user and every sign-in.
Current Microsoft guidance directs organizations to configure risk-based access through Conditional Access. Microsoft’s documentation also lists October 1, 2026 as the retirement date for the legacy user-risk and sign-in-risk policies configured directly in ID Protection. New and updated designs should therefore treat Conditional Access as the current policy engine for risk response.
Risk-based access belongs inside Microsoft Identity & Security.
Separate user risk from sign-in risk
User risk represents the probability that the identity itself has been compromised.
Sign-in risk represents the probability that one authentication attempt is not legitimate.
Conditional Access can evaluate those signals independently and combine them with app, device, location, and other conditions.
Use user risk for compromised identities
ID Protection can detect leaked credentials, unusual behavior, and other signals that increase the likelihood that an account is compromised.
User-risk policies can block access, require password change, or use Microsoft Entra’s current risk-remediation controls depending on the design.
The policy should protect the identity’s ongoing access, not merely challenge one suspicious sign-in.
Use sign-in risk for suspicious authentication
Sign-in risk is evaluated in real time as the authentication request occurs.
Policies can require MFA, reauthentication, or block access when the sign-in risk reaches the configured level.
Conditional Access and MFA are strongest when the stronger control is triggered by context instead of applied blindly to every session.
Use remediation instead of permanent admin queues
Microsoft Entra supports self-remediation patterns for risk where appropriate.
A user can satisfy a required authentication control or secure password reset so the risky event is remediated without waiting for an administrator to manually clear every case.
This reduces help-desk load while preserving policy enforcement.
Migrate legacy policies into Conditional Access
Microsoft’s current documentation explicitly tells organizations to migrate the old ID Protection risk policies to Conditional Access.
The newer model provides report-only mode, Graph API management, richer condition combinations, clearer diagnostics, and modern risk-remediation controls.
Keep the migration visible in change records so duplicated old and new policies do not create confusing access behavior.
Pair risk with authentication strength
Not every risky sign-in should be satisfied by the weakest available MFA method.
Authentication strengths can require a stronger method for privileged applications or high-consequence access.
The policy design should distinguish ordinary user productivity from administrative or sensitive-resource access.
Use sign-in logs for policy diagnosis
Risk-based policy is only useful if support and security teams can explain why access was blocked or challenged.
Sign-in logs should be reviewed alongside risk detections, Conditional Access results, authentication method, and user context.
This helps distinguish a real compromise signal from a device, location, or policy configuration problem.
Connect identity risk to incidents
Risk signals become more valuable when they are correlated with endpoint, email, SaaS, and cloud activity.
Identity incidents change when Entra and Defender data converge because analysts can see whether a risky user also touched suspicious devices or resources.
Do not isolate ID Protection as an identity-admin dashboard when the same account appears inside a broader attack.
Keep risk policy proportional
Very aggressive thresholds can create user friction; very loose thresholds can allow compromised access to continue.
For administrators working around SC-300, the durable model is to understand user risk and sign-in risk separately, enforce them through Conditional Access, use self-remediation where safe, investigate through sign-in evidence, and connect high-risk identities to the wider Microsoft security incident picture.
Risk thresholds should be chosen with the organization’s tolerance for false positives and missed compromise in mind. A policy targeting medium and high risk can protect broadly, while a high-risk-only policy may reduce friction but allow more suspicious sessions to proceed. Start with report-only evaluation and examine who would have been challenged before enforcing across the whole tenant.
User-risk remediation is stronger when password and passwordless scenarios are both considered. Microsoft’s current “require risk remediation” control is designed to support adaptive remediation across authentication methods, while older “require password change” behavior is tied more directly to password-based recovery. Organizations moving toward passkeys and phishing-resistant methods should verify that the remediation control matches their authentication strategy.
Sign-in risk can be combined with device and location conditions. A medium-risk sign-in from an unmanaged device to a sensitive app may justify stronger action than the same risk level from a known compliant workstation. Conditional Access allows these signals to work together instead of forcing risk to act as a standalone switch.
Risk policy should include exclusions for emergency access accounts where Microsoft’s guidance recommends preserving recovery, but those accounts require their own monitoring and protective controls. Exclusion should not mean “trusted forever”; it means the account follows a separate emergency-access architecture.
Guests and external users need testing because their authentication happens across tenant boundaries. Cross-tenant trust, MFA claims, Conditional Access, and risk signals can combine in ways that differ from internal employees. Pilot with real partner accounts rather than assuming the internal-user experience generalizes.
Security operations teams should understand risk-detection timing. Some detections are calculated in real time while others appear after additional analysis. A user might become risky after a sign-in has already completed, which is why user-risk remediation and ongoing incident correlation matter in addition to one sign-in decision.
Risk dismissal should be controlled. Administrators can make incorrect risk decisions that suppress future attention to an account. Keep roles narrow, require investigation evidence before dismissing risk, and use the incident record to document why a detection was considered benign.
Organizations migrating from legacy ID Protection policies should compare policy targets, risk levels, exclusions, controls, and report-only results before removing the old configuration. The migration should preserve intent while taking advantage of Conditional Access diagnostics and current remediation capabilities.
Identity Protection is most effective when it reduces time between suspicious behavior and stronger access requirements. The mature operating model tunes thresholds from evidence, keeps authentication methods ready for remediation, investigates repeated risk, and uses Conditional Access as the orchestration layer that connects risk to the rest of the access context.
Risk policy should be monitored for repeated remediation loops. If the same users trigger medium or high risk frequently, the issue may be compromised devices, weak authentication methods, risky network patterns, or unresolved credential exposure rather than a policy that is “too strict.” Investigate the recurring source before lowering thresholds.
Policy scope should include service and break-glass exclusions deliberately. Workload identities generally follow different controls from human user risk, while emergency accounts should have a separate recovery design. Avoid broad exclusions such as “all admins” merely to reduce support friction.
Security teams should review risk detections alongside user behavior and incident context before dismissing them. A risky sign-in followed by new app consent, mailbox rule creation, or privileged access can turn an ambiguous identity signal into a strong incident hypothesis.
The mature risk-policy program therefore treats risk as one input to adaptive access. It combines current Conditional Access policy, strong authentication readiness, investigation, self-remediation, external-user testing, and incident correlation rather than relying on one legacy ID Protection switch.
Risk policies should also be aligned with help-desk and SOC handoff. A user who cannot self-remediate needs a clear support route, while a high-risk identity tied to an active incident should move quickly into investigation rather than ordinary password-reset support.
Review risk-policy outcomes after major authentication changes such as passkey rollout, device-enrollment changes, or cross-tenant policy updates. The signals and remediation experience can behave differently as the identity environment evolves.
Risk policy documentation should name the targeted users, applications, risk levels, grant controls, exclusions, and remediation path. During an incident, support teams need to know why the policy exists and what outcome it is supposed to enforce rather than infer intent from a complex Conditional Access expression.
Use pilot and report-only evidence to tune policy before broad deployment, then keep a regular review after enforcement. Threat patterns, authentication methods, and workforce behavior change, so risk thresholds and remediation assumptions should not remain frozen indefinitely.
Keep risk-policy ownership explicit so identity, help-desk, and security-operations teams know who tunes thresholds, who investigates detections, and who approves exceptions.
Review exclusions regularly.
Keep remediation paths tested and documented.
Review policy drift.