A whiteboard drawing of a mind map that explains the word compliance

The underestimated compliance policy in Microsoft Intune

Way back when I started to work with Microsoft Intune, I remember that I had a very hard time understanding the use case for the compliance policy.

They don’t do anything, and I can’t even get them for all of my configuration settings?

Part of that is still true today, but not in a bad way. This post will explain what you need to know about them, how to design them and why it’s a vital part of most Microsoft courses I deliver.

Compliance policy 101

Compliance policies are used to verify that a device have configured the security settings that are required by an organization. This does not mean that you need to use Intune to configure a specific setting.

Compliance policies are as applicable to a BYO-device as for a company owned. However, the responsibility to configure the required settings could be either the user, and IT-department or both. Regardless, we want to ensure that the settings have applied before we allow access to company resources.

Evaluation of compliance policies

Compliance policies are evaluated, and the result sent to Intune, on the same schedule as policies – which is around every 8th hour. We should therefore not rely on compliance policies to, as an example, prevent malicious behavior or IT-attacks. If you force a device sync that will also trigger a compliance sync.

That allows us to manually or automated evaluate compliance more often. Other integrations, that do not rely on the compliance state being pushed from the device, such as JAMF and Microsoft Defender ATP, will give you an even faster and more frequent evaluation.

Compliance policies are there to ensure that those risk can be prevented from the start. We will have a lag between something changing on a device that makes it non-compliant until that information reaches the Intune service – make sure you are aware of that.

Compliance policies can be integrated with Configuration Manager to allow you to track compliance for just about anything. The settings that are available to you in the Intune-portal is in comparison limited, but in most cases, it should be enough from a security point of view.

A part of something bigger

Compliance policies have, on their own, a limited use case, even if we can use them to lock or retire devices that are non-compliant. We will get back to that later in this post. The real benefit is of course to integrate compliance as a part of your conditional access strategy.

CA policy that requires Compliant device










Integrating with conditional access have two benefits, first the obvious one that we can ensure that devices that are connecting to cloud- and/or internal resources are following security requirements.

The other aspect is that you can guide users into the management scenario you prefer, managed devices or managed apps. If you configure your conditional access for a specific app to require a compliant device, that will require the device to be enrolled. If not, the user of the device can connect – if they fulfill the other controls in the CA policy.

Designing compliance policies – more than just the settings

When I visit new customers, I usually find the compliance policies in the same state. They have one compliance policy per platform, with all or most settings configured according to their requirements. This configuration does work, but it has several downsides.

Some also have the default tenant wide settings configured. In rare cases I also find that many of the compliance policies are not assigned or not widely deployed.

Compliance policy settings – default or not?

There are settings that are available and configured in Intune to allow for a smooth onboarding and migration to a zero-trust security model. They aren’t really, in my opinion, supposed to stay in that state. One of them, which I may cover in a later blog post, is Hybrid Azure AD join as a requirement in Conditional Access.

The other one, is the setting for how to treat devices (or users really) that aren’t targeted by a compliance policy. The default settings is to mark these as compliant, to ensure access to corporate resources. You can find this, and the other settings mentioned in the paragraph, in the Endpoint Manager portal, Devices, Compliance Policies, Compliance policy settings.

This setting is something that, when you have implemented your Conditional Access policies and users are able to register their devices, I recommend that you change. To allow any device, from which a user is trying to access a service as compliant, based on that the users isn’t targeted by policies, is a bad idea.

Going on vacation or what?

Second is the time before a device that have not communicated with Intune is marked as non-compliant, or Compliance status validity period. 

Compliance Settings




In this case you should look at your organization and try to figure out how many days it is likely that a user could be offline under normal circumstances. The number of days should be the limit for when a device is marked as non-compliant. The default is 30 days, which depending on your organization could be a long time. Especially today where its very uncommon to go without a connection for an extended time period.

We configure this setting to ensure that an attacker would not be able to block access to the Intune service, but allow access to other online services while configuring the phone to a non-compliant state.

Also, the last setting here is Enhanced jailbreak detection. It requires location services to be turned on to work properly, but I advise you to try it out. If you find that it actually has a significant impact on battery or that your users turn location services off, you can consider to turn it off. If not, keep it on.

Do not make the group policy mistake – break down your policies

Do not put a variety of different settings into the same compliance policy. Divide them into logical policies based on the platform.

As an example: Have one policy for password settings and one policy for disk encryption.

This also allows you to more easily apply granular policies over time, if needed. For an organization that runs Windows, MacOS, Android and iOS you´ll probably see around 20-25 policies in total, instead of 4.

This will give you a much easier overview of which devices that aren’t compliant for a specific setting. It will also allow you to make notifications and compliance timings much more granular, relevant and user friendly.

A list of Compliance policies

A list of Compliance policies

Notify, notify, notify and take action

The main benefit of having multiple policies is that its much easier to inform the user of a non-compliant device about the reason for non-compliance. This allows the user to either seek help or remediate the non-compliance state on their own. If you are using a single policy, we can’t target a specific notification to a specific reason for non-compliance, making it harder to self-remediate.

In general, I see a much lower usage of notifications and actions for non-compliance than what would be useful and valuable both for the users but perhaps especially for administrators. The most common setting I see is just leaving the configuration at default. The default setting is to change the compliance state to non-compliant instantly when a configuration is changed to a non-compliant value.

In some cases, this is a suitable configuration, such as jailbreak detection or password configurations. These are either settings that could be potentially dangerous or which could be remediated easily and swiftly. For other settings, it could be more suitable to change the actions to more customized options.

Actions not action!

That brings us to another aspect of the actions. You are not limited to a certain number of actions for a policy. You could have multiple actions and notifications for each policy. Below you can find an example for a policy that evaluates the version of an iOS device.

Notification and actions for non-compliance








As you can see, I send customized notifications at a number of intervals and I also combine e-mail notifications as well as the newly released feature of push notifications. Lastly, I do take additional actions as well as change the compliance state of the device.

The available actions for iOS are the once below, but varies based on the platform:

iOS actions






This kind of process for non-compliance is what I would advise for most of your compliance policies. Also note that the e-mail notifications can send additional notifications to other addresses than the user that is targeted by the compliance policy. A very useful feature for administrators or security managers to get notified if a user tries to bypass the security configuration.

We also have actions that will retire a device (which is again very useful for BYOD scenarios especially) and lock devices (which may be mostly applicable to shared devices or kiosk). For personal devices, we in general would apply CA policies and therefore limit the usage of the device.

It is all about timing – give the user a chance

For notifications and actions to work efficiently we need to configure the timings for each action accordingly. Just as in the example above it could be a reasonable configuration to wait to put the device into a non-compliance state. This is especially applicable to version checks. It will, most likely, take the user a while to remediate the compliance state.

You can also use timings to send additional notifications with intervals to the user. Reminding the user to remediate if they have not done that after the first notification have been received.

Finding the correct timing

The timings always count from the time when the compliance state reached the Intune service, so there may be a time difference between the configuration change, the compliance state and therefore also the notifications. The difference could be up to 8 hours, which is also why we cant be more exact than a day. Keep this in mind when configuring your notifications as well.

The timings should be based on the ability to self-remediate as well as your organizations policies of course. Its therefore hard to give any general recommendations. Do have in mind that, again depending on the configuration, some compliance states could be harder to remediate during a weekend as an example. Like in the example above where I allow three days after non-compliance before the device is locked/retired.

Compliance policy integrations

Some aspects of the compliance policies are dependent on integrations with other tools and solutions. Based on your needs, your platform and your environment it could be advisable to integrate with these. Most importantly is however to be aware that these settings is not evaluated correctly, and it may lead to unexpected results.

ME Configuration Manager

If you are using Microsoft Endpoint Configuration Manager, you should be co-managing the devices that aren’t exclusively managed by Microsoft Intune. One of the oldest, and most valuable aspects of Co-management, is compliance evaluation.

With an option added in Configuration Manager 1910 we can combine the advanced options available in Configuration Managers configuration items with the compliance evaluation of Intune. In practice, we can evaluate close to anything on a co-managed device and send that compliance state to Intune. This could include settings in LOB-apps, more granular options for BitLocker-encryption or a third party anti-malware.

Microsoft Defender Advanced Threat Protection

For Windows and Android devices, we can base compliance state on the device risk delivered from Microsoft Defender ATP. Apart from providing a very detail and fast security evaluation of a device, MD ATP also communicates directly with the Intune. This allows for a more frequent update to the compliance state. Note that MDATP does not necessarily evaluate the activated features or applied configurations of the device. You should therefore ensure that that is covered by other compliance policies.

3d party threat protection

For iOS and Android, we can get a similar experience and state reporting from 3rd party threat protection tools. The protection here is mostly based around malicious apps, or apps that may required higher privileges than needed for a functioning app. Just as MDATP the 3rd party app, based on your configurations, sets a device risk score that you can evaluate as part of your compliance policy.


If you are using JAMF Pro to configure the MacOS devices in your environment, the tool is easy to integrate with Microsoft Intune. JAMF will continuously send inventory data from the devices to Intune, which Intune uses to evaluate the compliance state of the device. That allows you to manage Macs with JAMF, while getting the benefits from compliance and conditional access with Intune.


Even though we will not cover this integration in detail in this post, it is possible to use the compliance state of a device to allow or prevent access to internal networks and/or VPNs. The most common hardware vendors that support that from a networking perspective is Cisco and Checkpoint. The integration would enable a scenario where a firewall or wireless network controller would ask the Intune service for a compliance state. Based on that state, network access could be allowed, prevented or limited.

What you can learn from working with compliance policies

Other than being very useful, what can you learn from working with compliance policies?

First, you can learn a lot about integrations with other 1st and 3rd party products. That´s also why I usually save compliance policies together with Conditional Access to the end of every MS Intune course I deliver. It summarizes everything that the people who take my class have learned in a very hands on way.

Second, you learn about user interactivity. Since compliance policies drives Conditional Access, it will have an impact on the users experience. Imagine the situation yourself:

You are watching TV, when suddenly the program you are watching is interrupted. On the screen a message is visible:

You have broken one of our rules, we have therefore paused your subscription until you make up for what you have done.

Rather frustrating right? Not knowing, and also negatively impacting the experience, will for sure make your users angry.

Therefore, make it easy for users to remain compliant. Give them the proper information to get back to a compliant state. That will help your organization to stay compliant.

What Compliance policies are built for

Lastly, you also learn when to use the proper tool. If you are looking for something that instantly will block access if a malicious app is installed, compliance policies alone are not the tool.

If you are looking for something to report back on policy applicability on a granular level, compliance policies is not the tool

If you want to configure settings that will apply and reconfigure devices, compliance policies isn’t what you are looking for.

On the other hand: If you want to ensure that your users are keeping their devices up to date in a promptly fashion – it’s the tool to use.

If you want to allow your users to enroll their own devices, but don’t want to enforce policies in an intrusive way, it’s a great tool.

When you want to ensure that your users can’t access data on an unprotected devices, it’s a very good combination together with Conditional Access.

Summary (or TL: DR)

Compliance policies is one of the vital tools in your device management toolbox. Ensure to understand the usage of them and how to configure them in an efficient way. There are also a number of aspects that I haven’t been able to cover in this post. Therefore it is  likely that another one will follow with more details on individual settings.

  • Spilt the settings into logical policies, to make it easy to communicate the reason for non-compliance.
  • Configure the tenant wide settings to suit your needs, ensure that all users have a policy applied to them.
  • Use actions and notifications to minimize the amount of interaction needed with your service desk. When a user needs to remediate, they should know why and how.

Furthermore, evaluate what you want to use compliance policies for, and if MS Intune is enough to fulfill those needs. You may need to integrate additional services, to further protect your data and applications.

In the end, that´s what compliance policies are all about. Helping us protecting what´s valuable. Its one of the gatekeepers and implemented correctly it will be essential in your Stay Current strategy.

Links to official documentation as well as useful community blogs:






1 reply
  1. Avatar
    Robert Stein says:

    Great write up. I was struggling to come up with a compliance and action protocol and reading this was super helpful in clarifying what I need to do.


Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *