Securing Windows MAM Only Access with Conditional Access

With more and more companies today allowing BYOD scenarios we need to consider all the potential security risks around this. Working primarily with larger enterprise customers I don’t usually get into the Windows MAM only area as devices are MDM onboarded, and recently a partner posed a question to me whereby BYOD was allowed but they found users were opting out of allowing device management when prompted by Office apps.

In this situation the end user is still allowed to access company data on their device, which is undesirable of course as Windows Information Protection will not secure the data. So let us step through this issue and how to leverage filters within conditional access to prevent this type of situation from happening.


The first thing we need to ensure is that we are licensed for Intune and Azure AD Premium P1 or higher (in this example we are focused on SME, so Microsoft 365 Business Premium is ideal) and that we have a Windows MAM policy in place.

Below is an example of the required Windows MAM policy;

The Main Issue – Desktop Apps

Here we have an end user who is using their personal device with Microsoft 365 Apps installed, and upon launching Outlook for instance, they are initially prompted for their credentials and then asked to allow management of the device;

  • Outlook Email Address Dialogue
    The end user enters their credentials

In the above screenshot we can also see that the device is not Azure AD registered (for clarity)

  • Management Dialogue
    Now the user is displayed a dialog box similar to the one below, and here is where issues can arise.

As now the user begins to consider the potential for their organisation managing data or “spying” on other elements of their device. At this point the user can simply hit the “No, sign into this app only” and continue.

At this point the user has access to data, but control policies are not implemented.

Conditional Access Control – Desktop Apps

The one element we know about this scenario is that the device will not be Azure AD Registered in our environment when the user opts out of the device management dialogue. Using this known use case, we can construct a conditional access rule which prevents signing into Office 365 using trust type filters.

  • Create a new Conditional Access Policy
  • Naming the policy something like “Windows – Desktop Apps – Block Non AAD Registered Personal Devices” or using your CA naming convention
  • Select the users/groups you wish to apply the policy to, remembering to exclude the break glass admin account(s)
  • Select the Office 365 cloud app in the Cloud Apps or Actions section
  • Go to the Conditions section and go to Device Platforms, selecting to include “Windows”
  • Now go to the Client Apps section and select “Mobile apps and desktop clients”
  • Now we will go to the “Filters for devices” section and apply the limitations that will require the device to be at least AAD registered for access
  • Here we are going to set to exclude the following trustTypes
    • Azure AD Registered
    • Azure AD Joined
    • Hybrid Azure AD Joined
  • Finally we will go to Access Controls / Grant and pick the option to “Block access” and enable the policy

With the policy in place, let us try accessing company resources once again on the non AAD registered “personal” device and see what happens;

  • Creating a new profile and the user is prompted for their email address;
  • The user is then prompted with a sign in dialogue;

This time the user is blocked from signing in;

Next Step – Browser Access

With desktop apps now limited to only allow access where the device is at least Azure AD Registered, our next step is to limit browser based sign in’s.

Note: In this example I am focusing on Microsoft 365 Business Premium licensed users so MCAS download block is not available.

  • Create a new Conditional Access policy naming it something similar to “Windows – Browser – Block Non AAD Registered Personal Devices”
  • Use the same users / groups as you did in the desktop app policy
  • Select Office 365 as the App to limit (note that if you wish to lock down additional web based applications, add these also)
  • On the conditions section select Windows as the device platform and then underneath client apps select only the browser option
  • Use the same filter list as you did previously
  • Select the Block access option in the Access Control / Grant section

With this in place, the end user will also be prevented from accessing Microsoft online applications in the browser session unless their machine is at least Azure AD registered / MAM managed.

AAD Registered User Experience

Where the end user accepts the management state, or joins the device to Azure AD manually through the Access Work or School options, the apps will open and access to the corporate data will be controlled;

  • Outlook
  • Device Registration Details
  • Browser Access

Data / Profile Removal

If the user decides to attempt to remove the workplace join settings, data is removed, and access is once again blocked;

Data / Profiles Removed:

Browser Access:


Being both familiar with the types of user based access controls required by organisations and how to implement conditional access is vital to ensure that cracks do not form, allowing unmanaged or unwanted devices / apps from accessing corporate data.

Remember this post is for a specific use case scenario, and you should also block additional platforms to avoid user agent spoofing on Windows devices. You should also cater for legacy authentication when configuring policies, although Microsoft will be blocking this later in the year.

I hope this helps those managing Windows clients in this MAM only type scenario.

Maurice Daly

Maurice has been working in the IT industry for the past 20 years and currently working in the role of Senior Cloud Architect with CloudWay. With a focus on OS deployment through SCCM/MDT, group policies, active directory, virtualisation and office 365, Maurice has been a Windows Server MCSE since 2008 and was awarded Enterprise Mobility MVP in March 2017. Most recently his focus has been on automation of deployment tasks, creating and sharing PowerShell scripts and other content to help others streamline their deployment processes.

Add comment


Categories use cookies to ensure that we give you the best experience on our website.