Compliance policies in Intune refer to a set of rules and requirements that organizations can enforce on devices to ensure they meet specific security and regulatory standards. These policies are designed to safeguard sensitive data and maintain a secure environment for corporate resources accessed through managed devices.
A compliant device adheres to these rules and policies and is able to access corporate resources, where a non-compliant device cannot. Compliance policies are the foundation of security and device management, since they allow administrators to better manage endpoints.
In this post we will create a basic compliance policy for Windows devices, assign it to a group and observe the various settings and states of the compliance calculation.
To start creating the compliance policy head to Intune portal and devices blade and create a new compliance policy.
Select Windows 10 and later and Create the policy.
Give a name and a description to your compliance policy and press Next.
In the next screen we have to select the options and checks the compliance policy is going to perform in the endpoint. Going though the available options we can see that firstly there is a Custom compliance option. This is a perfect option for enforcing custom controls in endpoints (will be discussed in another post). Moving forward there is the device health settings.
These settings include check about:
- Bitlocker: Windows BitLocker is a full-disk encryption feature available in various editions of Microsoft Windows, including Windows 10 Pro, Enterprise, and Education. BitLocker helps protect data on a computer’s hard drive by encrypting it, making it unreadable and inaccessible to unauthorized individuals who may attempt to access or steal the data. When BitLocker is enabled, it encrypts the entire Windows operating system drive, including the operating system files, user files, and system files. It uses the Advanced Encryption Standard (AES) algorithm with 128-bit or 256-bit encryption keys to secure the data. If we want to secure our endpoints and ensure that the corporate data remain safe even after a device is stolen or lost, then this option is essential.
- Secure Boot: Windows Secure Boot is a feature implemented in modern versions of the Windows operating system, starting with Windows 8 and continuing in subsequent versions. It is designed to protect the integrity and security of the boot process by ensuring that only trusted and digitally-signed software components are loaded during system startup. The primary goal of Windows Secure Boot is to prevent the loading of malicious or unauthorized software, such as rootkits or bootkits, during the boot process. It achieves this by verifying the authenticity and integrity of each component involved in the boot process, including firmware, bootloader, and operating system kernel. It is also an essential security feature for our endpoints.
- Code Integrity: Code Integrity is a security feature implemented in Windows operating systems that helps protect the integrity and authenticity of system files, device drivers, and other executable code. It ensures that only trusted and digitally-signed code is allowed to run on a Windows system, guarding against unauthorized or malicious modifications. We will require code integrity for our endpoints.
Continuing onward, we have to configure the compliance policy’s settings regarding the device properties. As you can see below this essentially means defining OS specific settings. A best practice here is to follow Microsoft’s Windows OS lifecycle found here, to keep up to date with what versions are getting out of support soon and change this setting accordingly.
We will leave the Configuration Manager compliance as Not Configured since we are not using SCCM for co-managing our devices.
The next settings refer to security policies. These can vary from encryption and TPM to firewall and Defender for endpoint settings. All compliance settings regarding security can be found here.
Keep in mind that some of these settings may show relative notification on the endpoints (such as the Require encryption of data storage on device). The below image shows a notification received that indicates that the endpoint should be encrypted. The best approach is to handle these settings proactively from Intune (such as deploying encryption configuration profiles) and avoid adding them in compliance policy.
Last but not least, the Microsoft Defender for Endpoint setting allows us to define a device threat level limit, beyond which the device will be deemed non-compliant.
After assigning the policy to a device group, the compliance policy will be calculated and set the device to a compliant or not-compliant state.
The compliance policy is ready.
It is important to mention here that some policies such as the Bitlocker policy is calculated during startup, so it is recommended to perform one or two restarts after the enrollment of a device.