Diving into geo filter with Entra Conditional Access – Part 2

So in part 1 (Link) I talked about the “why” of geo filter. Now let’s get a bit more technical and talk about the “how”.

The foundation

So first of all, I will explain briefly the Conditional Access setup. I have used the framework I presented in an earlier post (insert link) and have a block-by-default setup up and running. As part of that setup I will define “Named location” as they are called, which identify locations based on either IP addresses or country. Then these locations are used in Conditional Access policies to enforce the intended behavior if a user signs in from certain locations. The allowlist setup (ref part 1) ensures all locations are blocked by default, so I need to worry about where the user can sign in from, and not the opposite.

In this scenario I will assume that the company in question resides in Norway and with a certain subset of users travelling frequently around Scandinavia (Norway, Sweden and Denmark). This will cross slightly over to the part 3 where I will go through exceptions, but that’s ok.

In short: the policy flow is like this:

1. Default policy: Block all sign-ins except those from Norway.
2. Group-specific policy: Allow Norway + Sweden + Denmark for the “Scandinavia travelers” group.
3. Explicit exception: Will be covered in Part 3

Named Locations are for more than just geo filters

In Entra Conditional Access we have a menu options called “Named locations” and this is our first stop. Here we define several locations and not just only for geo filters.

First we define the locations we need for the demo, that would be one location for Norway and one location for Scandinavia (Norway+Sweden+Denmark). This will be used on the Conditional Access geo blocks.

In addition, I also always recommend that you define your Office location(s) here based on their IP addresses, but be sure to keep them tightly scoped (i.e. only include your egress IPs which are actively in use, and not the entire subnet). You should always do this regardless if you apply geo filters or not.

But why do I recommend this?

Because this feature overlaps with Entra ID Protection which handles user risk and sign-in risk. You can mark named IP ranges as trusted (country-based locations can’t be trusted), and that signal helps reduce noisy risk flags. Even without Entra P2, Entra still performs some risk evaluation and may flag risky sign-ins, but you’ll see limited detail. The richer insights and automated responses (like full risk types, user risk scoring, and policy-driven remediation) require Entra P2 (Link).

In short: The automatic risk evaluation for your sign-ins becomes more accurate if you define your office IPs and mark them as trusted, even if you don’t have P2 licenses. Also, beware that marking a location as trusted IS NOT the same as the MFA IP whitelist we had in the legacy MFA portal. You should never exempt a location from requiring MFA.

Setting up the Conditional Access policies

First we have the default Conditional Access policy which blocks sign-ins unless they are from Norway. Simply block the sign-in unless location is Norway. We want this to be the default behavior for all users in this tenant.

But some users may have other needs

So let’s assume we have a subset of users accounts who travel regularly. For example this company has about 300 employees with a sales department which consists of ~25 people who often travel to meet customers, vendors, trade shows, product demos etc. Imagine weekly travels to major cities across Scandinavia. These users often sign in from hotel wifi, conference venues, roaming mobile, customer offices, etc. That doesn’t fit our default geo block well since it blocks everything outside Norway.

One could remove the geo block or expand it to include all of Scandinavia, but that would open up all the other employees for unnecessary risk since the remaining users always work from within Norway.

So let’s keep Zero Trust and least privilege in mind and make a more surgical configuration of this geo block:

First, we create a named location for Scandinavia, consisting of Sweden and Denmark (Norway is allowed so no need to include it).

Second, we create a dedicated Entra Security group with a corresponding name for the relevant accounts.

Next, we add a new Cond Access policies for sign-ins across Scandinavia, scoped to this new security group

Lastly, we add the new security group as exception to the default geo block Conditional Access

Now a subset of the employees can be joined to our new security group and then sign in from anywhere in Scandinavia without exposing the remaining users who still can only sign in from Norway. But this of course also means you need to find a way to secure this group, because any security group involved in Cond Access policies, can potentially pose a security risk.

My go-to solution in these situations is to use a Restricted Management Administrative Unit (Link) as this by default will prevent any changes to be made until either a role is explicitly delegated to the AU or the group is removed from it. Both which requires either Privileged Role Admin or Global Admin, meaning changes to the group requires much higher privileges than normal.

And that was part 2….

Geo filters aren’t about locking down everything, they’re about smart control. Start with block‑by‑default, layer in named locations, and keep the allowed locations secured with MFA, managed devices etc. Do that and you’ll cut risk without slowing down your coworkers.

In Part 3 we’ll tackle exceptions head‑on. This is probably the most difficult part of geo.block for many organizations out there, and I will demonstrate how to allow them without poking holes in your Zero Trust posture. Expect practical patterns for balancing flexibility with good security.