> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# App Protection Policies

> Set up MAM-without-enrollment for BYOD — what app protection actually protects (org data in managed apps) and doesn't (the device), with the user-experience honesty that makes BYOD adoption work. Use for "protect company mail on personal phones", MAM policy requests, or "can we wipe company data without touching their photos".

<Info>
  **Category:** Microsoft 365 Administration · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/m365-administration/app-protection-policies/SKILL.md)
</Info>

**Connectors:** `IT Glue` `Hudu`

**Role:** [Technician](/start-here/roles/technician), [Security & Compliance Owner](/start-here/roles/security-compliance-owner)

**Outcome:** Risk & Compliance

**When to use:** A ticket asks to protect company email on personal phones where users refuse MDM, to set up a MAM policy, or to answer "if \<user> leaves, can we remove company data from their personal phone?" or "what can the company actually see on my phone?" Also when a BYOD population is created by a personal-device enrollment block (see enrollment-restrictions). App protection (MAM-WE) draws a container around org data inside managed apps on a device the MSP does not manage — its adoption succeeds or fails on one honest sentence to users: "the company can see and wipe its data in work apps — not your photos, messages, or location." This skill configures the container and delivers that sentence.

**Run it:** on one client's request — you scope, design the policy, and write the comms, a technician runs it in the Intune console (not a Flow: it needs a human at the console).

## Prompt

```
You are preparing an app-protection (MAM-WE) rollout for a technician to execute. You scope, design the policy, and write the comms and rollback; the tech drives the Intune console. Never mark a policy as applied on intention, and never invent platform behavior — verify current platform behavior against vendor docs rather than asserting from memory.

1. Scope and licensing. Confirm Intune licensing covers the target users and identify the BYOD population (which users, which platforms). Docs first: check the client's documentation and the knowledge base for the client's BYOD stance and any existing MAM policy to extend rather than duplicate (skip gracefully if those connectors aren't available).

2. Be precise about what it protects — and put it in every artifact:
   - Protects: org data inside policy-managed apps (Outlook, Teams, OneDrive, Office...) — PIN/biometric to open work apps, encryption of org data, cut/copy/paste and save-as restrictions to unmanaged apps, and selective wipe of org data only.
   - Does not: manage the device, see personal apps/photos/texts/browsing/location, patch the OS, or protect data in apps outside the policy. It also does not make a compromised device safe — pair with conditional launch checks (min OS, jailbreak/root block) for a floor.
   Never describe MAM as "managing" or "securing the phone." Plans or client comms that blur this line get corrected before they ship.

3. Design the policy: target the managed-app set (start with the Microsoft core apps in use), data-transfer rules (org data to policy-managed apps only; decide contact-sync and backup exceptions deliberately — over-tight paste/save rules are the #1 usability complaint), access requirements (app PIN, biometric allowed), and conditional launch (minimum OS, jailbreak/root block, offline grace period, wipe-on conditions). Do not tighten data-transfer rules past what the pilot proves usable; a policy users route around protects nothing.

4. Enforce the gate or it's optional. MAM without a Conditional Access policy granting mail/app access only to protected apps is opt-in security — users on unprotected native mail clients bypass it entirely. Plan the CA "require app protection policy" grant alongside the MAM policy, with report-only soak per the conditional-access-review discipline, and state the user-visible effect: native/unsupported mail apps will stop working; Outlook (etc.) becomes the path. MAM without CA enforcement is labeled "optional protection" in the plan — the client must choose enforcement (or its absence) knowingly.

5. User experience honesty in the comms: what changes (app PIN prompt, work data stays in work apps, native mail stops if CA enforces), what the company can do (wipe org data from work apps), and what it cannot see or touch (personal content, location). This is the adoption make-or-break — BYOD users who suspect surveillance refuse, escalate, or quietly stop reading mail off-hours. Personal-device privacy claims must be accurate for the platforms in question — verify current platform behavior rather than asserting from memory.

6. Approval and pilot. Send an approval request to the client authority: policy settings, the CA enforcement decision and its user-visible effects, comms, pilot group, and rollback (unassign policy; relax the CA grant — both reversible without touching devices). No selective wipe without the standard destructive-action approval; even "org data only" is user-visible and occasionally catches unsaved work. Pilot on real personal devices across platforms; verify the block behaviors AND that legitimate daily flows survive before broadening (schedule the rings as follow-ups).

7. Offboarding tie-in. Record in the client's documentation (leave a note, update the ticket, and update the client's doc system) that a departing BYOD user gets a selective wipe (org data only) as part of offboarding — this is the payoff of the whole setup; wire it into the client's offboarding checklist (see employee-offboarding). Document what/why/when/rollback in the note.

When in doubt about privacy accuracy or CA enforcement scope, do nothing and escalate rather than guessing at platform behavior.
```


## Related topics

- [Safe Attachments and Links Policy](/skill-library/m365-administration/safe-attachments-links-policy.md)
- [Anti-Spam Policy Tuning](/skill-library/m365-administration/anti-spam-policy-tuning.md)
- [IIS Web App](/skill-library/troubleshooting-playbooks/iis-web-app.md)