Protect company data on a phone you will never be allowed to manage.
App protection policies work independently of any device management solution, applying only in the work context and leaving personal data untouched. For a workforce that will not accept enrolment of personal phones, which describes most of this market, this is the control that actually gets deployed.
- No enrolmentWorks 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
Microsoft states that app protection policies can be used independently of any mobile device management solution, protecting company data with or without enrolment. Management is centred on the user identity rather than the device. In a market where staff will not hand over control of a personal phone, and where insisting produces either refusal or a second phone nobody uses, this is the version that gets adopted.
Work context only, and Microsoft gives a precise example
Policies apply only in the work context, and if a personal account is signed into the app the data is untouched. Microsoft illustrates it exactly: a user drafting an email in Outlook cannot switch the from address from the work context to the personal one once the subject or message body is populated, because those are protected. That specificity is what makes the boundary explicable to staff.
A published three-level framework, so you are not guessing
Microsoft defines three configuration levels. Level one, basic, gives PIN protection, encryption and selective wipe, with Android device attestation validated. Level two, enhanced, adds data leakage prevention and minimum operating system requirements, and Microsoft states it is applicable to most mobile users accessing work or school data. Level three, high, adds advanced protection, enhanced PIN configuration and mobile threat defence for high risk data.
Selective wipe that removes company data and nothing else
A mobile application management selective wipe removes company app data from an app without removing the app or touching personal content. The mechanism is specific: the Intune SDK checks every thirty minutes for a wipe request, and also checks when the user launches the app and signs in with their work or school account. That is a meaningfully better answer for a leaver than asking for their personal phone.
Control over where data can go
Settings cover data relocation, including saving copies of organisational data and restricting cut, copy and paste, and access, including requiring a PIN and blocking managed apps from running on jailbroken or rooted devices. Microsoft describes what happens without them plainly: company and personal data intermingle and company data ends up in personal storage.
Different rules for managed and unmanaged devices
Policies can be targeted by device management state, so you can apply a less strict policy to Intune managed devices and a more restrictive one to devices not enrolled in any management solution, or apply a policy to unenrolled devices only. That is the configuration most organisations actually want, because a corporate phone and a personal one do not warrant identical friction.
Device integrity checks on Android
Google Play Integrity checks are used alongside root detection. Basic integrity fails for rooted devices, emulators, virtual devices and devices showing signs of tampering. The certified devices check additionally fails devices with an unlocked bootloader, a custom system image, or which the manufacturer never applied for or passed Google certification. Users failing can be blocked or have their corporate account wiped.
Encryption before data leaves the app on iOS
Microsoft is honest about a limit here: app protection policy cannot control the iOS share extension without managing the device. The answer is that Intune encrypts corporate data before it is shared outside the app, so a file opened outside a managed app is encrypted and unusable. Microsoft even suggests validating this behaviour yourself, which is worth doing during a pilot.
Three things that do not happen on an unmanaged device.
Microsoft lists these limitations directly, and they are the honest counterweight to the convenience of not enrolling.
- Applications are not deployed to the device. The user installs them from the store themselves, which means the rollout depends on people actually doing that, and your instructions have to account for it.
- Certificate profiles are not provisioned. Anything that depends on a device certificate is unavailable, which matters for some internal applications and for certificate-based network access.
- Company Wi-Fi and VPN settings are not provisioned. The device will not automatically join your corporate wireless network or connect to your VPN, so internal-only resources need a different route. Microsoft Tunnel for mobile application management, an Intune advanced capability, exists specifically to address the VPN half of this for unenrolled Android and iOS devices.
- There is also a policy enforcement caveat Microsoft states plainly: to ensure that policies are enforced, use Conditional Access together with app protection policies. Without that pairing, somebody can simply use a different application to reach the same data.
Four things that make the difference between adoption and a stalled project.
We start at level two and adjust from there
Microsoft states that the enhanced level is applicable to most mobile users accessing work or school data, which makes it a defensible starting point rather than an arbitrary one. Basic is thin for most organisations and high introduces friction that a general population will resent. Starting where Microsoft points and moving specific populations up is the design that survives.
We explain the personal boundary before anybody sees a prompt
The single biggest source of resistance is the belief that IT can now see personal photographs and messages. The honest answer is specific and reassuring: policies apply only in the work context, personal accounts in the same application are untouched, and a wipe removes company data without touching the device. Saying that clearly, in advance, prevents most of the pushback.
We pair it with Conditional Access, because Microsoft says to
Microsoft states directly that to ensure policies are enforced, Conditional Access should be used alongside app protection policies. Without that pairing somebody simply reaches the same mailbox from an unprotected application and the policy achieves nothing. This is not an optional enhancement, it is what makes the control a control.
We check the prerequisites that quietly break rollouts
The Company Portal is required on Android to receive policies. Android devices need Entra ID registration for Microsoft 365 apps. Outlook mobile supports Exchange Online or Exchange Server with hybrid modern authentication only. The Office mobile apps support SharePoint Online but not SharePoint on-premises. Each of these has stopped a rollout we have been asked to rescue.
Six UAE situations where app protection is the right answer.
A workforce that refused device enrolment
The most common starting point. An enrolment project was attempted, staff objected to the organisation managing their personal phone, and the project quietly stopped while everybody carried on reading company email on it anyway. App protection resolves the standoff, because it protects the data without managing the device.
High-turnover operations where devices are personal
Retail, hospitality, logistics and facilities, where staff use their own phones and turnover is constant. Selective wipe removing company data from an application without removing the application or touching the phone is a far more workable leaver process than trying to recover a personal device from somebody who has already gone.
A regulated firm needing evidence of mobile data control
Where a regulator or a client asks how company data is protected on mobile devices, the published three-level framework gives you a recognised configuration standard to point at, and the policy settings themselves are the evidence. That is a better answer than asserting that staff are told not to save things locally.
A mixed estate of corporate and personal phones
Some people have company phones, others use their own, and applying identical friction to both is neither necessary nor tolerable. Targeting by device management state, with a less strict policy for Intune managed devices and a more restrictive one for unenrolled devices, is exactly what this situation needs.
An organisation with contractors and temporary staff
People who need access for a project, on their own devices, for a defined period. Enrolment is disproportionate and slow. App protection plus Conditional Access gives them protected access quickly, and selective wipe ends it cleanly when the engagement finishes, without any device ever being handed over.
A business worried about copy, paste and save-as
Where the concern is not a stolen phone but data quietly leaving through ordinary use, restricting cut, copy and paste and controlling where copies of organisational data can be saved addresses it directly. Microsoft describes the alternative plainly: company and personal data intermingle and company data ends up in personal storage.
How company data on personal phones is actually handled here.
| Feature | App protection deployed | Full enrolment required | Nothing on personal devices |
|---|---|---|---|
Company data protected on personal phones | Yes | Only if they enrol | 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 |
Frequency in the UAE market | Uncommon | Common on corporate devices | Very common |
Three levels, and which population each is for.
| Level | What it adds and who it is for | |
|---|---|---|
| Level 1, basic | PIN, encryption and selective wipe, with Android device attestation validated. An entry level configuration. | |
| Level 2, enhanced | Data leakage prevention and minimum operating system requirements. Microsoft states this is applicable to most mobile users. | |
| Level 3, high | Advanced data protection, enhanced PIN configuration and mobile threat defence. For users accessing high risk data. | |
| Managed devices | A less strict policy can be applied where the device is already enrolled in Intune. | |
| Unmanaged devices | A more restrictive policy, or a policy applied to unenrolled devices only. | |
| Windows devices | 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
Which populations, which devices, and which of the three framework levels. Microsoft states the enhanced level suits most mobile users, so that is usually the baseline, with a higher level for any population handling high risk data and a lighter one for corporate managed devices.
- 2
Confirm the prerequisites
Conditional Access in place, Company Portal available for Android users, Entra ID device registration for Android Microsoft 365 apps, and confirmation that your mail and file platforms are supported, since Outlook mobile needs Exchange Online or hybrid modern authentication and the Office mobile apps support SharePoint Online rather than on-premises.
- 3
Communicate the boundary before deploying
A short, specific message explaining that policies apply only in the work context, that personal accounts and personal data in the same application are untouched, and that a wipe removes company data without affecting the phone. This is the step that determines how the rollout is received.
- 4
Pilot, then widen
A representative group across the device types and applications that matter, testing the PIN experience, the copy and paste restrictions, and the behaviour when data is shared outside a managed app. Microsoft even suggests validating the iOS encryption behaviour by trying to open a corporate file outside a managed application, which is a useful pilot test.
- 5
Connect it to the leaver process
Selective wipe should be part of offboarding rather than something somebody remembers. It removes company data from the applications without touching the device, and the wipe is picked up within thirty minutes or at next sign-in, which makes it a practical step in a real process.
What organisations 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 leaver 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 enrolment 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.
MDM solutions
The wider device management picture across Windows, Apple and Android, and when enrolment is the better answer.
If enrolment 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
Mobile Threat Defense
Device risk into Conditional Access, and the connector that fails open
Microsoft Intune
Device management and endpoint security
Entra Conditional Access
The control that decides who reaches your data
MDM Solutions Dubai
Device management across Windows, Apple and Android
Intune Suite
Eight advanced capabilities, and one trial each per tenant
iPhone and iPad Management
Remove company data from a phone you do not own
DLP Solutions
Microsoft Purview DLP and labels
Endpoint Security
Defender for Endpoint and Intune managed