The realities and limitations of managing personal (BYOD) devices in Microsoft 365 and Endpoint Manager

These days, I am willing to bet that I get asked about BYOD endpoints over corporate endpoints 10 to 1. Personal devices (even personal Windows devices) are creeping into the workplace more and more, especially with so many working from home. And this does present a few challenges for those of us in IT roles. We face increasing pressure to make these scenarios work (while also keeping everything secure).

Therefore, in this post I will attempt to address the nebulous set of questions surrounding BYOD and “be real” about what we can (and cannot) accomplish. But first, I want to make sure that we understand some basics about how Azure AD and Intune view both personal and corporate devices. Yes, we CAN distinguish between them, but what does the distinction mean?

Personal vs. Company-owned devices in Endpoint Manager

Endpoint Manager has some built-in “assumptions” about device ownership. For example, Windows 10 Autopilot devices, including Azure AD Joined or Hybrid Azure AD Joined devices, will automatically be classified as company-owned devices. Meanwhile, folks who download the Company Portal app from the publicly available app stores (whether Apple, Google Play, Microsoft Store, etc.) will be registering their devices as personal. So how you enroll a device can communicate whether that device is corporate or not. As well, we do have the ability to explicitly tell Intune who owns the device (corporate device identifiers is one way, or manually setting the device ownership on a per-device basis).

As you work within the product, you may find that certain settings are only available to certain types of devices. For example, when you onboard an iOS device into the Intune service through Apple Business Manager, Intune assumes that this device is company-owned. By going through the “Automated device enrollment” path, you will discover that you have a greater number of management controls available within the Device configuration profiles and so on. More bits you can flip. This is because the ownership of the device lives with the company, not the individual, so it will naturally expand IT’s level of control over the device. You can even prevent the user from installing apps from the app store.

On the Android side of things, we can manage devices as “Personal Work Profile” (this assumes BYOD/personal ownership) or “Fully managed” (which is used for corporate owned devices). Likewise you will see differences in the types of settings and controls available to you for each. For example, I cannot put a personal device into “kiosk mode” (dedicated device).

You will also notice that the personal/corporate distinction is not as strong with Windows 10. You won’t find dozens and dozens of segmented policy settings that say they only work on company-owned machines, etc.

However, there is one major difference with a corporate-owned Windows 10 device (Azure AD or Hybrid Azure AD Joined): you can sign into the computer with your Microsoft 365/Azure AD credentials, rather than using a local account or personal Microsoft account (as you would on a personally owned device). And when you use Autopilot to deploy the PC, you also have the option of removing local administrator privileges for this managed user account. So that right there is the biggest difference between corporate-owned vs. personal Windows 10 devices.

The shift in responsibility, and risk

But note that allowing an end user to retain local administrative privileges is no small thing. You are accepting a lot more risk by doing so. It means the user can basically install any application or change any setting. I saw a statistic at a security conference a couple of years ago (granted this could look different today) about how 80% of all known ransomware variants are mitigated simply by removing local admin. That’s 4 out of 5! So if you are an organization flirting with the idea of moving to BYOD Windows machines, consider that stat carefully first.

Are there other ways of removing local admin on a Windows 10 machine? Sure, but they are all kinda hokey and come with their own issues. Generally removing these privileges on personal machines in frowned upon. The supported way of achieving this is Autopilot (which means Azure AD Joined or Hybrid Azure AD Joined: a.k.a. corporate-owned machines).

In general, when I am approached by someone about BYOD Windows endpoints, my first reaction is to slap that person in the face (metaphorically) and strongly suggest that personal Windows devices should not be allowed to enroll and gain (full) access to corporate information. What I will recommend instead is that we at least use Conditional Access to require MFA and also severely limit data access (so that information cannot be downloaded to the device).

If the organization is willing to accept the substantial risk increase with BYOD, then we can look down the other available paths. But this needs to be your first question: whether to allow any access, or at least whether to limit the access from unmanaged devices via Conditional Access policies.

The gradients of control

Now assuming you are comfortable allowing the same level of access on personal devices as corporate-owned devices, we now have to decide how and to what extent we are going to mitigate our risks. There is not just one answer here; we actually have gradients of control.

The weakest form of control and lightest-weight management option is MAM (a.k.a. App protection policies) without enrollment. On a Windows device, deploying one of these policies will enable Windows Information Protection. On Windows or Mobile platforms (iOS + Android), MAM will allow you to do the following:

• Encrypt application data in the corporate (read: Microsoft) apps
• Apply a basic access control such as PIN/fingerprint/Hello
• Prevent data from being copied or exported to non-corporate apps and data storage or network locations
• Remotely wipe corporate app data from lost/stolen devices

Another important thing to understand is your auto-enrollment settings. You can find these settings from Azure AD under Mobility (MDM and MAM) or from Endpoint Manager by navigating to Devices > Windows > Windows Enrollment > Automatic Enrollment.

Here we find an “MDM User scope” and an “MAM User scope.” If you set only the MDM User scope to All, leaving MAM on None as I have pictured above, then every single Windows 10 device, whether personal or corporate, will automatically enroll for MDM, giving you more controls over the endpoint. This will be true whether you Azure AD Join a computer, or Azure AD Register it by adding a work/school account.

If you set both options to All, then personal devices will prefer to go down the MAM enrollment path rather than the MDM enrollment path (you should also deploy an App protection policy to protect the app data in this case). Meanwhile, corporate owned machines (Azure AD Joined) will still auto-enroll for MDM.

And of course you can also use security groups here to segment out specific users. For example, only licensed users (who have an Intune license) should be allowed to enroll for either MDM or MAM.

Finally I would also complement the autoenrollment scope by assigning device enrollment restrictions from Endpoint Manager. Navigate to Devices > Enroll devices > Device enrollment restrictions to create your own preferred restrictions.

You could even decide to enable different restrictions for different groups of licensed users. For example, Frontline workers might only be allowed to enroll personal Android or iOS devices, whereas your Ops users might be allowed to bring Mac and Windows, etc. You can have different restrictions assigned to different groups, like so:

Personally I like to maintain control of the device as much as possible, so that I can measure it for compliance and apply Conditional Access policies at a minimum. So that should tell you what my selections look like. But to each their own.

And of course whether you go down the MAM or MDM path with personal devices, you can always enforce Multi-factor Authentication. For some folks, MAM with MFA will be enough; it covers the primary risks they care about: loss/theft and unauthorized access. But note that MAM/Windows Information Protection is not a perfect technology. We can actually do much better with MAM on iOS and Android devices. For example, we can enforce managed applications using Conditional Access (so that you cannot “go around” the controls simply by using a third-party client app for example).

This means corporate data must be accessed only within the company managed apps; with MAM you can then draw boundaries between those apps and the non-managed apps. Unfortunately, we cannot guarantee similar using Windows or MacOS devices; the Conditional Access controls “Require approved client app” and “Require app protection policy” only work for iOS and Android. So MAM/Windows Information Protection is not a complete solution on Windows, in my opinion.

MDM for BYOD: Device Compliance

If you want to move up one step from mere app protection (MAM) then you will need to enroll your devices with Microsoft Endpoint Manager/Intune. The most common way of achieving this would be to have users download and sign into the Company portal app (though on Windows devices you can also leverage the autoenrollment options that I highlighted above). Either way, the goal is to register the device with Azure AD and also enroll it for management with the Intune cloud service.

At this point, you will want to implement Compliance policies and Conditional Access. Using these tools, you will be able to require devices to meet certain minimum criteria in order to gain and maintain access to company resources. For example, you can require encryption, or a minimum OS version. For Windows devices you might even require Microsoft Defender Antimalware to be enabled.

If a compliance check fails, then Conditional Access will again block the user from working with that corporate data until the compliance issue can be resolved.

The big sticking point: multiple corporoate profiles

The other annoying thing about BYOD management is that you can really only have a single corporate management profile on any given device. For contractors who work with multiple companies, or even folks who sit on the board for another company (not their own), this is a giant pain-in-the-you-know-where.

Whether you are trying to go the MAM or the MDM route, you will find it impossible to have two different managed profiles at the same time, on the same device. You will be prompted with an error message and asked to remove one of the two corporate accounts. It’s not ideal. I really hope the Intune team is working toward a resolution on this issue. At least for MAM.

The limits of a “heavier hand”

Once a personal device is enrolled, you have a fair amount of leverage, but not an infinite amount. Moving beyond Compliance policies, you also have Configuration profiles and Endpoint security profiles; these will enforce certain settings similar to how you would have used a GPO in the past. But those settings cannot be used as a bar for access like Compliance can.

Always remember that your control is somewhat limited when the end user is free to install their own software, and to change settings (especially in Windows). For example, even on a “lightly managed” personal device, I could push down certain software packages like Office, Edge and others. I can even lay down some security settings for those managed apps.

Unfortunately, I cannot force the user to remain within those applications alone (like I can with iOS and Android). If they want to use a different mail client for instance, or download Firefox or Opera and bypass some of the protections I applied in the Edge browser, then there is little I can do to prevent that as long as they have ultimate control over their device.

Taking advantage of additional powers such as Network boundaries, Application Guard, Defender for Endpoint and so on might continue to help you whittle down your risk (provided you have the appropriate Windows SKU’s/licensing), but you never get full control until you own the device. Basically, for BYOD we can make the managed environment a safer environment, and we can also make it a little less convenient to go around the managed environment, but it is never impossible to do so. Thus it is not a complete solution (and nothing ever will be, so long as the end user is the administrator on the device).

True control is device ownership

Whether we are talking mobile devices or Windows devices, the ultimate in control lies in being able to prevent application installations and control exactly what software packages are available on the endpoints. And in order to do that, you must own the device.

Note that you can achieve a basic inventory of devices with any of the management methods (you will see all devices registered in Azure AD), but the only way to guarantee your application inventory (apps that store and process corporate data on endpoints) is through fully managed (corporate-owned) MDM devices.

For mobile devices, blocking access to the public app store, and requiring the user to get their apps instead from the Company app store/Intune is the penultimate, and goes much further than MAM (although MAM on mobile platforms is still considered adequate for meeting many business and compliance requirements). For Windows devices, achieving a similar level of control means removing local admin privilege, and then managing the app deployments & updates entirely without user input.

With Windows devices we can even implement Application Control / AppLocker policies that block any executables and DLL’s which are untrusted. Remember that if you attempt to implement any application control solution without first removing the local admin privilege, you are playing a fool’s game. Anyone with local admin privileges can easily bypass application control (first or third-party). And of course this means they are still free to install their own software packages and execute any program (including malicious code) at will.

But once you have the hammerlock on ownership, you can know and not guess that your other security settings and restrictions are staying put the way you want them. Sure, Compliance policies can help enforce some basic settings such as a PIN and encryption, but without taking full ownership of the device, you can never be certain about all of the security profiles and settings that you might want to enforce.

Conclusion

Hopefully this framework gives you a slightly better picture of your options when it comes to BYOD devices. For Windows devices in particular, I am still highly cautious about recommending anything less than corporate-owned devices (one of the few surviving best practices from old world to new). In my opinion, MAM just is not strong enough in Windows 10.

However, we have to acknowledge that there are still legitimate scenarios that call for BYOD, and in those cases I would be looking heavily toward Conditional Access policies (to prevent certain kinds of access from unmanaged endpoints altogether) and after that, stepping up to MDM and Compliance policies. End users who want to enroll must give up at least some control to corporate IT.

And for some shameless self-promotion: in February and March in 2021, I will be offering live courses on Microsoft Endpoint Manager (Intune), covering best practices and BYOD scenarios for both mobile devices as well as Windows 10. Do check out those opportunities (which are also included with the year-long commitment to advancing your Microsoft 365 Practice Development).