Most MSPs I talk to have a Conditional Access policy that blocks “high-risk countries”. They built it once, switched it on, and never looked at it again.
Then they sleep well at night.
That’s the problem.
A country block on its own is theatre. The attacker is on a VPN egress inside a country you allow, or a residential proxy, or a mailbox client that already has a refresh token. Named locations are useful — but only if you understand what they actually do, and where they fall down.
What is a named location, really?
A named location is a label. That’s it.
You’re telling Entra ID, “this IP range is my office”, or “these countries are where my staff actually work”. The location doesn’t enforce anything on its own. It’s a building block you then reference inside a Conditional Access policy.
The policy does the work. You decide whether to block, require MFA, or skip a control. The location is just the where.
And here’s the bit that bites people. Location is evaluated after first-factor authentication. The password’s already gone. Conditional Access then decides what happens next. Treat named locations as a layer, not a perimeter.
Step-by-Step: Setting up a country block that actually earns its keep
Portal path only. Report-only first — non-negotiable.
Open Named locations
Sign in to the Microsoft Entra admin centre as a Conditional Access Administrator. Go to Protection > Conditional Access > Named locations.
Create a Countries location
Click + Countries location. Name it something obvious — “Allowed countries — AU only” beats “Country Block 1”. Pick the country (or countries) where your staff actually sign in. Tick Include unknown areas if you want the location to also catch IPs the geo-database can’t classify. I leave that off for allow-lists and on for block-lists. Save.
Create the policy
Go to Policies > New policy. Name it. Under Users, pick All users — then exclude your break-glass accounts. Always. Under Target resources, pick All resources.
Set the network condition
Under Network, set Configure to Yes. Include Any network or location, then under Exclude select Selected networks and locations and pick your “Allowed countries” entry. That gives you “block everything outside my country”.
Grant
Under Access controls > Grant, choose Block access.
Switch to Report-only and review
Set Enable policy to Report-only. Create. Then watch the sign-in logs for at least 48 hours. The report-only results tell you exactly which users would have been blocked. Anyone surprising in there? Investigate. Then flip the policy on.
Why this actually changes behaviour
Here’s the real win. Once you’ve got clean named locations, every other CA policy gets sharper.
The “skip MFA from a trusted location” pattern — careful with that. Marking your office public IP as trusted feels like a productivity gift to users. It’s also the exact thing an attacker on your guest Wi-Fi or a compromised contractor on your VPN will piggyback. My recommendation? Don’t mark anything as trusted unless you have a strong reason and you’ve documented it. Use sign-in frequency and authentication strength to soften MFA friction instead.
“But our staff hate MFA prompts in the office.” Then fix the prompts. Don’t punch a hole in the wall.
The other classic trap is the corporate VPN. If everyone egresses through one public IP in a country you’ve blocked, you’ve just locked your own staff out. Map your VPN exits before you write the policy. Read the network assignment conditions before you write the policy, not after.
Notice what’s missing from all of this? PowerShell. You don’t need it. The portal does the job, and the audit trail is clearer.
A country block doesn’t stop attackers. It thins the noise so the rest of your stack can do real work. If you’re not showing your clients this — and explaining why “trusted location” is a loaded word — you’re leaving security maturity on the table.
That’s the job. Use named locations for that, and not for the warm feeling a checkbox gave you.
CIAOPS 