Microsoft-managed Conditional Access policies
Entra · Official Microsoft guidance
Observed content change
May need admin actionCheck whether a default changed for your tenant or devices; check the roles and permissions you grant; check your licensing.
This policy requires users identified as high risk by Microsoft Entra ID Protection to remediate their risk before continuing to access organizational resources. A new security group [added: named “Conditional Access: User Risk remediation”] is created alongside this policy to scope the affected users. [added: Microsoft populates this group with eligible active users registered for MFA, up to the tenant’s available Microsoft Entra ID P2 license count.] Instead of blocking access entirely, this policy uses adaptive risk remediation to guide users through the appropriate recovery flow based on their authentication method and the type of threat detected. For more information about the remediation experience, see User self-remediation …
[added: Organizations that don't already have an enabled customer-managed Conditional Access policy targeting user risk. Microsoft skips tenants that already have an enabled customer-managed Conditional Access policy targeting user risk. Existing user risk policies in Report-only or Off state don't prevent this Microsoft-managed policy from being created. This check is specific to user risk policies, not all Conditional Access policies.]
[added: Administrators can review policy impact in report-only mode, exclude emergency access accounts, and turn the policy On before the scheduled enforcement date. If the policy remains in Report-only, Microsoft automatically enables it according to the schedule communicated to your tenant.]
Source: Microsoft source · © Microsoft · MIT.
Read the current Microsoft source · Link to this observation · Compare any two versions
Observation details
- Observed by ChangeIntel
- 4 Nov 09:01 UTC
- Source update metadata
- 4 Nov 08:39 UTC
- Microsoft's latest commit in that period
- Update user risk remediation policy details · committed 4 Nov 00:03 UTC · View diff
- First observed on this installation
- 5 Oct 17:50 UTC
- Last successful check
- today 17:20 UTC
- Next check due
- today 23:20 UTC
Observed time is not publication or effective time.