Stop Impossible Travel at Sign-In: Entra's New Require Risk Remediation Control

The dangerous part of an account compromise is rarely the login itself. It is the hours, sometimes days, between that login and anyone noticing. During that window the attacker is reading email, walking through SharePoint, sitting in Teams, all with valid credentials and zero alerts that anyone is acting on.

Picture the textbook case: a CFO signs into Microsoft 365 from Denver, and two minutes later there is another successful login from Eastern Europe. No VPN, no approved travel, no reasonable explanation. That is impossible travel, and it almost always means the account is compromised.

With risk-based access policies in Microsoft Entra ID, that second login gets blocked automatically before the attacker ever opens a file, even with real user credentials or an active session in hand. This post covers how Entra detects and scores risk, what Microsoft's new risk remediation option in Conditional Access changes, and how to implement the protection in your tenant.

Where Entra's risk signal comes from#

Microsoft processes billions of sign-ins across all tenants every day. That global telemetry feeds machine learning models built to spot risky behavior: sign-ins from known malicious IP addresses, anonymous networks, suspicious devices, and unusual geographic patterns.

At the tenant level, Entra builds a behavioral profile per user: typical sign-in locations, usual devices, preferred browsers, historical activity patterns. When a sign-in deviates from that baseline, Entra evaluates the event and assigns a risk level.

Deviation alone is not a verdict. A user signing in from Boise eight hours after signing in from Denver could be legitimate and may rate as low risk. A user signing in from Tokyo minutes after signing in from Colorado is physically impossible and rates high.

Microsoft does not publish the exact scoring logic, and that opacity is intentional. Revealing the calculation methods would hand attackers the recipe for staying under the thresholds.

Two risk types, one enforcement engine#

Entra evaluates identity risk along two axes, and the distinction matters when you write policies.

Sign-in risk scores the individual authentication attempt: impossible travel, sign-ins from known malicious infrastructure, anonymous proxy usage.

User risk scores the account itself, asking whether multiple correlated events over time suggest the identity is compromised.

Both feed directly into Conditional Access, which is the point: the platform takes automated action without waiting on alerts, tickets, or a human investigation.

The licensing gate, and the cheaper way through it#

Risk-based access policies require advanced identity protection, which means Entra ID P2. That ships inside Microsoft E5, and it is also available through the Microsoft Defender Suite add-on for Business Premium.

For many small and mid-sized organizations, the Defender Suite add-on is significantly more cost effective than an E5 migration. In our experience it is also the easier conversation, especially at renewal time or in the weeks after a security incident, when budget conversations move quickly.

Building the baseline policy#

Once licensed, configuration lives in Microsoft Entra ID under Conditional Access. Microsoft provides policy templates, though many organizations build custom policies for clarity and control.

The recommended starting point is a policy that blocks high-risk sign-ins:

1. Apply to all users, excluding emergency access accounts
2. Target all cloud apps
3. Set the condition to sign-in risk: high
4. Set the access control to block

What the new Require risk remediation option adds#

Microsoft recently introduced Require risk remediation (opens in new tab), a new Conditional Access control that consolidates several security actions into a single setting. Instead of choosing between a hard block and separate password or session controls, the policy can require the risk be remediated as the condition of access.

Plan for the false positive before it pages you#

If you choose to block access rather than reset passwords and sessions, implement it thoughtfully. There are real-world cases of executives traveling internationally getting blocked on false positives, with time zone differences delaying the response and business operations taking the hit.

Going more restrictive is often the right call. Just pair it with standard operating procedures for false positives, so the 2 a.m. blocked-CEO scenario has a runbook instead of a scramble.