Block Sign-ins from Risky Countries

If your business operates only in France and Europe, why accept sign-in attempts from the other side of the world? A large share of brute-force and credential-stuffing attacks originates from regions where you have no legitimate users. Microsoft Entra ID Conditional Access lets you close that door cleanly and in a documented way, without writing a single line of PowerShell.

The idea is simple: you define named locations that describe, by country or by IP address ranges, the areas from which your teams actually work. You then turn those locations into a condition inside a policy that blocks everything coming from elsewhere. The result is not a magic fortress, but a massive reduction in noise: fewer automated attempts reach your accounts, and your sign-in logs become far easier to read when you hunt for genuine anomalies.

In this article you will see how named locations work, how to build an allow-list approach (block everything except a trusted zone), which pitfalls to avoid (travel, VPNs, remote work), and why geo-blocking never replaces multi-factor authentication. Finally, we stress the safe deployment method: report-only mode first, break-glass account excluded second.

Understanding Entra ID named locations

A named location is a reusable object in Entra ID that groups together either a list of countries or regions, or one or more public IP address ranges (IPv4 and IPv6). Once created, it becomes available as a condition in any Conditional Access policy. You define it once and reuse it everywhere.

How the country is determined

For a country-based location, Entra ID determines the country in two ways. By default it uses the public IP address of the sign-in and matches it against a geolocation database. You can also enable determination by GPS coordinates, which relies on the Microsoft Authenticator app: during a sign-in, the app occasionally requests the device location. This method is more accurate but requires Authenticator and the user's consent.

• Public IP determination: fast and transparent, but bypassable with a VPN or proxy.
• GPS determination: more reliable about real position, but depends on Authenticator and the device location.
• 'Unknown locations' option: IP addresses the geolocation database cannot map to any country can be included in the location, so you can treat them as a separate zone.

Marking a location as trusted

IP-range-based locations can be marked as trusted. This is useful for your offices' outbound IPs: a sign-in from a trusted IP can lower the calculated risk and ease certain requirements. Country-based locations, on the other hand, cannot be marked as trusted, because a simple IP geolocation does not offer the same level of confidence as an address range you actually control.

Two strategies: block-list or allow-list

There are two ways to approach geo-blocking, and the choice changes everything from a security standpoint.

The block-list approach (avoid using it alone)

The block-list consists of creating a location that groups 'risky' countries and blocking sign-ins from them. It is intuitive but fragile: the world has roughly 250 countries and territories, and an attacker only needs to rent a server in a country you did not block to get through. You end up forever chasing a list that keeps growing.

The allow-list approach (recommended)

The recommended approach is the reverse: you create a location listing only the allowed countries (for example France and your European neighbours), then you block any sign-in that does NOT come from that location. You move from an 'everything is allowed except a few exceptions' posture to 'everything is blocked except what I explicitly allow.' It is the principle of least privilege applied to geography.

Explicitly allow the small number of countries you work from, rather than trying to block the vast majority you do not work from.

Building the rule step by step

Here is the concrete procedure to set up an allow-list blocking policy. Read all the steps first, especially the last two about deployment safety.

1. 1In the Entra admin center, open Protection > Conditional Access > Named locations, then create an 'Allowed countries' location listing only the countries your teams sign in from.
2. 2Decide whether to include unknown locations: in a strict allow-list logic, do not include them in the allowed countries, so they get blocked.
3. 3Create a new Conditional Access policy, for example 'Block outside allowed countries'.
4. 4Under Assignments, target all users, THEN immediately exclude your break-glass account and, ideally, a group of pilot administrators.
5. 5Under Conditions > Locations, include 'All locations' and exclude the 'Allowed countries' named location.
6. 6Under Access controls, select 'Block access'.
7. 7Set the policy to 'Report-only' mode and save: no sign-in is blocked yet, but everything is logged.
8. 8After a few days of observation in the sign-in logs, if no legitimate false positive appears, switch the policy to 'On'.

Pitfalls to know before you enable

Geo-blocking has real side effects on perfectly legitimate users. Anticipate them to avoid tickets and mid-meeting lockouts.

• Business travel: a colleague travelling outside the allowed countries will be blocked. Plan a temporary exception process or a 'travellers' group.
• VPNs and proxies: an employee who enables a VPN with a foreign exit point will appear to sign in from that country and be blocked.
• Remote and cross-border workers: employees living in a neighbouring country that is not listed may be affected. Add those countries if needed.
• Mobile networks: some carriers route traffic through gateways in another country, distorting geolocation.
• Services and automation: non-interactive identities or connectors may egress from foreign datacenters. Handle them with trusted IPs or targeted exclusions.

A classic mistake to absolutely avoid: applying the policy to all users without excluding a break-glass account, then locking yourself out of the tenant because you are travelling or a VPN is active. This is precisely what report-only mode and the break-glass account prevent.

Geo-blocking does not replace MFA

This is the most important point in the article. Country blocking reduces noise and the automated attack surface, but it does not prove the identity of the person. A determined attacker rents a server or VPN in an allowed country and bypasses geography entirely. Geo-blocking is a noise-reduction layer, not an authentication layer.

• Require multi-factor authentication for all users, administrators first.
• Combine it with Entra ID Protection's sign-in risk and user risk policies.
• Use geo-blocking to cut volume, MFA to verify identity, and risk signals to react to abnormal behaviour.
• Consider phishing-resistant methods (FIDO2 keys, Windows Hello) for sensitive accounts.

How AuPoint simplifies this deployment

Setting all this up manually means juggling several portal screens, understanding the include/exclude logic, and not forgetting a single safety step. AuPoint turns this process into a few clicks, in plain language, designed for SMBs and MSSPs who manage Microsoft Intune and Conditional Access without being full-time Entra experts.

• Ready-made templates for allow-list blocking, with the allowed countries to tick.
• Systematic report-only deployment first, with a built-in reminder to observe before enforcing.
• Break-glass account protection: AuPoint stops you from locking yourself out of your tenant.
• Plain-language explanations of every side effect, with no jargon and no PowerShell.

FAQ

Is country blocking enough to secure Microsoft 365?

No. It strongly reduces automated attempts and makes your logs clearer, but it does not verify the user's identity. It must always be combined with multi-factor authentication and, ideally, risk-based policies. Treat it as a noise filter, not an authentication barrier.

What happens to an employee travelling abroad?

If they sign in from a country outside your allowed list, they will be blocked. Plan an exception process in advance: a temporary 'travellers' group excluded from the policy, or adding the relevant country for a short period. Always test this scenario in report-only before enforcing to measure the real impact.

How do I enable a policy without risking a lockout?

Always deploy in report-only mode first to observe which sign-ins would be blocked, without actually blocking them. Systematically exclude a break-glass account that is subject to no geographic restriction. Only after several days of observation with no false positives do you switch the policy to 'On'.

Geo-blocking is one of the most cost-effective rules to put in place: little effort, immediate reduction of attack noise. With AuPoint you deploy this policy and your other Intune and Conditional Access protections in a few clicks, always report-only first and with your break-glass account protected. Discover how AuPoint makes Microsoft 365 security simple and safe for your business.