Most organisations no longer work from one fixed office, one trusted network or one type of device. Users sign in from home, hotels, customer sites, mobile networks and sometimes from countries where the business has no reason to expect any activity.

That flexibility is useful, but it also creates risk. If your organisation only operates in the UK for example, a sign in attempt from a country you do not trade with should raise questions. This is where location based Conditional Access in Microsoft Entra ID can help.

A location based conditional access policy lets you control access to cloud apps based on where the sign in appears to come from. One common use case is blocking access from countries or regions where your users should not be signing in.

What location based Conditional Access does

Location based conditional access uses network location as one of the signals in an access decision. That location can be based on named countries/regions or specific IP ranges.

Eg. An organisation may decide that users should only be able to access Microsoft 365 services from the UK, Ireland and a small number of approved travel locations. Any sign in from outside those areas can be blocked automatically.

This does not mean location based access control is perfect. IP addresses can be masked, routed through other locations or reported incorrectly. Users may also travel for legitimate reasons. Because of this, location blocking should be treated as one layer of protection rather than a complete security strategy. There should also be a clear process in place within the company for users who travel for business, holidays or personal visits to other countries. If access to company resources is required during this period, it should be granted only with prior approval and monitored appropriately.

A key point many people miss

Conditional Access policies are enforced after first-factor authentication is completed.

That means the user still needs to enter their username and password first. Only after that first authentication step does Microsoft Entra ID evaluate the conditional access policy and decide whether to allow or block access.

This matters because conditional access is not designed to be the first line of defence against attacks such as denial of service (DoS) attempts. It can help reduce risk after authentication begins, but it should sit alongside other controls such as strong passwords, multifactor authentication , identity protection, monitoring and good account hygiene.

Named locations

Before you can block a location, you need to define it as a named location.

  • In the Microsoft Entra admin centre , named locations can be created using either countries and regions or IP ranges. Countries and regions are useful when you want a broad rule, such as blocking access from countries where your company does not operate. IP ranges are useful when you want to define known office networks, VPN ranges or other trusted network paths.

  • When using IP ranges, you can also mark a location as trusted. This can be useful for known corporate networks, but it should not be done casually. A trusted location becomes an important part of your access logic, so it needs to be accurate and maintained.

  • There is also an option to include unknown areas when using countries and regions. This is worth considering because not every sign in location can be identified cleanly. Blocking unknown areas may improve security, but it can also create support issues if legitimate traffic is affected.

This policy could apply to all users and all cloud apps, with emergency access accounts excluded. The team would first run the policy in “report-only mode”, review the impact, then enable it once you are confident it will not block legitimate users.

Why report-only mode matters

Blocking access by location sounds simple, but mistakes can be painful. A badly scoped policy can stop users, administrators, service accounts or critical processes from working.

That is why report-only mode is important. It lets you see what the policy would do before it starts enforcing the block. This gives you time to check sign in logs, confirm the affected users and spot any unexpected behaviour.

A location block should not be switched on without reviewing the impact first.

Accounts you should exclude

Microsoft recommends excluding emergency access accounts (break glass accounts) from conditional access policies. These accounts are there for recovery if administrators get locked out because of a policy mistake or wider identity issue.

You also need to think carefully about service accounts and service principals. Some older scripts or backend processes may still rely on non-interactive accounts.

This is where many location blocking policies go wrong. The technical policy is easy to create. The hard part is understanding what depends on the accounts you are about to restrict.

A sensible implementation approach

Start by confirming the business requirement. Do you want to block specific High-risk countries or allow only approved countries?

Then create the named location in Microsoft Entra ID . Build the conditional access policy with clear naming, sensible exclusions and the right target resources. For most broad location blocks, organisations usually target all users and all cloud apps, while excluding emergency access accounts and other approved accounts.

Set the policy to report-only mode first. Review the sign in logs and policy impact. If the results look clean, move the policy to on and monitor closely after the change.

This should be carried out in line with the company’s change control process.

This is also a good time to make sure administrators know what to check if a user suddenly cannot access Exchange Online , SharePoint Online , Microsoft Teams or other Microsoft 365 services.

Conclusion

Blocking access by location is a practical way to reduce unnecessary risk in Microsoft Entra ID. It is especially useful when your organisation knows where users should and should not be signing in from.

The key is to implement it properly. Define the locations carefully, exclude emergency access accounts, test in report-only mode, review the impact, then implement the policy in line with the company’s change control process.