Per-App VPN: How It Works on iOS, macOS, and Android

Most enterprise VPN setups treat the device as the unit of protection — everything on it goes through the tunnel. That works well for a company-issued laptop that never leaves the office, but it creates real problems the moment you introduce BYOD devices or a mixed fleet where employees use the same phone for corporate apps and personal browsing.

Per-app VPN takes a different approach. Instead of routing all device traffic through an encrypted tunnel, it designates specific apps as the only ones whose traffic goes through that tunnel. Everything else — streaming, personal email, social apps — goes directly to the internet. The IT admin controls which apps are included. The end user controls nothing.

This distinction matters for three reasons: it reduces the bandwidth load on your corporate infrastructure, it gives employees on BYOD devices a legitimate privacy guarantee, and it lets your security team scope network protection to the apps that actually carry regulated or sensitive data. You're not protecting Netflix. You're protecting your ERP system and your internal file server.

This article covers how per-app VPN tunneling works at the OS level, how MDM-enforced per-app VPN differs from the user-configured kind, and how to set it up on iOS, macOS, and Android Enterprise. It also covers VPN client compatibility and where enterprise deployments tend to stall before any device is ever configured.

TL;DR

What Is Per-App VPN?

If you've already deployed per-app VPN on at least one platform, skip ahead to the How Per-App VPN Works on Each Platform section for configuration specifics.

Per-app VPN is a network policy that designates specific apps as VPN clients. Only those apps' traffic travels through the encrypted tunnel — every other app on the device connects directly to the internet. The IT admin defines the app list. On a managed device, the end user has no visibility into or control over which apps are included.

This is different from full-device VPN, which routes all traffic through the tunnel regardless of which app generated it. It is also different from split tunneling, which is a VPN-server-side configuration that excludes certain traffic by IP range or subnet. Split tunneling operates at the network layer. Per-app VPN operates at the app layer, enforced by the OS and the MDM policy that pushed the configuration profile.

Per-app VPN requires two things to work: a mobile device management solution to push the VPN configuration profile to devices, and a compatible VPN client installed on each device. The distinction between MDM vs MAM is relevant here — MAM (mobile application management) controls app behavior and data policies, but per-app VPN is a network policy enforced at the device level through MDM, not through the application itself — which means without MDM enrollment, there is no mechanism to enforce or audit that the tunnel is active.

Per-App VPN vs. Full-Device VPN: Why the Distinction Matters for Enterprise

Per-app VPN and full-device VPN solve the same underlying problem — protecting corporate traffic — but they make opposite assumptions about device ownership and user behavior. For enterprise fleets with any BYOD or mixed-ownership component, those assumptions have real consequences for compliance, user experience, and infrastructure cost. The benefits of mobile device management become far more pronounced when your network policy matches your actual fleet composition. And where per-app VPN fits within your broader MDM strategy is a decision that deserves a clear framework.

When Full-Device VPN Makes Sense

Full-device VPN is the right model in a narrow set of situations:

• Company-owned, single-purpose devices with no personal use — field service tablets, warehouse scanners, kiosk terminals
• Environments where all traffic must be inspected for regulatory reasons, such as certain financial services implementations with data loss prevention requirements
• Small, highly controlled fleets where the admin overhead of full-device tunneling is manageable and the compliance requirement justifies it
• Devices that never leave a controlled network environment and need a consistent, auditable connection path for every request

When Per-App VPN Is the Right Call

For most enterprise environments, per-app VPN is the better default:

• Any BYOD environment — routing personal traffic through corporate infrastructure creates a legitimate employee privacy concern and puts data on your VPN server that you are not obligated (and may not want) to hold
• Mixed-ownership fleets where the same MDM policy applies to both corporate-owned and employee-owned devices
• Organizations looking to reduce VPN server bandwidth load — only regulated app traffic consumes tunnel capacity
• Teams protecting specific high-risk apps (EHR systems, financial platforms, legal document tools) without forcing the entire device through compliance infrastructure
• Remote workforces using personal devices who would otherwise experience degraded performance from a full-device tunnel running alongside their normal daily activity

The Enforcement Gap You Need to Know About

The most important distinction in per-app VPN is not iOS vs. Android. It is MDM-enforced vs. user-configured.

A user-configured per-app VPN — one the employee sets up themselves on their own device — can be turned off by that employee at any time. The moment they toggle it off, the apps you thought were protected are connecting without a tunnel. There is no alert. There is no policy violation flag. The traffic simply goes out unprotected.

An MDM-enforced per-app VPN, pushed as a configuration profile to a managed device, cannot be removed by the end user on a fully managed or supervised device. The profile is locked. The app list is enforced. If the user tries to delete the VPN configuration, the MDM re-pushes it.

On BYOD devices with lightweight enrollment, the picture is more nuanced. If the user can remove the management profile entirely, they also remove the VPN configuration with it. This is not a per-app VPN failure — it is an unmanaged device problem. The solution is stronger enrollment, not a different VPN model.

One second-order consequence to plan for: if you push a per-app VPN profile and later remove it from the MDM console, enrolled devices lose the configuration without any notification to the end user. Apps that staff depend on for secure access may fail silently — and no error message will point to VPN removal as the cause. Test profile removal in a staging group before touching production.

In practice, the longest delays in per-app VPN deployments are not configuration problems. They are procurement cycles and security team sign-off timelines that run weeks longer than the technical setup itself.

How Per-App VPN Works on Each Platform

This section assumes you have an MDM solution in place and at least one supported VPN client deployed to your devices. If not, start with the What Is Per-App VPN? section first.

Per-app VPN is supported across iOS, macOS, and Android Enterprise, but the configuration approach and payload syntax differ meaningfully across platforms. What works on iOS does not translate directly to macOS, and Android Enterprise adds a Google EMM layer that neither Apple platform requires. Pushing these profiles as part of your mobile device management implementation is straightforward once you understand the per-platform logic — the gap is in knowing where each platform diverges. Following mobile device management best practices, always test per-app VPN profiles on a staging group before rolling them out fleet-wide. The following covers what each platform actually does and where admins typically run into trouble.

iOS Per-App VPN

iOS handles per-app VPN through the PerAppVPN key within the VPN configuration payload, pushed via MDM. Admins specify which apps are tunneled using bundle IDs — for example, com.yourcompany.erpapp. The VPN profile contains the full list of bundle IDs, and the OS enforces the tunnel for those apps only.

Two additional keys expand what iOS per-app VPN can cover. The SafariDomains key routes Safari traffic to specified domains through the tunnel — this is domain-level scoping for the browser, distinct from app-level tunneling, and is useful for browser-based internal tools. The OnDemandRules key lets you configure the VPN to connect automatically when a designated app opens and disconnect when the app closes, so the tunnel is only active when it is actually needed.

A common configuration mistake: admins push the VPN profile but forget to push the app itself via MDM. If the app is user-installed rather than MDM-managed, the per-app VPN policy may not apply to it. Every app in the bundle ID list should be an MDM-managed app.

If on-demand rules are not triggering the VPN when a designated app opens, check whether the app is MDM-deployed or user-installed. Only MDM-managed apps reliably honor on-demand per-app VPN triggers on iOS.

macOS Per-App VPN

macOS supports per-app VPN through VPN configuration profiles pushed via MDM, with admins designating apps by bundle ID — the same conceptual model as iOS. The implementation, though, is more limited. macOS does not support Safari domain-level VPN scoping in the same way iOS does, which matters if you are trying to protect browser-based internal tools rather than native apps.

A common mistake specific to macOS: using the same MDM VPN profile for both iOS and macOS devices. The payload syntax overlaps but is not identical. Admins who build one profile and assign it to both platforms often find that one platform applies it correctly and the other silently fails. Maintain separate VPN profiles per platform — it adds one configuration step and removes a significant troubleshooting surface.

Android Enterprise Per-App VPN

Android Enterprise — previously referred to as Android for Work, a term still in use in older documentation and some IT forums — handles per-app VPN through managed configurations pushed via Google EMM. The AlwaysOnVpnPackage managed configuration key designates a specific VPN app as the always-on provider for the work profile. Per-app traffic scoping is then handled within that VPN app's own managed configuration.

The device ownership model determines the scope of enforcement. On work profile devices (BYOD), the VPN applies only within the work profile — personal apps are never tunneled, and the employee's personal traffic is never visible to the IT admin. On fully managed devices (device owner mode, COD only), the VPN policy covers all managed apps on the device.

The VPN app itself must be deployed to the work profile, not the personal profile. If the VPN app is installed in the personal profile, it cannot tunnel work profile traffic — and there will be no error indicating why.

If the VPN app is not applying to work profile apps, verify that the app was distributed through managed Google Play and deployed specifically to the work profile. A VPN client that is not available on managed Google Play cannot be used in a work profile configuration, regardless of whether it supports the right protocols.

Choosing the Right VPN Client for Per-App Enforcement

Protocol support and per-app enforcement support are two different things. A VPN client can fully support IKEv2 or IPsec and still fall back to full-device tunneling when per-app scoping is applied — either because the client does not implement the OS-level network extension properly, or because it was built before the per-app APIs existed.

Per-app VPN enforcement on iOS requires the VPN client to integrate with Apple's Network Extension API. On macOS, the client should use a system extension rather than a legacy kernel extension — kernel extensions have limited per-app VPN support on modern macOS versions, and Apple is actively deprecating them. For Android Enterprise work profile deployment, the client must be available on managed Google Play and must support managed configurations so the MDM can push VPN server settings without any manual user input.

When evaluating a VPN client for per-app deployment, check for:

• Native iOS Network Extension API support
• macOS system extension (not a legacy kernel extension)
• Managed Google Play availability for Android Enterprise work profile
• Managed configuration support so the MDM can configure the client without user action
• MDM-deployable installation — a client the user has to download and set up manually undermines the entire enforcement model

A cloud MDM platform handles VPN client deployment across the fleet as part of the standard app push workflow — the client lands on the device pre-configured, and the user never touches the VPN settings.

If per-app VPN enforcement is inconsistent across devices running the same client version, check whether the client uses a system extension or a kernel extension on macOS. Kernel extension-based clients have documented limitations with per-app VPN on recent macOS versions, and the behavior can differ device-to-device depending on the OS version installed.

How Trio MDM Helps You Deploy Per-App VPN Across Your Fleet

Deploying per-app VPN across a mixed fleet means managing different payload formats, different OS enrollment models, and different app deployment pipelines — all at the same time. Trio MDM handles the cross-platform coordination from a single Device List that surfaces all enrolled devices — iPhone, iPad, Mac, Android, and Windows — regardless of platform.

For Apple devices, Trio MDM's depth in Apple device management — including support for supervised enrollment via Apple Configurator 2 and APN certificate management — means that configuration profiles deploy through the same standard profile workflow used for every other Apple policy. iOS and macOS devices are managed through the same Apple MDM stack, using separate per-platform assignments to match the configuration approach described in this article. You can manage these policies alongside your full Apple fleet through Trio MDM's unified endpoint management interface, which provides a centralized view of all enrolled devices regardless of OS.

For Android, Trio MDM connects with Google EMM to manage Android Enterprise devices in both Work Profile (BYOD and COD) and Fully Managed (COD only, Android 8.0+) modes. Managed configurations — including those needed for per-app VPN client deployment — are pushed through this Google EMM integration. On Work Profile devices, policy enforcement applies only within the work profile, keeping personal traffic completely outside the corporate management boundary.

For BYOD fleets specifically, Trio MDM isolates corporate data in a separate workspace with no location tracking and no full-device control. Employees get a real privacy boundary. IT admins get policy enforcement on the apps that matter. If you need to understand how Trio MDM fits your budget before committing, the MDM pricing breakdown is a good starting point.

Ready to see how it works on your fleet? Start your free trial or book a demo to walk through per-app VPN deployment and your specific platform mix with the Trio MDM team.