Intune App Protection for BYOD Without Device Enrollment

Start from who owns the device and what you need to control. If the phone is the employee's and you need to protect the company data in Outlook, Teams, the Office apps, OneDrive and Edge, app protection (MAM) does that without enrolling the device and without IT seeing the rest of the phone — Microsoft's guidance recommends it for personal devices. If the device is organization-owned, or you need device-level controls — OS-update rules, Wi-Fi and certificate profiles, a compliance check before access, a full wipe — you need enrollment (MDM), and Microsoft recommends enrolling organization-owned devices and layering app protection on top where specific apps need it. Most organizations end up with both: MAM for personal phones, MDM for corporate ones. This engagement writes that split down in a decision record on Day 1 and builds the MAM half; the MDM half is the Intune enrollment service for each platform.

Inside the Microsoft apps you sign into with your work account: IT can require a PIN or biometric, encrypt the work data, stop it being copied, saved or shared into personal apps, require links to open in Microsoft Edge, block the apps on a jailbroken or rooted phone, and remove the work data — only the work data — when you leave. Outside those apps: nothing. The device is not enrolled, so IT cannot see your personal apps, photos, messages or location, cannot push settings to the phone and cannot wipe it. The phone does get registered with Microsoft Entra ID through Microsoft Authenticator (iOS) or Company Portal (Android) so Conditional Access can recognise it; registration is not enrollment, and the registration guide we hand over explains the difference in plain words.

Any Conditional Access policy that still uses that grant became read-only on that date: you can disable or delete it, but not edit it, and new policies can only use 'Require app protection policy'. Microsoft's current documentation says the old policies keep enforcing while enabled; its earlier retirement notice said the grant would stop applying. Either way you cannot adapt them to a new app or a new group of users, so they no longer function as a control you can manage. The replacement grant only works when an Intune app protection policy is actually assigned to the user and the app — so the fix is not a one-line policy edit; it is building the app protection policies, adding the new grant, proving it on a pilot and then disabling the old policy. That is exactly the sequence in this engagement.

Any app built with the Intune App SDK that a user signs into with a work account: Outlook, Teams, Word, Excel, PowerPoint, OneNote, OneDrive, SharePoint, Microsoft Edge, To Do, Planner, Loop, Viva Engage, Power BI, Power Apps and the rest of Microsoft's protected-apps list, plus third-party apps their vendors have integrated with the SDK. Native mail, calendar and browser apps cannot receive a policy, so the Conditional Access grant denies them access to work data — which is the intended outcome. Line-of-business apps your developers built need the SDK or app wrapping first; that is separately scoped.

On iOS or iPadOS they install Microsoft Authenticator if they do not already have it, sign into Outlook or Teams with their work account, accept a short registration prompt, and set an app PIN or use Face ID or Touch ID. On Android they install Company Portal and the Microsoft apps, sign in, and Company Portal registers the device — it does not enroll it — then they set the PIN. From then on the work apps ask for the PIN or biometric after the inactivity period you chose, copy and paste into personal apps is blocked or limited as designed, save-as offers only approved locations such as OneDrive, and links open in Edge. Personal apps are untouched. Users may need to restart an app once for the policy to apply; the registration guides cover that.

No — and that is deliberate. The native Mail app cannot carry an Intune app protection policy, so once 'Require app protection policy' is enforced it is denied access to the mailbox. Users move to Outlook, where the policy applies. The readiness check finds who is on native mail today, the communications tell them what to install and when, and the rollout is ordered so nobody is cut off before they have Outlook working. The companion control we build makes sure Exchange ActiveSync clients cannot slip around the policy either.

Two things, and both are in the runbook. First, disabling the account in Microsoft Entra ID triggers the 'disabled account' conditional-launch action, which blocks or wipes the work data in the protected apps automatically at the next check-in. Second, an administrator can issue a selective wipe from the Intune admin center for any user at any time — it removes the work data from the Microsoft apps on that device and leaves personal data alone. The wipe takes effect at the next app launch or the SDK's periodic check, which Microsoft documents as every 30 minutes while the app is running. Nothing about this requires the device to be enrolled or the employee to hand the phone over.

Every user in scope needs an Intune licence and Microsoft Entra ID P1 or P2 for the Conditional Access policy. Both are included in Microsoft 365 Business Premium, E3, E5 and F3 and in Enterprise Mobility + Security E3 and E5; if you are on Business Basic or Standard, Intune Plan 1 and Entra ID P1 can be added per user. Outlook also needs an Exchange Online mailbox and the Office apps need Microsoft 365 Apps — Microsoft's stated requirements for the apps to accept a policy. We confirm all of this from your licence report on Day 1, before any policy is assigned. Licences are yours and are not part of our fee; the subscription pages linked from this page show current pricing.

Partly, and we are careful about it. Windows MAM applies an app protection policy to Microsoft Edge on a personal Windows device that is not joined or enrolled to any tenant — so work sites opened in Edge get the protections, and Conditional Access can require it. It covers Edge only: not Outlook desktop, not Office desktop apps, not the file system. Microsoft's Intune documentation describes it as available, while its Conditional Access documentation still labelled the Windows grant as preview at the time of writing, so we treat it as optional and confirm your devices qualify in the readiness check. If people need full Office on a personal PC, the answer is usually a managed device, Windows 365 or Azure Virtual Desktop — a different conversation we will have with you honestly.

The fee is a tenant fee plus a per-user fee — see the price on this page. The tenant fee covers the design, the policies, the Conditional Access work, the pilot and the documentation. The per-user fee is counted once for every user in the target group agreed at kickoff and covers the rollout support that scales with headcount: registration guides, communications, help-desk escalation during the rollout window and the status review before sign-off. Worked example on the listed rates: 100 users is $500 plus the $1,950 tenant fee, $2,450 in total; 250 users is $3,200. Organizations above roughly 1,000 users are quoted as a scoped project. Licences are separate. The price is fixed in writing before work begins, and you pay after you approve delivery.

One week: readiness and the decision record on Day 1, policies built in report-only on Day 2, pilot on Day 3, rollout wave on Day 4, status review and handover on Day 5. That assumes licences are assigned before kickoff, the decision record is approved on Day 1, pilot users are available on Day 3 and no Conditional Access redesign is needed first. Very large or multi-region rollouts can be staged in waves after the pilot; that changes the calendar, not the scope.

No — it completes the picture. App protection policies are targeted by management state, so the policies built here apply to unmanaged devices and leave your enrolled fleet alone; if you also want app-level protection on enrolled devices, that is a second policy set targeted to managed devices, which the decision record covers and the enrollment services configure. The Conditional Access policy is written so an enrolled, compliant device or an app carrying a protection policy both satisfy it — one policy, both populations.

Usually yes. Existing policies are often unassigned, assigned to the wrong group, targeted to all device types instead of unmanaged ones, or never enforced by Conditional Access — which the June 2026 retirement made visible for many tenants. The readiness check reviews what is there, the decision record says what to keep, merge or replace, and the fee is the same fixed price. We do not rebuild what already works.

Screenshots of work data can be blocked as a policy setting on iOS/iPadOS and Android, and we can enable it where the decision record calls for it. A photograph of the screen with another device cannot be prevented by any software, and on iOS the share sheet can still hand work content to an unmanaged app because Microsoft's app protection does not control the share extension without managing the device. App protection makes accidental and casual leakage hard; it is not a defence against a determined insider, and we say so rather than oversell it.

You receive the decision record, the as-built configuration, the selective-wipe and offboarding runbook, the administrator runbook, the registration guides and the recorded handover session, and your administrators run it: new joiners register, leavers are wiped, and policies are adjusted as apps and OS versions move. If you would rather we ran it, the Managed Microsoft Intune Service covers ongoing operation. Organizations that buy their Microsoft licensing through IT Partner also get break-fix support during business hours at no extra charge, so a registration problem after handover is a ticket, not a quote.