Rolling out a new named location without breaking Conditional Access

Named locations look like the most harmless object in Conditional Access: a name and a list of IP ranges. They are not. A named location is referenced by policies you may have forgotten, its trusted flag changes how risk detection and MFA registration behave tenant-wide, and the ranges themselves are only as accurate as whoever last spoke to the network team. Most CA lockouts I have seen were caused by a location change, not a policy change.

This runbook is for adding a new office, changing an egress address, or introducing a location condition for the first time.

First, understand what a location touches

Three separate things depend on named locations:

1. Policies with a location condition — include (apply only from here) or exclude (apply everywhere except here). The exclude case is where the risk is: a policy that requires MFA "except from trusted locations" silently stops requiring MFA from any address you add to the trusted list.
2. The Mark as trusted location flag. Trusted locations feed Entra ID Protection — sign-ins from them do not generate unfamiliar location or atypical travel detections — and they are the modern replacement for the legacy per-user MFA trusted IPs list. Marking a location trusted lowers risk scores for everything coming from it.
3. Country locations used for geo-blocking, which are evaluated on IP geolocation or, optionally, on GPS from the Authenticator app.

Before changing anything, list the policies that reference the location you are touching. Entra admin center → Conditional Access → Named locations shows a count of policies per location; open each. For a new location, this list is empty — the risk comes when you add it to an existing exclude.

Step 1: get the addresses right

The egress address the network team gives you is wrong more often than it is right. Verify:

• Ask a device on the site what its public address actually is (curl ifconfig.me or a sign-in log entry from a known user at that site). Compare with what you were told.
• Check for multiple egress paths — SD-WAN failover, a guest Wi-Fi network on a separate circuit, split-tunnel VPN. Each is a distinct public address, and users will move between them without knowing.
• Check the range width. A /24 offered casually by a colleague may include a neighbouring tenant's addresses at the same carrier. Prefer the narrowest range that covers the real egress.
• IPv6. If the site has IPv6 egress, sign-ins will arrive over it and a v4-only location will not match them. Add the v6 prefix or confirm it is not routed.

Write the source of each range next to it in the location's name or a change ticket. Six months from now, "Oslo office 203.0.113.0/28 — confirmed by sign-in logs 2026-09-02" beats "Oslo".

Step 2: create the location, but do not trust it yet

Add the named location with its ranges. Leave Mark as trusted location unchecked for now. Nothing changes in the tenant at this point — a location that no policy references and that is not trusted is inert.

Step 3: prove the match with a report-only policy

Create a new policy in report-only mode: all users, all cloud apps, condition Locations → include the new location, grant Require MFA (the grant control does not matter; you only want the evaluation). Leave it for a few days.

Then check the sign-in logs. Filter on the new policy under Conditional Access → Report-only: success and Report-only: not applied. You are answering two questions:

• Do sign-ins from the site match? If users you know are in that office show not applied, the ranges are wrong.
• Do sign-ins from elsewhere match? If a home worker's sign-in reports success on the location, the range is too wide.

The What If tool in Conditional Access also lets you simulate a sign-in from a specific IP against all policies, which is quicker for spot checks. The CA testing guide covers the workflow in more depth.

Step 4: add it to the real policies, one at a time

Now, and only now, attach the location to the policies that need it. Do the least dangerous first:

• Include-style policies (require compliant device from this location) are low risk: a wrong range just means the policy applies or not.
• Exclude-style policies are where you slow down. Adding a location to "require MFA except from trusted locations" removes MFA for that range. Ask whether the policy should exclude locations at all in 2026 — the CA design guide argues that location-based MFA exclusions are a legacy pattern that token theft and adversary-in-the-middle phishing have made unwise, and a new office is a fine moment to retire the exclusion rather than extend it.

For each change, stay signed in with a separate admin session, and have a break-glass account ready. Save, wait a few minutes for propagation, and test a sign-in from the site and one from outside.

Step 5: decide about trusted

If the location must be trusted — because your risk policies would otherwise fire on every sign-in from a new office — flip the flag last, after a week of clean policy behaviour. Watch Identity Protection's risky sign-ins the following day for a drop that is larger than the office explains; that is a sign the range is wider than the office.

Changing or removing an existing location

Removing a range that users are actively signing in from is the reverse failure: every policy that excluded the location suddenly applies to them, which is usually just an MFA prompt but for a device-compliance policy can be a block. Sequence it:

1. Report-only copy of each affected policy with the new range set.
2. Compare a week of results.
3. Change the real location.

Never delete a location that policies still reference; remove the references first, or the policy's condition becomes an empty set with behaviour you did not intend.

What this never needs

Support engagement, downtime, or a maintenance window. Every step is reversible within minutes, provided the break-glass account is excluded from every policy and you did not save a policy with an empty location condition. The only hard part is patience: the report-only week feels unnecessary right up until the morning it is not.