Named locations in Conditional Access: IP ranges, countries, trusted IPs and the pitfalls

Named locations look like the simplest part of Conditional Access, yet they cause a surprising share of "why was I blocked?" and "why wasn't MFA required?" tickets. In this post I'll build IP and country locations the right way, migrate the legacy MFA trusted IPs, cover the IPv6, VPN and proxy traps, and show how to confirm in the sign-in logs which location a sign-in actually matched.

How it works#

Microsoft Entra ID decides a user's location from the public IP address of the request, or from GPS coordinates supplied by Microsoft Authenticator. Policies apply to every location unless you scope them. In the policy editor the condition is now called Network (formerly Locations) and offers four choices:

• Any network or location: every IP address on the internet, usually combined with an exclusion.
• All trusted networks and locations: every named location marked as trusted, plus the legacy MFA trusted IPs if they're configured.
• All Compliant Network locations: shown to tenants with Global Secure Access.
• Selected networks and locations: specific named locations.

Named locations hold IPv4 ranges, IPv6 ranges or countries. The limits are 195 named locations and 2,000 IP ranges per location, and masks must be longer than /8. Private addresses never appear: Entra ID only sees the public address your network uses to reach the internet.

Location is evaluated at sign-in and whenever an app redeems its refresh token, which for modern authentication apps happens about once an hour. Without continuous access evaluation, a user who leaves the office can keep access for up to an hour.

You need Microsoft Entra ID P1 and at least the Conditional Access Administrator role.

Step-by-step#

1. Inventory the egress addresses users really come from#

List the public IPv4 and IPv6 egress ranges of offices, full-tunnel VPN gateways and data centers, then compare them with reality. If you stream sign-in logs to Log Analytics:

SigninLogs
| where TimeGenerated > ago(14d) and ResultType == "0"
| summarize SignIns = count(), Users = dcount(UserPrincipalName)
    by IPAddress, Location, Networks = tostring(NetworkLocationDetails)
| order by SignIns desc

High-volume addresses with an empty network list are usually an office or VPN range you haven't defined yet, very often an IPv6 range.

2. Create an IP ranges location#

Go to Entra ID › Conditional Access › Named locations, add an IP ranges location, enter the ranges in CIDR notation (for example 203.0.113.0/24 and 2001:db8:abcd:12::/64) and select Mark as trusted location only for networks your organization controls. Trusted named locations also improve the accuracy of ID Protection's risk calculation. The same with Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.ConditionalAccess"
$body = @{
    "@odata.type" = "#microsoft.graph.ipNamedLocation"
    displayName   = "HQ egress"
    isTrusted     = $true
    ipRanges      = @(
        @{ "@odata.type" = "#microsoft.graph.iPv4CidrRange"; cidrAddress = "203.0.113.0/24" }
        @{ "@odata.type" = "#microsoft.graph.iPv6CidrRange"; cidrAddress = "2001:db8:abcd:12::/64" }
    )
}
New-MgIdentityConditionalAccessNamedLocation -BodyParameter $body

3. Create a countries location, if you need one#

Add a countries location, choose the countries and decide how location is determined:

• Determine location by IP address: Entra ID maps the IPv4 or IPv6 address to a country with a periodically updated table. Select Include unknown countries/regions in block policies, so addresses that map nowhere are caught too.
• Determine location by GPS coordinates: Authenticator reports the phone's position every hour, and users may be prompted hourly. It requires the Authenticator app, doesn't work when only passwordless methods are set (passwordless phone sign-in also needs MFA push notifications enabled), and rejects jailbroken devices and spoofed locations. Keep it for very sensitive apps.

4. Use the location in a policy and test it#

Two common patterns: require MFA with Any network or location included and All trusted networks and locations excluded, or block a countries location while excluding your emergency access accounts. Start in report-only mode and use What If with an IP address or country to confirm the result. Careful: a report-only policy with a GPS-based location still asks users to share their location, and refusing may block them.

5. Migrate the legacy MFA trusted IPs#

Trusted IPs in the MFA service settings accept only IPv4, up to 50 ranges, and Microsoft no longer recommends them. They appear as MFA Trusted IPs in the location list. Continuous access evaluation also can't see them, so sign-ins that match them get one-hour tokens without instant IP enforcement. To migrate:

1. Open Entra ID › Multifactor authentication › Additional cloud-based MFA settings and copy the ranges under Trusted IPs.
2. Create a trusted IP ranges location with those ranges plus their IPv6 equivalents.
3. Find policies that select MFA Trusted IPs directly and switch them to the new location; policies using All trusted networks and locations pick it up automatically.
4. Check Skip multifactor authentication for requests from federated users on my intranet: while it's on, any request carrying the AD FS insidecorporatenetwork claim counts as a trusted location. It only works while AD FS issues that claim, so replace it with IP ranges before you move domains to cloud authentication.
5. Clear the legacy list, then verify.

Verify#

• In Entra ID › Monitoring & health › Sign-in logs, open a sign-in from the office: the IP address is in your range and the Conditional Access tab shows the expected policy result. In Microsoft Graph (and the NetworkLocationDetails column in Log Analytics) the sign-in lists the matched network name and a type such as namedNetwork or trusted.
• A sign-in from a phone on mobile data is treated as outside the trusted network.
• Rerun the query: no high-volume office address is left without a network name.

More detail in reading sign-in logs like an engineer.

Tips & gotchas#

• Cloud proxies and VPNs: Entra ID sees the proxy's address and ignores X-Forwarded-For, which can't be validated. Microsoft calls keeping a cloud proxy's IP list current nearly impossible; prefer compliant or hybrid joined device controls there, or Global Secure Access source IP restoration.
• Never trust shared egress IPs. Adding a shared proxy range as trusted weakens every policy that excludes trusted locations.
• Split tunneling: Entra ID and Exchange Online may see different addresses, which matters once CAE enforces location; see continuous access evaluation.
• IPv6: if a site has IPv6 and you only defined IPv4, those users fall outside your trusted location.
• Housekeeping: a trusted location can't be deleted until you remove the trusted flag, and deleted locations can be restored within 30 days.

References#

• Conditional Access: Network assignment (Microsoft Learn)
• Configure Microsoft Entra multifactor authentication settings: trusted IPs (Microsoft Learn)
• Continuous access evaluation: supported location policies (Microsoft Learn)