One BYOD Standard, Every Client: The Tiered Model That Scales

The strict answer to personal devices is the same in every tenant: require managed devices for corporate resources, full stop. The real world answers back. Some clients will be genuinely upset if personal-device access disappears, and the remote and hybrid era has only raised the pressure to flex. The mistake MSPs make is treating each of those conversations as a one-off, which produces a different BYOD posture in every tenant and no way to verify any of them.

The fix is to decide your tiers once, attach a fixed policy stack to each tier, and classify clients into them. This guide builds that standard for Microsoft 365 environments running Entra ID and Intune. By the end you will know how to:

• Limit BYOD use to restricted web access only
• Block downloads of files and email attachments on personal devices
• Enforce managed browsers and restrict cut, copy, and paste
• Lock down corporate data on personal phones
• Apply DLP-style protections to unmanaged Windows devices

Three tiers, decided once#

When it comes to supporting BYOD, the options fall into three buckets:

• No support: personal devices are not enrolled in MDM and get no access (or web-only access at most)
• Limited support: personal devices can be enrolled but must meet minimum requirements such as OS version and antivirus protection
• Full support: personal devices enroll and are fully supported for security configuration and remote updates

Our recommended default tier for clients who need BYOD at all:

• Web-only access with restricted permissions. Restricted meaning no local downloads of documents or email attachments, and cut, copy, and paste blocked to unmanaged destinations.
• No MDM enrollment for personal devices. You can technically auto-enroll personal devices to push more protection, but if limited access is the goal, enrollment becomes an administrative nightmare. Policies scoped to All Devices or All Users start failing on personal hardware, and your reporting and operations pay for it.

Classify every client into a tier, then deploy the corresponding stack below.

The corporate-only tier: what full lockdown looks like#

For clients in the no-support tier, Conditional Access is the main enforcement point, and the right policy depends on the environment:

• Hybrid joined devices with Intune compliance enforced: set the grant controls to require both hybrid join and compliance. This is one of the strictest policies you can enforce.

• Hybrid joined, no compliance policies: require hybrid joined devices alone in the grant controls.
• Cloud-native (Entra joined, not hybrid): create a Block policy scoped to Office 365 apps under Target Resources, then use Filter for Devices under Conditions:

You could simply exclude corporate devices and block everything else, but the filter syntax above shows how to match Entra registered and Entra joined trust types, which comes up in other policy configurations too.

Users outside the criteria see this at sign-in:

Close the enrollment side door too. With auto-enrollment on, users can enroll personal devices into Intune unless you stop them. In the Intune admin center, go to Devices > Enrollment (under Device Onboarding) > Device Platform Restrictions and modify the default policy to block devices classified as personal:

The web-only tier: four building blocks#

Block downloads with app-enforced restrictions#

App-enforced restrictions for SharePoint and Exchange Online limit what unmanaged devices can do inside the web apps. Microsoft documents both ends:

• SharePoint and OneDrive unmanaged device access controls (opens in new tab)
• Limit access to Exchange Online from Outlook on the web (opens in new tab)

These settings let you limit or block repository access on unmanaged devices. Turning them on in SharePoint auto-creates two Conditional Access policies:

• The first enforces the session controls for SharePoint Online, targeted specifically at the browser under Conditions > Client Apps
• The second blocks SharePoint Online for the Mobile and Desktop client apps, with grant controls requiring a compliant or hybrid joined device. If you run cloud-native or have not adopted Intune compliance, update this one to filter on personally owned devices instead.

A detail that surprises people: the policy targets only Office 365 SharePoint Online as the resource, yet the restrictions apply across the Office suite, Word, PowerPoint, Excel, and Teams included. After enforcement, a user signing in to a desktop app on a personal device sees this (an example of signing in to Word post-policy):

In the browser, downloads are blocked and the Microsoft 365 apps show a limited-access banner:

Protect phones with app protection policies, not enrollment#

The MAM side of Intune lets users reach corporate apps on personal phones safely, without the device ever joining MDM. App protection policies can:

• Encrypt corporate data on the device
• Require additional authentication into the app, such as a PIN or Face ID
• Restrict cut, copy, and paste to unmanaged apps
• Restrict Save As
• Block access on jailbroken devices
• Remotely wipe corporate data from the apps at any time, or after a set period of inactivity (90 days, for example)

These belong in your default baseline: they protect corporate data on mobile immediately without taking away the user's flexibility on the go. More detail: App protection policies overview (opens in new tab).

An older recording, but the end-user experience it demos has changed little: watch the MAM walkthrough (opens in new tab).

Make MAM mandatory with Conditional Access#

Pair the app protection policies with a Conditional Access policy scoped to the iOS and Android device platforms, using the grant control Require app protection policies. The effect: users must use an approved Microsoft application to reach corporate resources, which blocks the native mail client on the phone from connecting to email.

The older companion recommendation, requiring approved client apps, is headed for deprecation, so build on app protection policies instead: Microsoft Entra change announcements, March 2023 (opens in new tab).

Force a managed browser on Windows#

App protection policies exist for Windows too, currently scoped only to Edge. The policy adds restrictions like cut, copy, and paste control, documented here: App protection policy settings for Windows (opens in new tab).

Pair it with a Conditional Access policy using the Require app protection policies grant control, scoped to the Windows device platform, and users must sign in to their work or school account in Edge:

Every other browser is blocked. One war story before you deploy: in our testing, enabling this policy while already signed in to the managed Edge profile produced an infinite loop on the Switch Edge profile screen, fixed only by completely removing and re-establishing the profile. A terrible end-user experience. Roll this one out carefully.

What replaced WIP for unmanaged Windows devices?#

Windows Information Protection used to be the answer here, and it was a good one: app-level security on unmanaged devices, much like app protection policies on mobile. Microsoft sunset WIP (opens in new tab) and moved the capability under Endpoint DLP in Purview (opens in new tab).

Endpoint DLP policies are built for any device, but you can approximate a personal-devices-only scope: create dynamic groups in Entra that bucket corporate-owned devices, then exclude those groups from the policy assignment:

The honest critique of this shift: it forces a maturity level with Purview that most MSPs have not reached. Where WIP let you blanket-protect, Endpoint DLP pushes you to define the specific content being protected. Creating the policy means defining conditions:

Then layering the restrictions:

The protections are genuinely good, and maturing data protection practice is the right direction. It is simply a lot to take on at once versus declaring "restrict user capabilities on unmanaged devices across all apps and actions."

The practical takeaway: MAM for Edge plus app-enforced restrictions for SharePoint and Exchange already produce the outcome you would want from Endpoint DLP on unmanaged devices, making these policies largely redundant. Endpoint DLP earns its place when those policies are not enforced, or when you need to scope to particular actions and documents, for example anything carrying a specific sensitivity label.

Supporting enrolled personal devices? Use filters#

For clients in the limited or full support tiers, where personal devices do enter MDM, plan for different policy scopes by ownership. In the Intune admin center, go to Devices > Filters and create a filter matching personal devices:

When scoping policies and configuration profiles assigned to All Devices or All Users, include or exclude that filter. A concrete use case:

• You support personal devices in a limited capacity
• You have a policy syncing OneDrive to devices, which should not touch personal hardware
• You create the OneDrive configuration profile, assign it to All Devices, and exclude the personal-device filter

Rolling the standard across the client base#

There are many valid ways to assemble these pieces, and some environments will justify alternatives. The sequence that works:

1. Inventory which customers can currently reach corporate resources from unmanaged devices. That list is usually longer than anyone expects.
2. Assign each client a tier: no support, limited, or full.
3. Test the stack for each tier, starting with web-only access plus app protection policies on mobile. That pairing delivers flexibility to clients while keeping data under control.
4. Deploy tier by tier, leading with report-only Conditional Access where user impact is uncertain.

One standard, three tiers, every client classified. That is BYOD you can actually verify.