azureblog.co.uk
← cd ~/posts

Named locations: getting IP ranges and countries right in Conditional Access

Named locations look simple, but trusted IPs and country blocks are easy to get subtly wrong. What they can and can't do, and how to use them well.

2 min read⚠ checked 17 Dec 2025Entra ID · Conditional Access
Part 4 of 7 in Conditional Access from zero
On this page
  1. IP ranges
  2. Countries and regions
  3. Good patterns
  4. Building a country block safely
  5. Watch out for

let policies react to where a sign-in comes from. There are two kinds.

Where is the sign-in coming from?
Office egress IPMatches a trusted IP range named location
Country you don't operate inMatches a blocked-countries location
Anywhere elseNormal policies apply
How a named location is matched.

IP ranges

A list of public IPv4 and IPv6 ranges, such as your office internet connections or VPN egress. You can mark a range as trusted, which lowers risk in Identity Protection and lets policies include or exclude "all trusted locations".

  • Use your egress IP addresses: the ones the internet sees, not internal ranges.
  • Remember IPv6. If your offices have it, sign-ins may come from IPv6 addresses you haven't listed.
  • Keep the list current when ISPs or VPN providers change.

Countries and regions

Locations can be defined by country, determined either from the IP address or from GPS coordinates via Authenticator. GPS needs the user to share location from the app, so use it carefully.

Good patterns

  • Block unexpected countries where you have no staff or business. Keep an exception process for travel.
  • Don't skip MFA because a user is in the office. It's tempting, but an attacker inside your network, or a compromised device in the office, then gets an easier ride. Use location as a signal, not a pass.
  • Protect security info registration. Requiring that methods are registered from a trusted location, or with a , makes it harder for an attacker with a stolen password to add their own method.
Remember: IP location is approximate, and VPNs and cloud proxies move traffic around. A country block reduces noise; it isn't a strong security boundary on its own.

Building a country block safely

  1. Export a month of sign-ins and list the countries successful sign-ins came from. You'll find more than you expect: travel, VPNs and cloud services.
  2. Create a named location of the countries you allow, then a policy that blocks everything except that location. An allow-list is easier to reason about than a long block-list.
  3. Exclude , and decide how travellers request an exception (a temporary group exclusion works well).
  4. Run it in for two weeks before switching it on.
kql
SigninLogs
| where TimeGenerated > ago(30d) and ResultType == "0"
| summarize Users = dcount(UserPrincipalName), SignIns = count() by Country = tostring(LocationDetails.countryOrRegion)
| order by SignIns desc

Watch out for

  • Mobile networks sometimes route traffic through another country.
  • Cloud services signing in for users, such as some third-party integrations, appear from their own data centres.
  • Unknown locations: an IP that can't be placed counts as an unknown country, which you can choose to include or exclude.

This post was last checked against Microsoft's documentation over six months ago. The approach should still hold, but check the linked sources for anything that has changed before you act on it.

Next in Conditional Access from zero · part 5 of 7Rolling out "require compliant device" without a flood of tickets →

Related posts