Compliance is an ever-changing, challenging, and complex topic that genuinely intrigues me. Today, we will drill down into the world of devices, particularly Device Compliance.

Without proper compliance, even if your devices are Azure AD-joined, non-compliant or compromised devices might slip by and gain access to your organization’s resources.

That’s why it’s so important to have a system controlling which devices can access your resources and enforce basic compliance standards.

Meet Intune

Intune is Microsoft’s mobile device management solution allowing you to create Compliance Policies based on your organization’s requirements. The settings and rules of the compliance policies must be met by the users and devices in order to be compliant. And we also need to define the actions for non-compliant devices - do we need to notify the user that the device is non-compliant?

The compliance or non-compliance of a device can also be used in Conditional Access policies to block or give access to organizational resources. We will look at conditional access and devices in another post.

There are two parts to compliance policies in Intune. Let’s look at them…

Compliance policy settings 

These are tenant-wide settings that established a baseline for how compliance policies work in your Intune, and every device will receive them. And these settings are separate from the device compliance policy settings we will look at later.

The setting Mark devices with no compliance policy assigned as is all about deciding if devices default to being compliant or non-compliant before receiving any device compliance policies. You have two options:

• Decide that all devices are compliant until “proven guilty” - selecting Compliant (default)
• Decide that all devices are non-compliant until the compliance policies have confirmed that it’s a healthy device - selecting Non compliant

Make sure to default to Not Compliant if you plan to use Conditional Access. That way, only devices confirmed as compliant will access corporate resources.

You also have settings for Enhanced jailbreak detection and Compliance status validity period, read more here: Device compliance get started

Device compliance policies

Device-compliance policies define the requirements that users and managed devices must meet to comply. For example, devices should not be jail-broken, and managed devices should run a minimum OS version. We can also utilize signals from Defender for Endpoint and make sure to be below the machine risk score to be compliant. They also support actions for non-compliant devices, for example, being remotely locked or sending the user an email about the device status.

We must create a separate policy for each platform type we plan to use in the environment. The available settings vary depending on the platform type you select when you create a policy. Each device compliance policy includes one or more actions for non-compliance. These actions are rules applied to devices that don’t meet the conditions you set in the policy. You can read more here: Actions for non-compliance

When you create a device compliance policy, you’ll typically deploy it to all users within a user group or to all devices in a device group. Deploying device compliance policies to users ensures that all devices associated with each user are checked for compliance. Device groups make compliance reporting easier.

Summary and next steps

I hope you now understand more about why device compliance is so substantial and how it’s generally used. This was just an overview of the concepts, so you know what I’m talking about in some upcoming posts.

As an example, we will look into enabling Defender for Endpoint. This is a requirement for onboarding devices into Microsoft Purview, so we can use Endpoint DLP and Insider Risk Management further down the road.

You might want to look at how to Create Compliance policies.

Thank you for reading
/Simon