Handling Unmanaged Windows Devices – Using Windows MAM with Intune

All organizations differ in how they want to secure (or not secure) their data. Inevitably, the weakest points in an organization’s defense are the end users and endpoints. Allowing any device access to corporate resources is generally not a good practice. It’s much easier to control access from company-owned hardware since we can ensure our endpoints are patched and secure. However, we have no such control over personally owned devices. If there is no regulation over access from unmanaged devices, the organization is at much higher risk for compromise and unauthorized data exfiltration. For mobile devices (iOS/Android), we’ve had Mobile Application Management available for a while. On the Windows side, there was WIP, which is now deprecated. There are also some controls for preventing downloads of data using conditional access app control and blocking the use of desktop apps, but this still lacked the granular control of iOS/android app protection policies. Most recently, though, Microsoft has released MAM for Windows. This is currently limited to Microsoft Edge but is a much better solution than what was previously mentioned. After doing a bunch of testing, this is a great solution for employees who are not issued a corporate device and need to rely on a personally owned Windows computer for access to company apps and data. Before we get into MAM on Windows, let’s take a quick look at our options for dealing with personally owned (unmanaged) Windows devices: 

Option 1 – Do nothing: 

The way tenants are configured by default is to allow unrestricted access from personally owned devices. This is not a recommended practice and increases the risk of compromise for your organization. If you’re using Microsoft Business Basic or Standard, or another licensing SKU that doesn’t include an Entra ID P1 license, you will not be able to change this behavior since you need conditional access. If you happen to be stuck with a non-P1 license, implementing Azure Security Defaults will help by requiring MFA and blocking legacy authentication, but you can’t block access from unmanaged devices.  

Option 2 – Block unmanaged Devices: 

On the opposite end of the spectrum, we can simply block any unmanaged device from accessing corporate resources. This is the most strict and secure method. Unless the device is enrolled in Intune, access to your cloud apps is blocked. Users will need to use a corporate Intune-managed device for access. If all your employees are issued a company-owned device, you’ll want to strongly consider blocking access from personally owned devices. The conditional access policy to only allow access from compliant devices is rather simple: 

Create and name your policy. Select your Users, Cloud Apps, and OS platforms. 

Then, make your grant control that the device must be marked compliant: 

This will block any non-compliant managed device from accessing your selected cloud apps.

Option 3 – Windows MAM: 

Windows MAM is a great option for any employees who are not issued a corporate device and still need access to company web apps and resources. This allows you to restrict how the company data is accessed and what can be done with it. It also allows you a bit of granular control over the access requirements and what users can and cannot do while accessing data. For example, you can block copy/paste and downloading of any data to the local PC. You can also set minimum OS or Edge versions. Full details can be found here – Data protection for Windows MAM | Microsoft Learn along with the requirements. You simply need an Intune and Entra ID P1 license, but your endpoints also must meet version requirements: 

To start using Windows MAM, we need two things – an App Protection policy, and a Conditional access policy. The app protection policy is what implements the restrictions on the unmanaged endpoints. It does this at the application level. In this case, the controls are baked into the Edge work profile that gets created. The conditional access policy is how we enforce this, by requiring that unmanaged endpoints must use an app protection policy when accessing corporate resources.

To create an app protection policy for Windows, open Intune and navigate to Apps > App Protection Policies. Click create policy, and then choose Windows: 

Provide a name, and then there are only two sections we need to configure – Data Protection and Health Checks. Both sections are mostly self-explanatory. The data protection section is how you want to handle sending and receiving data within the Edge work profile. I’ve set my example policy with the strictest settings that don’t allow copy/paste, or sending/receiving to or from outside sources. I also have printing blocked:  

The Health checks section is comprised of app and device conditions for the unmanaged endpoints. These are also mostly self-explanatory. I should note that the default Offline Grace Period is only 12 hours, which will result in the user being blocked the very next day (unless they keep the work profile opened and active on their device). So I’ve changed the value to 10080 (7 days). We’re also able to set Minimum Versions for Edge and Windows so we aren’t allowing old unsupported versions access to our resources.  

Here is some clarification on the Offline Grace Period:

Now that we have our App configuration policy created, we need to create two conditional access policies – One that will block the use of the desktop apps on non-compliant (unmanaged) devices and another that requires an app protection policy for unmanaged devices when signing in using a browser.  

We’ll walk through creating our first policy below, which blocks the use of desktop clients. Create a new conditional access policy, provide a name, and select your users (probably all users). In the target resources section, select Cloud Apps and Office 365.  

For the Conditions, select Windows as the targeted device platform and for Client Apps, select Mobile apps and desktop clients 

Lastly, for the grant controls, require that the device be marked compliant: 

Next time a targeted user tries signing into a desktop app (OneDrive, Word, Outlook, etc.) from an unmanaged Windows device they will be blocked from authenticating and receive the below error: 

The next policy we create will require that an app protection policy is used if a user is authenticating from a browser on an unmanaged device. Create a new policy, provide a name, and then target the same user group you targeted in the previous conditional access policy. For the target resources, select Office 365 

Under Conditions, we need to configure device platforms, client app, and device filters. Select Windows as the device platform, browser as the client app, and filter to exclude compliant devices from this policy: 

Next, under the grant controls, select to require an app protection policy. Enable the policy when you’re finished.  

Now that we have our app protection policy and conditional access policies created, we can do some testing and see what the behavior is like: 

If we try signing in from Chrome or Firefox on an unmanaged device we receive the below notification message. Clicking launch in Edge will open Edge and allow you to authenticate, which will create a new work profile: 

The user will authenticate with their credentials: 

After signing in, click continue: 

Before we move on, let’s quickly talk about the below screenshots. When you click continue in the above screenshot, you’ll be presented with the below window. It’s important to know what will happen based on what you select. Device registration is a requirement for conditional access,  so we need to register the device, but we don’t want to enroll it with Intune. When you receive the prompt, you want to uncheck the box to Allow my organization to manage my device and then click OK. See the descriptions in the screenshots below:  

Wait for the device to complete its registration. This should take less than a minute.

Before we move on to more testing, you probably don’t want users enrolling personally owned devices in Intune. It’s good practice to block this using enrollment device platform restrictions. In most cases, users mistakenly enroll their devices without knowing what they did. Creating a restriction, like the two screenshots below, will prevent them from mistakenly enrolling a device in Intune:

Looking back at our MAM device, after the device is registered, the work profile creation will be completed and the app protection policy will be enforced on the work profile. You can see your edge profiles by clicking in the top left of Edge. We can see the newly added work profile here: 

Let’s test some of the app protection policies. If we try to drag content into or out of the browser: 

If we try to copy/paste to or from the browser: 

If we set a minimum OS version with a warning in our app protection policy, this is what the warning will look like for the user. You can configure multiple rules, so you can add a warning for versions that are approaching the end of servicing, and block anything that is at the end of servicing.  

You can check your Windows OS version by issuing the command “winver” from the run or a cmd: 

A reference for all Windows 10/11 versions and their end-of-servicing dates is below. I suggest keeping anything that is end of servicing blocked: 

• Windows 11 – release information | Microsoft Learn 
• Windows 10 – release information | Microsoft Learn 

And if we block by OS version, we receive this message: 

We can do the same for the version of MS Edge. You can find a list of the Edge Versions here – Microsoft Edge release notes for Stable Channel | Microsoft Learn . You can find the version on a specific machine from the ellipses menu > Help and Feedback > About Microsoft Edge 

If we specify a minimum edge version with a warning, and the user is below the specified version, they’ll receive the below warning message: 

Also, here’s an example to force wipe user data if they are below a certain version of Edge: 

The next time the user launches the work profile, they’ll receive the below message stating that their data has been wiped from the device. After they update to the required version, they can re-add their work profile to get access to the corporate resources.

If we try downloading a file from SharePoint or OneDrive:  

If we try uploading a file to OneDrive or SharePoint via the upload button or by dragging it into the browser: 

Attempting to download an email attachment: 

 We also receive the same message if we try downloading any other file from the internet: 

If printing is blocked in the app protection policy, and we try printing a document: 

In addition to the app protection policies, you can use App Configuration Policies to target certain configurations for Edge in the work profile. Here’s an example where you can set the home page and tabs you want open when the work profile starts: 

On the endpoint, users can view app configuration policies by navigating to edge://policy/. In the below screenshot, there is an app configuration policy to hide the Microsoft Rewards that we can see:

Using Progressive Web Apps 

You can also install the progressive web apps and they will maintain their link to the work profile and the app protection policies. Blocking or wiping data behaves the same way, and if data is wiped, the PWA is removed. This makes it very useful and convenient to get more of the desktop app feel, but still maintain the benefits of the app protection policy.  

PWA for Outlook: 

Monitoring and Using Wipe Requests: 

To verify if a user is using Windows MAM on a personally owned device, navigate to Apps > Monitor > App Protection Status. Search for the user, and their apps managed by app protection policies will be listed. We can see in the screenshot below that Edge is listed, and the device type is Desktop:

If we need to wipe the data from a MAM endpoint, navigate to Apps > App Selective Wipe. Locate the desired user and select the user’s device from the list, and select continue:

The next time the user tries to use their work profile, or if they’re actively using it, within a few minutes they’ll receive the below message that their data has been removed. I’m not sure why it says the account is disabled, but it does complete the wipe request:

In testing, this all happened in less than a minute. If we navigate back to the App selective wipe portion of Intune, we can see the wipe request is marked as completed: