Insights

Many organisations are using Microsoft 365 to protect their identities, with Multi-Factor Authentication and Conditional Access. But as adoption continues to grow, attackers are adapting methods to compromise victims by using techniques that evade MFA.

A good example of this is Adversary-in-the-Middle (AiTM) attacks. We recently wrote an article about this. In the article, we explain how this type of attack works and outline the methods you can use to protect your organisation.

One of the mitigation methods is device compliance, but you may be wondering what device compliance is, how it’s configured, and what benefits it provides. This article will cover all of this.

What is device compliance?

Endpoints are one of the six key elements within a Zero Trust approach. Once an identity is granted access to your resources, data from those resources can flow to the endpoint. However, this can represent a large attack surface—especially if those endpoints aren’t in the state you’d like.

For example, the endpoints may be missing several vendor updates, endpoint protection software might not be installed or might not be running the latest definitions, or the device might not be encrypted.

There may be legitimate reasons for this, e.g. the user has recently returned from annual leave and their device hasn’t been online to receive updates. Regardless of the reason, the state of a device sometimes isn’t compliant with your organisation’s standards and requirements for access to your data.

Microsoft Intune has support for device compliance policies. These policies allow you to configure the requirements for devices to be considered compliant or non-compliant. As an example, you can require that a Windows device has a specific version of Windows, that the device is encrypted or that Defender for Endpoint considers the device to be below a specified risk level; if a device doesn’t meet these requirements, it’s considered non-compliant. You can also create your own custom compliance controls such as requiring that your web content filtering solution is active.

Intune will then evaluate the device against the compliance policy requirements, and mark the device as compliant, or non-compliant. It’s also possible to configure a grace period for any non-compliance, which is useful in the scenario of a newly provisioned device that might not yet meet compliance requirements.

1. Zero Trust Diagram

Source: Microsoft – https://www.microsoft.com/en-gb/security/business/zero-trust

How can I use device compliance to protect my organisation?

Intune shares the device compliance status with Entra ID (formerly Azure Active Directory), meaning you can leverage compliance state with Conditional Access policies.
Here’s a screenshot of how this appears within Entra ID:

You can block access to your resources if the user is accessing data from a non-compliant device. Here’s a screenshot of how this control appears within Entra ID Conditional Access:

Once this is assigned and enabled, the users and cloud apps targeted by your policy will only be able to sign-in to those cloud apps if their device is marked as compliant. Non-compliant devices will be blocked.

What if I want additional controls, such as allowing access from unmanaged devices, but limiting that access?

You can also extend this further by using additional Microsoft tooling. Using Defender for Cloud Apps, you can limit the experience for the user if they’re accessing data from a non-compliant device, such as providing browser-only access without download and print capabilities.

Note that if a device is not enrolled in Intune, it will be considered non-compliant because Intune is unable to verify the compliance state of the device.

By requiring users to use a compliant device to access your resources, you can ensure that any data that a user accesses is secured to your requirements, as well as protecting against threats such as AiTM. Device compliance significantly enhances your endpoint security posture and is strongly recommended. If device compliance is enforced, then any user with a non-compliant device may be blocked from accessing resources within your tenant.

If your organisation doesn’t yet have a clear understanding of the devices being used to access your data, we recommend defining this before starting a device compliance project. If device compliance is implemented, and unmanaged personal devices are in use, those devices may be blocked. So, it’s wise to perform a discovery exercise to understand the endpoints that your users are signing in from and how this aligns to your organisation’s posture before progressing further.

Finally, you should also try to achieve acceptance of this project internally. It’s possible that a user using a non-compliant device will be blocked from access until their compliance issue is resolved. This will result in disruption to the user; they’ll have to submit a service request with your service desk to resolve the issue. However, a small amount of disruption is acceptable if the alternative is a non-compliant device accessing your resources.

How do I get started with device compliance?

You can view a list of all supported device compliance configuration settings on the Microsoft Docs here.