Support tip: Aligning network policy with Microsoft Intune and Zero Trust
By: Jon Callahan – Sr Product Manager | Microsoft Intune Cloud services don’t just rely on the network. They redefine it. As organizations adopt Microsoft Intune and advance their Zero Trust strategies, many discover that traditional, perimeter-based architectures no longer align with modern security expectations or the connectivity needs of a distributed workforce. Zero Trust is built on the principle of "never trust, always verify,” where access decisions are enforced through identity, device health, and compliance signals. Microsoft Intune strengthens this model by extending security and management through the cloud. By removing dependencies on on-premises infrastructure, it strengthens network resilience and Zero Trust enforcement with policy-driven device management and secure connectivity to Microsoft endpoints. This is where friction occurs. Traditional enterprise networks were built around a castle-and-moat model of perimeter defense: build high walls around the perimeter and trust everything inside, rather than identity-based access. Centralized egress points, VPNs, proxy servers, and deep packet or TLS inspection worked well when apps, data, and users stayed inside the moat. Today, work and data are everywhere. Legacy network designs often force traffic into hairpinned routes (indirect paths through central gateways) that add latency, reduce performance, and increase management overhead for Intune, Microsoft 365, and other SaaS apps. The challenge deepens when network teams try to maintain allow lists for cloud services using static IP addresses. Microsoft’s endpoint IPs can change frequently, especially with CDN-backed services like Intune and Microsoft 365, to strengthen security, improve resilience, and scale globally. This is why Microsoft recommends domain-based egress policies, frequent updates based on the published endpoint lists, and bypassing SSL inspection for Microsoft-bound traffic that doesn’t support inspection. Enabling cloud services The shift to hybrid work environments shows the limits of perimeter-based networks. Users expect fast and reliable access to their apps and data whether at home, in the office, or on the go. To support this shift, organizations need to modernize their network architecture and policies. Local internet egress and optimized paths to trusted services like Intune are essential. Policies built on Zero Trust and cloud-native principles help ensure performance and security. In contrast, controls such as VPN-only access, TLS inspection, or centralized proxies often slow users down and block required endpoints. When networks get in the way, the impact is noticed: Device check-ins and compliance evaluations fail, leaving devices marked as non-compliant Enrollments stall or time out Apps download slowly, fail to update, or never install When these failures occur, users often blame Intune or their IT admins, even when the real issue is network policies. In a Zero Trust model, network policy works alongside identity and device-based signals to enforce access decisions. Network policy should enable cloud services, not obstruct them. Adopting cloud-native connectivity and Zero Trust enforcement protects users, devices, and data while improving reliability and user experience. This approach aligns with Microsoft’s Secure Future Initiative (SFI) and the principle of “Secure by Design,” which extend Zero Trust principles into the foundation of how services are built and operated. As part of this effort, Intune service endpoints are moving to Azure Front Door to enhance security, reliability, and performance while simplifying firewall management across Microsoft services. For details on required IP addresses and endpoints, see Support tip: Upcoming Microsoft Intune network changes. Outbound traffic management Aligning network policies with Zero Trust and cloud-native architecture can require trade-offs. Outbound traffic management is critical for Intune’s performance, but organizations differ in their compliance needs and tolerance for complexity. Below are three common models we see with our customers. Endpoint enforced access This model eliminates perimeter bottlenecks by moving enforcement closer to the user, device, and apps, which is the core of Zero Trust. Enforcement happens at the endpoint through identity, compliance, and device health signals, while the network provides fast, direct internet access with minimal restrictive filtering. Best for: Organizations ready to adopt a Zero Trust network architecture built on Intune and identity-driven signals, or those with minimal outbound filtering requirements. How to implement: Policy-based enforcement and compliance: Intune enforces and validates device health and measures device compliance and app protection policies for Microsoft Entra Conditional Access Identity-driven enforcement: Microsoft Entra Conditional Access evaluates signals such as user identity, device compliance, and risk level before granting access to cloud resources Threat protection: Microsoft Defender for Endpoint monitors device risk and blocks compromised endpoints from accessing cloud resources; enforce the built-in firewall on Windows and macOS devices Bypass traffic inspection: Don’t decrypt or inspect Intune and related Microsoft traffic using technologies like proxies, TLS inspection, deep packet inspection, or data loss prevention systems Use split-tunnel VPN and local internet egress: Route Intune and Microsoft 365 traffic locally to avoid unnecessary hairpinning Benefits: Establishes Zero Trust controls with identity, device, and threat-based enforcement Local internet egress and optimized paths to Intune and Microsoft 365 avoid latency and centralized paths No allow list or complex firewall rules to manage Avoids VPN, proxies, and TLS inspections and reduces the risk of interfering with user experience and device management failures This model requires strong endpoint management and identity controls to ensure Zero Trust enforcement. Domain enforced filtering When endpoint-only enforcement doesn’t meet your organization's requirements, Fully Qualified Domain Name (FQDN) filtering offers a middle ground by adding network controls while staying adaptable to dynamic cloud services. This approach should be paired with endpoint enforcement to maintain a Zero Trust architecture. Best for: Organizations that need outbound restrictions for compliance, while maintaining reliability and flexibility in cloud services. How to implement: Use domain-based rules: Filter traffic by FQDN rules that rely on DNS to adapt to changing IP addresses and CDN-backed services Leverage automation: Integrate with the Microsoft 365 IP Address and URL web service and use automation, scripts, Azure Firewall service tags, or vendor tools to keep rules up to date Bypass traffic inspection for trusted services: Avoid decrypting or inspecting Intune traffic, which can break certificate pinning and cause service failures Resolve locally: Use local DNS and Internet egress so devices connect to the closest Microsoft endpoint Benefits: Builds on endpoint enforced Zero Trust controls Easier maintenance than IP-based filtering Automatically adapts to Microsoft's dynamic, cloud-hosted services Reduces service disruptions when automated Aligns with most regulatory and compliance frameworks This model requires more robust network automation and may introduce additional processing overhead compared to endpoint-enforced access. Domain and IP enforced filtering This model combines FQDN-based rules with IP filtering for the strictest assurance. It provides maximum control but introduces the most overhead. Like domain enforced filtering, this too should be combined with endpoint enforcement to maintain a Zero Trust posture. Best for: Organizations in highly regulated industries that require dual enforcement with domains and IPs to meet strict audit and assurance needs. How to implement for Intune: Combine domain with IP rules: Use FQDN alongside IP address ranges to filter traffic Automate aggressively: Integrate with the Microsoft 365 IP Address and URL web service and use automation, scripts, Azure Firewall service tags, or vendor tools to keep rules up to date. Avoid manual updates, which lead to outages and brittle network policies Bypass traffic inspection for trusted services: Exclude certificate-pinned services from TLS inspection to avoid breaking Intune functionality Optimize performance: Architect your network to use local DNS and internet egress so devices connect to the closest Microsoft endpoint Benefits: Builds on Zero Trust with the strictest network controls Provides dual verification for outbound traffic Helps satisfy strict regulatory and compliance requirements This model introduces the highest administrative overhead and complexity to maintain. It’s also the most likely to cause performance issues and service disruptions if not properly automated. However, for organizations with strict regulatory requirements, these trade-offs may be necessary to meet compliance obligations. Extending with cloud-first controls While traditional network models address outbound traffic at the infrastructure layer, a Zero Trust approach uses cloud-native security tools that eliminate many of these challenges. Issues like hairpinning, brittle IP allow lists, TLS inspection conflicts, and complex firewall rules stem from applying perimeter-era tools to cloud-based services. Cloud-first network and security tools reduce friction and strengthen Zero Trust. Cloud-delivered secure web gateway (SWG): Provides secure access to internet and SaaS apps while protecting against internet threats, building on the capabilities of traditional proxies (Microsoft Entra Internet Access) Zero Trust Network Access (ZTNA): Connects users securely from any device and any network without relying on VPNs or central tunneling (Microsoft Entra Private Access) Data loss prevention (DLP): Protects sensitive information across endpoints, Microsoft 365 apps, SaaS services, browsers, and on-premises file shares, with classification and policy enforcement (Microsoft Purview DLP) Cloud access security broker (CASB): Provides SaaS discovery, session control, and real-time policy enforcement (Microsoft Defender for Cloud Apps) Managing outbound traffic for cloud services is about more than connectivity. It’s about aligning network policies so they enable cloud services and embrace Zero Trust principles like identity, device health, and compliance signals over legacy perimeter defenses. Microsoft Intune supports through policy-driven device management and security that reinforce Zero Trust and cloud-native adoption. The result is an architecture that secures your environment and delivers the reliability and user experience needed for today’s hybrid work. Resources Intune network endpoints US government network endpoints for Intune China endpoints for Intune Support tip: Upcoming Microsoft Intune network changes Microsoft 365 URLs and IP address ranges Microsoft 365 network connectivity overview Azure Front Door Azure service tags Microsoft Secure Future Initiative (SFI) Microsoft Zero Trust As always, if you have any questions let us know in the comments or reach out to us on X @IntuneSuppTeam!
