# Named locations are configured

Without named locations configured in Microsoft Entra ID, threat actors can exploit the absence of location intelligence to conduct attacks without…

Source: https://maester.dev/docs/tests/ZTA.21865

<!-- This file is generated by website/scripts/generate-test-docs.mjs. Do not edit manually. -->

:::note[Maester checks this too]
[CIS.M365.5.2.2.14](/docs/tests/CIS.M365.5.2.2.14) (Ensure trusted 'named locations' are defined) checks the same setting. Running both reports it twice.
:::

## Overview

Without named locations configured in Microsoft Entra ID, threat actors can exploit the absence of location intelligence to conduct attacks without triggering location-based risk detections or security controls. When organizations fail to define named locations for trusted networks, branch offices, and known geographic regions, Microsoft Entra ID Protection can't assess location-based risk signals. Not having these policies in place can lead to increased false positives that create alert fatigue and potentially mask genuine threats. This configuration gap prevents the system from distinguishing between legitimate and illegitimate locations. For example, legitimate sign-ins from corporate networks and suspicious authentication attempts from high-risk locations (anonymous proxy networks, Tor exit nodes, or regions where the organization has no business presence). Threat actors can use this uncertainty to conduct credential stuffing attacks, password spray campaigns, and initial access attempts from malicious infrastructure without triggering location-based detections that would normally flag such activity as suspicious. Organizations can also lose the ability to implement adaptive security policies that could automatically apply stricter authentication requirements or block access entirely from untrusted geographic regions. Threat actors can maintain persistence and conduct lateral movement from any global location without encountering location-based security barriers, which should serve as an extra layer of defense against unauthorized access attempts.

## Remediation

- [Configure named locations to define trusted IP ranges and geographic regions for enhanced location-based risk detection and Conditional Access policy enforcement](https://learn.microsoft.com/entra/identity/conditional-access/concept-assignment-network?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci)

## Run it

The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:

```powershell
Install-Module ZeroTrustAssessment -Scope CurrentUser
Connect-Maester
Invoke-Maester -Pack ZTA -SkipBuiltIn
```

Leave out `-SkipBuiltIn` to run Maester's own checks in the same run.

<details>
<summary>About this check</summary>

| | |
| --- | --- |
| Severity | Medium |
| Effort to fix | Low |
| Impact on users | Low |
| Pillar | Identity |
| Category | Application management |
| Product | [Entra ID](/docs/tests/products/entra) |
| Feature | Conditional Access |
| Area | Access control |
| ATT&CK | [T1078.004](/docs/tests?mitre=T1078.004) Cloud Accounts |
| Licence | P1 |
| Tenant | Workforce, External |

Product, feature, area and ATT&CK are Maester's: the assessment does not record them, so Maester keeps them in the pack's `taxonomy.json`.

</details>

<p class="mt-ms-note not-content"><svg class="mt-ms-note__logo" viewBox="0 0 21 21" aria-hidden="true"><rect width="10" height="10" fill="#f25022"/><rect x="11" width="10" height="10" fill="#7fba00"/><rect y="11" width="10" height="10" fill="#00a4ef"/><rect x="11" y="11" width="10" height="10" fill="#ffb900"/></svg><span>A Microsoft check, part of the <a href="/docs/tests/packs/zero-trust-assessment">Zero Trust Assessment</a> pack. Text from ZeroTrustAssessment 3.1.0, © Microsoft, <a href="/docs/tests/packs/zero-trust-assessment#licence">MIT licence</a>.</span></p>
