Use IP Allowlisting to enforce zero trust policies for specific SaaS Applications integrated with Entra ID

Use Named locations and Conditional Access policies in Entra ID to ensure use of a Service Tunnel when authenticating to a SaaS Application like O365
Updated On: Aug 13, 2026

Step 2: Create a Named location to use in a Conditional Access policy

This step defines the trusted IP range (the CSE Access Tier egress) that Entra will recognize as "behind the Service Tunnel." The exact menu paths below reflect the Entra admin center at the time of writing; treat Microsoft's block-access-by-location guidance and network assignment documentation as the source of truth for the current console, which Microsoft can change without notice.

2.1 In the Microsoft Entra admin center, browse to Entra ID > Conditional Access > Named locations, and select + IP ranges location. (Microsoft moved this from the earlier Protection hub.)

2.2 Enter a name (e.g., Service Tunnel) and the IP address(es) of the relevant Access Tiers.

The CSE-maintained egress IPs are published on the Global Edge Network IP Ranges page. Use the values under Global Edge Egress IPs (global_edge_egress_ip_ranges.txt) and paste the whole list into the Named location.

Keep the CIDR notation for Entra. Unlike OneLogin, Entra expects CIDR-form IP ranges in Named locations, so leave the /32 (and other prefix-length) suffixes in place exactly as published.

Mark as trusted location (optional). Microsoft treats this checkbox as optional for this scenario. Marking the egress range as trusted improves Entra ID Protection risk-calculation accuracy and prevents the Named location from being deleted while it carries the trusted designation.

Step 3: Create a Conditional Access policy and assign the location condition

This step ties the Named location to the protected application so that Entra blocks any sign-in not originating from the Access Tier egress IP.

3.1 In the Entra admin center, browse to Entra ID > Conditional Access > Policies, and select New policy.

3.2 Enter a name for the policy and include the following configurations:

  • Assignments:

    • Users - Include the users in scope for this policy, and Exclude your emergency-access (break-glass) accounts and any service accounts, per Microsoft's guidance (see the warning below).

    • Target resources - Under Resources (formerly cloud apps), select the relevant application(s) for which you want to require a Service Tunnel connection before authentication (e.g., Office 365).

  • Conditions:

    • Network - Set Configure to Yes; under Include, select Any network or location; under Exclude, select the location(s) defined in Step 2. (Microsoft renamed the earlier Locations condition to Network, and it now also appears at the Assignments level; existing policies built on Locations continue to work.)
  • Access Controls:

    • Grant - Set to Block access.

3.3 Set Enable policy to Report-only, and Save. After confirming in the sign-in logs that only the intended sign-ins would be blocked, set the policy to On.

Avoid locking yourself out. This policy blocks every sign-in to the selected application(s) that does not come from the Access Tier egress IP. Follow Microsoft's guidance: exclude your emergency-access (break-glass) accounts under Users > Exclude, and validate the policy in Report-only mode before switching it On.

Expected Behaviour

If the user DOES NOT have the Service Tunnel connection established, they will receive a Microsoft error message indicating that they cannot access the resource (error code 53003, "Access blocked by Conditional Access policies"). The user(s) must have the relevant Service Tunnel connection established in order to access the resource (e.g., Office 365).