The replacement risk policy does not cover guests (and the old one never did)

On 1 October the deadline Microsoft had been announcing for a year fell due for the legacy Entra ID Protection risk policies. There was no outage, no email, no red icon in any console — there was none on 31 July 2025 either, when those two screens went read-only and you quietly stopped being able to touch them. What interests us about the date is not the drama but what you find when you rebuild those policies in Conditional Access: the control Microsoft recommends states in writing that it is not supported for external and guest users. It is the line we did not find in any of the migration guides we read.

The destination control does not do what the source one did. It leaves one specific account type out, and with that account type the full story is odder than anyone tells it. And to know whether it is working you have to go down into the sign-in log, where the field that would tell you is named in a misleading way. What follows comes, almost entirely, from reading back to back a handful of Microsoft documentation pages that are normally read apart.

What retired, with the quote up front

Microsoft writes it in a warning box on both pages that touch the subject, with the same date and two different wordings: "The legacy risk policies configured in Microsoft Entra ID Protection are retiring on October 1, 2026" on the concept page, and "…will be retired on October 1, 2026" on the how-to. There are two policies: user risk and sign-in risk, the ones configured from ID Protection —formerly Identity Protection— rather than the ones you know today as conditions inside Conditional Access. Those are still there; in fact they are the destination.

What the documentation does not say is what happens to the object the day after. And there is a difference here worth looking at slowly, because almost all the coverage skips it: the guides going around state that the policies stop being enforced, whereas Microsoft's original announcement, back in June 2025, spoke of retiring the user interface for those two policies. Switching off a protection and removing the screen it was configured from are not the same thing. We have not found a Microsoft sentence saying they stop being evaluated, so we are not going to write one.

If what happens is what the whole industry assumes —that they stop being enforced— the failure mode is one we already know from other retirements in this same product: a retired policy does not return an error. No failed sign-in, no alert, no ticket; just a user flagged as high risk signing in like any other day. It is the mechanism we described when Entra retired dynamic membership by memberOf: what retires does not fall over, it goes still. And if what happens is the other thing —the screen goes and the rule lives on— that is no better, because then you have a protection in force that nobody can read or correct any more.

Migrating is not moving, and the order matters

The procedure Microsoft publishes has two mandatory steps and one optional, and the order of the first two is not decorative. One: create the equivalent user-risk and sign-in-risk policies in Conditional Access in report-only mode and, once the behaviour is confirmed, flip the toggle from "Report-only" to "On". Two: only then go into ID Protection and set the old policy to "Disabled". The third, which Microsoft marks as optional, is creating other risk policies if you need them. Invert the first two —switch off, then build— and you leave the window uncovered on precisely the days you are touching identity.

There is a sign that this is not automatic, and it is not our opinion: on the same page, below the procedure, Microsoft publishes a detailed script for opening a support case dedicated to this migration, with the literal summary "Migrate legacy ID Protection policy" and the exact menu path to the team that handles it. A vendor does not document a support route for something that moves on its own.

And one detail many people skip while rebuilding: Microsoft warns that you should not combine the sign-in risk condition and the user risk condition in the same Conditional Access policy. They are two separate policies. If you came from two policies in ID Protection and were tempted to merge them into one tidier "risk policy", the vendor is telling you not to.

The recommended control is not the one you had

Here is the first jump the word "migrate" hides. For high user risk, what Microsoft recommends today is not "require password change" but a different control: "Require risk remediation". And selecting it automatically applies two more settings: "Require authentication strength" is selected as a grant control, and "Sign-in frequency – Every time" is applied as a session control, which the documentation marks as mandatory. They are not optional and you did not choose them: they come with the control.

Better does not mean identical. Authentication strength is a control with its own opinion about which methods count —we wrote about it when explaining why a third-party MFA may not count as MFA for Entra— and "every time" reauthentication is a change users feel. If you get here on Monday migrating in a hurry and on Tuesday you start getting calls from people being asked to identify themselves over and over, it is not a fault: it is the control you were recommended, doing what it says on the tin.

There are also precedence rules that matter precisely during the overlap window: "Require risk remediation" overrides "Require password change", and "Block" overrides all of them; and Microsoft asks that each user be assigned to only one of those policies at a time to avoid conflicts. During the migration you will deliberately have the old and the new alive at once. That is correct, but it is worth knowing which one wins while it lasts.

The part on nobody's checklist: guests

The sentence sits in the control's documentation, in the special-considerations section, and it is so short it gets skipped: "Require risk remediation is not supported for external and guest users because Microsoft Entra ID doesn't support session revocation for those users". Not supported for external and guest users, because Entra cannot revoke sessions for those accounts.

The reason is sound, which is why it will not change: a guest's credential and session live in their home tenant, not yours. You grant access to a resource; you do not own their identity. What is yours is the consequence: in a small company working with suppliers, consultants, an external auditor or a customer inside a shared Teams, guest accounts are precisely the ones whose credential hygiene you do not control. You cannot see their MFA, you do not manage their password, you do not know whether their laptop has EDR.

It is worth being precise, because it is easy to overshoot in the opposite direction and sell a regression that does not exist. The old policy did not remediate guests either. Microsoft documents this on a separate page, the one on ID Protection for B2B users: "If a guest user triggers the ID Protection user risk policy to force password reset, they will be blocked", because passwords cannot be reset in the resource directory; "Guest users do not appear in the risky users report", because risk is evaluated in their home directory; and an administrator in the inviting tenant "cannot dismiss or remediate a risky B2B collaboration user". Translated: with the legacy policy, you blocked the risky supplier with no way of unblocking them yourself, and without seeing them in any report.

What you never had, and is now written down where it belongs, is automated user-risk remediation for those accounts. The capability is the same as it always was; what has improved is the vendor's candour. Before, it blocked your supplier and said so on a page you had to go looking for on purpose; now the new control declares it in its special considerations, in plain sight of whoever writes the policy.

So what do you do with guests? Here Microsoft's answer is the opposite of what we expected when we started reading, and it is the part that forced the most corrections to the draft of this post. Its Zero Trust guidance for guest access says, literally: "we recommend that you exclude guests from risk-based MFA policies and require these users to always use MFA". And the Conditional Access guidance for B2B users spells out the how: create a group containing all your organisation's external users and add it as an exclusion on your risk-based policies, both user risk and sign-in risk. In other words: for guests you do not condition MFA on risk, you require it always.

With two traps worth knowing before you touch anything, because both end in the same place —the supplier phoning you because they cannot get in. The first: the sign-in risk policy does get evaluated for a guest, but "if a user hasn't previously registered for Microsoft Entra multifactor authentication in the resource tenant, the user is blocked", and that is deliberate, so an attacker holding a stolen password cannot register their own second factor in your house. The second is subtler and almost everyone misses it: "you can only apply authentication strength policies to external users who authenticate with Microsoft Entra ID"; for guests using email one-time passcode, SAML/WS-Fed or Google federation you have to use the plain MFA grant control. The email-code guest is the most common kind in a small company, and is exactly the one left outside authentication strength.

The rest of the work with guests is not a checkbox. It is scope —what they can reach and from when—, expiry —dated access reviews, not forever— and the written decision about what you demand of anyone coming in from outside. We say that knowing it is the part that gets postponed the most: in the tenants we run, the guest roll is almost always the oldest inventory in the house.

The hybrid user who cannot self-remediate

The next warning is not on that page but on the other one: the how-to, right where you do the migration. It sets two prerequisites: users must have registered for MFA before they find themselves in a situation requiring remediation, and for hybrid users synced from an on-premises directory, password writeback must be enabled. For the first one Microsoft also writes the outcome: "Users not registered are blocked and require administrator intervention". And one more line worth its weight: a password change made outside the remediation flow —the user who goes into their profile and changes it on their own— does not meet the secure-password-change requirement.

Put that next to the typical estate of a company with some years on it: an on-premises directory synced to Entra, people who registered MFA three years ago and people who kept dodging it, and a password writeback someone configured once and nobody has looked at since. A user gets flagged high risk on a Monday morning. If they had no MFA registered, the documentation says plainly how it ends: blocked, and an administrator is needed. What happens to the hybrid user missing password writeback we have not found written anywhere, so we say it as what it is —our own inference, and the kind worth testing in your own tenant before trusting it—: without writeback there is no secure password change against the on-premises directory, and without a secure change there is no self-remediation. Test it yourself; we cannot assert it.

How to prove it is migrated (looking at the screen is not enough)

A policy switched on in a screen does not prove it is doing anything. The proof lives in the sign-in log, and it has a documented trap worth knowing before you call the job done. Three readings:

• Your policy showing up does not mean it was applied. The log section is called appliedConditionalAccessPolicies, and Microsoft's own documentation spells it out: "the section is called applied Conditional Access policies; however, policies that were not applied also appear in this section". There is one entry per policy. What tells you something is the result on your policy's entry, not its presence. If it is still in report-only, it is documenting what it would have done; it is not doing it.
• Check there is risk to read. The riskLevelAggregated field returns the value hidden when the user or sign-in was not enabled for ID Protection. A hidden on somebody you believe is covered means your risk policy has nothing to read from. This is where licensing shows up: risk-based policies require Microsoft Entra ID P2 (or Entra Suite for full ID Protection access). Without it, the policy exists and evaluates nothing.
• Do it with two accounts, not with yours. A member and a guest. It is the only way to see the gap from the previous section with your own eyes rather than taking somebody's word for it —ours included. And review the exclusions the documentation itself recommends and that have to be rebuilt in the new policy: emergency access (break-glass) accounts and service accounts. With one caveat that surprises a lot of people and is written down: calls made by service principals are not blocked by a Conditional Access policy scoped to users; that is what workload identity policies are for.

The exceptions your policy engine already has

Reading the same page, something turns up that deserves its own section. During risk remediation, Entra uses a dedicated, secure flow for actions such as session revocation, and the documentation says that flow "is allowed to proceed without being impacted by other Conditional Access policies". It even publishes the identifiers: AppId 93625bc8-bfe2-437a-97e0-3d0060024faa in the public cloud and ResourceId 00000003-0000-0000-c000-000000000000.

It is not a hole and we are not going to sell it as one. It is the way out of a deadlock: if the policy blocks the risky user, the user cannot remediate their risk, and then the thing protecting you leaves the account unusable until somebody rescues it by hand. The exception exists because without it the system bites its own tail.

The honest reading for anyone building Zero Trust is this: "everything goes through the policy" is false in any real policy engine, yours included. What distinguishes a mature deployment is not the absence of exceptions; it is having the list written down, with its identifier, its reason and whoever signed it off. The one above ships with all three, which is why it is a good example. The ones you wire up on a Friday to unblock somebody usually ship with none —and we already wrote about that when we covered the Conditional Access policies that appear in your tenant without you writing them.

What we are not saying

We are not saying the retirement is bad. It is better, and the page itself lists why: managing access policies in one place, report-only mode, Graph APIs, the ability to enforce reauthentication, combining risk with other conditions such as location, multiple risk policies targeting different groups and levels, better sign-in log diagnostics about which risk policy applied, and support for the backup authentication system. Those are real advantages and we want them.

Nor are we saying Microsoft hid it. The warning is in a box, with the date, on both pages that touch the subject; we quoted it verbatim above. What grates is the verb. "Migrate" suggests moving something from one place to another with its properties intact, and what you actually have to do here is rebuild it, verify it and accept that the result is not identical. With one part —guests— that has no equivalent and must be covered another way.

And the caveat against our own interest, which is the least popular one: if you never had those policies switched on, absolutely nothing happened to you on 1 October. Nothing happened in July 2025 either, when you stopped being able to create them. That is not good news: it means you have gone years without an automated response to identity risk, and Microsoft's calendar has nothing to do with it. If on top of that you do not have P2, this whole article does not apply to you; the first step then is not a policy but a licensing decision, and there are cheaper, higher-return things to do first —starting with phishing-resistant MFA for whoever administers. Conflict of interest up front: we sell exactly this work, so read the above with that suspicion in place.

Sources (verified on 3 October 2026): the retirement date with its wording, the user-risk and sign-in-risk policy controls, the behaviour of "Require risk remediation" by authentication method, the precedence rules, the lack of support for external and guest users, and the exempt flow with its AppId and ResourceId all come from Microsoft Entra ID Protection risk-based access policies (Microsoft Learn). The migration steps, the support-case script, the warning against combining risk conditions in one policy, the risk-level recommendations, the two settings that apply themselves, the prior MFA registration and password writeback requirements, the note about password changes outside the flow, the recommended exclusions, the sentence about service principals and the P2 or Entra Suite licence requirement come from Risk policies (Microsoft Learn). The three guest limitations —blocked when forced to reset a password, absent from the risky users report, and impossible to dismiss or remediate from the resource tenant— come from Microsoft Entra ID Protection for B2B users. The block on guests without MFA registered in the resource tenant, the limit of authentication strength to external users authenticating with Entra ID, and the procedure for excluding external users from risk-based policies come from Authentication and Conditional Access for B2B users. The verbatim recommendation to exclude guests from risk-based MFA and require MFA always comes from the Zero Trust guidance for guest and external user access. The caveat about appliedConditionalAccessPolicies and the hidden value of riskLevelAggregated comes from Learn about the monitoring and health activity log schemas. With one declared caveat: the 31 July 2025 move to read-only and the wording that what retires is the user interface come from the What's new in Microsoft Entra – June 2025 announcement, whose body we could not open; we take them from coverage of that announcement and present them as such, not as a quote we read in the original. What is ours, and not those sources': that "migrate" describes a rebuilding job badly, the distinction between retiring the interface and the policy ceasing to apply, what the guest gap means for a company working with suppliers, the inference about the hybrid user without password writeback —declared as an inference—, the two-account verification procedure and the Zero Trust reading of the documented exception.