MSA3.7 Named Locations and Network Controls

Named locations are the most misused CA feature. The common pattern: define the corporate office IP range as a "trusted location," then create a CA policy that skips MFA for trusted locations. The admin team believes they've reduced friction for office workers while maintaining security for remote workers. In reality, they've created a policy that can be bypassed by anyone who routes traffic through the corporate VPN, which includes the attacker who compromised an employee's VPN credentials. IP-based trust treats the network as an identity signal, but networks are not identities. This sub teaches the four types of named locations, the appropriate use for each, and the architectural principle: location should modify friction, not replace authentication controls.

Estimated time: 45 minutes.

The four types of named locations

Type 1. IP range locations

IP range locations define specific IPv4 or IPv6 CIDR blocks that represent known network egress points. You specify the IP ranges and optionally mark the location as "trusted." The trusted flag has two effects: it improves Identity Protection's risk calculation (sign-ins from trusted locations are less likely to be flagged as risky), and it creates a referenceable tag that CA policies can use in location conditions.

Common uses: corporate office egress IPs, VPN gateway IPs, data center egress IPs, known partner network IPs. Each IP range must be a CIDR block, individual IPs are specified as /32 (IPv4) or /128 (IPv6).

Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.ConditionalAccess"

# Inventory all existing named locations
$namedLocations = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/namedLocations" `
  -OutputType PSObject

Write-Host "=== NAMED LOCATION INVENTORY ==="
Write-Host "Total named locations: $($namedLocations.value.Count)"
Write-Host ""

foreach ($loc in $namedLocations.value) {
  $type = switch ($loc.'@odata.type') {
    "#microsoft.graph.ipNamedLocation" { "IP Range" }
    "#microsoft.graph.countryNamedLocation" { "Country/Region" }
    "#microsoft.graph.compliantNetworkNamedLocation" { "Compliant Network (GSA)" }
    default { $loc.'@odata.type' -replace '#microsoft.graph.','' }
  }

  $trusted = if ($loc.isTrusted) { " [TRUSTED]" } else { "" }
  Write-Host "  $($loc.displayName) — $type$trusted"

  if ($loc.ipRanges) {
    foreach ($range in $loc.ipRanges | Select-Object -First 5) {
      Write-Host "    $($range.cidrAddress)"
    }
    if ($loc.ipRanges.Count -gt 5) {
      Write-Host "    ... and $($loc.ipRanges.Count - 5) more ranges"
    }
  }

  if ($loc.countriesAndRegions) {
    Write-Host "    Countries: $($loc.countriesAndRegions -join ', ')"
  }
  Write-Host ""
}

Creating a corporate office location:

$officeLocation = @{
  "@odata.type" = "#microsoft.graph.ipNamedLocation"
  displayName = "NL-Corporate-Offices"
  isTrusted = $true
  ipRanges = @(
    @{ "@odata.type" = "#microsoft.graph.iPv4CidrRange"; cidrAddress = "203.0.113.0/24" }
    @{ "@odata.type" = "#microsoft.graph.iPv4CidrRange"; cidrAddress = "198.51.100.0/24" }
  )
} | ConvertTo-Json -Depth 5

Invoke-MgGraphRequest -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/namedLocations" `
  -Body $officeLocation
Write-Host "✓ Created: NL-Corporate-Offices (trusted, 2 IP ranges)"

What "trusted" means, and what it doesn't: Marking a location as trusted does NOT mean "no security controls required." The trusted flag is a risk signal modifier, not a security bypass. Trusted locations reduce Identity Protection's risk scoring for sign-ins from those IPs: an admin signing in from the office is less likely to trigger an "unfamiliar location" risk detection. Trusted locations also enable CAE's IP-based enforcement from MSA2.9, when a token is used from a non-trusted IP after being issued from a trusted IP, CAE can trigger a claims challenge.

The architectural principle: never use trusted locations to skip MFA entirely. Use them to improve risk accuracy and enable CAE IP enforcement. All users still require MFA from every location: the trusted flag adjusts the risk calculation, not the authentication requirement.

Type 2. Country/region locations

Country-based locations use Microsoft's IP-to-country mapping to determine the geographic origin of a sign-in. You specify countries/regions and optionally include "unknown" areas (IPs that don't map to any country).

# Block access from countries where your organization never operates
$blockedCountries = @{
  "@odata.type" = "#microsoft.graph.countryNamedLocation"
  displayName = "NL-Blocked-Countries"
  countriesAndRegions = @("RU", "CN", "KP", "IR")
  includeUnknownCountriesAndRegions = $false
  countryLookupMethod = "clientIpAddress"
} | ConvertTo-Json -Depth 5

Invoke-MgGraphRequest -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/namedLocations" `
  -Body $blockedCountries
Write-Host "✓ Created: NL-Blocked-Countries (RU, CN, KP, IR)"

The country-blocking CA policy:

The policy references the named location by its ID. After creating the named location above, retrieve its ID and create the CA policy:

$bgId = (Get-MgGroup -Filter "displayName eq 'SG-CA-Exclude-BreakGlass'").Id

# Get the blocked countries location ID
$blockedLocId = (Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/namedLocations" `
  -OutputType PSObject).value |
  Where-Object { $_.displayName -eq "NL-Blocked-Countries" } |
  Select-Object -ExpandProperty id

$countryBlockPolicy = @{
  displayName = "CA-All-BlockAccess-BlockedCountries"
  state = "enabledForReportingButNotEnforced"
  conditions = @{
    users = @{
      includeUsers = @("All")
      excludeGroups = @($bgId)
    }
    applications = @{ includeApplications = @("All") }
    locations = @{
      includeLocations = @($blockedLocId)
    }
  }
  grantControls = @{
    builtInControls = @("block")
    operator = "OR"
  }
} | ConvertTo-Json -Depth 5

Invoke-MgGraphRequest -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" `
  -Body $countryBlockPolicy
Write-Host "✓ Created: CA-All-BlockAccess-BlockedCountries (report-only)"

The includeUnknownCountriesAndRegions decision: Some IP addresses can't be mapped to any country, they return "unknown" in the IP-to-country lookup. Setting this to $true blocks these IPs as well. This is more restrictive (catches attackers using anonymising services) but also blocks legitimate users on networks with unresolvable IPs (some satellite internet, some mobile carriers). The recommendation: set to $false initially, review sign-in logs for "unknown" location sign-ins during the report-only period, then enable if your user base doesn't include populations on unresolvable networks.

The travel problem and three architectural solutions:

Country blocking affects legitimate travellers. An employee on a business trip to a blocked country can't sign in. This isn't a theoretical problem, it generates helpdesk tickets and executive escalations. Three options, each with different trade-offs:

Option 1. Require stronger MFA instead of blocking (recommended for most organizations). Replace the block grant control with a phishing-resistant authentication strength requirement. Users signing in from blocked countries must use a passkey or FIDO2 key: the strongest method. The logic: if the sign-in is legitimate (traveling employee), they can satisfy the requirement. If it's an attacker using stolen credentials, they can't satisfy phishing-resistant MFA. This converts the location signal from a hard block to an additional authentication requirement.

Option 2. Temporary travel exception group. Create a group SG-CA-Exclude-TravelCountries. Before travel, the employee (or their manager) submits a request. An admin adds the employee to the group for the travel duration. The group is excluded from the country-block policy. After travel, the employee is removed. The risk: the exception group can grow unchecked if removals aren't automated. Use dynamic membership with an expiry attribute, or set a calendar reminder to remove the user.

Option 3. Accept the block and use break-glass for emergencies. Block all sign-ins from the listed countries with no exceptions. Employees traveling to these countries use the break-glass accounts for emergency access only. This is the most secure option but the most operationally restrictive, acceptable for highly regulated environments where travel to sanctioned countries is extremely rare.

Type 3. GPS-verified locations

GPS locations use the Microsoft Authenticator app to report the device's actual GPS coordinates, replacing IP-based geolocation with physical position verification. This is architecturally stronger than IP-based location because the GPS coordinates come from the device's hardware, not from the network path: a VPN can't spoof GPS.

How it works at each step:

1. A CA policy with a GPS-based country location condition evaluates a sign-in.
2. The user receives a notification in Microsoft Authenticator: "Share your location."
3. The user opens Authenticator and grants location permission (first time) or the app shares silently (background permission already granted).
4. Authenticator sends GPS coordinates to Entra ID.
5. Entra ID compares the coordinates against the country/region boundaries defined in the named location.
6. If the coordinates are within the allowed region, the condition is satisfied.

The operational constraints that limit GPS to specific scenarios:

GPS verification requires Authenticator installed and location permissions granted. Not every user has Authenticator, and not every user will grant always-on location access. The check occurs once per hour for up to 24 hours after the initial share, users see a notification each hour confirming the check. This creates persistent friction: a user accessing a GPS-protected resource sees hourly location prompts for the entire working day.

GPS verification works only with passwordless phone sign-in if MFA push notifications are also enabled, it doesn't work with passwordless-only configurations where push is disabled.

GPS does not work when the device is in airplane mode, when location services are disabled by MDM policy, or when the user denies the Authenticator location permission.

When GPS is justified: Regulatory scenarios requiring physical location proof (data residency, sanctions compliance, gaming regulations). For general CA policies, IP-based country locations are sufficient. GPS verification is a targeted tool for high-security use cases, not a replacement for IP-based locations across the workforce.

Type 4. Compliant network (Global Secure Access)

The compliant network is the strongest location control because it verifies the traffic path, not the source IP or the physical location. Traffic must flow through your organization's Global Secure Access tunnel to satisfy the compliant network condition. An attacker who steals a token can't replay it from outside the GSA tunnel: the resource provider rejects the request because it didn't come through the compliant network.

Unlike IP range locations (which you must maintain as your network changes), the compliant network is automatically maintained by GSA. You don't need to update IP ranges when your VPN provider changes or your office moves: the GSA client on the device establishes the tunnel, and the tunnel proves the traffic path.

# Check if compliant network is available
$compliantNet = $namedLocations.value | Where-Object {
  $_.'@odata.type' -match 'compliantNetwork' -or
  $_.displayName -match "Compliant Network"
}

Write-Host "=== COMPLIANT NETWORK STATUS ==="
if ($compliantNet) {
  Write-Host "✓ Compliant network location exists: $($compliantNet.displayName)"
  Write-Host "  Global Secure Access is configured in this tenant."
  Write-Host "  CA policies can require traffic through GSA."
  Write-Host ""
  Write-Host "  Typical policy: block access from any location EXCEPT"
  Write-Host "  compliant network. Effect: only traffic through GSA is accepted."
} else {
  Write-Host "No compliant network location found."
  Write-Host "Global Secure Access is not configured."
  Write-Host ""
  Write-Host "To enable:"
  Write-Host "  1. Global Secure Access → Settings → Session management"
  Write-Host "     → Adaptive access → Enable Conditional Access Signaling"
  Write-Host "  2. Deploy the GSA client to devices"
  Write-Host "  3. Configure traffic profiles (Microsoft, Internet, Private)"
  Write-Host "  4. Create CA policy: block from Any location, exclude Compliant Network"
}

Requirements and cost: Global Secure Access requires Entra Suite licensing (or standalone Entra Internet Access / Entra Private Access). The GSA client must be deployed on devices. Traffic profiles must be configured. This is a significant infrastructure investment: the compliant network is a Phase 3/4 deployment for most organizations, not a day-one control. For organizations without GSA, IP range locations plus device compliance provide reasonable location assurance. The compliant network adds the strongest assurance but at higher infrastructure cost.

Why IP-based trust is weaker than you think

The common pattern: "If the user is on our corporate network, skip MFA." The assumption: being on the corporate network proves the user is in the office, on a managed device, with physical access controls. The reality:

VPN access: Any user who connects to the corporate VPN exits through the corporate IP range. A remote worker on a compromised personal laptop, connected to the VPN, appears to be "on the corporate network." If your CA policy skips MFA for the corporate IP range, the attacker who compromised the VPN credentials authenticates without MFA from anywhere in the world.

Cloud proxy and SASE: Organizations using cloud proxies (Zscaler, Netskope, Palo Alto Prisma) route all traffic through the proxy's IP ranges. The proxy IP is not your corporate network, it's a shared infrastructure. If you trust the proxy IP and multiple organizations use the same proxy IP range, sign-ins from other organizations' users could appear to come from your "trusted" network.

Split tunnelling: Many VPN configurations use split tunnelling, only traffic destined for on-premises resources goes through the VPN. Microsoft 365 traffic goes directly to the internet. The user's M365 sign-in comes from their home ISP IP, not the corporate IP, even though they're "on the VPN." Your trusted location never matches.

Dynamic IPs: ISPs in many regions assign dynamic public IPs that change periodically. Your corporate office IP might change when the ISP rotates addresses. If you hardcoded the IP in the named location and it changes, your trusted location stops matching, users in the office start getting MFA prompts. The fix (maintaining the named location with every IP change) is an operational burden that scales poorly with multiple offices and ISPs.

Token replay from a different IP: Even when the initial sign-in comes from a trusted location, a stolen token replayed from a different IP is still a valid token. CA evaluated the sign-in at authentication time, it doesn't re-evaluate every subsequent API call (except through CAE for supported apps). If your CA policy skipped MFA because the sign-in came from a trusted location, the stolen token carries no MFA claim: the attacker replays a weaker token than they would have if MFA had been required. The trusted location exception reduced the token's security properties, not just the sign-in's.

The architectural principle: use location to modify friction and improve risk scoring, not to replace security controls. Every CA policy should require authentication controls (MFA, authentication strength, device compliance) regardless of location. Location conditions should modify the experience, not the requirement.

Legitimate uses of named locations (each preserves the authentication requirement):

Improve risk scoring: Mark corporate IPs as trusted. Identity Protection incorporates this into risk calculation, sign-ins from trusted locations are less likely to be flagged as "unfamiliar location" or "impossible travel" risk detections. The MFA requirement is unchanged. The trusted flag makes the risk evaluation more accurate, not weaker.

Block impossible countries: Block sign-ins from countries where you have no employees or operations. This catches the lowest-effort attacks (stolen credentials used from distant countries) without affecting legitimate users. A credential stolen from your office and used from Russia triggers the country block before MFA is even evaluated.

Reduce friction on compliant networks: If you deploy Global Secure Access, the compliant network verification is architecturally strong enough to be a CA condition for reducing additional prompts, because it verifies the traffic path (not just the IP) and the verification happens continuously (not just at authentication time).

Enable CAE IP enforcement: Named locations enable CAE's IP-based enforcement from MSA2.9. When a token is used from a different IP than the authentication IP, CAE-capable resource providers trigger a claims challenge. The named location defines which IPs are "expected", tokens used from unexpected IPs get re-evaluated. This is location as a detection signal, not as a trust anchor.

The location decision summary

When designing CA policies, use this decision framework for the location condition:

SCENARIO                         USE LOCATION?   TYPE              PURPOSE
─────────────────────────────    ─────────────   ────────────────  ──────────────────────
Block access from sanctioned     Yes             Country/region    Hard block or stronger
  or high-risk countries                                           MFA requirement

Improve risk scoring for         Yes             IP range          Mark as trusted, reduces
  office-based sign-ins                          (trusted)         false-positive risk detections

Require compliant network for    Yes             Compliant         Verifies traffic path, the
  sensitive resources (GSA)                      network           strongest location control

Verify physical location for     Yes             GPS-verified      Regulatory requirement for
  regulatory compliance                                           physical presence proof

Skip MFA from corporate network  NO              —                 IP-based trust is too weak.
                                                                   Use device compliance instead.

Reduce MFA friction for VPN      NO              —                 VPN IP ≠ identity. Attacker
  users                                                            with VPN creds bypasses MFA.

Block specific IPs (attacker)    NO              —                 Attackers change IPs. Use
                                                                   risk-based policies instead.

The "NO" rows are the common anti-patterns. If you're about to create a CA policy that uses a trusted location to skip or weaken authentication, stop and use device compliance or authentication strength instead. Location modifies friction and risk scoring. It doesn't replace authentication.

Record your named location configuration. The critical architectural decision: trusted office locations improve Identity Protection risk scoring accuracy (fewer false positives from office sign-ins) but should NOT be used to skip MFA. All users should require MFA regardless of location. The trusted location reduces noise, not controls.

Before moving on, verify your understanding: Run the named location inventory. How many named locations exist in your tenant? Which are marked as trusted? Are any IP range locations used to skip MFA in CA policies? Explain three reasons why "skip MFA from the corporate network" is architecturally weak. For each, describe a specific scenario where an attacker bypasses the policy.

Reusable script: the commands from this sub assembled for operational use:

Document your named location strategy in 03-conditional-access/named-locations.md. Include: each named location with its type, IP ranges or countries, trusted designation, and purpose. The CA policies that reference each location. The architectural principle (location modifies friction, not security). Any location-based CA policies with their justification.