Event details
Never trust, always verify. Tune in for tips and insights to help you secure your endpoints using Microsoft Intune as part of your larger Zero Trust strategy. Find out how you can use Intune to protect both access and data on organization-owned devices and personal devices used for work. Ask Microsoft Anything (AMA) and get the answers you need to implement the right policies, security settings, device configurations, and more. Only at Tech Community Live!
Speakers: Mike Danoski, Clay Taylor, & Angela Robertson
Moderator: Jon Callahan
This event is part of Tech Community Live: Intune edition.
I'm in! How do I sign up?
Select “Add to calendar” to save the date and “Attend” to save your spot, receive event reminders, and participate in the Q&A. If you can’t make the live event, don’t worry. You can post your questions in advance and catch up on the answers and insights later in the week. All sessions for this Intune edition of Tech Community Live will be recorded and available on demand immediately after airing.
This event will feature AI-generated captions during the live broadcast. Human-generated captions will be available by the end of the week.
Where can I post my questions?
Scroll to the bottom of this page and select “Comment.”
2 Comments
- VanakenJBrass Contributor
Our network is built around Zero Trust. Intune is our device management tool (Windows devices). Intune features require a lot of URL's to be whitelisted which makes supporting Intune in a Zero Trust network a challenge; more: when Microsoft changes Intune IP or URLs, or from our side, the network team makes changes we are not aware of.
One shortcoming for Intune management is a standardized connectivity test that reports on connectivity issues and helps Intune admins check and act on connectivity issues; it would even enable security admins and network admins to smoke test Intune pro-actively when making changes and thus avoid disruptions for Intune. What is the Intune team's opinion on this?
- Francesco Scarpello
Microsoft
This 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.