Corporate Data on Personal Phones: The Intune Policy That Contains It Without Enrollment

Your customer's payroll spreadsheet is one careless tap from someone's personal notes app, and the phone it happened on was never yours to manage. That is the BYOD problem in one sentence, and as of September 2021, app protection policies in Microsoft Intune remain the cleanest answer. They containerize corporate data inside the apps you trust, without enrolling the device in management at all, and without getting in the user's way.

This walkthrough covers what the policies aim to do, how to build one from a blank Endpoint Manager console, and what your end users actually experience once it lands.

What is an app protection policy supposed to accomplish?#

Three goals drive the design:

• Keep corporate data out of untrusted or unmanaged locations
• Provide end-to-end protection when a device is lost or stolen
• Grant access to corporate data while restricting how it can be shared

How do you build the policy?#

1. Sign into the Endpoint Manager admin center (opens in new tab).
2. Go to Apps > App Protection Policies > Create Policy.

This example builds an iOS policy. Android policies mirror iOS with a few obvious differences native to the OS nomenclature.

1. Provide a name.

1. In the Apps section, choose which device types the policy targets. It can apply to both managed and unmanaged devices, and a common pattern is two policies, with the unmanaged-device policy carrying the tighter restrictions. This example scopes to unmanaged devices.

1. Click +Select Public Apps. This is where you declare which apps are sanctioned, meaning trusted, in the organization. Microsoft has a preset library, and we recommend at least including the core Office suite. These become your managed apps, the ones you can then wrap with protections like cut, copy, paste, and save-as restrictions. Custom apps can also be uploaded for protection outside Microsoft's offerings.

1. The Data Protection section defines the security settings for your managed apps. We will not cover every toggle here, but the pattern that matters: restrict these permissions to other policy-managed apps, as shown below. That single choice is what keeps corporate data circulating only inside the container.

1. Access Requirements define app-level security like a PIN or an additional sign-in. If a device is stolen or broken into, this is the extra layer standing between the thief and corporate data.

1. Conditional Launch is a set of if-then statements you declare for when a device reaches a certain state, such as blocking access or wiping corporate data when conditions fail.

1. The final tabs scope the policy to specific users or groups. The policy takes effect immediately, and users opening the protected apps on an iOS device are told their data is being protected.

What changes for the user?#

The point of app protection is that almost nothing changes until the user tries to move data somewhere it should not go. Here is the experience end to end.

The first sign-in. When a user signs into a protected app like Outlook, they get a prompt explaining the organization is now protecting data in the app:

Copy and paste hits a wall. Cut, copy, and paste into unmanaged applications is restricted. Here is an attempt to copy an email message into a personal notepad app:

Save-as is limited too. Saving a Word document to a personal location on the iOS device is blocked by the policy:

The PIN gets established up front. If you configured additional access controls like a PIN, the user is asked to set it the first time they open a managed app after the policy is created:

The trade worth making#

App protection policies take light administrative work to set up and meaningfully raise the protection of corporate data on devices you will never fully manage. For the BYOD-heavy customer base most MSPs carry, that is about the best effort-to-impact ratio in the Intune catalog.

Microsoft's reference documentation is here: App protection policies overview (opens in new tab)