Network truth
Map each office, data center, VPN, proxy, SD-WAN, secure web gateway, cloud NAT, mobile carrier, and disaster-recovery path to the public address Microsoft Entra actually observes.
Microsoft Entra network-signal governance
Microsoft Entra Named Locations Governance Guide
Turn IP ranges, countries, VPNs, proxies, and trusted-network designations into governed Conditional Access evidence—not permanent assumptions about where a person, device, or workload really is.
Governance objective
Use location as one contextual signal—not proof of identity, trust, or physical presence
Microsoft Entra named locations are reusable objects consumed by Conditional Access and other identity features. They can represent public IPv4 or IPv6 ranges, countries or regions resolved from IP, geography reported through supported GPS workflows, or network signals from Global Secure Access. The result is useful context, but it is not a substitute for strong authentication, device health, user risk, application sensitivity, or incident investigation.
Policy truth
Record every Conditional Access, Identity Protection, B2C, sign-in review, or automation dependency that includes, excludes, trusts, or reports the named location.
Lifecycle truth
Assign an owner, authoritative source, validation procedure, ticket workflow, expiry, exception process, evidence repository, review cadence, and rollback plan.
Boundary: a trusted location is not a trusted user or device. Credentials can be stolen and used from an office, compromised endpoints can connect through corporate egress, and VPN or proxy paths can make remote users appear internal. Keep authentication strength, device, risk, and workload controls independent.
Location types and limits
Know exactly what Microsoft Entra evaluates
| Location type | What Entra evaluates | Key limitations | Required evidence |
|---|---|---|---|
| IPv4 or IPv6 CIDR ranges | The public client address presented to Microsoft Entra is matched against one or more configured ranges. | Use public egress, not private endpoint addresses. Microsoft documents no more than 195 named locations, 2,000 ranges per location, and only CIDR masks greater than /8. | ISP or cloud allocation, NAT/proxy design, route owner, both address families, effective date, policy consumers, sign-in sample, and change ticket. |
| IP-based country or region | Microsoft resolves the observed IPv4 or IPv6 address using a periodically updated country/region mapping. | Geolocation is best effort. Mobile carriers, VPNs, CDNs, and centralized gateways can appear far from the user. Borders and mapping data change. | Expected countries, business presence, remote-work patterns, VPN exits, mobile tests, false-positive history, unknown-region decision, and review date. |
| GPS-based country or region | Supported Microsoft Authenticator workflows can provide a device’s GPS country/region for location evaluation. | Requires supported Authenticator behavior and MFA push; passwordless-only use is insufficient. Users may be prompted hourly. Use only where the experience fits highly sensitive access. | Supported methods/platforms, privacy and legal review, user communication, pilot results, prompt frequency, accessibility, support procedure, and fallback. |
| Unknown countries/regions | Addresses Microsoft cannot map can be included in a geographic named location. | Excluding unknown areas can create a blind spot; including them in a broad block can disrupt legitimate traffic. The choice must match policy intent. | Observed unknown events, applications, user population, ISP/VPN source, risk, disposition, exception criteria, monitoring, and tested result. |
| Trusted IP location | An IP-based named location can be marked trusted and used by Conditional Access and risk calculations. | Trust affects more than one policy and can reduce perceived sign-in risk. A trusted range cannot be deleted until the trusted designation is removed. | Business justification, security controls, address custody, attack-path review, Identity Protection impact, policy dependency, approval, and expiry. |
| Global Secure Access network | Conditional Access can use compliant-network and traffic-forwarding signals when the Microsoft Security Service Edge integration is configured. | Without appropriate signaling, Microsoft Entra can see the proxy egress rather than the original source; location and risk detections may lose fidelity. | Traffic profile, connector/client state, source preservation, sign-in fields, network compliance, proxy path, failure behavior, and operations owner. |
Authoritative inventory
Build a location register that a network engineer and identity analyst can both defend
Identity
Object ID, display name, type, trusted flag, creation and modification time, creator, change ticket, environment, and business purpose.
Address source
IPv4/IPv6 CIDRs, countries, unknown handling, GPS method, GSA signal, ISP or cloud provider, allocation record, and technical contact.
Network path
Office, NAT, VPN, proxy, secure gateway, SD-WAN, mobile carrier, cloud workload, VDI, DR, split tunnel, and failover behavior.
Consumers
Conditional Access policy IDs, include/exclude role, Identity Protection, B2C, sign-in queries, automation, incident playbooks, and reporting.
Risk and exceptions
Threat model, bypass effect, authentication/device controls, false positives, approved exceptions, owner, compensating controls, and expiration.
Validation
Observed sign-in IP, named-location result, country, network path, policy result, test identity, target resource, timestamp, correlation ID, and reviewer.
Dependency review
Trace every edit to the access decisions it can change
| Change event | Hidden impact | Pre-change checks | Post-change proof |
|---|---|---|---|
| ISP circuit or public NAT change | Office users can become external or blocked; the retired range can later belong to another customer and retain unintended trust. | New allocation proof, IPv4/IPv6 discovery, firewall/NAT design, failover paths, policy consumers, old-range retirement date, and emergency access. | Sign-ins from every egress, policy evaluation, old-range negative test, audit log, monitoring, ticket, and delayed removal evidence. |
| VPN or secure web gateway change | Full/split tunnel, regional exits, proxy chaining, and failover can alter the IP Entra observes and the country it resolves. | Client populations, traffic destinations, all exit pools, IPv6 behavior, service bypasses, GSA signaling, mobile scenarios, and vendor change window. | Interactive and noninteractive sign-ins through normal/failover exits, named-location result, country, risk, app audiences, and support findings. |
| Office opening, closure, or acquisition | Ranges can be trusted before controls are ready or remain trusted after custody ends. Acquired networks might contain unmanaged devices. | Ownership transfer, circuit inventory, local controls, identity/device readiness, users/apps, exception need, cutover phases, and decommission plan. | Before/after inventory, sign-in samples, policy results, address custody, device posture, old-site removal, residual exception, and acceptance. |
| Country allow/block model change | Travel, remote work, mobile carrier routing, VPN exits, guest users, unknown mapping, and service dependencies can cause false blocks or bypasses. | Sign-in history, business countries, traveler workflow, guest population, application criticality, emergency exclusions, unknown setting, and legal review. | Report-only results, pilot travel tests, false-positive queue, blocked-event review, country mapping, help-desk data, and executive risk acceptance. |
| Mark or unmark trusted | Risk calculation and multiple policies can change even when the named location’s CIDRs remain identical. | All consumers, Identity Protection impact, office compromise scenario, authentication/device controls, monitoring, approval, and rollback. | Trusted-state audit event, policy and risk results, simulated internal attacker scenario, exception review, sign-in evidence, and owner acceptance. |
| IPv6 adoption | Users can bypass IPv4-only definitions or be blocked when applications and networks begin connecting over IPv6. | ISP prefixes, RA/DHCPv6, NAT64/proxy behavior, VPN support, endpoint tests, sign-in-log discovery, and all current named-location consumers. | IPv6 sign-ins from each path, correct named-location match, policy result, IPv4 regression test, monitoring, inventory, and documented prefix lifecycle. |
Ten-stage governance runbook
Discover, approve, change, validate, and retire locations without silent access drift
Authorize scope and ownership
Define tenant, environments, locations, network owners, identity owners, reviewers, Conditional Access Administrator authority, evidence retention, review cadence, emergency contacts, change window, success criteria, and rollback authority.
Export the immutable baseline
Capture named-location objects, object IDs, ranges, countries, trusted flags, unknown settings, GPS choices, Conditional Access policies, Identity Protection dependencies, sign-in logs, audit logs, and current network diagrams. Hash raw exports.
Discover observed egress
Test each office, VPN mode, proxy, cloud workload, VDI pool, mobile carrier, branch, failover, DR, and IPv4/IPv6 path. Compare network records with actual Microsoft Entra sign-in addresses and countries.
Reconcile custody and purpose
Verify every CIDR with the ISP, cloud account, firewall, proxy, or gateway owner. Mark ranges unknown, shared, temporary, vendor-controlled, or ending soon. Remove private addresses and never infer custody from a reverse DNS name alone.
Map policy dependencies
For every location, list policies that include or exclude it, whether it weakens or strengthens enforcement, target users/resources, related authentication/device/risk controls, exception owners, and the outcome if the object changes or disappears.
Design and approve the change
Use descriptive names, least scope, both IP families, explicit unknown-region handling, tested emergency access, staged policy edits, support communications, monitoring, negative tests, and a time-bound rollback plan. Review trusted designations separately.
Observe in report-only
Where policy behavior changes, use report-only or a parallel test policy. Review real sign-ins, What If simulations, audiences, IP/country, named location, device, risk, client, authentication, exclusions, and unexpected service dependencies.
Pilot every network path
Test standard, privileged, guest, mobile, remote, managed, unmanaged, VPN, proxy, split tunnel, full tunnel, failover, IPv6, traveler, unknown-region, and emergency scenarios against representative Microsoft 365 and Azure resources.
Implement and monitor
Save before/after object and policy exports, confirm audit events, validate positive and negative paths, monitor sign-in failures and risk detections, keep the old range only for an approved overlap window, and remove trust before deletion when required.
Close and schedule review
Preserve approvals, source records, test matrix, sign-in samples, correlation IDs, audit events, incidents, rollback result, exceptions, residual risk, owner acceptance, expiration dates, and next review. Revalidate after every network/provider change.
Validation and rollback
Prove both the expected match and the expected non-match
Minimum test plan
- Confirm the public IPv4 or IPv6 in the sign-in event—not a local private address.
- Verify the named location and country/region shown for normal and failover paths.
- Test included, excluded, trusted, untrusted, and unknown-location outcomes.
- Run representative target resources and review every audience/service dependency.
- Validate interactive and noninteractive sign-ins, VPN/proxy modes, mobile networks, and travelers.
- Confirm emergency accounts remain usable and monitoring alerts on every use.
- Repeat after token/session refresh where the access decision might not reevaluate immediately.
Rollback package
- Before exports for named locations and every dependent Conditional Access policy.
- Object IDs, original CIDRs/countries/trusted flags, and exact change sequence.
- Authorized rollback operator, support bridge, maximum impact threshold, and communication.
- Disable the affected policy or restore the prior location definition using emergency access.
- Revalidate sign-in, target resource, named-location match, risk, device, and authentication.
- Preserve affected users, requests, timestamps, correlation IDs, audit events, and resolution.
- Define defect remediation and new acceptance gates before reattempting the change.
Geolocation rule: Microsoft describes IP-to-physical-location mapping as best effort. Do not treat a country field as forensic proof. Correlate with network architecture, user activity, device data, authentication, risk detections, carrier/VPN behavior, and incident evidence.
Common governance failures
Prevent trusted-range sprawl and location-based access outages
These patterns produce false trust, false blocks, stale exceptions, and weak incident evidence. Treat them as blocking defects.
Private IP ranges entered
Microsoft Entra evaluates public internet egress. RFC1918 addresses from endpoints do not identify the organization’s observed cloud source.
IPv4-only inventory
IPv6 adoption can create nonmatches, blocks, or bypasses when named locations and dependent policies contain only legacy prefixes.
VPN equals office
Remote users, vendors, compromised devices, and split-tunnel applications can share or bypass corporate egress. Authentication and device controls remain necessary.
Trusted forever
ISP changes, office closures, provider reallocations, and acquisitions can transfer an address while the tenant continues treating it as trusted.
Country equals person
Mobile pools, VPNs, centralized proxies, and imperfect geolocation can show a country different from the user’s physical location.
Unknown regions ignored
Unmapped addresses can become a policy blind spot or a false-positive source. Decide explicitly and monitor the outcome.
Proxy source lost
If proxy or Global Secure Access signaling is incomplete, Entra can evaluate the gateway address instead of the original source and reduce risk fidelity.
Policy edited without location review
A location object can be accurate while its include/exclude use creates a bypass. Audit both the object and every consumer.
No negative test
Testing only that office users succeed does not prove outsiders fail, retired ranges no longer match, or emergency access remains available.
Evidence and measures
Measure data quality, dependency health, and operational response
Minimum closeout: scope, object and policy exports, hashes, authoritative IP allocation, network diagram, dependency register, trusted-location approval, test matrix, sign-in and audit evidence, exception list, rollback result, incidents, residual risk, owners, expiration, and next review date.
Related ecosystem guides
Connect network context to policy, identity, devices, and recovery
Conditional Access reviewAudit assignments, network conditions, resources, controls, exclusions, and evidence.
Security Defaults vs CAChoose the baseline or granular access-control model and plan cutover.
Sign-in log operationsValidate client IP, country, named location, policy, audience, device, and risk.
Device registration reviewKeep location context separate from device identity, management, and compliance.
Cross-tenant accessGovern partners, external identities, trust claims, tenant restrictions, and exceptions.
Emergency access securityProtect and test cloud-only recovery independent of normal network paths.
Microsoft 365 admin toolsetUse related planning, assessment, and evidence-building resources.
Microsoft 365 managed servicesGet ongoing identity, endpoint, email, network, and tenant operations support.
Authoritative Microsoft references
Validate design and limits against current documentation
- Conditional Access network assignment conditions
- Block access by location with report-only validation
- IPv6 support in Microsoft Entra ID
- Sign-in activity details and IP geolocation limitations
- View applied Conditional Access and named-location evidence
- Protect networks and preserve Global Secure Access signals
- Plan and govern Conditional Access deployment
- Troubleshoot Conditional Access sign-ins
Frequently asked questions
Microsoft Entra named locations FAQ
Should we enter our private office IP addresses?
No. Microsoft Entra observes the public IPv4 or IPv6 address used to reach the cloud, not an endpoint’s private RFC1918 address. Document the actual NAT, proxy, VPN, or gateway egress and verify it in sign-in logs.
Does marking an office location trusted make users or devices trusted?
No. The designation affects how named locations are used and can improve Identity Protection risk calculations, but it does not prove the identity, device health, or safety of activity. Maintain independent authentication, device, risk, and monitoring controls.
Why must we add IPv6 ranges?
Clients and networks can reach Microsoft Entra over IPv6 even when the existing inventory is IPv4-focused. If public IPv6 prefixes are missing, legitimate users can fail location conditions or traffic can avoid the intended match.
Can a country value prove where the user was?
No. Microsoft describes IP geolocation as best effort. VPN exits, mobile carriers, proxies, and centralized gateways can appear far from the device. Use it as context and corroborate with other identity, device, network, and risk evidence.
How often should named locations be reviewed?
Use a documented periodic cadence and event-driven review after ISP, VPN, proxy, SD-WAN, cloud NAT, office, acquisition, DR, IPv6, or policy changes. High-impact trusted ranges and broad country rules deserve more frequent validation.
What is the safest way to change an active named location?
Back up the object and all dependent policies, validate the new path in report-only or pilot scope, test positive and negative cases, preserve emergency access, implement during a controlled overlap window, monitor sign-ins, and remove retired trust only after evidence passes.
IT Perfection Microsoft 365 identity and network support
Keep location-based access aligned with the network Microsoft Entra actually sees
IT Perfection helps organizations in Irvine, Orange County, Los Angeles County, and Southern California inventory public egress, reconcile IPv4 and IPv6, map VPN and proxy paths, review Conditional Access dependencies, stage changes, validate sign-in evidence, manage trusted exceptions, and establish repeatable governance.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience.
This guide is for initial planning and operational guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, or legal/compliance review. Validate current licensing, network architecture, tenant behavior, Microsoft documentation, privacy requirements, and tested rollback procedures before implementation.
