Lesson 37 — Microsoft Entra Named Locations and Trusted Networks
Microsoft Entra Named Locations allow administrators to define familiar network ranges and geographic regions that Conditional Access can use as sign-in context.
A named or trusted location does not prove that the user, device or session is safe. It only tells Microsoft Entra where the request appears to originate. VPN gateways, shared offices, proxies, mobile carriers and cloud services can place many different identities behind the same public IP address.
This lesson explains IP-based and country-based Named Locations, trusted network design, VPN and remote-worker scenarios, location-based Conditional Access policies, lifecycle governance and the Zero Trust principle that network location is context—not identity assurance.
What you will learn
This lesson explains how Named Locations support Conditional Access decisions and why recognised network context must never be mistaken for proof of trust.
Learning objectives
After completing this lesson, you should be able to configure, use and investigate Microsoft Entra Named Locations safely.
- Explain the purpose of Named Locations.
- Compare IP-based and country-based definitions.
- Understand what marking a location as trusted changes.
- Design location conditions in Conditional Access.
- Assess VPN, proxy, IPv4 and IPv6 behaviour.
- Investigate unexpected location matches.
- Govern location changes and stale IP ranges.
- Apply Zero Trust principles to network context.
The problem this solves
Organisations often need different access controls for corporate offices, approved VPN gateways, remote workers and sign-ins from selected countries or regions.
Named Locations provide reusable location definitions so those conditions can be applied consistently across Conditional Access policies.
Named Location evaluation flow
What are Named Locations?
Named Locations are reusable definitions of network or geographic context in Microsoft Entra.
They can represent public IP address ranges or selected countries and regions.
What they are not
Named Locations are not device identities, user authentication, network access control or proof that traffic is safe.
They provide one signal that Conditional Access can combine with other signals.
Named Location types
| Type | How it is defined | Typical use |
|---|---|---|
| IP-based location | Public IPv4 or IPv6 ranges | Corporate offices, datacentres, VPN gateways and known egress points |
| Country or region location | Selected geographic countries or regions | Country-based restrictions, monitoring or additional authentication |
| Trusted location | An IP-based Named Location marked as trusted | Policies that distinguish familiar corporate network context |
| Unknown location | No matching Named Location | Remote, mobile, new or unclassified access |
IP-based Named Locations
IP-based locations use the public address observed by Microsoft Entra, not the device's internal private address.
Define stable egress ranges that represent known network boundaries.
Public egress matters
Thousands of internal devices may appear to Microsoft Entra through one NAT gateway, firewall or proxy address.
The Named Location therefore identifies the shared egress point rather than each device behind it.
Office network flow
Country and region locations
Country-based locations use IP geolocation to estimate where a sign-in originates.
They can support broad geographic controls, but geolocation is not exact and may reflect a proxy, carrier or VPN endpoint rather than the user's physical position.
Geolocation limitations
Mobile networks, satellite services, privacy relays, corporate VPNs and cloud proxies can produce unexpected countries or regions.
Country blocking should therefore include testing, exception handling and monitoring.
IP versus country definitions
| Design factor | IP-based location | Country or region location |
|---|---|---|
| Precision | Matches configured network ranges | Depends on IP geolocation |
| Best suited to | Known offices, VPNs and egress gateways | Broad geographic policy decisions |
| Change frequency | Changes when ISP or network ranges change | Changes as geolocation databases update |
| Main risk | Stale or incomplete ranges | False geographic assumptions |
| Trust value | Recognised network context only | Approximate geographic context only |
Trusted Locations
An IP-based Named Location can be marked as trusted.
This label allows selected policies and identity-risk calculations to treat the location differently, but it does not convert every user behind that IP into a trusted identity.
Trusted does not mean safe
An attacker using a compromised office device, VPN credential or remote access session can appear from the same trusted public IP address as legitimate users.
Identity and device controls remain essential.
Location context versus assurance
| Signal | What it tells you | What it does not prove |
|---|---|---|
| Trusted location | The request came through a recognised IP range | That the user or device is legitimate |
| MFA | The user completed an additional authentication step | That the device is healthy |
| Compliant device | The device meets management policy | That the current session is risk-free |
| Low sign-in risk | No significant risk was detected at that time | That compromise is impossible |
| Authentication strength | A required class of method was used | That all post-authentication activity is safe |
VPN gateways
Users connected to a corporate VPN often appear from the VPN's public egress address.
If that address is trusted, every connected user may receive the same location context regardless of their physical location.
Split tunnelling
With split tunnelling, Microsoft 365 or SaaS traffic may bypass the corporate VPN and use the user's local internet connection.
The sign-in may therefore not match the VPN Named Location even though the VPN client is connected.
VPN evaluation flow
Remote workers
Remote workers frequently change public IP address and may use home broadband, mobile hotspots, hotels or customer networks.
Design policies around identity and device assurance rather than trying to maintain every remote address.
Contractors and shared networks
Contractors may connect through the same corporate VPN or office network as employees.
Use user, group, guest, device and authentication conditions to distinguish access requirements.
IPv4 and IPv6
A location definition that includes only IPv4 may not match traffic that exits through IPv6.
Inventory both address families and test real sign-ins from supported networks.
Dynamic addresses
Consumer and some business internet services can change public IP addresses.
Do not mark unstable ranges as trusted unless the organisation can maintain them accurately.
Common location-based policy patterns
| Policy pattern | Potential benefit | Design caution |
|---|---|---|
| Require MFA outside trusted locations | Reduces prompts on familiar networks | Weakens protection if trusted networks are compromised |
| Block selected countries | Reduces access from unsupported regions | VPNs and geolocation errors can affect legitimate users |
| Restrict administrators by location | Limits privileged access paths | Can cause lockout during emergencies or travel |
| Require compliant device outside office | Adds assurance for remote access | Guest and unmanaged-device workflows require planning |
| Monitor unfamiliar locations | Creates investigative context | Should be combined with risk and identity evidence |
Require MFA outside trusted locations
This pattern can reduce prompts inside recognised networks, but it should not become the organisation's only MFA policy.
Privileged users and sensitive applications often require MFA regardless of network location.
Country blocking
Country restrictions can support legal, business or threat-driven requirements.
Emergency access, travelling users, guest access, service traffic and VPN endpoints must be assessed before enforcement.
Privileged access
Do not rely on a trusted location to protect administrators.
Require strong authentication and appropriate device assurance even when the request originates from a corporate network.
Emergency access
Location restrictions can lock administrators out when networks change or service dependencies fail.
Protect and monitor emergency access accounts and exclude them only where required for recovery.
Named Location lifecycle
Change management
Public IP ranges may change during ISP migrations, firewall replacements, datacentre moves or VPN redesigns.
Network teams should notify identity administrators before the change reaches production.
Ownership and review
Every Named Location should have a technical owner, business purpose, source of truth and review date.
Unused or unexplained locations should be removed through controlled change.
Agent Foskett investigation: “The trusted office wasn't trusted.”
Investigation evidence
- User and workload Sign-in Logs
- Observed IP address and geographic location
- Named Location definitions
- Conditional Access policy results
- VPN and proxy routing configuration
- Device information and compliance state
- Authentication details and sign-in risk
- Audit history for location changes
Operational warning signs
- Trusted locations include broad ISP ranges.
- IPv6 ranges are missing.
- Old VPN gateways remain configured.
- Country blocking affects travelling users unexpectedly.
- Privileged MFA is skipped on corporate networks.
- Locations have no owner or review date.
- Sign-in IPs do not match network-team expectations.
Review checklist
| Review area | Question | Evidence |
|---|---|---|
| Purpose | Why does this Named Location exist? | Documented business and security requirement |
| Accuracy | Are all current IPv4 and IPv6 ranges included? | Firewall, ISP and VPN records |
| Trust | Should this range still be marked trusted? | Risk and architecture review |
| Policy use | Which policies reference the location? | Conditional Access inventory |
| Impact | Are legitimate and suspicious sign-ins classified correctly? | Sign-in Logs |
| Ownership | Who maintains the definition? | Named technical owner |
| Lifecycle | Can stale ranges or locations be removed? | Change record and review date |
Common mistakes
- Treating trusted location as trusted identity.
- Excluding all corporate traffic from MFA.
- Ignoring IPv6 and split tunnelling.
- Using dynamic consumer IP addresses.
- Blocking countries without testing VPN behaviour.
- Forgetting contractors and guests behind shared egress.
- Leaving stale network ranges in production.
Best practices
- Use stable public egress ranges.
- Document every location and owner.
- Include IPv4 and IPv6 where applicable.
- Test VPN and split-tunnel behaviour.
- Use report-only policies before enforcement.
- Keep privileged authentication independent of network trust.
- Review Sign-in Logs after every network change.
Key takeaways
- Named Locations provide reusable network and geographic context.
- IP-based locations match public egress addresses.
- Country and region locations depend on IP geolocation.
- A trusted location does not prove that the user or device is trustworthy.
- VPNs can place remote users and contractors behind the same address.
- Split tunnelling can bypass the expected VPN egress path.
- IPv4 and IPv6 must both be considered.
- Location policies require report-only testing and real Sign-in Log evidence.
- Privileged access should retain strong authentication regardless of location.
- Zero Trust treats network location as context—not assurance.
Related Agent Foskett resources
Continue learning
Microsoft Entra Named Locations and Trusted Networks
Microsoft Entra Named Locations define public IP ranges and geographic regions that Conditional Access can use when evaluating sign-in context, VPN access, trusted network definitions and location-based controls.
Microsoft Entra Academy Lesson 37 — Named Locations and Trusted Networks
This Agent Foskett lesson explains IP-based locations, country and region definitions, trusted locations, VPN gateways, split tunnelling, IPv4, IPv6, location policy design, monitoring and Zero Trust investigation.
