Intune network endpoints & ports

Devices must reach these services directly — TLS inspection and authenticated proxies break enrolment and check-in. Allow the wildcard domains rather than pinning IP addresses where possible. Everything is outbound from the device; Intune never needs an inbound port opened.

Authoritative source: these endpoints change over time. Always confirm against Microsoft's own list at learn.microsoft.com/en-us/intune/intune-service/fundamentals/intune-endpoints before finalising firewall rules. Microsoft also publishes the list as a machine-readable service tag / endpoint feed, and Autopilot has its own page: Windows Autopilot networking requirements.

Core Intune service

Entra join, hybrid join and device registration

Hybrid join additionally needs line of sight to a domain controller (LDAP, Kerberos, SMB, RPC — the standard domain-member set), because the device joins on-prem AD first and registers with Entra ID afterwards. The Entra-side traffic is the same 443 set as above; there is no separate port list for hybrid join.

Windows enrolment, Autopilot and updates

User-driven Autopilot does not perform TPM attestation, so the attestation rows only matter when a profile uses self-deploying mode or a technician runs pre-provisioning. When they are blocked, provisioning stops at Securing your hardware or Registering your device for mobile management — see the enrolment error family.

Apple (iOS/iPadOS/macOS enrolment)

Note: APNs is required on the device network (corporate Wi-Fi), not just the server side. Port 5223 from the device to *.push.apple.com; devices fall back to 443 only on some networks.

Google (Android enrolment)

Port summary

Rules of thumb: no SSL inspection on *.manage.microsoft.com, *.dm.microsoft.com, APNs or FCM; allow certificate revocation endpoints (port 80) or chain validation fails; and re-check Microsoft's endpoint doc after service updates — this sheet is a starting point, not a contract.

Common questions

What is the minimum set of ports Intune needs? Outbound TCP 443 to the Microsoft hostnames above, plus outbound TCP 80 for certificate revocation (CRL/AIA) fetches and the NCSI probe. Nothing inbound. Every other port on this page belongs to a platform push service (Apple, Google), Delivery Optimization or NTP — needed for those features, not for Intune itself.

Are the endpoints different for the UK, Europe or another region? Mostly no. The core service hostnames (*.manage.microsoft.com, *.dm.microsoft.com, the Entra and Autopilot hosts) are global, and Microsoft publishes one list for every country. Three feature areas do depend on your tenant location — not your country — which is one of North America, Europe or Asia Pacific (Intune admin center > Tenant administration > Tenant status): the Intune Management Extension content CDN for Win32 apps and scripts, the macOS sidecar CDN, and the Azure Attestation hosts for Windows 11 device-health compliance. A UK tenant is a "Europe" tenant. The CDN hosts all sit under *.manage.microsoft.com, so a wildcard rule already covers them; only the *.attest.azure.net hosts need separate rules. The sovereign clouds are genuinely different: Intune for US Government uses *.manage.microsoft.us and its own endpoint page.

Which endpoints does Windows Autopilot need? The Autopilot deployment service (ztd.dds.microsoft.com, cs.dds.microsoft.com), login.live.com for the device ticket, the NCSI probe, NTP, the Entra registration and Intune enrolment hosts — and, for self-deploying and pre-provisioning modes only, the TPM attestation hosts. Windows Update and Delivery Optimization matter during the Enrollment Status Page if you install updates or apps there. Autopilot has no extra ports beyond TCP 80/443 and UDP 123.

Do I have to allow IP addresses instead of hostnames? Prefer hostnames. If a firewall can only take addresses, download the ranges from Microsoft's endpoint documentation or the published service tag / JSON feed rather than copying them from a blog post — the ranges change, and the list includes both IPv4 and IPv6 prefixes. Pinning a partial IPv4 list is the most common cause of a fleet that enrols fine and then loses check-in months later.

Can devices go through a proxy? An unauthenticated, transparent proxy that does not break TLS is fine. Two things break enrolment and check-in: authenticated proxies, because the Intune Management Extension and the enrolment client run as SYSTEM with no user credentials to offer, and TLS inspection of *.manage.microsoft.com, *.dm.microsoft.com, the attestation hosts, APNs or FCM, because the clients pin or validate certificates the proxy replaces. Microsoft also requires device.login.microsoftonline.com and enterpriseregistration.windows.net to be excluded from break-and-inspect, or device registration and device-based Conditional Access fail. Configure the proxy system-wide (WinHTTP or a PAC reachable before sign-in), not just for the user's browser.

What does Android need beyond 443? Firebase Cloud Messaging on TCP 5228–5230 to mtalk.google.com. Without it, devices only receive policy when the user opens the Company Portal or Intune app, so changes appear to take hours. Android Enterprise enrolment also needs Google Play and accounts.google.com on 443.

Can I use any HTTPS endpoint as the "TLS authentication endpoint" in a Network List Manager policy? Any HTTPS endpoint that meets Microsoft's four conditions. The Allowed TLS Authentication Endpoints setting (Windows 10 20H2 and later) lets Entra-joined devices recognise the corporate network: if any listed URL answers over HTTPS, the network is treated as authenticated and the Windows Firewall domain profile applies. Microsoft's requirements for the endpoint are that it is an internal address not reachable from outside the organisation's network, that it has no further authentication in front of it (no sign-in or MFA), that the device trusts the server certificate (the issuing CA's certificate is in the machine's trusted roots), and that the certificate is not a public one — use your internal PKI. The URL must return HTTP 200 without redirecting; the page content is irrelevant. An IIS site on an internal server with an internally issued certificate is the usual choice. Test it from a device with Invoke-WebRequest -Uri https://nls.corp.example.com -UseBasicParsing -MaximumRedirection 0 and check for status 200.