Intune App Protection for BYOD Without Device Enrollment is a one-week, fixed-fee implementation that protects Microsoft 365 data inside the Microsoft apps on employees' personal iPhones, iPads and Android phones — without enrolling the device, and without IT seeing or controlling anything outside those apps. IT Partner designs and builds Intune app protection policies for Outlook, Teams, the Office apps, OneDrive and Edge (PIN or biometric, encryption, cut/copy/paste and save-as restrictions, managed-browser links, offline grace period, jailbroken and rooted-device block), enforces them with a Microsoft Entra Conditional Access policy that uses 'Require app protection policy' — the control that replaces 'Require approved client app', which Microsoft retired on June 30, 2026 — adds Windows MAM for Microsoft Edge where it fits, writes the selective-wipe runbook and the per-platform registration guide, and proves it on a pilot before the rollout wave. The fee is a tenant fee plus a per-user fee for the users you roll out to. Every user in scope needs an Intune licence (Intune Plan 1 is included in Microsoft 365 Business Premium, E3, E5 and F3); licences are yours and are not part of the fee. Corporate-owned devices that need device-level control are covered by the Intune enrollment services for iPhone and iPad, Android, Windows and macOS.
There are two ways to protect company data on a phone an employee owns, and choosing between them is the first decision. Mobile device management (MDM) enrolls the device: IT gains device-level control — compliance checks, OS-update rules, Wi-Fi and certificate profiles, full or selective wipe — and the employee accepts that the organization can see the device in Intune. Mobile application management (MAM) never enrolls the device. An Intune app protection policy lives inside each Microsoft app the employee signs into with a work account — Outlook, Teams, Word, Excel, PowerPoint, OneNote, OneDrive, SharePoint, Edge and the other apps built on the Intune App SDK. Inside that boundary IT can require a PIN or biometric, encrypt work data, stop it being copied, saved or shared into personal apps, and wipe it when someone leaves; outside that boundary the phone stays the employee's. For personal devices Microsoft's own guidance recommends MAM; for organization-owned devices it recommends enrollment, with MAM layered on top where specific apps need extra protection. This service is the MAM half. The enrollment half is Microsoft Intune Initial Setup for iPhone & iPad Management and Microsoft Intune Initial Setup for Android Device Management. IT Partner runs the readiness check (licences, existing Conditional Access, current MDM state, the apps people actually use on their phones, iOS/iPadOS and Android version spread), writes a one-page decision record for which users get MAM, which get enrollment and which get both, then builds the policies: one app protection policy for iOS/iPadOS and one for Android, targeted to unmanaged devices and to the Microsoft core apps, assigned to a security group; a Microsoft Edge app-configuration policy so links from Outlook and Teams open in the managed browser; and the Conditional Access policy that makes the whole thing enforceable — 'Require app protection policy' for iOS/iPadOS and Android, started in report-only, switched on for the pilot group, then for production. Where the organization has personal Windows PCs reaching Microsoft 365 through a browser, we add the optional Windows MAM policy for Microsoft Edge. We validate on a pilot of up to ten users, support the rollout wave, and hand over the selective-wipe runbook, the registration guides and the app-protection status report your administrators will use from then on. Why now: on June 30, 2026 Microsoft retired the Conditional Access grant 'Require approved client app'. Policies that still contain it are read-only — they can be disabled or deleted but not edited — and Microsoft's guidance is that every new policy use 'Require app protection policy' instead. Microsoft's current documentation says the old policies keep enforcing while they stay enabled; its earlier retirement notice said the grant would simply stop applying. Either way they can no longer follow your app mix or your user population, so treat them as a liability rather than a control. And the replacement grant only does anything if an Intune app protection policy is actually assigned to the user and the app — which is why this engagement builds both halves together and migrates any policy that still names the retired grant. The broader design of your Conditional Access estate is its own service: Microsoft Entra ID Conditional Access Policy Implementation; our article Microsoft Entra ID Conditional Access: Real-World Design Patterns shows where the app-protection grant sits in a full policy set and why policies should not be left in report-only. Who this is for: organizations of roughly 25–1,000 users on Microsoft 365 whose employees read mail and Teams on their own phones and tablets, and tenants whose Conditional Access still references the retired grant. Who it is not for: corporate-owned fleets that need device-level control (use the enrollment services), kiosk and shared devices, and organizations whose main exposure is a line-of-business app not built with the Intune App SDK — each of those is separately scoped. The fee has two parts. The tenant fee covers the design, the policies, the Conditional Access work, the pilot and the documentation. The per-user fee, counted for every user in the target group agreed at kickoff, covers the rollout support that scales with headcount — the registration guides, the wave communications, help-desk escalation for registration failures during the rollout window, and the app-protection status review before sign-off.
Confirm licences and administrative access, inventory Conditional Access (flagging every policy that names the retired grant), current MDM state and the apps people use on their phones. Decide the populations (MAM, enrollment or both), the protected app set, the protection level, whether Windows MAM is in scope, the pilot users, success measures and client responsibilities. Count the target group for the per-user fee.
Create the iOS/iPadOS and Android app protection policies targeted to unmanaged devices, the Microsoft Edge app configuration policy, the optional Windows MAM policy, and the Conditional Access policy with 'Require app protection policy' in report-only mode with break-glass exclusions. Build the companion control for clients that cannot carry a policy. Review the report-only sign-in evidence.
Pilot users install the broker app (Microsoft Authenticator on iOS/iPadOS, Company Portal on Android) and sign in; verify PIN or biometric, encryption, data-transfer and save-as blocks, managed-browser links, native-mail denial and selective wipe on each platform. Switch the Conditional Access policy on for the pilot group. Correct in-scope issues and record results.
Send the approved communications and registration guides, enable the Conditional Access policy for the target group in the agreed order, run help-desk escalation for registration failures, watch the app-protection status report, and disable each policy that still used the retired grant once its replacement is proven.
Review who is checked in and who is not, close remaining registration issues, finalize the decision record, as-built, selective-wipe runbook and administrator runbook, run the recorded handover session, and confirm acceptance against the success criteria.
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.