BYOD without enrolment: protecting data with Intune app protection policies

Protecting the app rather than the device

Enrolling a personal smartphone in Intune gives the organisation visibility and control over the device that many employees, quite reasonably, refuse. App protection policies (often called MAM, for Mobile Application Management) tackle the problem from the other end: they do not manage the phone, only the corporate content inside compatible apps such as Outlook, Teams, OneDrive, Edge and the Office apps.

In practice, the user signs in with their work account in a managed app; the policy then applies to that account, and only to that account. Their photos, personal messages and other apps stay out of reach. On iOS, Microsoft Authenticator acts as the broker; on Android, the Company Portal app must be installed, even without enrolment.

Data transfer settings

This is the heart of the policy, and where we most often find overly permissive values. The key settings:

• Send organisation data to other apps: limit to policy-managed apps, so an attachment cannot be opened in any personal app;
• Save copies of organisation data: block saving outside approved locations (the organisation's OneDrive and SharePoint);
• Cut, copy and paste: restrict to managed apps, possibly allowing paste in;
• Receive data from other apps: decide whether external content may enter managed apps;
• Encryption of organisation data and blocking backups to personal backup services.

Microsoft publishes a data protection framework with several levels, from basic to high protection. It is a good starting point that saves configuring everything by hand; it still needs to be adapted to how people actually work.

Conditional launch

The policy can also make access depend on the state of the device and the app, without enrolment: minimum operating system and app versions, jailbroken or rooted devices, maximum PIN attempts, and an offline grace period after which access is blocked and the data wiped. An app-specific PIN, or biometrics, adds a barrier if the phone is unlocked and left unattended.

Making the policy mandatory with Conditional Access

An app protection policy that is not required protects nothing: the user can always fall back to the phone's native mail client or an unmanaged browser. Conditional Access is what closes the door. The usual pattern:

1. a policy targeting the iOS and Android platforms, for Office 365 apps;
2. the "Require app protection policy" grant control;
3. a complementary policy for mobile browsers, so that managed Edge is required rather than any browser;
4. blocking legacy authentication, which would otherwise bypass the whole set-up.

Microsoft has announced the retirement of the "Require approved client app" control in favour of requiring an app protection policy; if your policies still rely on it, check the current state of that retirement and migrate.

Selective wipe

When an employee leaves or loses their phone, selective wipe removes only the corporate data held in managed apps, leaving the rest of the device untouched. The request is made from the Intune console for a given user and device, and runs the next time the app is opened. Disabling the account and revoking sessions remain essential alongside it: the wipe cleans up data already on the device, it does not cut off access.

What an audit checks

• App protection policies for iOS and Android, assigned to every relevant user.
• Data transfer settings: sending, saving, copy and paste, backup.
• Conditional launch settings: minimum versions, jailbroken devices, offline period.
• Conditional Access policies requiring app protection, with no bypass path (native client, browser, legacy authentication).
• The leaver process: selective wipe, session revocation, account disablement.