Protect company data on a phone you will never be allowed to manage.
These policies operate entirely independently of any device management platform, take effect only inside the work context, and never touch anything personal. Where a workforce simply will not agree to having their own handsets enrolled, which describes the overwhelming majority of American BYOD populations, this is the control that actually reaches production. It is also a defensible answer to the mobile device question on a HIPAA risk assessment or an insurance renewal form.
- No enrollmentWorks on unmanaged personal devices
- Three levelsMicrosoft published data protection framework
- Work context onlyPersonal data is untouched
- Selective wipeCompany data removed, app and phone left alone
Eight things about app protection that decide whether it works for you.
It works without enrolling the device, which is the whole point
These policies function with or without enrollment, quite deliberately, because what is being managed is the user identity rather than the hardware. Consider the alternative in a real organization. You insist on enrolling personal handsets, and you get either outright refusal or a company phone that lives in a drawer. This is the version people actually agree to.
Work context only, and Microsoft gives a precise example
Nothing applies outside the work context, so a personal account signed into the same application carries on entirely untouched. The published illustration is worth repeating because of how concrete it is: somebody composing an email cannot switch the from address from their work identity to their personal one once a subject line or body text exists, since those fields are protected. Being able to describe the boundary that precisely is exactly what makes it explicable to staff.
A published three-level framework, so you are not guessing
Three configuration levels are defined and each builds on the one below. The first delivers PIN protection, encryption and selective wipe, with attestation validated on Android. The second layers on data leakage prevention and a floor on operating system version, and is stated as applicable to most people accessing work data. The third adds advanced protection, stronger PIN configuration and threat defense, aimed at high risk data. Having that published saves you designing a scheme from first principles.
Selective wipe that removes company data and nothing else
The wipe takes company data out of an application while leaving both the application itself and every piece of personal content exactly where they were. Mechanically it is quite specific: the SDK polls every thirty minutes for a wipe request, and also checks whenever somebody launches the application and signs in with their work account. Weigh that against the alternative for a departing employee, which is asking politely for their own phone back.
Control over where data can go
One group of settings governs relocation, covering whether copies of organizational data can be saved and whether cut, copy and paste are restricted. Another governs access, covering PIN requirements and whether managed applications may run at all on rooted or jailbroken hardware. The consequence of having neither is described plainly enough: company and personal data intermingle, and your material ends up sitting in somebody personal storage.
Different rules for managed and unmanaged devices
Targeting can key off the management state of the device, letting you run something lighter on enrolled hardware and something considerably stricter on anything outside management entirely, or scope a policy to unenrolled devices alone. In practice that is what nearly every organization actually wants, because imposing identical friction on a company phone and somebody personal one is neither necessary nor well received.
Device integrity checks on Android
Play Integrity checks run alongside root detection, and there are two tiers. The basic check fails rooted hardware, emulators, virtual devices and anything showing signs of tampering. The certified check goes further, additionally failing devices with an unlocked bootloader, a custom system image, or from a manufacturer that never applied for or never passed certification. Anybody failing either can be blocked outright or have their corporate account wiped.
Encryption before data leaves the app on iOS
There is a limitation acknowledged openly in the documentation: the iOS share extension cannot be controlled by policy without managing the device itself. The mitigation is encryption applied to corporate data before it leaves the application, so a file opened somewhere outside a managed app arrives encrypted and useless. You are even encouraged to verify that behavior for yourself, which is genuinely worth an hour during your pilot rather than taking on trust.
Three things that do not happen on an unmanaged device.
These limitations are listed openly in the documentation, and they are the honest price of not enrolling. Anybody presenting this approach without mentioning them is selling rather than advising.
- Nothing gets deployed to the device. People install the applications from the store themselves, which means your rollout depends entirely on individuals actually doing that, and your communications have to be written accordingly rather than assuming software will appear.
- No certificate profiles are provisioned either. Anything relying on a device certificate is simply unavailable, which bites on certain internal applications and on any certificate-based network access you may have built.
- Corporate wireless and VPN settings are likewise not provisioned, so the handset will not join your network or establish a tunnel on its own and internal-only resources need another route entirely. There is a tunnel capability, an advanced Intune feature, built specifically to solve the VPN half of this for unenrolled Android and iOS devices.
- One further caveat is stated plainly and gets overlooked constantly: pair these policies with Conditional Access if you want them enforced. Without that pairing, somebody who finds the restrictions inconvenient simply opens a different application and reaches exactly the same data.
Four things that make the difference between adoption and a stalled project.
We start at level two and adjust from there
Since the middle level is stated as applicable to most people accessing work data, choosing it is a defensible decision rather than an arbitrary one, and that matters when somebody senior asks why. The entry level is thin for most organizations, and the top level introduces friction a general population will resent within a fortnight. Begin where the guidance points and move specific groups upward. That is the design that survives contact with actual users.
We explain the personal boundary before anybody sees a prompt
Almost all the resistance you will meet comes from one belief, which is that IT can now read personal photographs and messages. The truthful answer happens to be both specific and reassuring: nothing applies outside the work context, a personal account inside the same application is untouched, and a wipe takes company data without affecting the phone. Say exactly that, in writing, before anybody sees their first prompt, and most of the pushback never materializes.
We pair it with Conditional Access, because Microsoft says to
The guidance is direct that Conditional Access should accompany these policies if you want them enforced. Think about why. Without it, anybody who finds a restriction inconvenient opens a different mail application, reaches the identical mailbox, and your policy has accomplished precisely nothing. This is not an enhancement to consider later. It is the thing that turns a preference into a control.
We check the prerequisites that quietly break rollouts
Four specifics, and every one of them has personally derailed a rollout we were later asked to rescue. Android needs the Company Portal present to receive policies at all. Android devices need directory registration for the Microsoft 365 applications. Mobile Outlook works with Exchange Online, or Exchange Server under hybrid modern authentication, and nothing else. And the Office mobile applications support SharePoint Online but not an on-premises deployment.
Six situations where app protection is the right answer.
A workforce that refused device enrollment
By far the most common way these conversations begin. Somebody attempted an enrollment project, staff objected to their employer managing a phone they bought themselves, the project quietly stopped, and everyone carried on reading company email on those same handsets regardless. This breaks the deadlock, because the data gets protected without anybody surrendering their device.
High-turnover operations where devices are personal
Stores, restaurants, delivery operations, home health, field service: places where staff use their own phones and the roster changes every month. Being able to pull company data out of an application without removing the application or affecting the phone is a vastly more workable offboarding step than attempting to recover a personal handset from somebody who stopped answering your calls two weeks ago.
A regulated firm needing evidence of mobile data control
A HIPAA risk assessment, a SOC 2 auditor, an FTC Safeguards review or a customer questionnaire all eventually ask how company data on mobile devices is protected. The published framework hands you a recognized configuration standard to name, and the policy settings themselves constitute the evidence behind it. Compare that with the answer most organizations currently give, which amounts to saying staff have been told not to save things locally.
A mixed estate of corporate and personal phones
Part of the workforce carries company hardware, the rest use their own, and subjecting both groups to identical friction is neither necessary nor something people will tolerate quietly. Targeting on management state, running something lighter where the device is already enrolled and something stricter where it is not, is precisely the shape this situation calls for.
An organization with contractors and temporary staff
People who need access for one project, on their own equipment, for a known number of weeks. Enrolling them is both disproportionate and too slow to be useful. Protection policies paired with Conditional Access get them working securely almost immediately, and a selective wipe closes the whole thing cleanly at the end of the engagement without any hardware ever changing hands.
A business worried about copy, paste and save-as
Sometimes what keeps people awake is not a stolen handset but data leaking out through entirely ordinary daily use. Restricting cut, copy and paste and governing where copies of organizational data may be saved addresses exactly that. The alternative is described plainly enough in the documentation: company and personal data intermingle, and your material ends up in somebody personal storage.
How company data on personal phones is actually handled.
| Feature | App protection deployed | Full enrollment required | Nothing on personal devices |
|---|---|---|---|
Company data protected on personal phones | Yes | Only if they enroll | No |
Staff willing to accept it | Usually | Frequently not | Not applicable |
Personal data untouched | Yes | No, the device is managed | Yes |
PIN required for work data | Yes | Yes | No |
Copy and paste to personal apps restricted | Yes | Yes | No |
Company data removable when somebody leaves | Yes | Yes | No |
Applications deployed automatically | No | Yes | Not applicable |
Wi-Fi, VPN and certificates provisioned | No | Yes | No |
Jailbroken and rooted devices detected | Yes | Yes | No |
How common this is | Uncommon | Common on corporate devices | Very common |
Three levels, and which population each is for.
Level
Level 1, basic
- What it adds and who it is for
- PIN, encryption and selective wipe, with Android device attestation validated. An entry level configuration.
Level
Level 2, enhanced
- What it adds and who it is for
- Data leakage prevention and minimum operating system requirements. Microsoft states this is applicable to most mobile users.
Level
Level 3, high
- What it adds and who it is for
- Advanced data protection, enhanced PIN configuration and mobile threat defense. For users accessing high risk data.
Level
Managed devices
- What it adds and who it is for
- A less strict policy can be applied where the device is already enrolled in Intune.
Level
Unmanaged devices
- What it adds and who it is for
- A more restrictive policy, or a policy applied to unenrolled devices only.
Level
Windows devices
- What it adds and who it is for
- Policies split into data protection settings and health checks with conditional launch actions.
Five steps, and the communication starts before the configuration.
- 1
Decide scope and level
We settle which populations are in scope, which devices, and which of the three levels applies to each. The middle level becomes the baseline in most engagements because it is documented as suiting most mobile users, with anybody handling high risk data moved up a level and corporate managed hardware given something lighter.
- 2
Confirm the prerequisites
Conditional Access has to exist, the Company Portal has to be available to Android users, Android devices need directory registration for the Microsoft 365 applications, and your mail and file platforms have to be supported. That last one is not a formality: mobile Outlook requires Exchange Online or hybrid modern authentication, and the Office mobile applications work against SharePoint Online rather than an on-premises farm.
- 3
Communicate the boundary before deploying
A short and specific message goes out first, covering three points: nothing applies outside the work context, personal accounts and personal content inside the very same application are untouched, and a wipe removes company data while leaving the phone alone. Of every step in this engagement, this is the one that determines how the whole thing is received.
- 4
Pilot, then widen
A genuinely representative group spanning the device types and applications that matter to you, exercising the PIN experience, the copy and paste restrictions, and what happens when data is shared beyond a managed application. There is even a suggested test worth borrowing: attempt to open a corporate file outside a managed app on iOS and confirm the encryption behaves as described.
- 5
Connect it to the offboarding process
The wipe belongs in your documented leaver process rather than in somebody memory. It clears company data out of the applications without affecting the device at all, and gets picked up either within thirty minutes or at the next sign-in, which is fast enough to be a genuine step in a real offboarding checklist rather than an aspiration.
What organizations ask about app protection policies.
Fifteen questions worth answering first.
Scope
- Are personal devices in scope, corporate, or both?Policies can be targeted by management state.
- Which level fits your workforce?Microsoft states level two suits most mobile users.
- Is any population accessing high risk data?That is the level three case.
- Which applications need protecting?The protected apps list is published.
- Are Windows devices in scope as well as mobile?Windows app protection exists and works differently.
Prerequisites
- Is Conditional Access in place?Microsoft says use it to ensure policies are enforced.
- Is the Company Portal installed on Android devices?Required to receive policies on Android.
- Are Android devices registered with Entra ID?Required for MAM on Microsoft 365 apps.
- Is your mail Exchange Online or hybrid modern auth?Outlook mobile app protection depends on it.
- Do you rely on SharePoint on-premises?The Office mobile apps support SharePoint Online only.
User experience
- How often should the PIN be rechecked?The recheck interval is configurable.
- Do staff understand what is and is not protected?The work versus personal boundary needs explaining.
- How will users install the apps?They are not deployed on unenrolled devices.
- What happens when somebody leaves?Selective wipe, and it should be part of the offboarding process.
- Do you have any Teams Android room devices?They do not support app protection policies.
The pages around this one.
Microsoft Intune
The platform this sits in, including full device enrollment for the estate you do own.
Conditional Access
The policy layer Microsoft says to pair this with, and without which the protection can simply be bypassed.
Mobile threat defense
The threat layer that level three of the framework brings in for high risk populations.
If enrollment failed, this is the conversation to have instead.
Protecting company data on a personal phone without managing the phone is a materially easier proposition to put to staff, and it is the one that gets accepted. Paired with Conditional Access it is a genuine control rather than a gesture.
Related Services
Explore more solutions that work great with this service