Intune App Protection for Personal Phones: Secure Outlook Without Enrolling

What app protection does on a phone you do not own

You can protect Outlook and the other Microsoft 365 mobile apps on a personal phone without enrolling the phone in Intune. Rather than managing the device, you manage the company data inside the apps. An app protection policy follows the work account: it puts a PIN in front of work content, limits where that content can be copied or saved, and lets you remove only the work data from those apps later. Microsoft calls this mobile application management (MAM) without enrolment. Everything else on the phone stays the owner's business.

The alternative is mobile device management (MDM), where the phone is enrolled and you can push settings, apps and certificates and, if it comes to it, factory-reset the handset. That is a fair trade for a company-owned phone. For BYOD (bring your own device) it is often more control than the situation justifies, and staff are entitled to be wary of it. MAM draws the line at the app. Policies apply only in a work context: a personal account in the same app is left alone, and a brand-new document counts as personal until it is saved to a work location such as OneDrive.

Start with a small pilot group (Lab Mobile Pilot in these steps), two licensed users and their own phones. Before trying selective wipe, make sure each participant understands which work data may be removed. Keep policy assignments limited to the pilot until you have checked the result.

Before you begin

This is the short list of things that stop the exercise working. Everything else can wait for a later article in the series.

• Licences: every user the policy targets needs an Intune licence assigned. Microsoft says an unlicensed user does not receive the policy. Microsoft 365 Business Premium and the E3/E5 bundles include Intune. Business Basic and Business Standard come with Basic Mobility and Security instead, and Microsoft's own comparison table lists mobile application management under Intune only.
• Mailbox: Outlook for iOS and Android supports app protection with an Exchange Online mailbox, or on-premises Exchange with hybrid modern authentication. It does not support Exchange in Office 365 Dedicated.
• Word, Excel and PowerPoint also need a Microsoft 365 Apps licence, and a managed location such as OneDrive configured, because Intune decides what counts as work data by where it came from (Exchange email or a work OneDrive account).
• Phone software: Intune requires iOS/iPadOS 17 or later and Android 10 or later for app protection. The Microsoft apps themselves can demand newer versions, so check the Office mobile system requirements before you promise anyone support.
• Android only: the Company Portal app must be installed. The phone is still not enrolled, but much of the app protection logic lives in Company Portal. Microsoft 365 apps on Android also need the device registered with Microsoft Entra ID, which the user is prompted to complete at sign-in.
• Admin access: someone who can create app protection policies and selective wipe requests in the Microsoft Intune admin center. For a lab, the Intune Administrator role is simplest. Work out a narrower role before you do this in a real tenant.
• Test people: two lab accounts with mailboxes and licences, and phones whose owners understand the work account will be wiped from Outlook during the exercise. Do not use a real colleague's phone for the first run.

Choose the settings before you click anything

Microsoft groups app protection settings into three levels. Level 1 is the minimum (PIN, encryption, selective wipe). Level 2, which Microsoft describes as applicable to most mobile users accessing work data, adds data-leakage controls and a minimum OS version. Level 3 is for high-risk users and can have significant user impact. For a BYOD pilot, Level 2 is the sensible starting point, with a few changes of our own where noted. Settings are named slightly differently on each platform, so the iOS/iPadOS label comes first and the Android label second where they differ.

The point of the data-transfer settings is simple: if work content can only travel between apps that carry the same policy, copying an attachment into a personal notes app or messaging app stops being possible without the user doing anything unusual.

• Data protection - Backup Org data to iTunes and iCloud backups (iOS/iPadOS) or Backup org data to Android backup services (Android): Block. This keeps work data out of personal cloud backups.
• Data protection - Send org data to other apps: Policy managed apps. This is the setting that does the heavy lifting.
• Data protection - Receive data from other apps: leave at All Apps for the pilot. Tightening it to Policy managed apps is a Level 3 control and stops people opening files sent from unmanaged apps.
• Data protection - Save copies of org data: Block, then under Allow user to save copies to selected services choose OneDrive and SharePoint only. Microsoft's Level 2 also lists Photo Library; leave it off for a straightforward pilot. The save-copies controls only become configurable once Send org data to other apps is set to Policy managed apps.
• Data protection - Restrict cut, copy and paste between other apps: Policy managed with paste in. Users can paste into the work apps from anywhere but cannot copy work content out to unmanaged apps.
• Data protection - Restrict web content transfer with other apps: Microsoft Edge. Links tapped in Outlook open in a policy-managed browser. Users without Edge are prompted to install it, so warn them.
• Data protection - Org data notifications: Block org data (Block Org Data on iOS/iPadOS). This stops org data appearing in operating-system notifications, including on connected wearables.
• Data protection - Android only: Screen capture and Google Assistant: Block. This blocks screenshots of work content. iOS/iPadOS has a separate Screen capture setting that defaults to Allow and depends on a recent Intune SDK in the app, so treat it as optional.
• Data protection - Encrypt Org data (iOS/iPadOS) or Encrypt org data (Android): Require, which is the default.
• Access requirements - PIN for access: Require. PIN type: Numeric. Simple PIN: Block. Select minimum PIN length: 6. Microsoft's Level 2 allows simple PINs with a minimum of 4. Stricter costs the user almost nothing, so that is our judgement call rather than Microsoft's recommendation.
• Access requirements - Recheck the access requirements after (minutes of inactivity): leave at the default of 30. Leave biometrics at their defaults.
• Conditional launch - Max PIN attempts: leave at the default of 5 with Reset PIN. Offline grace period: leave the defaults (1440 minutes block, 90 days wipe).
• Conditional launch - Add Jailbroken/rooted devices with Block access, and Disabled account with Block access. Both are in Microsoft's Level 1 and Level 2 tables.
• Conditional launch - Add Min OS version with the action set to Warn first. Microsoft recommends matching the OS versions its own apps support, on an N-1 basis. We are deliberately not giving a number, because it changes: look up the current supported version rather than guessing.
• Leave alone for now: extra Wipe data actions, Android Play integrity verdict, Samsung Knox attestation, Mobile Threat Defense and device lock complexity. Each can lock out legitimate users, especially on older or unusual handsets. Add them once the pilot shows who would be caught.

Create the pilot group and the two policies

App protection policies target users through groups, not devices, and nothing happens until a group is assigned. Start with a small group so a mistake affects two people rather than the whole firm. The policy wizard asks for a platform first, so you build two policies, one for iOS/iPadOS and one for Android.

Target Core Microsoft Apps rather than Outlook alone. If you limit data transfer to policy managed apps but only Outlook carries a policy, an attachment cannot be opened in Word or Excel without leaving the protected zone. Core Microsoft Apps covers Edge, Excel, Office, OneDrive, OneNote, Outlook, PowerPoint, SharePoint, Teams, To Do and Word, which is also what Microsoft's framework targets.

1. Create a security group named Lab Mobile Pilot and add the two test users, who must already have an Intune licence and a mailbox. Microsoft says security groups can be created in the Microsoft 365 admin center. Use a plain assigned group, not All users.
2. Sign in to the Microsoft Intune admin center and select Apps > Protection. Select Create policy, then iOS/iPadOS.
3. On the Basics page, name the policy Lab-MAM-iOS-Pilot and add a short description. Select Next.
4. On the Apps page, set Target policy to to Core Microsoft Apps. Select View a list of the apps that will be targeted if you want to confirm Outlook is in the list. Select Next.
5. On the Data protection page, set the values from the previous section. Select Next.
6. On the Access requirements page, set the PIN values. Select Next.
7. On the Conditional launch page, add Jailbroken/rooted devices, Disabled account and Min OS version using the Select one dropdown, and set each action as described above. Select Next.
8. On the Assignments page, include only Lab Mobile Pilot. Do not add All users. If you later need one policy for unenrolled phones and a different one for managed phones, Microsoft supports that with assignment filters (Edit filter on this page), but you do not need that when piloting on unenrolled phones.
9. Select Next to reach Review + create, check the summary, then select Create.
10. Repeat from Apps > Protection > Create policy, this time choosing Android. Name it Lab-MAM-Android-Pilot and use the Android labels for the same settings.
11. Back on the Protection list, both policies should now appear. Policies are not instant. Microsoft says the service typically refreshes about every 30 minutes for a registered user, so give it that long before concluding anything is wrong. If a test user opened Outlook before they were in the group, the app may wait for its next retry interval (see the troubleshooting section).

Test on a real phone and record the evidence

The aim here is to see each setting do something. Take a note of the phone model, operating system version, app version, what you tried and what happened. That small record becomes your test evidence and is worth keeping for the pilot sign-off later in the series.

1. On the test phone, install Outlook and Microsoft Edge from the App Store or Google Play. On Android also install the Company Portal app. You are not enrolling the phone, so do not go through any device setup beyond what the apps ask for at sign-in.
2. Open Outlook and sign in with the test user's work account. On Android you may be asked to register the device with Microsoft Entra ID. Complete that. It is device registration for sign-in, not Intune enrolment.
3. Wait for the policy to arrive, which may take around half an hour. Microsoft says users see a notification on the device when the policy applies. Now is a good moment to answer the email you have been avoiding.
4. Open a work email. When you try to access work content, Outlook should ask the user to create an app PIN that meets your rules. Yes, that is a second PIN on top of the phone's own passcode, and staff will mention it. Explain it before the pilot starts and save yourself the questions.
5. Try to copy text from a work email and paste it into a personal notes app. The work text should not paste. Pasting text from elsewhere into a work email should still work, because of the 'with paste in' setting.
6. Try to save or share a work attachment to the phone's local storage or a personal app. Saving to OneDrive or SharePoint should be offered. On iOS/iPadOS the share sheet may still list unmanaged apps: Intune cannot control that extension without managing the device, so it encrypts the file instead. The test passes if the file will not open in the unmanaged app.
7. Tap a web link in an email. It should open in Microsoft Edge. On Android, try a screenshot of a work email, which should be blocked.
8. If you want to see the personal side, add a personal mailbox to Outlook and confirm that content from it is not restricted. Outlook shows a combined view of personal and work mail, so it prompts for the Intune PIN on launch.
9. In the Microsoft Intune admin center, select Apps > Monitor > App protection status and find the test user. You should see Outlook, the platform, a Management type of unmanaged, the policy name, a recent Last sync and the app marked as protected. The report can lag the phone by some minutes.
10. Optionally, in Microsoft Edge on the phone, open about:Intunehelp. Microsoft lists it as a way to check which policy settings are applied to a given app on the device.

Practise a selective wipe safely

A MAM selective wipe removes the work account and its data from the protected apps. It does not factory-reset the phone, touch personal accounts or photos, or remove the apps themselves. Anything Outlook synced directly into the phone's native contacts is removed, but contacts synced from the native address book to another service cannot be wiped. Full device wipe and remote lock need MDM enrolment, so they are not available here.

Do this only on a test phone whose owner knows what is about to happen, with no unsaved work in the app. Use the device-based request below. The User-Level Wipe option in the same area issues wipes to all of that user's devices and keeps doing so at every check-in until an administrator removes the user from the list, which is the wrong tool for a small pilot.

1. Confirm the test user is signed in to Outlook on the test phone and has some mail visible.
2. In the Microsoft Intune admin center, select Apps > App selective wipe > Create wipe request.
3. Select Select user, choose the test user, and select Select. Then select Select the device, choose the test phone, and select Select. On iOS 16 and later the device name appears as a generic name, so identify the phone by its type and the user.
4. Select Create. The service creates a separate request for each protected app on that phone, so expect several rows for one user.
5. On the phone, open Outlook. The wipe happens when the app runs, and Microsoft says it can take up to 30 minutes after the request. If the app is already open, it checks for wipe requests about every 30 minutes.
6. Check both sides. On the phone, the work account and its mail should be gone from Outlook while personal items remain. In the admin center, the requests under Apps > App selective wipe should move from pending to successful. Completed entries stay in the report for four days.
7. Tidy up. Any request that stays pending is displayed until you delete it, so right-click it and choose Delete wipe request. Then sign the test user back in to Outlook to confirm the policy applies again and the PIN prompt returns.

What stays open without device management

This approach is genuinely useful, but it is narrower than MDM. Be honest about that with whoever is signing off the risk. The NCSC's BYOD guidance says the challenges should not be played down, that effectiveness depends on how thoroughly the device can be managed, and that the privacy expectations of the device owner have to be balanced against organisational control. App protection sits at the lightly-managed end of that spectrum. In our judgement it suits email and documents for ordinary staff and is a weaker answer for people handling highly sensitive data. Nothing here has been tested by us on a real device, so any claim to your auditor needs your own test record behind it.

Microsoft's documentation lists the main constraints:

• Apps are not deployed. Users get Outlook and the rest from the app store themselves.
• No certificate, Wi-Fi or VPN profiles reach these phones.
• No factory reset, remote lock or device inventory. Your visibility is per app instance, through the App protection status report (user, app, platform version, last sync, Android model and patch level and similar).
• Protection applies only inside protected apps. The phone's built-in mail app, an unmanaged browser or an old Exchange ActiveSync client can still reach the mailbox unless Conditional Access requires an app protection policy. The Conditional Access grant is called Require app protection policy. Build it in Report-only mode first, exclude your emergency access accounts, and apply the app protection policies to the pilot phones before you turn it on. Microsoft's grant-controls page says the older Require approved client app grant retired in early March 2026 and that new policies should use only Require app protection policy, while the step-by-step page still shows both ticked, so check the current portal before you build it. A later article in this series covers it properly.
• Device-level checks are limited to what conditional launch offers, such as minimum OS version, jailbreak or root detection and, on Android, device lock and integrity checks. You cannot force a phone to update or to have a passcode in the way MDM can.
• Staff should be told what you can and cannot see. A short, plain note that you can see which work apps are protected and can remove work data, but cannot read personal content or wipe the phone, prevents the rumours.

If it did not work

Most failures come down to licensing, group membership or timing.

• No PIN prompt and no policy: check that the user has an Intune licence, is in Lab Mobile Pilot, and signed in to the app with the work account. Confirm the policy's Apps page includes the app. Microsoft's retry intervals before registration are 12 hours if the user is unlicensed or has no policy assigned (24 hours on older Android SDKs), 12 hours if the app is not in the policy, and 24 hours if the tenant has not been onboarded. Once registered, updates typically arrive in about 30 minutes. Retries need the app to be launched, so close and reopen it.
• Android shows nothing: confirm Company Portal is installed and that the user finished the Microsoft Entra registration prompt.
• Management type says MDM rather than unmanaged: the phone is enrolled somewhere, or a device-management-state filter is excluding it. Check how the policy is targeted.
• iPhone asks for two PINs: this happens when two apps from the same publisher were built with different Intune SDK versions (before or after 7.1.12, or 14.6.0). It is expected and fades as apps update.
• Locked out after too many wrong PINs: with the default of 5 attempts and Reset PIN, the user resets by signing in with their work account and completing multifactor authentication if prompted.
• Wipe request stuck as pending: the user has to open the app, and it can take up to 30 minutes. Delete stale requests once you are finished.
• Report-only Conditional Access shows Report-only: Failure even though everything seems fine: Microsoft notes this is expected for the app protection control in report-only mode, because the control is not enforced until the policy is on.
• To back out the pilot: in Apps > Protection, select the policy, then Properties, then Edit next to Assignments, remove Lab Mobile Pilot from the Include tab and select Save. Enforcement should stop at the next refresh, typically about 30 minutes. Removing a policy assignment does not guarantee that existing work data is removed. Confirm the data-removal outcome on a pilot device and use selective wipe where appropriate.

Optional: read the policies back with Microsoft Graph

The portal is the supported route for building these policies in this article. If you want a scripted check of what is configured, Microsoft Graph has a read-only call for iOS/iPadOS app protection policies in the v1.0 endpoint, which needs the DeviceManagementApps.Read.All permission (delegated or application). Run it in PowerShell with the Microsoft Graph PowerShell SDK installed, signed in as an administrator who can consent to that read-only scope. It only reads. It changes nothing and returns policy names and the key settings we chose above.

The script does not handle paging, so use it only for a small number of policies. Android has an equivalent endpoint, androidManagedAppProtections; confirm its property names in the current Graph reference before adapting the script. Microsoft's mggraph-intune-samples repository also contains sample JSON templates for the three protection levels. Read any template line by line before importing it into a tenant.

Connect-MgGraph -Scopes "DeviceManagementApps.Read.All"
$response = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/deviceAppManagement/iosManagedAppProtections"
$response.value | ForEach-Object {
    [pscustomobject]@{
        Name             = $_.displayName
        Assigned         = $_.isAssigned
        PinRequired      = $_.pinRequired
        MinimumPinLength = $_.minimumPinLength
        SimplePinBlocked = $_.simplePinBlocked
        OutboundTransfer = $_.allowedOutboundDataTransferDestinations
        SaveAsBlocked    = $_.saveAsBlocked
    }
} | Format-Table -AutoSize