BYOD & app protection (MAM)

Corporate email and Teams on personal phones is already happening in your tenant — the only question is whether the data inside those apps is governed. This section ships the Intune App Protection Policies that make BYOD defensible without enrolling anyone's personal device.

Why this matters

BYOD is rarely a decision; it's a default. The moment Exchange Online is reachable, staff add their work account to Outlook — or worse, the native mail app — on a personal phone. Without App Protection Policies, that corporate data sits ungoverned: it flows into personal cloud backups, gets pasted into WhatsApp, and stays cached on the device long after the person has left.

Full MDM enrolment of personal devices is usually a non-starter — staff reasonably refuse, and the privacy conversation goes badly. MAM without enrolment is the workable middle ground: the organisation governs its own data inside Outlook, Teams and Edge, and never touches the personal side of the phone.

There is also a structural dependency most tenants miss. If your Conditional Access policy uses the Require app protection policy grant, App Protection Policies are the layer that grant checks for. Roll out the grant without them and it doesn't degrade gracefully — users are simply locked out of mail on mobile.

What a good build does

Decolla deploys a matched pair of App Protection Policies from the Library — one for iOS, one for Android — into your own Intune tenant, with industry-tested settings rather than blank templates: an app-layer PIN with biometric unlock, encryption of corporate data at rest inside the managed apps, cut/copy/paste restricted to policy-managed apps, save-as blocked to unmanaged locations, and selective wipe that removes corporate data only — personal photos, messages and apps untouched.

It is honestly scoped: this is data protection inside the managed apps, not device management. It will not inventory the phone, enforce a device passcode, or report device compliance — that is MDM, and a different conversation with the user.

Both policies appear as named items in the written plan you approve before anything runs, each with its delivery method and reversibility class stated. Each can be rolled back individually — Decolla removes its own policies cleanly if you change course. And they are designed to pair with the app-protection grant in the Conditional Access work, so the two halves of the control actually reference each other.

Where it bites people

Two classics from the helpdesk queue.

• CA and APP targeting drift apart. The Conditional Access grant requires an app protection policy, but the APP is assigned to a different group — or to an exclusion that no longer matches. Some users are blocked from mail on their phones with no obvious cause; others satisfy the grant with a policy that doesn't apply the restrictions you think it does. Keeping the assignment groups aligned is the whole game, which is why the two are built as a deliberate pair rather than in isolation.
• Android's broker requirement surprises users. App Protection on Android needs the Company Portal app installed on the device — even though the device is never enrolled. Users see "install Company Portal" and assume the organisation is taking over their phone. Without a clear note explaining that it acts as a broker, not enrolment — and that selective wipe cannot touch personal data — the helpdesk absorbs the fallout, and adoption stalls.

What's in this section (2 items)

Reversibility: auto reverses when unassigned · reverse reversible with a documented step · irreversible flagged before you approve the plan.