Event details
MicrosoftThis is a very valid concern and one we hear frequently: traditional networks built on perimeter defense (trust everything inside, rather than based on identity, device health and compliance signals), struggle to maintain allow list for cloud services as they need to maintain static IP address lists. Intune endpoint IPs can change, especially CDN based services. The reason why they can change is to strengthen security, improve resilience, and scale globally. Intune is designed to operate over dynamic, cloud-native endpoints, and forcing it through static IP allow lists, centralized proxies, or TLS inspection creates fragility and operational risk. Microsoft explicitly recommends:
- Domain-based egress policies (FQDN) instead of static IP allow lists, because Intune and M365 endpoints change frequently and are CDN-backed
- Bypassing SSL/TLS inspection for Microsoft endpoints that don’t support it, as inspection often breaks enrollment, check-in, and policy delivery
- Local internet breakout where possible, rather than hairpinning traffic through centralized VPNs or proxies
For more information Support tip: Aligning network policy with Microsoft Intune and Zero Trust | Microsoft Community Hub
On the point of a standardized connectivity test: today, Microsoft publishes Intune endpoint documentation (Network endpoints for Microsoft Intune - Microsoft Intune | Microsoft Learn), but Intune does not rely on a single “connectivity probe” by design. Zero Trust shifts enforcement and validation to identity, device health, and compliance signals, not network reachability alone. In other words, if identity and device trust are verified, the network should largely become a fast, transparent transport layer rather than a control plane.
In response on the AMA session where they suggested I point out what I would expect as a tool, I would mean a command-line tool to test under SYSTEM and USER context (Windows devices).
- SYSTEM context: testing of network endpoints required URL per Service Category (e.g. AutoPilot, Device Registration...) needed to enable managing the device with Intune (the 'essentials'); URLs for interactive features (edge, office) are not needed in this context. This test would confirm admins, security and network team that basic connectivity through firewall and proxy is confirmed or if not, which URLs have an issue.
Examples in the community exist, like https://github.com/Azure-Samples/TestDeviceRegConnectivity and https://manima.de/2024/08/intune-network-requirements-everything-i-learned/ - USER context: same test (optionally interactive), including tests for all Intune network endpoints for all Service Categories (so including URLs for interactive user features). Confirms complete connectivity. A good example for Microsoft 365 is the https://connectivity.office.com/
The tool/script would add value in a Zero-Trust world where other security tools on the Windows client try to limit network and Internet access and could break basic Intune connectivity.