Conditional Access named locations look like a network boundary and are not one. A named location is a list of public IP ranges or countries that a policy can include or exclude, matched against whatever address the sign-in appears to arrive from, and evaluated only after the first factor has already been checked. That last detail is where most location designs quietly fail. Here is what the condition actually reads, what marking a location trusted changes elsewhere in the tenant, and the ceilings you will hit before you expect to.
A named location is a condition, not a grant control. It decides which sign-ins a policy applies to and nothing at all about what happens once it does. If the controls underneath are weak, a precise location only makes them weak for a smaller audience. The Conditional Access policy design guide covers that layer. This page is only about the location condition and the trust flag hanging off it.
One disclosure first. My tenant is a lab with no enrolled devices, so I have not run these policies against a production estate or watched a real sign-in log fill up behind them. What follows is documented behaviour, verified against Microsoft Learn on 2 September 2026, plus the points where I would expect it to bite.
What Conditional Access named locations actually evaluate
Two kinds exist. They are configured in the same blade and behave differently enough that treating them as interchangeable is the first mistake.
| Type | What it matches | Can be marked trusted |
|---|---|---|
| IP ranges | Public IPv4 or IPv6 ranges in CIDR notation. Microsoft’s examples are 2001:db8::1/128 for a single IPv6 address and 2001:db8:abcd:0012::/64 for a subnet. | Yes |
| Countries or regions | A country list, resolved either by IP address against a periodically updated mapping table, or by GPS coordinates collected from Microsoft Authenticator. | No |
Microsoft has moved the condition since most of the guides on page one were written. The network assignment reference now states that the Location condition "moved and was renamed Network", that it initially appears both at the Assignment level and under Conditions, and that existing policies using Location continue to work without changes. The list itself still lives under Entra ID > Conditional Access > Named locations in the Microsoft Entra admin center. If a walkthrough tells you to look under Conditions and nowhere else, it predates the change.
The ceilings, and where they actually bite
Conditional Access named locations are capped in three places, and the numbers are worth knowing before a design meeting rather than after one.
| Limit | Value | Why it matters |
|---|---|---|
| Named locations per tenant | 195 | Sounds generous until someone models one location per branch office. A retailer with 300 sites cannot express its estate this way and has to aggregate. |
| IP ranges per named location | 2000 | Rarely a problem for offices. It becomes one when a location is built from a supplier’s published egress list. |
| Smallest accepted CIDR mask | Greater than /8 | You cannot express an enormous block in one entry, which is occasionally attempted when someone tries to allow a whole regional registry range. |
None of these are the interesting constraint. The interesting constraint is what the condition can see.
Marking a location trusted is not a local decision
The trusted flag on an IP based location does three separate things, and only the first is obvious.
- Conditional Access policies can include or exclude trusted locations as a group rather than by name.
- Microsoft states that sign-ins from trusted named locations improve the accuracy of Microsoft Entra ID Protection’s risk calculation. In practice that means you are telling the risk engine to be less suspicious of that address range, permanently.
- A location marked trusted cannot be deleted until the trusted designation is removed first, which is a small operational trap during clean-up.
Point two is the one worth sitting with. Marking the office range trusted is usually done to reduce prompts. The side effect is that risk scoring for every sign-in from that range is softened, including a sign-in from an attacker who has reached the corporate network or is simply sitting behind the same egress address on guest wifi.
The failure modes
The block runs after the password has already been checked
This is the single most misunderstood property of the whole condition. Microsoft’s own guidance on blocking access by location states plainly that "Conditional Access policies are enforced after first-factor authentication is completed" and that Conditional Access "isn’t intended to be an organization’s first line of defense" for scenarios such as denial of service.
Read that against a password spray from a blocked country. The credential is still validated. The attacker still learns whether the password was correct, because the failure they receive is a policy block rather than a bad password. A country block is a useful reduction in exploitable surface. It is not a firewall, and it does not protect a leaked credential from being confirmed as valid.
The address is the egress address, not the user
The condition sees the public address the sign-in arrives from. A user on a corporate VPN presents the corporate egress address wherever they physically are. A user on a consumer VPN presents whatever country that provider terminates in. Neither is a lie the platform can detect, and neither is a bug. It does mean a country policy answers the question "where did this traffic leave the internet from" and not the question most people think they are asking.
Unknown countries are a separate decision
Some addresses cannot be mapped to a country at all. Microsoft exposes this as an Include unknown countries/regions checkbox on the location itself, and the documentation is explicit that the setting decides whether those addresses fall inside the named location. A blocklist that leaves the box clear does not block unmappable addresses. An allowlist that leaves it clear will lock out anyone whose address stops resolving. Which way you want it depends entirely on whether the location is used for include or exclude, and the box does not know which.
GPS determination has a cost the design review usually misses
Choosing GPS coordinates instead of IP address requires Microsoft Authenticator on the user’s mobile device, and Microsoft documents that the system contacts the app every hour to collect the device’s GPS location. That is a per-user dependency on a personal device and a recurring background interaction, applied to every user the policy touches. It buys accuracy against VPN egress. It costs you a hard requirement that every in-scope user carries an enrolled phone.
Legacy trusted IPs are a different list entirely
The trusted IPs setting inside the multifactor authentication service settings is not the same object as a named location, and configuring one does not configure the other. Microsoft’s multifactor authentication settings reference says the feature requires Microsoft Entra ID P1, that location conditions are "the recommended way to configure MFA with Conditional Access because of IPv6 support and other improvements", and that if both per-user MFA and Conditional Access are configured you need to add trusted IPs to the Conditional Access policy and update the MFA service settings. Two lists, both live, and a tenant that has been through a migration usually has them disagreeing. If you are still working out which licence tier gives you what, the Entra ID P1 vs P2 comparison covers where the line sits.
What I would do differently
Treat Conditional Access named locations as an assignment narrowing device, never as the protection itself. The useful pattern is a strong grant control applied broadly, with location used to decide who is in scope, rather than a weak grant control that location is expected to rescue. Authentication strength and device compliance are controls. A named location is a filter, in exactly the same sense that a device filter is a filter.
Concretely, three positions I would hold. First, do not mark the office range trusted purely to suppress prompts, because the cost is paid silently in Identity Protection risk scoring and nobody reviews that trade later. Second, prefer blocking a small explicit set of countries over allowing a small explicit set, because the allowlist breaks the moment someone travels and the pressure to add an exclusion arrives at the worst possible time. Third, whatever the policy does, exclude the break-glass accounts, which Microsoft calls out for the obvious reason that a location misconfiguration is one of the easier ways to lock every administrator out of a tenant at once.
And if the goal behind the whole exercise is really "our people should only reach this from a managed device on our network", the honest answer is that the second half of that sentence is the weak half. The managed device is the part an attacker cannot borrow with a VPN subscription.
Last verified: 2 September 2026.
