Identity Geofencing: Your Strongest Geofencing Defence

This is the final part of a three-part series on geofencing in modern enterprise network defence. Part 1 covered outbound traffic filtering. Part 2 examined inbound traffic filtering. 

Quick recap: Part 1 showed that outbound geofencing has limited value because attackers host infrastructure in Western cloud environments. Part 2 found that inbound geofencing works well for reducing automated scan noise but is easily bypassed by targeted adversaries. If those conclusions left you wondering whether geofencing has any real teeth, this is the part where the answer changes. 

Why Identity-Layer Geofencing Is Different 

When you geofence at the network layer, you're blocking packets based on IP addresses. When you geofence at the identity layer, you're evaluating the context of an authentication request before granting an access token to your critical systems, like Microsoft 365, CRM, financial platforms – everything that matters. 

That distinction is fundamental, because the vast majority of cyberattacks rely on credential theft. Phishing, infostealer malware, and credential stuffing all end the same way: an attacker with a valid username and password attempting to log in. 

Consider a practical scenario. A user in Sydney falls for a phishing attack and hands over their password and a captured MFA token. The attacker, operating from Eastern Europe, Southeast Asia, or a cheap VPS in North America, attempts to replay that session token. 

With a Conditional Access policy that restricts logins to Australia and New Zealand, that authentication attempt is blocked before the attacker even reaches MFA. The credential is compromised, but it's useless from an unauthorised location. 

Microsoft's own data supports this consistently. Enforcing MFA, disabling legacy authentication, and applying Conditional Access policies protects against 99.9% of automated attacks. Incident response reports from CERT NZ reinforce this point: organisations without geographic login restrictions are disproportionately represented among victims of password spraying and Business Email Compromise campaigns originating from overseas infrastructure. 

For organisations using Microsoft Entra ID, Okta, or any modern Identity Provider with Conditional Access capability, this is one of the highest-return security controls available. It's not expensive, it's not complex to implement at a baseline level, and it directly neutralises the most common attack patterns. 

The Recommended Approach For ANZ Organisations 

For most businesses operating in New Zealand and Australia, the geographic footprint of your workforce is predictable. Your staff live, work, and travel primarily within ANZ. That makes the baseline policy straightforward. 

Define your Named Locations in Entra ID as New Zealand and Australia. Create a Conditional Access policy targeting All Users across All Cloud Apps. Under Conditions, set Location to Any Location and exclude your trusted Named Locations. Set the Access Control to Block. 

That creates a default-deny perimeter for the rest of the world. Anyone attempting to authenticate from outside ANZ is blocked before they reach your environment. 

Setting this up requires careful planning to avoid breaking legitimate business processes, but the baseline itself is not complicated. The complexity sits in the exceptions, which is where most implementations either succeed or create friction. 

Handling Travel Exceptions Properly 

The most common reason IT teams hesitate to implement identity geofencing is executive travel. What happens when the CEO flies to Singapore or the Sales Director visits the UK? 

The answer is not to weaken the global policy. Handle travel through controlled exceptions. 

Create a dedicated Security Group; something like CA-Exclude-GeoBlock-Travellers. Exclude this group from your geo-blocking Conditional Access policy. When someone travels, they're added to the group. When they return, they're removed. 

The critical rule: never leave users in this group permanently. If you have Microsoft Entra ID Governance or Privileged Identity Management, configure the group to require eligible activation with a strict time limit, active for the duration of the trip and automatically revoked afterwards. 

While a user sits in the traveller group, they're exposed to global authentication attempts, so compensating controls matter. Require a compliant device through Intune enrolment. Enforce phishing-resistant MFA like FIDO2 keys or Windows Hello for Business, regardless of where they're logging in from. The geographic restriction is temporarily relaxed, but the authentication requirements should be tightened to compensate. 

The Blind Spot Most Organisations Miss: Enterprise Apps 

One of the biggest implementation pitfalls is misunderstanding how location-based Conditional Access policies interact with non-human identities and third-party integrations. 

In the Microsoft ecosystem, third-party SaaS integrations, API connections, and automated workflows like Power Automate, Zapier, and cloud-based HR systems syncing to Entra, often authenticate as Enterprise Applications using Service Principals. 

This creates a specific problem. Some Enterprise Apps authenticate independently using a Workload Identity. Standard Conditional Access policies scoped to "Users" won't govern these at all. Microsoft now offers Workload Identity Conditional Access to address this, but many organisations haven't implemented it yet. 

The more common issue involves delegated permissions. A user in Auckland authorises a third-party app to act on their behalf, connecting their mailbox to a CRM hosted in US-East, for instance. That CRM will continually request refresh tokens from a US IP address. If your Conditional Access policy strictly blocks user authentication from outside ANZ, the CRM's token refresh request gets blocked and the integration breaks. 

The fix isn't to weaken the policy. Before enforcing any geo-block, review your Entra ID Sign-in logs, specifically the Non-interactive and Service Principal sign-in tabs. Identify which Enterprise Apps authenticate from outside your Named Locations and create targeted Conditional Access exceptions for those specific applications, or route their integration traffic through trusted IP gateways. 

ANZ-Specific Issues To Watch For 

When rolling out identity geofencing in New Zealand and Australia, several localised nuances can catch teams off guard. 

Starlink and rural connectivity. Starlink IP addresses can occasionally route through Australian Points of Presence, making a New Zealand user appear to be logging in from Sydney. Including both NZ and AU in your baseline Named Locations prevents these users from being locked out. The same issue applies to in-flight Wi-Fi and eSIMs; depending on the provider, the point of presence may sit in another country entirely. 

Corporate VPNs and Zero Trust proxies. If your staff use a cloud-hosted VPN or a secure web gateway like Zscaler that routes traffic through a node outside ANZ, Entra ID will read the foreign IP and block the login. Your network routing and Conditional Access locations need to be aligned, or you'll generate a wave of legitimate access failures on day one. 

Apple iCloud Private Relay. This privacy feature on iOS and macOS obscures user IP addresses. It generally tries to keep the apparent IP in the same country, but edge cases can cause regional mismatches, leading to blocked logins on personal devices accessing corporate data via MAM policies. 

Impossible Travel as a safety net. If an attacker manages to bypass your ANZ geofence using a domestic residential proxy, the scenario we covered in Part 2, Entra ID's Identity Protection can still catch them. Impossible Travel detection flags the physical impossibility: if a user badges into the Auckland office at 9:00 AM and an authentication request arrives from Perth at 9:15 AM, the system demands a password reset or strict MFA. A well-run SOC service will be monitoring these signals closely. 

Wrapping Up The Series 

Across these three posts, the pattern is consistent. Geofencing at the network layer, both outbound and inbound, offers diminishing returns against modern threat infrastructure. Attackers operate from the same cloud providers and regions your business already trusts, and the bypass methods are trivial and cheap. 

Identity-layer geofencing is a different proposition entirely. It directly neutralises the bulk of automated credential attacks, Business Email Compromise, and password spraying campaigns by blocking authentication before it reaches your environment. For organisations in New Zealand and Australia, wrapping a geographic perimeter around your Entra ID or Okta tenant is one of the most effective and lowest-cost ways to reduce your attack surface. 

If you've read all three parts and haven't reviewed your own Conditional Access policies recently, that's a good place to start.