Diving into geo filter with Entra Conditional Access – Part 1

After a hectic few weeks and the NIC conference now behind me, it’s time to get back to blogging! 🥳

This will be the first part of a small blog series where I want to talk more in detail about using Conditional Access (CA) to simply block on signins from locations your users (almost) never will sign in from, aka “geo blocks“. It’s not because geo blocks are the best type of defense on it’s own (it’s really not), but it is for many a low-hanging fruit. It usually takes a very low effort to implement, and the result can be quite dramatic in some cases. In my customer work, I frequently see either no geo blocking in place or configurations that create blind spots and operational friction. The goal of this series is to highlight approaches to geo blocks that reduce friction and blind spots, while staying true to Zero Trust: assume breach, verify explicitly, and minimize blast radius. Let’s hope I manage to do that. 😉

Before I go on, I want to remind you that the perfect should not be the enemy of the good. Just because you can’t design the perfect geo block setup, it is not an argument to not implement a best-effort one.

Why geo blocks?

In Microsoft Entra, geo blocking is implemented through CA policies. Administrators can define “named locations” in Entra based on countries or IP ranges, and then use CA to apply rules that either block or require additional verification when a sign-in originates from outside those boundaries. For example, if your workforce is based in Norway (where I live) you can configure Entra to deny or challenge logins from regions where you know your users will never be. This uses the sign-in telemetry Entra already collects, allowing the system to evaluate the location of every authentication attempt in real time before granting access.

The benefit of geo block is twofold:

First, it cuts down the noise. Most automated attacks and credential‑stuffing attempts come from global botnets in regions that have nothing to do with your business. By blocking them at the perimeter, you stop them before they ever touch your apps or trigger alerts. It also takes the wind out of low‑effort attacks like password spraying and brute‑force floods, which overwhelmingly come from botnets and proxy networks far outside your approved geographies.

Second, it strengthens your Zero Trust posture. By narrowing the set of “expected” locations, you make it harder for attackers to blend in and easier for your security team to spot anomalies. The control is quick to set up, requires little ongoing maintenance, and delivers immediate, measurable impact. That makes it one of the most cost‑effective defenses you can add to your tenant. Still, like any other security measure, it should be seen as part of a broader, layered strategy. This is not a silver bullet that magically fixes everything!

Why not geo blocks?

Geo blocking has some serious limitations. Any dedicated attacker can breeze past country rules by tunneling through proxies or consumer VPNs that pop out inside your “allowed” region. An attacker can also just buy a SIM card registered in the same country as their target, making their traffic appear perfectly legitimate.

🚨If an attacker steals a valid session token, your location rules won’t stop them. The token is already trusted, so it “flies under the radar” until it’s revoked. This is why token protection and revocation policies are just as critical as geo‑based access controls.

Travel complicates things, too: With users connect from hotel Wi‑Fi or airline networks that resolve to unexpected geographies, and suddenly your “clean” policy creates real‑world friction.

Bottom line:

I’m not saying “don’t use geo blocks”! I’m saying treat them as a helpful filter, not an absolute truth. Always, always, always pair them with strong MFA, device compliance, session risk, and token protections, and HAVE A PLAN READY FOR EXCEPTIONS that feel humane for both travelers and admins. Otherwise, you’ll block noise and your users in equal measure. My hope is that this series about geo block will help you with that plan.

So how do I get started?

Getting started can be more difficult in some environments than others, because this is heavily affected by how your company operates. If your company operates in a single country and most travel is limited to one or a few destinations, geo blocking is straightforward: Define the expected geographies and block the rest. In contrast, multinational organizations or teams with frequent, wide‑ranging business travel face a tougher design challenge. You’ll need broader allow lists, clearer exception paths, and tighter guardrails to avoid friction. This makes policy design, testing, and maintenance significantly more complex.

As always: Start by collecting the relevant information and then use it to start designing something which can work. This is an example:

• Which countries are we physically located in (offices, datacenters, subsidiaries)?
• Do we have VPN solutions which allows users abroad to bypass geo blocks?
  • If so, how protect it from misuse?
  • What about the mobile devices?
• Do we have contractors, partners, or vendors who sign in from outside those countries?
  • Are these guest accounts which can easily have another set of policies?
• Are there cloud services or automation accounts that originate from specific regions?
• How many employees regularly travel abroad for work?
• Is travelling abroad limited to a specific department or other subset of the company?
• Which countries do they typically travel to, and how often?
• Are these trips usually planned well in advance, or do last‑minute changes happen often?
• Do we have employees who live in one country but work for a team based in another?
• What’s the business impact if a legitimate user is blocked while traveling?
• How will we monitor and adjust policies as travel patterns or business operations change?
• How does geo blocking complement our other controls (MFA, device compliance, session risk)?
• Do we have visibility into sign‑in telemetry to validate that our assumptions about “normal” locations are correct?

Allowlisting vs Blocklisting

Before you start, agree on this foundational choice: allowlist or blocklist. It shapes every policy decision that follows.

• Allowlisting: Block all countries by default, then explicitly allow only the specific countries where your users are expected to sign in. This is widely recognized as the stricter, more secure approach because it minimizes the attack surface
• Blocklisting: This is the opposite approach. The default is allow all, and you selectively block countries you consider high‑risk or irrelevant. This is easier to set up initially but harder to maintain, since attackers can pivot through unblocked regions.

Allowlisting is generally the stronger, more predictable approach because it narrows the “allowed” surface area and reduces assumptions about what’s safe. It also aligns more cleanly with Zero Trust by default-denying access and requiring explicit verification for what’s permitted: assume breach, verify explicitly, and minimize blast radius.

Blocklisting’s primary advantage is that it is much easier to deploy in global or highly mobile organizations. It can also provide less friction for users who travel widely or your users constantly travel to many different counties.

Geo block vs VPN/GSA

VPNs and secure access gateways are all about how you connect. They check who you are, whether your device is healthy, and then give you a secure tunnel into company resources. Think of it like a guarded door: Once you’re allowed access inside, the guard makes sure you follow the rules and only go where you’re supposed to go.

Geo blocks, on the other hand, are about where the attempt is coming from in the first place. They look at the country or region of the sign‑in and can stop it right there if it’s not on the “allowed” list. That means a botnet in another part of the world, or someone trying stolen passwords from a random café Wi‑Fi, never even gets to “knock on your VPN/gateway door”. So the gateway manages the secure path once you’re in, while geo blocks cut down the noise by deciding which knocks on the door are worth answering at all.

Stay tuned for the next part

In the next post, I’ll shift from the “why” to the “how” and get into the nuts and bolts of geo‑blocking. Things like setting up named locations, building allowlist/blocklist conditional access policies, and scoping them to the right apps and groups as a solid default.

Then, in part 3, I’ll tackle the messy but unavoidable part: Handling exceptions. We’ll look at how to safely open things up when specific needs arise, and how to do it in a way that both end users and admins can actually live with. At the end of the day, it’s about having a plan that balances security with practicality.

In the meantime, I suggest you start thinking about your environment and how a geo-block could fit in. Do you operate within a single country? Do you have users who frequently travel abroad? Begin drafting how this approach could enhance the security of your tenant. Remember: Don’t let perfect be the enemy of good. Any progress is better than none.