Back to the blog

Apple Always-on VPN: govern persistent tunnelling with MDM

Article created on September 24, 2026 · Apple documentation published on September 17, 2026 and analysed on September 24, 2026 · Topic: MDM, VPN, networking, and security

Apple now documents an Always-on VPN declarative configuration for iOS 27, iPadOS 27, Shared iPad, and visionOS 27. MDM can enforce a device-wide IKEv2 tunnel while governing the limited traffic that must remain outside it. For IT leaders, the real task is not enabling a switch: it is preserving security and continuity across Wi-Fi, mobile networks, activation, and captive portals.

1. What Apple’s declarative configuration enables

The configuration applies to devices enrolled through Device Enrollment or Automated Device Enrollment. It defines one or more IKEv2 tunnels and can target Wi-Fi or cellular interfaces. Apple also lets administrators expose a user toggle; allowing users to turn the VPN off needs to be an explicit risk decision because it weakens the persistent nature of the control.

The declaration provides service and application exceptions. It can also allow the captive web sheet or only selected captive-network apps outside the tunnel. Actual availability depends on the MDM vendor implementing the declaration: its presence in iOS or iPadOS does not prove that Jamf or another service already exposes every setting.

2. Persistent tunnelling moves risk into the exceptions

An Always-on VPN reduces unmanaged network paths, but an overly strict configuration can stop a device joining hotel, station, or customer Wi-Fi. Conversely, a broad captive-portal exception or a poorly identified app can become a lasting bypass. Every exception therefore needs an owner, justification, technical scope, and review date.

The IKEv2 profile must align with certificates, DNS, proxies, segmentation, and filtering. Our guide to encrypted DNS and DNS proxy through MDM complements this analysis: tunnelling and name resolution need joint testing, especially when internal domains are reachable only through the VPN.

3. What does this change for a Belgian or French company?

For an SMB, the configuration can standardise remote access without asking each user to launch a VPN. For a mid-sized organisation, large enterprise, or public body, it provides a common declarative baseline for managed iPhone and iPad fleets, while requiring coordination across endpoint, networking, PKI, security, and support teams.

Employees frequently move between Belgian and French offices, home working, mobile networks, and customer sites. The pilot should therefore cover the carriers and SSIDs actually used in both countries, plus English and French support instructions. Data processing, logging, and VPN termination must remain aligned with the organisation’s compliance policies; the Apple feature alone does not make an architecture compliant.

4. Underside analysis: build an observable policy, not an opaque tunnel

A sound architecture separates four objects: the IKEv2 profile, device or user identity, documented exceptions, and operational signals. A device shown as “connected” does not prove that expected traffic uses the tunnel, internal DNS works, or business apps remain available. MDM, the VPN gateway, and network tooling need to produce correlatable evidence.

Underside recommends staged deployment: test devices, IT users, lower-risk populations, then critical business teams. Apple Business Manager and Automated Device Enrollment establish device ownership; MDM or Jamf distributes the policy; network teams validate routes, certificates, and exceptions. This separation of responsibilities prevents the VPN becoming a black box.

5. Qualification plan before broad deployment

Objective: deliver persistent, measurable, and resilient remote access without turning captive portals or app exceptions into a security blind spot.

Qualify your Apple VPN architecture

Official Apple source: Always-on VPN declarative configuration for Apple devices, published September 17, 2026.