Entra Risk Policies Retire Oct 1, 2026: What Banks Must Do

Somewhere in your tenant there is a policy nobody has opened in three years. It works. When a loan officer's password shows up in a breach dump, or a sign-in arrives from a country your institution does not operate in, that policy quietly steps in, makes the user prove who they are, and lets them back to work. No ticket. No call to your help desk. Most of the time, nobody even mentions it.

On October 1, 2026, that policy stops. Microsoft is retiring the legacy user risk policy and the legacy sign-in risk policy that live inside Microsoft Entra ID Protection. The company documents the date plainly, in a warning box, on two separate Microsoft Learn pages: the legacy risk policies configured in Microsoft Entra ID Protection are retiring on October 1, 2026.

Microsoft has been clear about this. Tenants with an affected policy enabled received individual notifications in the Microsoft 365 Message Center in early August 2026, one for each policy: MC1448338 covers the user risk policy and MC1448340 covers the sign-in risk policy. Search those two identifiers in your own Message Center. A hit means your institution is on the list. What will not be loud is the moment enforcement ends. Nothing errors. No banner appears in the admin center. The next risky sign-in simply proceeds the way an ordinary sign-in does, and unless somebody built a replacement first, there is no longer a policy in the tenant that acts on the risk signal at all.

What actually changes on October 1

Entra ID Protection has two things in it that people tend to blur together: the detections, and the policies that act on them. The detections are the intelligence layer. They watch every sign-in and score it. The policies are the enforcement layer, and they are the part being retired.

Microsoft's replacement is not a new product. It is the same two risk signals, evaluated by Conditional Access instead. Microsoft describes the mechanism directly: during each sign-in, ID Protection sends the detected risk levels to Conditional Access, and the risk-based policies apply if the policy conditions are satisfied.

Which is exactly why doing nothing is a problem. If the legacy policy is retired and no equivalent risk-based Conditional Access policy is enabled, there is no longer a risk-based policy left to receive that signal and act on it. Your other Conditional Access rules, your device compliance policies, and your Defender protections all keep running. What stops is the enforcement that was keyed to the risk score itself. The score still gets calculated. It just no longer changes what happens next.

What retires on October 1, 2026, and what has to replace it. There is no automatic migration.

The self-service loop that goes away first

Ask most IT directors what a risk policy does and they will describe a block. That is not really the point of it, and the difference matters for how your institution feels the retirement.

The valuable behavior is self-remediation. When a user risk policy fires with the remediation control set, Entra revokes the sessions and walks the user through proving who they are and, where a password is involved, changing it. Microsoft's own documentation is explicit about why this is preferable to blocking: allowing users to self-remediate significantly reduces the risk investigation and remediation burden on administrators. The compromised account gets cleaned up, the risk clears itself, and no administrator had to touch it.

Take that away and the work does not disappear. It moves. A branch manager whose credentials showed up in a breach dump keeps signing in the way she always does, because her sign-in still satisfies the rules that remain and no risk-based policy is left to escalate on the leaked-credential detection. The detection sits in the risky users report waiting for a human to notice it and act. Whoever reviews that report is now doing by hand what the policy used to do in seconds, and doing it hours or days later. For a lean IT team at a community bank or a credit union, that is not a small change. It is the difference between a control that runs itself and a queue somebody has to work. At most institutions that somebody is the same person already covering the help desk, the core conversion, and the examination prep.

Microsoft lists several other gains from moving the policies into Conditional Access: managing access policies in one location, enforcing sign-in frequency to require reauthentication every time, combining risk with other conditions such as location, and running multiple risk-based policies targeting different user groups or risk levels. That last one is genuinely useful in a financial institution, where the appetite for interrupting a wire operator is different from the appetite for interrupting a marketing coordinator. Institutions already running layered Conditional Access policies will find the risk conditions slot into a model they are already operating.

The detections keep firing. No risk policy acts on them.

It is worth being concrete about what the enforcement layer was covering, because the list is longer than most people assume. Entra ID Protection produces a wide set of risk detections, and the higher-value ones require an Entra ID P2 license. These are the signals that will keep arriving in your reports after October 1 with no risk-based policy configured to act on them. License tiers below follow Microsoft's published risk detection reference, which is worth checking against your own entitlements.

Read the second and third rows again. Password spray only fires once an attacker has already guessed a real password in your tenant, which makes it about as close to a confirmed finding as a detection gets, and it arrives as a sign-in risk that the legacy sign-in risk policy could challenge on its own. Attacker in the Middle fires when an authentication session has been routed through a malicious proxy, which is the modern way multifactor authentication gets bypassed rather than defeated. Microsoft raises the user to high risk on that one, and until now the legacy user risk policy could act on it without an administrator touching it.

This connects to a pattern we have written about before. A password spray campaign can slip past Conditional Access at tenants that have multifactor authentication turned on, and stolen session tokens let an attacker skip the sign-in entirely. Risk-based enforcement is one of the few controls that catches the aftermath of both, because it reacts to the account being compromised rather than to the login being wrong.

None of that stops on October 1. The detections keep arriving. What stops is the part that answered them without anyone being awake, which leaves a report that a person has to open, read, and act on every day, including the days nobody has time. Working that queue is the layer ABT operates for the institutions it manages, watching the Microsoft Entra ID Protection and Defender signals so a high-risk detection gets worked rather than left sitting.

The license question most institutions have not asked

Here is where this stops being a configuration task and starts being a budget conversation.

That reframes the whole exercise. If your institution holds P2, whether standalone or through Microsoft 365 E5 or the Entra Suite, October 1 is an afternoon of policy work followed by a few weeks of watching report-only results. If your institution does not hold P2, October 1 is the date a security capability leaves your environment, and the only ways to keep it are to license it or to accept the gap and document that decision.

Adding Entra ID P2 is a licensing change, which means it runs through whoever holds your Microsoft agreement. ABT is a Tier-1 Microsoft Cloud Solution Provider, so for the institutions we serve that part is a conversation rather than a project: how many of your users actually need P2 for these two policies, what the add-on does to your current agreement, and whether it can be in place before October 1.

Plenty of institutions are in the second group without knowing it. We see it across the more than 750 financial institutions whose Microsoft 365 tenants ABT manages: the policy is enforcing, the entitlement behind it quietly changed, and nothing ever surfaced the mismatch. Legacy risk policies were configured years ago, sometimes under a license mix that has since changed, sometimes by a predecessor. The policy kept enforcing. Nobody had reason to check what entitlement it depended on. The retirement is the moment that question gets asked, and it is much better asked in August than in October.

How to migrate before October 1

Microsoft documents the sequence, and it is short. The reason to follow it in order is that the middle step is the one that saves you from a bad morning.

Two rules govern how you build step one. First, keep them separate. Microsoft warns not to combine sign-in risk and user risk conditions in the same Conditional Access policy, and to create a separate policy for each risk condition. Second, follow Microsoft's recommended settings unless you have a reason not to.

For the user risk policy, Microsoft recommends selecting Require risk remediation when the user risk level is High. Choosing that control automatically brings two settings with it: Require authentication strength as a grant control, and Sign-in frequency set to Every time as a session control. Those are applied for you, which is the behavior that makes revocation actually stick.

For the sign-in risk policy, Microsoft recommends requiring multifactor authentication when the sign-in risk level is Medium or High, with the sign-in frequency session control included so a risky session has to reauthenticate rather than coasting on an existing token.

Exclude your emergency access accounts from both. Microsoft recommends keeping break-glass accounts out of Conditional Access policies specifically so a misconfiguration cannot lock every administrator out at once, and the same guidance applies to service accounts and service principals. If your institution does not maintain two cloud-only emergency access accounts with a permanently assigned Global Administrator role, build those before you build anything else.

On permissions: Conditional Access Administrator is the least privileged role Microsoft documents for creating or editing Conditional Access policies. There is no need to hand anyone Global Administrator to do this work, and handing it out anyway is the kind of finding that shows up later in a Microsoft Secure Score review.

The six steps in order. Confirming the license comes first because everything after it depends on the answer.

Three things that will block you

Most migrations of this kind stall on the same handful of prerequisites. All three are documented, and all three are easier to solve in August than under deadline.

• Security defaults are still on and they are mutually exclusive with the thing you are trying to build. Microsoft states that organizations choosing to implement Conditional Access policies that replace security defaults must disable security defaults. Smaller tenants that never moved off security defaults hit this before they can create a single policy, and turning security defaults off without immediately enabling replacement Conditional Access policies leaves a real gap in between. Plan that switch as one change, not two.
• Users are not registered for multifactor authentication. Microsoft is blunt about the consequence: users must register for Microsoft Entra multifactor authentication before they face a situation requiring remediation, and users who are not registered are blocked and require administrator intervention. Turning on a remediation policy over an unregistered population converts a security control into a help desk incident. For hybrid users synced from on-premises, password writeback also has to be enabled or the secure password change cannot complete.
• Guests and external users are not covered the same way. The Require risk remediation control is not supported for external and guest users, because Entra ID does not support session revocation for those accounts. Any institution with meaningful vendor, auditor, or correspondent access through guest identities needs a separate answer for that population rather than assuming one policy covers everyone.

None of these are exotic. They are just the sort of thing that turns a two hour task into a three week project when they surface on September 29 instead of August 7. Institutions that recently worked through the June 2026 Conditional Access enforcement change will recognize the shape of the problem, and probably already have the emergency access accounts and registration coverage sorted.

What an examiner will ask

Financial institutions do not get graded on whether Microsoft changed something. They get graded on whether the controls they say they have are actually running.

That is the exposure here, and it has a specific shape. Your information security program almost certainly describes risk-based or adaptive authentication somewhere. Your last examination may have referenced it. Your vendor questionnaires may assert it. If the legacy policy retires on October 1 and nothing replaces it, every one of those documents describes a control your environment no longer has, and the gap is invisible from the inside because nothing failed.

The scoping differs by charter. Mortgage lenders and mortgage brokers fall under the FTC Safeguards Rule, which requires a written information security program with controls that are actually implemented and periodically reassessed. Banks and federally insured credit unions answer instead to the information security guidelines their own prudential regulators issued under the Gramm-Leach-Bliley Act. The label changes. The question does not: can you show that the access controls in your written program are enforcing today?

Three artifacts answer that question well, and all three come out of doing the migration properly:

Keep the report-only output from step two. It is dated evidence that you tested the replacement policy against real sign-ins before enforcing it, which is exactly the change-management discipline examiners look for. Keep a record of the enforcing state, not just the policy's existence, because a Conditional Access policy sitting in report-only mode on October 2 protects nobody. And keep the licensing decision in writing, especially if you concluded that Entra ID P2 was not justified for some population. A documented risk acceptance is a defensible position. An undocumented gap that nobody noticed is not.

This is also where a managed operating model earns its keep, and it is the specific thing ABT sells. Guardian MxDR deploys a governed Conditional Access baseline, risk-based policies included where the tenant is licensed for them, and checks that baseline against live tenant state. A baseline policy sitting in report-only mode shows up as a warning in reports that refresh nightly, which ABT reviews with the institution on a set cadence rather than leaving it to surface at your next examination. Checking that a policy exists is easy. Checking every month that it is still in Grant mode rather than Report-only, still scoped to the right users, and still surviving the next Microsoft change is the part institutions quietly stop doing after the project ends.

Frequently Asked Questions