Protecting Company Data on Personal Phones Without Managing the Phone

Staff read work email on personal phones. That is true whether or not you have a policy about it, and a policy that says otherwise mostly produces workarounds — forwarding to personal accounts, screenshots, copies in messaging apps.

The useful question is not whether to allow it. It is what you protect, and how much of someone's own device you take control of to do it.

Two approaches, and the line between them

Device management (MDM) enrols the whole device. You can enforce passcodes, encryption, OS versions, restrict features, deploy apps and wipe the device. Appropriate for company-owned hardware.

App protection (MAM) protects company data inside specific apps, without enrolling the device. You control what happens to data in Outlook, Teams and the Office apps; you control nothing else on the phone.

For personal devices, app protection is usually the right answer. You get the control that matters — over your data — without acquiring the ability to wipe someone's photos, which is both an overreach and a liability you do not want.

What app protection actually enforces

Applied to the managed apps, policies can:

• Require a PIN or biometric to open the work app, separate from the device unlock
• Encrypt company data within the app
• Block copy and paste from managed apps to unmanaged ones, or allow it only between managed apps
• Prevent "Save As" to personal storage, allowing only approved locations
• Block screenshots on Android (iOS does not expose this to apps)
• Require a minimum OS version or block jailbroken and rooted devices
• Selectively wipe company data from the app while leaving everything personal untouched
• Enforce a timeout after which the PIN is required again
• Block backup of company data to personal cloud backups

The selective wipe is the key capability. When someone leaves, you remove company data from their personal phone without touching anything of theirs — and crucially, without needing their cooperation or their device in your hand.

The configuration that works

A reasonable starting baseline:

• PIN required, six digits or biometric, with a short timeout
• Data transfer restricted to managed apps only
• Save As blocked except to approved cloud storage
• Minimum OS version set, and raised on a schedule
• Jailbroken and rooted devices blocked
• Offline grace period of a few days, after which access is blocked until the device checks in

Then the piece that makes it enforceable: a Conditional Access policy requiring an approved client app or app protection policy for access to Exchange and SharePoint from mobile. Without that, the policies apply only to people who happen to use the managed apps, and anyone using the built-in mail client bypasses the whole thing.

That combination — app protection plus Conditional Access requiring it — is what turns a setting into a control.

What you give up

Be honest about the limits, because they matter:

• No visibility into device health. You cannot tell whether the phone is patched beyond what the app can see, or whether it is carrying malware.
• Only managed apps are covered. Data a user has already extracted through a permitted route is outside your reach.
• No certificate-based network access. Deploying a Wi-Fi or VPN certificate requires enrolment.
• Platform differences. iOS and Android expose different capabilities; screenshot blocking is the obvious example.

For most organisations handling ordinary business data on personal phones, these are acceptable. For devices handling regulated data in a high-risk environment, full management of a company-owned device is the right answer and should be budgeted for rather than argued around.

The conversation with staff

App protection succeeds or fails on whether people believe you. The message that works, because it is true:

We are not managing your phone. We cannot see your photos, your messages, your apps or your location. We cannot wipe your device. We are protecting work data inside work apps, and when you leave, we remove only that.

Say it explicitly, in writing, before deployment. The alternative — people discovering a new PIN prompt with no explanation — generates exactly the resistance that drives data onto unmanaged paths.

And mean it. If your policy does allow something more intrusive, say that instead. Nothing erodes cooperation faster than a reassurance that turns out to be inaccurate.

Where this fits with everything else

App protection handles personal mobile devices. It does not replace:

• Device management for company-owned hardware, where full control is appropriate and expected
• Conditional Access, which decides whether the sign-in is permitted at all
• Data classification and DLP, which govern the data itself regardless of device
• Offboarding process, which must include the selective wipe as an explicit step

The common failure is deploying app protection, feeling covered, and never adding the Conditional Access policy that makes it mandatory. The policies then protect the users who were going to behave anyway, and nobody else.