Apple Network Relay: govern routing with MDM
Apple adds Network Relay to declarative management on OS 27. An organization can send selected traffic through a chain of HTTP/2 or HTTP/3 relays without treating the feature as a general-purpose VPN. Its operational value depends primarily on accurate domain scope, TLS trust, and an intentional failure mode.
1. What Apple officially documents
The Network Relay configuration is available starting with iOS 27, iPadOS 27, macOS 27, and visionOS 27, including Shared iPad. It does not require supervision and supports User Enrollment, Device Enrollment, and Automated Device Enrollment. The chosen MDM must still implement the corresponding declaration.
Apple allows one or more relays, chained where necessary. Each relay exposes an HTTP/3 or HTTP/2 URL compatible with the CONNECT mechanism for TCP and UDP traffic. The configuration can add HTTP headers, reference a declarative identity for authentication, and pin server public keys; when no key is supplied, standard system TLS trust evaluation applies.
2. Selective routing is the real architecture decision
Included and excluded domains determine which connections traverse the relays. With User Enrollment, a relay identifier is required to associate the network path with managed apps. This granularity can protect business traffic on a personal device without claiming control over all of its traffic.
The design should start with applications and their dependencies: API domains, authentication, CDNs, telemetry, and third-party services. An incomplete list can leave an app partially working; an overly broad scope increases load, cost, and exposure of the relay platform.
3. DNS failover and user control must be explicit
The declaration includes a setting that permits or prevents failover to the system’s default DNS resolver. This is a tradeoff between continuity and control of the network path: failover may preserve service but bypass the intended control, while blocking it may interrupt access during an incident.
Apple also allows the user to turn the configuration off when the organization enables that option. The decision should reflect the risk model: a tightly governed corporate device, a BYOD device, and a shared device have different requirements. The visible relay name should also help support teams identify the active service clearly.
4. What does this announcement change for a Belgian or French organization?
For an SME, Network Relay can limit secure access to a small set of business services. For a mid-market company, large enterprise, or public body in Belgium or France, it adds a component for segmenting Mac, iPhone, and iPad access by enrollment, app, and domain.
The feature removes neither the need for VPN, nor for proxying, DNS filtering, or network access control: it adds a routing option that must be assessed alongside existing architectures. Security and network teams should document where data travels, who operates the relays, which logs are produced, and which contractual or regulatory duties apply.
5. Underside analysis: govern the path, not just the MDM profile
Our view is that a successful deployment connects four responsibilities: MDM publishes the declaration, networking provides available relays, identity issues certificates or other authentication material, and the business validates the domains it actually needs. A profile accepted by a device does not prove the end-to-end path works.
Network Relay complements declarative DNS management and Always-on VPN, but addresses a different requirement. The organization should maintain a clear matrix of relayed traffic, VPN traffic, DNS resolution, filtering, and direct access to avoid overlaps that are impossible to troubleshoot.
6. Recommended qualification plan
- Confirm Network Relay support in the MDM and minimum OS versions across devices.
- Map applications, domains, TCP and UDP flows, and external dependencies.
- Define client authentication, TLS trust, identity rotation, and service owners.
- Decide DNS failover and user disablement for each enrollment scenario.
- Test Wi-Fi, Ethernet, and cellular, then measure latency, availability, and logs.
- Document troubleshooting and removal before a ring-based deployment.
Objective: make Network Relay a measurable, governed network path with minimal scope, renewable identity, and an intentional failure mode.
Qualify your Apple architectureOfficial source: Apple Platform Deployment — Network relay declarative configuration for Apple devices.