Diving into geo filter with Entra Conditional Access – Part 3

In part 1 we talk about the “why” of geo filters in Entra, and in part 2 we covered the “how” of building the foundation. All of this with Zero Trust in mind, and focusing on reducing the attack surface where we can.

Here in part 3 we will cover what I believe is a major reason geo filter saren’t as secure as they could be: The exceptions!

When I work with customers, I’m often met with skepticism about blocking access, because many imagine scenarios where users are blocked from signing in and can’t do their job. Meaning urgent calls to the IT helpdesk which already have enough on their plate. This can lead to more noise and less productivity, and I strongly suspect it’s a key reason many don’t deploy geo filters in their Entra environment. To be honest I can understand their point and I know a lot people think about the different edge cases. These may seem insurmountable, and so the end result is often a semi-good filter with tons of exceptions. The typical reasoning sounds like: “But what if someone is abroad and wants to check email?” or “We have frequent travelers and can’t manually add every country.“

Handling exceptions

❗Let’s stick with the example in part 2 (link at the top) where we imagine we’re a company in Norway, most employees work from within Norway and a select few are signing in from different places across Scandinavia.

While Adele would normally sign in from Norway, the company policy is that sign-ins from outside Norway are blocked by default. (Yes, you should inform your employees about this). This means that Adele needs to make sure she can access her work-resources while travelling.

Scenario: Adele will travel to the UK for a week for a work-related assignment

How can Adele make sure she can sign in from UK while travelling?

• Ticket to IT helpdesk? Sure they can always create an exception from the Geo filter in Conditional Access (CA).
  • But who is going to remove that access after the travel is complete? In real-life, that will very likely not happen as manual follow ups on group memberships tend to slip. So we end up with huge gaps in the protection from geo filters after a while.
  • Are they going to add manual exceptions for every employee during vacations and holidays?
  • In other words, this approach won’t work.
• Ask her manager? They normally don’t have privileged access in the tenant and can’t do anything except go to IT and then we’re back to adding manual exceptions. Relying on IT or managers to add and remove exceptions for every trip is inefficient and error‑prone. So no, not a good idea either.

We know from part 2 that all countries are blocked by default and we have exceptions for Norway (to all employees) and Scandinavia (for the sales department). We can expand this setup with more countries very easily like this:

Each exception consists of three items:

1. An exception from the “block-all-but-Norway” CA policy, which is the default geo block.
2. A dedicated Entra security group: Excluded from the “block-all-but-Norway” default CA policy, and in scope for the new “Norway and UK” CA policy.
3. A dedicated Entra security group which
   • The “block-all-but-Norway” default CA policy is excluded from.
   • The new dedicated “Norway and UK” CA policy is scoped to (in this example).

In layman’s terms: It all comes down to group membership. If you’re in the group, you can sign in from Norway and the UK. Once you’re removed, you’re back to Norway only.

Perfect! We have a simple way to grant access without disabling geo filter protection. Now how do we add or remove users from these exception-groups in a timely manner without burdening the IT staff or delegate privileged roles all over? 🤔

🥳 Easy: Set up Entra Access Packages to manage membership in these groups!

Entra Access Packages to the rescue!

If you are unfamiliar with Entra Access Packages, it is a P2-feature in Entra ID Governance which allows you to assign access to Security groups, SharePoint Sites, Teams and other resources. The access can be permanent or temporary, with or without approval and renewal.

So in our scenario: Entra Access Packages let you wrap governance around these exception groups so that travel access is self‑service, time‑bound, and auditable. In practice, the employee who is travelling (Adele) requests the “Norway + UK” package, their manager or IT approves it, and Entra entitlement management automatically adds them to the right security group. Crucially, the package has an expiry date, so once the trip is over the user is removed automatically, no one needs to remember. You can also configure renewals, multi‑stage approvals, and access reviews, which means exceptions are granted only when justified and are automatically cleaned up afterwards. This eliminates the manual burden on IT, prevents lingering exceptions, and ensures your geo filter policies stay aligned with Zero Trust principles.

Another big win with this setup is how easy it is to plug into routines people already follow. If you’re heading abroad for work, chances are you already know where to book flights, hotels, and fill out travel forms. Just add “request IT access from abroad” to that list, nice and simple. Same goes for vacations. Most folks have to register their time off anyway, so why not have them (or their manager) request access for the time and countries they’ll be visiting while they’re at it?

Now, I’m not entirely sure why some people feel the need to check email and Teams while they’re supposed to be relaxing, but for many it seems non-negotiable. And with Access Packages, at least it’s easy to accommodate without bothering IT and provide surgical exceptions in the security design.

And finally, what about admins? Sure, an admin with the right privileges can simply drop someone into the exception group or add them as a direct exception to the CA policy. Technically, that works. But here’s the catch: Doing this completely defeats the purpose of using Access Packages. It’s a manual workaround that also means another manual step later to clean things up. That’s why it’s so important to make sure your IT team understands the value of sticking with the Access Package process once it’s in place.
Access Reviews can help here too,but that’s a topic for another post. 😉

Setting up Entra Access Packages

Entra resources

First set up the resources needed. In Entra admin portal we first define UK as a named location as we did in part 2. Then we create a security group for the UK exception in the geo filter.

Then we add the security group to the exception of the CA policy which makes the default geo filter.

Lastly, create a new CA policy that allows sign-ins only from Norway or the UK, and scope it to the new security group. And this should absolutely be combined with MFA requirements, compliant devices etc etc. Remember: Your security should consist of many layers!

Now the setup is that group membership dictates whether you can sign in from just Norway or Norway and UK. This is where we want to be when switching over to Entra Access Packages.

Making resources available with Entra Access Packages

A quick overview for the readers who aren’t too familiar with Access Packages.

• Resources: Security groups, SharePoint sites, Teams, and apps are added to a catalog.
• Catalog: A container that organizes resources. One catalog can hold many resources.
• Access package: Bundles resources from a catalog and makes them requestable to users.
• Policy: Defines the conditions for getting the package.

Our plan: Put group(s) in a catalog → put catalogs in an access package → govern access with a policy.

With this setup, users can self‑serve travel exceptions with approvals and automatic expiry. No manual clean‑up or delegation of privileged access needed.

Creating an Access Package for Norway+UK access

First step: The catalog

In Entra, navigate to Entitlement Management, select Catalogs and create a new catalog by giving it a name and description.

Now click on the new catalog, select “Resources” and “Add resources“, and on the next screen select “+ Groups and Teams” and add the security group used in the Norway+UK CA policy.

Second step: The Access Package

Still under Identity Governance, select “Access packages” and “New access package“.

Under “Basics”: Add a name and description of the access package. Also, select the correct catalog below.

Under “Resource roles“: Select “+ Groups and Teams” and add the correct group. “Select “Member” as the role (on the right side).

Under “Requests“:

• Users who can request access: For users in your directory
• Select specific scope: Specific users and groups
• Select users and groups: Here I select a group for all ordinary employees.
• Approval: Select your preferences for approvals. In this example I go for:
  • Require approval: Yes
  • Require requestor justification: Yes
  • How many stages: 1
  • First approver: Manager as approver
    • Make sure you select a fallback approver, this is for users where the manager is not defined.
  • Decision must be made in how many days?: 14
  • Require approver justification: Yes
• Enable
  • Enable new requests: Must be checked, or the package is unavailable.
  • Allow managers to request on behalf of employees: Yes, this is really useful in some scenarios

The remaining settings are just personal preferences

Requestor information is used to collect information or attributes, we will skip in this demo.

Under Lifecycle: We set the assignment to be maximum 14 days, specific timeline and without extending.

Custom Extensions: Skip for now.

Review and Create: Fix any issues you may find here and click “Create” when ready.

The access package is now created and visible to assigned users. There is also a direct link available you can give to the end user if needed.

Self service the access package

End users can find access packages at myaccess.microsoft.com, and in this example, Adele can simply click on the request button to the right.

The user follows the wizard and specifies start and end dates (up to 14 days, as configured).

Now, Adele’s manager can see her request at myaccess.microsoft.com, and here the request can be easily approved or rejected with a couple of mouse clicks. Then Entra handles the rest and Adele can sign in from Norway and the UK within the specified time period.

Manager-assigned access packages

A practical advantage here, which requires Entra ID Governance license, is manager‑initiated access. If someone forgets to request travel access, a manager can request or assign the relevant access package on their behalf and the exception applies immediately.

It also covers unplanned situations: Say an employee is on vacation and a critical incident pops up. Their manager can grant temporary access to email and files without waiting on IT. Because access packages enforce approvals, expiration, and access reviews, exceptions stay time-bound and auditable. This aligns perfectly with Zero Trust: Access is granted only when needed, only to the right person, and only for the right duration. No standing permissions, no implicit trust.

😍 Very, very cool stuff!

Seems like a lot of work? Good thing we have PowerShell!

Of course we don’t want to spend hours clicking in a web interface, especially when we can have PowerShell do the job for us. 😉

Now this blog post is long enough already. So to avoid making it way too long, I have made a repository with Proof-of-Concept scripts for this whole process. Hopefully these will help you automate the setup without spending hours in the portal. They are as always provided “as-is” with no guarantees or support and you use them at your own risk.

Conditional Access:

1. POC-Add-CountryNamedLocation.ps1
   • Creates a country-based named location in Entra ID Conditional Access
2. POC-Add-CountrySecurityGroup.ps1
   • Creates a security group for Conditional Access exclusions
3. POC-Add-GroupToPolicyExclusion.ps1
   • Adds a security group as an exclusion to a Conditional Access policy
4. POC-Create-LocationAllowPolicy.ps1
   • Creates a Conditional Access policy that allows sign-in from specific locations for a security group

• POC-Deploy-CountryException.ps1
  • Orchestrates the complete Conditional Access setup (1-4) including named location, security group, and CA policies.

Access Packages:

1. POC-Add-AccessPackageCatalog.ps1
   • Creates an access package catalog in Entra ID Identity Governance
2. POC-Add-CatalogResource.ps1
   • Adds a security group as a resource to an access package catalog
3. POC-Add-AccessPackage.ps1
   • Creates an access package within a catalog
4. POC-Add-AccessPackageAssignmentPolicy.ps1
   • Creates a self-service assignment policy with approval workflow for an access package

• POC-Deploy-AccessPackageSetup.ps1
  • Orchestrates the complete access package setup (1-4) including catalog, resource, package, and policy creation

Details are in the README file – DO NOT USE IN PRODUCTION WITHOUT TESTING

Finishing up my posts on geo block

At the end of the day, geo filters are not about making life harder for employees, they are about making access safer and smarter. The real challenge has always been exceptions, and that is where Entra Access Packages shine. By turning special cases into governed, time‑bound requests, you protect your environment without drowning IT in manual work or leaving gaps in your defenses.

This approach keeps Conditional Access policies aligned with Zero Trust principles: Access is granted only when needed, only to the right person, and only for the right duration. No standing permissions, no lingering exceptions, no implicit trust. Employees gain the flexibility they need, managers stay in control, and IT can focus on strategy rather than firefighting.

Strong security does not mean saying no to exceptions; it means saying yes in a way that is safe, simple, and sustainable. That is exactly what this model delivers.

Thank you so much for reading through my 3 blog posts about geo filters. I hope this was useful and inspiring and perhaps even you found some inspiration to your Entra security settings.

Take care!