On October 14, 2026, Microsoft published MC1507808 in the Microsoft 365 Message Center: “Reminder: Microsoft-managed CA policy will be enforced soon – Require risk remediation for high-risk users”. Microsoft has already created a Conditional Access policy and a matching security group in your tenant. The policy has been running in Report-only for 30 days, and if you do nothing, it switches to On the week of October 28, 2026.

That is less than two weeks away. And it lands only four weeks after the legacy user risk and sign-in risk policies in Entra ID Protection were retired on October 1, 2026, so a lot of tenants are going into this with no user risk policy in force at all, without anyone having noticed.

The questions are always the same when Microsoft switches something on in a tenant: What exactly happens, and to whom? Will someone be locked out? Should we let it happen or take control ourselves? This post is the practical version: what the policy actually does, what your users will experience (with examples), how to find out who is affected, and the steps to take before October 28.

Everything below is based on the Message Center post and Microsoft Learn documentation as of October 15, 2026.

MC1507808 at a glance

Message Center ID	MC1507808, published October 14, 2026
Policy name	“Require risk remediation for high-risk users” in MC1507808, listed as “Require remediation for high-risk users” on Microsoft Learn. Check the exact name in your tenant
Current state	Report-only, 30-day evaluation period ending
Enforcement	Week of October 28, 2026. Automatically set to On unless you set it to On or Off yourself
Who is in scope	Tenants with Microsoft Entra ID P2 (included in Microsoft 365 E5 and EMS E5)
Condition	User risk = High (Entra ID Protection)
Grant control	Require risk remediation (adaptive risk remediation)
Scope	A new security group created by Microsoft together with the policy
Not covered	Sign-in risk. Guests and external users are not supported by the control. Your existing CA policies and exclusions are not changed

Why Microsoft is doing this

User risk is Entra ID Protection’s estimate of how likely it is that an account is compromised: leaked credentials found on the dark web, password spray hits, anomalous tokens, threat intelligence matches. A high user risk without a policy attached to it is just a line in a report that nobody reads until after the incident.

For years, the standard answer was a user risk policy with Require password change. That has two problems in 2026:

1. The legacy risk policies configured inside ID Protection are retired as of October 1, 2026. If you never migrated them to Conditional Access, don’t count on them protecting you anymore.
2. Require password change does nothing useful for a user who signs in with a passkey or Windows Hello for Business. There is no password to change, and the risk often isn’t about a password in the first place.

The Microsoft-managed policy closes both gaps: it puts a user risk policy into every eligible tenant, and it uses the newer Require risk remediation control, which works for password and passwordless users alike.

The timeline: dates you need in your calendar

Date	What happens
October 1, 2026	Legacy user risk and sign-in risk policies in ID Protection are retired
Start of the 30-day evaluation	Microsoft creates the policy + security group in Report-only (check the creation date in your own tenant, see Step 1)
October 14, 2026	MC1507808 reminder published
Week of October 28, 2026	Policy switches to On if still in Report-only

What actually changes in your tenant

When the policy is On, a user in the scoping group who reaches high user risk is interrupted at sign-in and has to remediate. What “remediate” means depends on how the user signs in and on the threat observed. That is the “adaptive” part:

Scenario	What ID Protection does
Password user with an active risk detection such as leaked credentials, password spray or session history involving a compromised password	User does MFA, then a secure password change. Previous sessions are revoked.
Passwordless user with an active risk detection that doesn’t involve a compromised password, such as anomalous token, impossible travel or unfamiliar sign-in properties	User’s sessions are revoked and the user must sign in again. Risk is remediated after the successful sign-in.
Attacker-added device (flagged by Microsoft threat intelligence)	The Entra device object is disabled, sessions are revoked, and the user must sign in again.

Note for password users: Microsoft documents that token theft related detections (anomalous token, attacker in the middle, verified threat actor IP and similar) require a secure password change plus MFA to clear the risk. Don’t expect a password user to get away with “just sign in again”.

Two controls are added to the policy automatically: Require authentication strength and Sign-in frequency – Every time. That is what forces a strong reauthentication right after the session revocation.

What it does not do:

• It remediates user risk, not sign-in risk. Sign-in risk is covered by a different managed policy (Multifactor authentication and reauthentication for risky sign-ins) or your own.
• Require risk remediation is not supported for guests and external users, because Entra ID can’t revoke their sessions. Check that the Microsoft-created group contains no guests.
• It does not change your existing Conditional Access policies or their exclusions.

Examples: what your users will actually experience

Tables are nice, but helpdesk tickets come from people. Here is how this plays out for five typical accounts once the policy is On.

Example 1: Anna, password user, leaked credentials
Anna’s username and password show up in a credential dump. ID Protection raises her user risk to High. Next time she opens Outlook, she gets an MFA prompt, then a “Password change is required” screen. She sets a new password, her old sessions on her phone and laptop are revoked, and she signs in again. Risk state: Remediated. No ticket, if Anna is registered for MFA.

Example 2: Peter, passkey user, anomalous token
Peter signs in with a passkey and never uses a password. ID Protection detects an anomalous token for his account. The old Require password change control would have been pointless here. With Require risk remediation, Peter’s sessions are revoked and he is asked to sign in again with a method that meets the authentication strength. He might say “I had to sign in twice”. That is by design: if an at-risk user has just signed in, they are prompted again, and the risk is remediated after the second sign-in.

Example 3: Maria, high risk, no MFA registered
Maria is in the scoping group, but has never registered an MFA method. She can’t do MFA, so she can’t do a secure password change. Result: Maria is blocked, and only an admin can get her back in. This is the scenario that creates Monday morning tickets, and it is the main reason to do Step 2 below.

Example 4: svc-scan, a service account that signs in interactively
A scanner account with a password in a config file gets flagged as high risk. It can’t do MFA or change its own password. Result: blocked, and the scan-to-mail workflow stops. Exclude it now, and put it on the list of accounts that need a proper fix.

Example 5: Jonas, MSP technician from another tenant
Jonas works in your tenant as a guest, and Require risk remediation is not supported for guests. But Microsoft documents the “high risk technician” scenario: if Jonas’s credentials leak and he becomes high risk in his home tenant, he is blocked from signing in to other tenants, and he can only self-remediate if his home tenant has the right risk policies. Otherwise an admin in his home tenant has to remediate. If you are the MSP, make sure your own tenant has self-remediation policies, or your technicians get blocked everywhere they work.

Step 1: Find the policy and check its state

In the portal:

1. Sign in to the Microsoft Entra admin center as at least Conditional Access Administrator.
2. Browse to Entra ID > Conditional Access > Policies.
3. Look for the policy with remediation for high-risk users in the name. The Created by column says Microsoft, and the name starts with Microsoft-managed:. (MC1507808 calls it “Require risk remediation for high-risk users”, Microsoft Learn calls it “Require remediation for high-risk users”, so search for “remediation”.)

Or with Microsoft Graph PowerShell, which also shows you every other Microsoft-managed policy in the tenant:

Connect-MgGraph -Scopes "Policy.Read.All"

Get-MgIdentityConditionalAccessPolicy -All |
    Where-Object { $_.DisplayName -like "Microsoft-managed*" } |
    Select-Object DisplayName, State, CreatedDateTime |
    Sort-Object DisplayName |
    Format-Table -AutoSize

enabledForReportingButNotEnforced means Report-only. enabled means On, disabled means Off.

If the policy isn’t there, your tenant isn’t in scope (yet). Community trackers report that this reminder has so far only been seen in education tenants, which may be licensing or a staged rollout. Check again next week rather than assuming you are skipped.

Step 2: Find out who is actually affected

Option A: The Policy impact tab

Open the policy and select Policy impact. This shows what the policy would have done during the Report-only period, even though it hasn’t enforced anything. It is the fastest way to answer “would this have hit anyone last month?”.

Option B: The Risky users report

Browse to ID Protection > Risky users and filter on Risk level: High and Risk state: At risk. These are the people who will be interrupted the moment the policy turns on.

Option C: Microsoft Graph PowerShell, if you want the full picture

This script lists the high-risk users and checks whether they are registered for MFA, which is exactly the difference between Example 1 (self-remediates) and Example 3 (blocked):

Connect-MgGraph -Scopes "IdentityRiskyUser.Read.All", "AuditLog.Read.All"

# Users that are high risk right now
$highRisk = Get-MgRiskyUser -All -Filter "riskLevel eq 'high' and riskState eq 'atRisk'"

# MFA registration status for each of them
$result = foreach ($u in $highRisk) {
    $reg = Get-MgReportAuthenticationMethodUserRegistrationDetail -UserRegistrationDetailsId $u.Id -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        UserPrincipalName = $u.UserPrincipalName
        RiskLastUpdated   = $u.RiskLastUpdatedDateTime
        MfaRegistered     = $reg.IsMfaRegistered
        Methods           = ($reg.MethodsRegistered -join ", ")
    }
}

$result | Sort-Object MfaRegistered | Format-Table -AutoSize

Anyone with MfaRegistered = False on that list will be blocked, not remediated. Either get them registered this week, or remediate their risk manually now (see Step 6).

Also look at the members of the security group Microsoft created for the policy. Group membership is what defines the scope, and you are allowed to change it.

Step 3: Check your exclusions

Microsoft states that your existing exclusions are preserved. That is about your existing policies. Open this policy, go to Excluded identities, and verify:

• Break-glass / emergency access accounts are excluded. Don’t assume, look.
• Service accounts and shared accounts that sign in interactively are excluded (Example 4), and added to your list of accounts to replace with managed identities or workload identities.

Connect-MgGraph -Scopes "Policy.Read.All", "User.ReadBasic.All", "GroupMember.Read.All"

$p = Get-MgIdentityConditionalAccessPolicy -All |
    Where-Object { $_.DisplayName -like "Microsoft-managed*remediation*" }

$p.Conditions.Users.IncludeGroups |
    ForEach-Object { (Get-MgGroup -GroupId $_).DisplayName }

$p.Conditions.Users.ExcludeUsers |
    ForEach-Object { (Get-MgUser -UserId $_).UserPrincipalName }

$p.Conditions.Users.ExcludeGroups |
    ForEach-Object { (Get-MgGroup -GroupId $_).DisplayName }

Step 4: Check for conflicting risk policies

If a user is targeted by more than one user risk policy, precedence applies:

• Block overrides everything.
• Require risk remediation overrides Require password change.

So if Microsoft-managed: Block access for high-risk users (or your own block policy) is On for the same users, the block wins and the self-remediation never happens. Microsoft recommends assigning each user to only one of these policies. List every policy that uses user risk:

The Prefer header matters: riskRemediation is a newer enum value, and without the header Graph returns it as unknownFutureValue.

Get-MgIdentityConditionalAccessPolicy -All -Headers @{ Prefer = "include-unknown-enum-members" } |
    Where-Object { $_.Conditions.UserRiskLevels } |
    Select-Object DisplayName, State,
        @{n = "UserRisk"; e = { $_.Conditions.UserRiskLevels -join "," }},
        @{n = "Grant";    e = { $_.GrantControls.BuiltInControls -join "," }} |
    Format-Table -AutoSize

If you already have your own user risk policy with Require password change, this is a good moment to move it to Require risk remediation, especially if you have passwordless users (Example 2).

Step 5: Decide: let it turn on, own it, or turn it off

Option 1: Let it turn on

Fine if you have no user risk policy today and the result of Step 2 is clean. Even then, I would switch it to On yourself, on a day you choose, after telling the helpdesk. That way the change happens on your schedule, not in “the week of October 28”.

Option 2: Duplicate it and own it (my recommendation for most)

If you have a Conditional Access framework with naming standards and persona groups, a Microsoft-named policy scoped to a Microsoft-created group doesn’t belong in it. Use Duplicate, rename the copy to your standard, scope it to your own groups, keep Require risk remediation as the grant control, put it through your change process, and then set the Microsoft-managed original to Off.

You keep the protection, and the policy follows your rules. Microsoft-managed policies can’t be renamed or deleted, so Off is the end state for the original.

Option 3: Set it to Off

Only if you already have an equivalent or stronger user risk policy covering the same users. Document why, and what covers the risk instead. “It was new, so we turned it off” is not a security decision.

Step 6: Clean up current risk and tell the helpdesk

Before enforcement, deal with the users from Step 2 that are high risk today. In ID Protection > Risky users, per user:

• Reset password (temporary password) if the risk is real and the user can’t self-remediate.
• Confirm user compromised if your investigation says so, then revoke sessions and disable any suspicious devices.
• Dismiss user risk if it is a false positive. Note that dismissing doesn’t change the password, so still talk to the user.

Then give the helpdesk three sentences:

1. A high-risk user will be asked to change their password, or simply to sign in again, sometimes twice. That is expected.
2. A user who can’t do MFA will be blocked and needs an admin to remediate the risk in ID Protection.
3. Guests and external users are not supported by this control, so a guest with a risk problem is handled in their home tenant.

Hybrid identities: what to check

For synced users, Microsoft’s documentation notes that eligible hybrid tenants have password hash sync enabled, so users can self-remediate with a secure password change after MFA. Verify that:

• Password hash sync is actually running.
• Password writeback is enabled. Microsoft’s risk policy guidance requires it for hybrid users, so a password changed in the cloud lands on-premises too.
• If users change passwords on-premises (Ctrl-Alt-Delete), consider ID Protection > Settings > Allow on-premises password change to reset user risk. It is opt-in and requires password hash sync.

After enforcement: monitoring

Sign-in logs. In the sign-in log, open a sign-in and select the Conditional Access tab to see whether the policy applied. If you send sign-in logs to Log Analytics or Sentinel, this gives you the trend:

SigninLogs
| where TimeGenerated > ago(30d)
| mv-expand CAP = ConditionalAccessPolicies
| where tostring(CAP.displayName) has "remediation for high-risk"
| summarize Count = count() by Result = tostring(CAP.result), bin(TimeGenerated, 1d)
| order by TimeGenerated asc

During Report-only, look for reportOnlyInterrupted and reportOnlyFailure. After enforcement, failure means someone was stopped.

The remediation flow AppId. During remediation, Entra ID uses a dedicated flow for session revocation that is allowed through regardless of other Conditional Access policies (AppId 93625bc8-bfe2-437a-97e0-3d0060024faa in the public cloud). If you see it in the logs and wonder why your block policy didn’t catch it: that is why. Don’t try to block it.

Changes Microsoft makes to the policy. Microsoft can update managed policies, for example by adding newly eligible users. Those changes are logged with Microsoft Managed Policy Manager as the initiator:

https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?$filter=initiatedBy/app/displayName eq 'Microsoft Managed Policy Manager' and category eq 'Policy'

MC1507808 checklist

• ☐ Policy found and current state noted (Step 1)
• ☐ Policy impact reviewed (Step 2, Option A)
• ☐ High-risk users listed and MFA registration checked (Step 2, Option C)
• ☐ Members of the Microsoft-created security group reviewed
• ☐ Break-glass accounts excluded and verified (Step 3)
• ☐ Interactive service accounts excluded and listed for replacement
• ☐ No conflicting Block policy on the same users (Step 4)
• ☐ Decision made: On / Duplicate and own / Off (Step 5)
• ☐ Current high-risk users remediated or dismissed (Step 6)
• ☐ Helpdesk informed
• ☐ Hybrid: password hash sync + writeback verified

Quick answers to the questions everyone asks

Will users be locked out?
Only users who can’t complete MFA, and accounts that can’t do interactive sign-in. Everyone else self-remediates. That is why the MFA check in Step 2 matters more than anything else in this post.

Does it affect guests?
Require risk remediation is not supported for external and guest users, because Entra ID can’t revoke their sessions. Make sure the Microsoft-created group contains no guests.

Does it change my existing Conditional Access policies?
No. Microsoft states that existing CA settings and exclusions, including break-glass exclusions, are not changed.

Can I delete or rename the policy?
No. You can change the state and the exclusions. Use Duplicate if you need more control.

We already have a user risk policy with Require password change. Do we need this?
Not necessarily, but compare: Require risk remediation handles passwordless users and attacker-added devices; Require password change doesn’t. And watch precedence: if both apply to the same user, Require risk remediation wins.

What about sign-in risk?
Not covered by this policy. Use Multifactor authentication and reauthentication for risky sign-ins or your own sign-in risk policy.

We don’t see the policy. Are we safe?
You are not in scope yet. Check your licensing (Entra ID P2, for example through Microsoft 365 E5 or EMS E5) and check again. And if you had legacy ID Protection risk policies, remember they were retired on October 1, 2026, so the gap may already be there.

My recommended plan, condensed

• Today: Find the policy (Step 1). Run the high-risk + MFA script (Step 2). Verify break-glass exclusions (Step 3).
• This week: Check for conflicting block policies (Step 4). Clean up the users that are high risk today (Step 6). Decide: On, Duplicate and own, or Off.
• Before October 28: Brief the helpdesk. If you are letting it turn on, switch it to On yourself on a day you choose.
• After: Watch the sign-in logs for a couple of weeks and keep an eye on the audit log for changes made by Microsoft Managed Policy Manager.

References

• MC1507808 – Reminder: Microsoft-managed CA policy will be enforced soon (mc.merill.net)
• Microsoft Learn – Microsoft-managed Conditional Access policies
• Microsoft Learn – Microsoft Entra ID Protection risk-based access policies
• Microsoft Learn – User self-remediation with Microsoft Entra ID Protection
• Microsoft Learn – Remediate risks and unblock users
• Microsoft Learn – Configure risk policies

Wrapping up

MC1507808 is a good change. Adaptive risk remediation is the right control for a world where more and more users never type a password, and tenants that never migrated their legacy ID Protection policies may have lost their user risk coverage on October 1 without noticing.

But “Microsoft turns on a policy in your tenant” should never happen without someone having looked at it first. Spend an hour before October 28: find the policy, check who is high risk and whether they can do MFA, verify your exclusions, and then make the decision yourself instead of letting the calendar make it for you.

If you want help reviewing your Conditional Access and ID Protection setup, from a quick check of this one policy to a full CA framework, you know where to find me.