Blocking Sign-Ins by Country with Conditional Access and Named Locations

Most of the failed sign-ins in a typical tenant come from places no member of staff will ever legitimately be: automated credential-spray and password-spray attempts rattling through username lists from wherever the attacker has rented infrastructure. You cannot stop people trying, but you can stop those attempts from ever reaching a successful sign-in, and in doing so you strip out a large slice of the background noise in your sign-in logs. That leaves you free to concentrate on the threats that matter more, the ones coming from inside your own region and harder to tell apart from real activity. This guide covers a country-based blocking design in Microsoft Entra that does exactly that, and gives you a clean, repeatable way to let a genuine traveller through without weakening the block for everyone else.

A note on what this is and is not. Country blocking is attack-surface reduction, not a hard security boundary. It raises the cost and cuts the volume of opportunistic attacks, but it is built on IP geolocation, which is imperfect, so it belongs alongside multi-factor authentication and device compliance rather than in place of them. Treated that way, it is one of the highest-value, lowest-effort controls you can put in.

How the Pieces Fit Together

The design has three parts that work together:

• Named locations in Entra, one grouping the countries you consider highest risk, another grouping a second tier of countries you also block but are willing to open up for a specific person when there is a reason.
• Two Conditional Access policies, each blocking sign-in from one of those named locations.
• A manually maintained country list, kept in three columns, that is the human-readable source of truth for which country sits in which tier. This is where you make decisions; the named locations are just the enforcement of those decisions.

The two tiers are doing real work. The top tier is the hard line: nobody signs in from those countries, ever, no exceptions. The second tier is also blocked by default, but it is the tier you use to grant temporary, tracked access to one person when they genuinely need it, without ever having to open a hole in the top tier.

The Country List: Your Source of Truth

Before touching Entra, keep a simple list in whatever your team uses for documentation. Three columns:

How you populate the two blocked tiers is a judgement call based on your own workforce. The usual approach is to block countries where no member of staff lives or would normally sign in from, chosen so that day-to-day nobody is affected, while accepting that people do sometimes travel to, work from, or transit through those places, which is what the exception workflow is for. Countries move between High Risk and Medium-High Risk over time as circumstances change. The Not Risk Categorised column barely changes once you have set the other two.

Building the Two Named Locations

Named locations live in the Microsoft Entra admin center under Entra ID, Conditional Access, Named locations. You need at least the Conditional Access Administrator role. Create two country-based locations:

1. Create a Countries location named for your High Risk tier. Choose to determine location by IP address (the practical choice for this design; the GPS option prompts users hourly and is meant for very sensitive apps only). Select the countries from your High Risk column.
2. Create a second Countries location named for your Medium-High Risk tier, and select the countries from that column.

There is one option worth a deliberate decision: Include unknown countries/regions. Some IP addresses cannot be mapped to a country at all. Ticking this box folds those unmappable addresses into the named location. For a block list this widens the net, catching traffic that cannot be placed, at the cost of occasionally catching a legitimate connection that happens to be unmappable. Decide it consciously rather than leaving it at the default.

Entra determines the country by resolving the sign-in's public IP against a mapping table it maintains. That detail matters for later, when we get to why this is not perfectly reliable.

Building the Two Block Policies

Each named location gets its own Conditional Access policy. The two policies are near-identical, differing only in which location they target. Build each one like this:

Test in report-only first

Report-only mode records what the policy would have done, blocking nobody, so you can watch the effect in the sign-in logs before it bites. Leave both policies in report-only for a day or two and review the Conditional Access tab of the sign-in logs. You are looking for any legitimate user who would have been blocked, which most often surfaces a traveller or a remote worker whose traffic appears to come from somewhere unexpected. Once the report-only results look clean, switch the policies to On.

Letting a Real Traveller Through

This is the core of the design, and the part that makes the two-tier structure worth the effort. Someone needs to sign in from a country that currently sits in your High Risk tier. The rule is absolute: you never open up a High Risk country. Instead, you use the Medium-High tier and a per-user exclusion, and the workflow is built so that reverting it is a forced step, not something left to memory.

To grant access

To revert, on their return

The elegant part is that moving the country back to High Risk is itself the forcing function. Because the country has to be returned to the top tier as part of closing out the request, the whole exception gets unwound as a unit: the country goes back behind the hard line, and the ticket that tracks it will not close until it has. It means a temporary exception is far less likely to quietly become permanent, which is the usual failure mode with access exceptions.

The Trade-Off Worth Knowing

While a user is excluded from the Medium-High block policy, that exclusion applies to the whole policy, so they can sign in from any country in the Medium-High tier, not only the one country they travelled to. This is a known and accepted trade-off in this design, and two things keep it bounded: the exclusion is time-limited by the ticket and its return date, and the country-move-back step ensures the exception is fully closed out rather than lingering.

If you ever have a case where that is not tight enough, for example a very high-value account where you want to permit exactly one destination country and nothing else, the tighter alternative is a separate, narrowly scoped policy for that person that blocks everything except their single destination, rather than excluding them from the broad block. That is more work per exception and more policies to keep track of, so it is worth reserving for the cases that truly need it rather than making it the default. For the everyday travel exception, the move-and-exclude workflow above is the pragmatic choice.

Geolocation Reality, and the APAC Problem

The whole design rests on Entra correctly working out which country a sign-in came from, and that is where honesty is required, because IP geolocation is only approximately right. It maps the public IP address of the connection to a country using a mapping table, and that mapping is wrong often enough to matter, particularly in the Asia-Pacific region.

The classic example is that some Japanese ISPs route traffic in a way that makes a user physically in Japan appear to be signing in from Singapore. Hong Kong connections can resolve as mainland China. Mobile networks backhaul traffic through gateways that can sit in a different country from the user. Satellite internet routes to whichever ground station is nearest, which may be across a border. VPNs, corporate proxies, and cloud egress all present the country of the exit point, not the user. The consequence cuts both ways: a legitimate user in an allowed country can be blocked because their traffic appears to come from a blocked one, and in principle an attacker in a blocked country can appear to come from an allowed one. This is precisely why country blocking is a noise-reduction control and not a boundary.

The practical workaround

What matters to Conditional Access is not where the user physically is, but which country their connection appears to originate from. That is a thing you can find out ahead of time. Have the user, from the exact connection they will be using (the hotel wifi, the office, the mobile hotspot), open any public "what is my IP" style service in a browser and read off the country it reports. That reported country is what Entra will see. Categorise the exception based on that, not on the pin in the map.

So if someone is travelling to a country in your High Risk tier but their ISP there consistently presents as a different country, you learn that in advance and can plan the exception around the country that actually shows up. It is not foolproof, because the exit point can change, but it is repeatable enough to be useful, and it turns a mysterious "why am I blocked" support call into something you can check and reason about.

How Fast the Block Takes Effect

In practice, blocking and unblocking take effect quickly. A fresh sign-in attempt is evaluated against the current policies, so within a minute or two of moving a country or changing an exclusion, new sign-ins see the new rule. For the everyday case of turning the block on, or letting a traveller through, it is effectively immediate.

The caveat is about sessions that are already established. Conditional Access re-evaluates continuously for some conditions, but country and region locations are not among the conditions it re-checks in near real time, and a token that has already been issued can remain valid until it expires. There can also be some propagation delay on policy and group changes in certain cases. So moving a country back into High Risk stops new sign-ins from it promptly, but it does not necessarily tear down a session that is already live.

If you need an existing session cut off immediately rather than at its next token refresh, do two things: revoke the user's sessions directly (from their profile in the admin center, or with the revoke sign-in sessions cmdlet), and consider adding a sign-in frequency control to the block policies so re-evaluation happens on a short cycle rather than the long default. For the common purpose of this design, cutting off the flood of new attempts, the prompt behaviour on fresh sign-ins is what matters, and the session caveat rarely bites. But it is worth knowing so nobody assumes a moved country instantly logs out someone already connected.

Documentation and Tracking

The workflow depends on good record-keeping, and it is light. For every active exception, keep a record that captures the person, the country, the reason, and the return date from their line manager. The tracking ticket is the natural home for this, and its return date is your out-of-band reminder to revert, independent of anyone remembering.

In your country list documentation, it helps to visibly flag any country that is currently in a moved state, with a note of which ticket moved it and when it is due back. That way, a glance at the list tells you not just the current tiers but which entries are temporary and owed a return. A country sitting in Medium-High Risk with a note saying it was moved for a specific person until a specific date is self-documenting; a country sitting there with no note is a prompt to go and find out why.

Two things are worth auditing periodically: whether any country has been left in the wrong tier, and whether any user exclusion has outlived its ticket. The audit logs record every change to a policy, including which country moved and which user was excluded, with the before and after values, so a periodic review against your open tickets will catch anything that slipped. The exclusion that was never removed is the one to watch for, because it silently leaves someone with broader access than intended.

A Note on Licensing

Conditional Access and named locations require Microsoft Entra ID P1 for every user in scope, which is included in Microsoft 365 E3 and Business Premium among others. The more advanced governance features that can automate exception expiry, such as access reviews and access packages, need P2 or Entra ID Governance. You can run the whole design described here on P1 with a manual workflow; the P2 features are an optional upgrade for automating the revert rather than relying on the ticket.

---

Quick-Action Checklist

The whole design in order. Each step links back to the detail above.

1. Write the three-column country list: High Risk, Medium-High Risk, Not Risk Categorised. This is your source of truth.
2. Create two country named locations in Entra, one per blocked tier. Decide the Include unknown countries option deliberately.
3. Create two block policies, one per named location, All users included, Block access, and break-glass accounts excluded from both.
4. Run both in report-only for a day or two. Review the sign-in logs for any legitimate user who would have been blocked, then switch to On.
5. To grant a traveller access: move their country from High Risk to Medium-High Risk, add the user as an exclusion on the Medium-High policy, and raise a ticket with a manager-supplied return date.
6. To revert: remove the exclusion, move the country back to High Risk (the forcing function that closes the exception), and close the ticket.
7. For unexpected blocks, have the user check what country their connection reports from that same connection with a public IP-checking page. The apparent country, not the physical one, is what Entra sees.
8. If you need an active session cut immediately, revoke the user's sessions directly; a moved country stops new sign-ins promptly but does not instantly end a live session.
9. Audit periodically against open tickets: any country in the wrong tier, and any exclusion that outlived its ticket.

Closing Thoughts

The value of this design is disproportionate to how little it takes to run. Two named locations, two policies, and a short workflow, and a large fraction of the opportunistic sign-in noise simply stops reaching you. The point is not that it is impregnable, because it is not, but that it clears the field: with the background spray filtered out, the sign-in activity that remains is more likely to be either real or a threat worth your attention, which makes everything downstream easier to reason about. You can leave it exactly as it is indefinitely, a quiet permanent reduction in noise, or once the logs are calmer and you can see clearly, use that clarity to build something more sophisticated on top, whether that is risk-based policies, tighter per-destination exceptions, or device-based controls. Either way, it earns its place from the first day it is switched on.

← All guides