Microsoft Switched Off a Sign-In Safety Net on October 1. Does Your Business Have a Replacement?

· by IDE Solutions
Short answer: Microsoft retired the old risk-based sign-in policies in Entra ID Protection on October 1, 2026. Rebuilding them as Conditional Access policies requires Entra ID P2 licenses, and Microsoft 365 Business Premium includes only P1. If your company has Business Premium, check whether anything automatically reacts to a hijacked login. Probably nothing does.
Many owners believe that Microsoft 365 Business Premium "watches" for stolen passwords and locks suspicious logins on its own. It does not. Business Premium gives your IT team the tools to write rules, such as "ask for a second step when someone signs in from abroad", but the part that scores every sign-in for risk and reacts by itself belongs to a higher licence tier.
That distinction became more visible on October 1, when Microsoft switched off the older way of configuring that automatic reaction. If you are not sure which side of the line your company sits on, a Microsoft 365 security assessment settles it quickly, because the answer sits in your tenant settings, not in a brochure.
Quick answers
What exactly did Microsoft switch off? The legacy user risk and sign-in risk policies that were configured inside Entra ID Protection. Microsoft's documentation says they were retired on October 1, 2026 and tells administrators to recreate them as Conditional Access policies.
Does this affect a company on Business Premium? Only indirectly. Microsoft's licence table lists risk policies as available with Entra ID P2 only, and Business Premium includes P1. Most Business Premium tenants therefore never had these policies running in the first place.
Will my staff notice anything today? No. Nothing visibly breaks. That is the problem: a tenant without an automatic reaction looks exactly like one that has it, until someone's login is stolen.
What is the cheapest sensible fix? Make sure every user is registered for multi-factor authentication and that a few well-chosen P1 Conditional Access rules are switched on. If you want the automatic risk reaction as well, the upgrade path is a P2 licence.
What did the retired policies actually do?
Every time someone signs in to Microsoft 365, Microsoft scores that sign-in for how likely it is to be an attacker. The signals include a login from an anonymous IP address, a password-spray pattern, or a password that turned up in a leaked list. Microsoft describes these detections as the input for automatic rules.
Two rules used that score. The sign-in risk rule asks for a second verification step when a login looks suspicious. The user risk rule forces a secure password change, or ends the person's sessions, when an account looks compromised. Both ran without anyone in your office lifting a finger, at three in the morning or on a public holiday.
Until October 1 an administrator could switch these on inside ID Protection. That place no longer works. The same rules now belong in Conditional Access, the general rulebook for who may get into what, and from there they behave the same way.
Which licence do you need to keep this protection?
Microsoft's own tables settle this. In the Entra licensing documentation, risk-based Conditional Access is listed under Entra ID P2 and is not ticked for P1. The same page states that P1 is included in Microsoft 365 Business Premium, and that P2 comes with the Microsoft Defender Suite add-ons for Business Premium.
| Capability | Entra ID P1 (in Business Premium) | Entra ID P2 |
|---|---|---|
| Conditional Access rules (user, device, location, app) | Yes | Yes |
| Automatic sign-in risk and user risk policies | No | Yes |
| Full risky-user and risky-sign-in reports | Limited | Full |
| Alerts and weekly digest for users at risk | No | Yes |
One consequence deserves a plain sentence. If your IT provider once told you that "risk-based protection is on", and you hold Business Premium without a Defender Suite add-on, ask them to show you which policy they mean. Either it is a simpler P1 rule that does something different, or it was never working.
What should a 20-person firm do this week?
Take a 20-person accounting practice as the example. Its staff open client payroll files from home, from client offices and from phones. A stolen password there is not an IT inconvenience: it is a data-protection notification and a difficult conversation with clients. The practice holds Business Premium. The sensible sequence has four steps, and none of them needs a new purchase.
First, find out who is registered for MFA. Microsoft's remediation flow depends on it. The documentation warns that users who have not registered for multifactor authentication before a risk event are blocked and need an administrator. Whether you use risk policies or not, an unregistered account is the weak point, and a shared mailbox login or a former seasonal employee is where it usually hides. The accounting and finance firms we support hold exactly this kind of client data.
Second, confirm that a baseline Conditional Access set exists. That means MFA for all users, a block on legacy sign-in methods, and a stricter rule for administrators. These are P1 features and you already pay for them.
Third, check whether anyone had legacy risk policies enabled. If your tenant had P2 licences, open the ID Protection dashboard and see whether the user risk and sign-in risk policies were enforced. If they were and nobody built Conditional Access replacements, you have had a gap since October 1.
Fourth, decide on P2 with a number in hand. Count the accounts that can reach sensitive data: partners, finance, HR, administrators. Licensing only those people is a legitimate option, and it costs less than licensing everyone.
How do you migrate if you did have risk policies?
Microsoft's migration guidance is short. Create the equivalent user risk and sign-in risk policies in Conditional Access in report-only mode, review the results, and when they look right switch the policies to On. Then disable the old policies in ID Protection.
The recommended settings show what you are buying. For sign-in risk, Microsoft recommends requiring MFA when the level is medium or high. For user risk, it recommends requiring remediation at the high level: a secure password change after MFA, or a session reset for people who sign in without a password.
Two details cause most of the trouble. Keep at least one emergency access account out of the policies, so a configuration error cannot lock everyone out, including you. And do not combine user risk and sign-in risk in a single policy. Microsoft's documentation tells you to build them separately.
Report-only mode is the step people skip when they are in a hurry. It costs a few days of waiting, and it is what shows you that the finance director's travel pattern would have triggered a prompt on Monday morning.
Is P2 worth it for a business with 15 to 50 people?
It depends on what you hold and who you answer to, not on headcount. A firm that handles other people's money, health data or legal files has a stronger case, because a quiet account takeover there brings notification duties and client trust costs that exceed any licence fee. A design studio with no regulated data can reasonably stay on P1 and put its effort into MFA coverage and device rules.
There is also a cost that never appears on the licence quote: attention. Risk policies only help if someone reads the risky-user reports and handles what the automation cannot. A tenant with P2 and nobody reading the reports has bought an alarm that nobody hears. Reading those reports is the part our cloud security services take over for small teams that have no security person.
If the answer is "not yet", write that decision down with a date, the way you would for any accepted business risk. A note saying "we looked at it and chose P1 plus MFA for everyone" gives you something to show a customer or an auditor, and silence does not.
What else is on the early October calendar?
Identity rules are not the only thing with a date this month. Office 2021 support ends on October 13, a deadline we covered in our Office 2021 article, and Windows 10 machines are on their own clock too. Treat early October as one review window: identity rules, old Office installs and unsupported Windows machines in a single pass is a better use of an afternoon than three separate scrambles.
The wider lesson is that Microsoft moves security settings between menus and licence tiers without a visible alarm. A setting that was on last quarter may sit on a different shelf now. Reviewing your Conditional Access list every quarter, with a named person responsible, takes about an hour and catches exactly this kind of change. Our Microsoft 365 hardening checklist lists the other defaults worth checking while you are in there.
Five questions to send to your IT provider
Send these to whoever manages your Microsoft 365 tenant and ask for written answers within the week:
1. Which Entra licences do we hold: P1, P2, or a Defender Suite add-on?
2. Were legacy user risk or sign-in risk policies ever enabled in our tenant, and if so, what replaced them?
3. What share of users are registered for MFA, and which accounts are not?
4. Which Conditional Access policies are in report-only mode, and why?
5. Who reads the sign-in and risky-user reports, and how often?
An answer of "I will have to check" is useful information. It tells you the control exists on paper and has no owner. If you want the same questions answered with evidence from your own tenant, our Microsoft 365 management work starts with exactly this inventory.
Find out what actually reacts when a login is stolen
We read your Entra and Conditional Access configuration, compare it with the licences you hold, and give you a short written answer: what protects sign-ins today, what stopped on October 1, and what the cheapest sensible upgrade would be.
The gaps come back as a plain-language list ranked by the damage a stolen password could do, so you can decide before an incident decides for you.
This article was drafted with AI assistance and reviewed, edited and approved by IDE Solutions before publication. More in our Impressum.