As a general principle, you should always try to institute a strict policy of requiring managed devices to access corporate resources across your customers. You would think selling a customer on this wouldn’t be hard given the security considerations, but the reality is that we will always have customers that will get upset if you don’t allow access on personal devices. In addition, the remote/hybrid world we now live in has driven up demand further to be more flexible in this area. In this article, I wanted to outline security best practices when it comes to supporting access from personal devices in Microsoft 365. This article assumes you are leveraging Entra ID and Intune. By the end of the article, you will know how to:
- Limit BYOD/Personal use to restricted web-access only
- Prevent download capabilities of files or email attachments on personal devices
- Enforce managed browsers and restrict Cut, Copy, Paste capabilities
- Lock down data on mobile devices
- Enforce other DLP related settings to unmanaged devices
Considerations for Corporate-Only Devices
First things first, let’s go through a checklist of what settings/configurations you want to have in place to lock things down to just corporate owned devices.
Conditional Access Policies
Conditional access policies are going to be your main consideration here for locking things down. Depending on the customer environment and how strict you want to lock things down there are some options you have to work with:
- Corporate Devices are hybrid Joined AND compliance policies are enforced with Intune => Here you would modify the grant controls to require both factors to be in place to gain access to corporate resources. In my opinion, this is one of the strictest policies you can enforce.
- Corporate Devices are hybrid Joined AND compliance policies are not enforced => Only require hybrid devices in the grant policy
- Corporate Devices are Entra Joined (not hybrid) => In this situation you can create a Block policy that is scoped to 365 apps in “Target Resources” and modify the “Filter For Devices” under “Conditions” to something like the following:
Technically, you can just exclude the corporate devices and block all others here but I wanted to show how you can filter for Entra ID registered and Entra ID joined devices as well as that could come up for other policy configurations.
Users who do not meet the criteria above would receive the following message when trying to login:
Intune Restrictions
If you have auto-enrollment turned on in Intune, you can restrict users from auto-enrolling personal devices through devices restrictions. In the Intune Admin Center, go to Devices>Enrollment (under Device Onboarding)>Device Platform Restrictions. Here you can modify the default policy to block devices classified as personal:
BYOD Best Practices
The policy I recommend taking up if you do need to support BYOD devices is to:
- Allow web-access only on these devices with restricted permissions.
- When I say restricted permissions, I mean things like blocking local downloads of docs and attachments in email, as well as preventing cut, copy, paste to unmanaged locations.
- Not allowing these devices to join MDM
- You could certainly try to apply more protection by having these devices auto-enroll into Intune but in my experience, if all you are doing is trying to create limited access, enrolling these devices creates an administrative nightmare given we scope many of our policies to “All Devices” or “All Users” in Intune. When these policies start failing on personal devices, it can really mess up our reporting/operations.
When it comes to supporting BYOD in MDM, I’d classify the ways you could do that in 3 buckets:
- No Support => personal devices are not enrolled in MDM
- Limited Support => Personal devices can be enrolled into the solution but must meet minimum requirements such as OS, Antivirus protection, etc.
- Full Support =>Personal devices can be enrolled and are fully supported from security configurations and remote updates
Now lets get into some of the policy configurations.
Use App Enforced Restrictions
You can create app enforced restrictions with SharePoint and Exchange Online to limit users access to these applications on unmanaged devices. The following articles detail this out completely:
As you will notice these policies allow you to limit or block access to these repositories on unmanaged devices. Turning on these settings in SharePoint will create two Conditional Access Policies automatically:
- The first enforces the session controls for SharePoint online and targets this specifically to the browser under Conditions>Client Apps
- The second blocks access to SharePoint online to the Client apps of “Mobile and Desktop clients” along with requiring the grant controls of requiring a compliant device or hybrid joined devices. Note that you could update this one to look at personally owned devices as the filter if you don’t run a hybrid environment or don’t leverage Intune yet for compliance.
Its key to note that while you will notice you are only selecting “office 365 SharePoint” as the target resource in the Conditional Access Policy, this enforces these restrictions across the office suite such as Word, PowerPoint, Excel, along with Teams. After this policy is enforced users trying to sign in to Desktop applications on personal devices will receive the following message (this is an example of me trying to sign into Word after the policy was enforced):
If they are in their browser, they will be prevented from downloading documents locally and will get a message in the 365 apps:
Mobile Access-App Protection Policies
The MAM side of Intune allows you to let users access corporate apps on their personal cell phones in a secure fashion. These policies allow you to configure security settings such as:
- Encrypting the data on the device
- Requiring additional authentication to get into the app such as a pin, faceID, etc.
- Restricting Cut, copy, paste to unmanaged apps
- Restricting save as
- Preventing access on Jailbroken devices
- Remotely wiping data on these apps at any time or after a certain period of inactivity (i.e. 90 days)
I love to include these policies as part of the default baselines to immediately protect corporate data on mobile devices and not inhibit the users flexibility on access corporate info on the go.
More information: App protection policies overview – Microsoft Intune | Microsoft Learn
This is an older video but I demo out some of the end-user experience here which as not changed much since this recording:
Pairing App Protection Policies with Conditional Access
You can also pair these policies with Conditional Access policies (scoped to Device Platforms of iOS and Android) with the grant controls of “Require app protection policies”.
Previously I would also recommend requiring approved client apps, but that will be deprecated in the future: Microsoft Entra Change Announcements – March 2023 Train – Microsoft Community Hub
What this allows you to do is require an approved Microsoft application for access to resources and prevents users from leveraging native apps on the device like the native mail client to connect to email.
Requiring a Managed Browser | MAM for Edge
You can also create an App Protection Policy for Windows. Today, this only allows you to scope the apps to Edge. When you add this policy you can add more restrictions outlined here such as cut, copy, and paste restrictions:
App protection policy settings for Windows – Microsoft Intune | Microsoft Learn
If you pair this policy with a conditional access policy that has the Grant control of “Require app protection policies” and is scoped to the Device platform of Windows, users will be required to sign into their work or school account on Edge:
This means they will be blocked from using any other browser. I personally had a negative end-user experience where I was already signed in to the managed profile, enforced this policy, and then got stuck in an infinite loop when clicking at Switch Edge profile of seeing this screen. I ended up having to completely remove my profile and reestablish it to get this to work which was a terrible end-user experience. Be careful rolling this one out!
Windows Information Protection (WIP) is gone => Endpoint DLP.
For some of us out there, we used to leverage WIP on unmanaged devices which I really liked because you could implement a ton of great security for managed apps on unmanaged devices just like what we have with app protection policies on mobile. Microsoft sunset these policies on unmanaged devices: Announcing the sunset of Windows Information Protection (WIP) – Microsoft Community Hub
And has begun to move everything under Endpoint DLP settings in Purview: Learn about Endpoint data loss prevention | Microsoft Learn
Most of us out there have yet to tap into many of the capabilities in Purview including DLP policies. Effectively, these policies were meant for any device but you can try to leverage Dynamic groups in Entra to bucketize corporate owned devices and then scope them in one of these policies as an exclusion so you can apply the policy to only personally owned devices:
The main thing I don’t like about this shift is that now you are almost being forced to have a certainly level of maturity with the other Purview data protection features. Instead of being able to blanket protections, you are really encouraged to get specific with the content you are protecting. Here is an example of creating the DLP policy and needing to define the conditions:
From here, you can then apply further restrictions:
Don’t get me wrong, I think the protections are nice and I do think we should be encouraged to get more mature with our data protection policies/configurations but I do think it’s a lot to try to do all at once vs just saying “I want to restrict users capabilities on unmanaged devices across all apps and actions”
The main takeaway here is that if you use a combination of the MAM Policy for Edge along with the App Enforce Restrictions for SharePoint/Exchange, you get the result of what I would want to be doing with Endpoint for DLP on Unmanaged Devices so these policies would be a bit redundant. The main consideration here is if you are not enforcing those policies and wanted to scope things further to particular actions and/or documents. An example of that is if you wanted to scope a policy to documents with a certain sensitivity label.
Additional Intune Considerations
The only other call out I want to make is if you are intending to support personal devices in MDM in some capacity. There may be considerations for different scopes of policies based on if the device is corporate or personal. Within the Intune Admin Center, you can go to Devices>Filter to create a filter that looks for personal devices
From here, when you are scoping various policies/configuration profiles, you can exclude/include these device filters from scopes like “All Devices” or “All Users”
Use Case:
- You support Personal Devices in a limited capacity
- You have a policy to sync OneDrive to devices but you do not want this policy to apply to personal devices
- You create the OneDrive configuration profile>Add the assignment of all devices and exclude the personal device filter
Conclusion
I hope this provided some targeted guidance on supporting BYOD in your environments. Keep in mind there are many ways to set this up and, depending on your environment, there might be better alternatives. Start by assessing the customers you have today that can access corporate resources on unmanaged devices and begin to test the policies I have outlined in this blog. Starting with Web Only Access + App Protection Policies on mobile devices is a great way to provide flexibility to customers while still maintaining security.