Compliance and Conditional Access

Compliance is the signal; Conditional Access is the gate

Microsoft's Intune compliance documentation defines compliance policies as rules and conditions that evaluate managed device configuration. Microsoft Entra Conditional Access can then use the compliance status as an access signal. MD-102 questions usually test whether you know which service evaluates the device and which service grants or blocks access. Compliance is the signal; Conditional Access is the gate. Confusing the two leads to wrong answers.

The lifecycle is straightforward:

1. A device enrolls into Intune.
2. Intune assigns a platform-specific compliance policy.
3. The device checks settings such as OS version, encryption, password, jailbreak or root status, or threat level.
4. Intune reports the device as compliant or not compliant.
5. Conditional Access evaluates the sign-in and can require the device to be marked as compliant before access is granted.

Compliance policy settings versus compliance policies

Intune has two compliance layers. Compliance policy settings are tenant-wide and affect how compliance behaves for every device. Device compliance policies are platform-specific rule sets assigned to users or devices.

The highest-value tenant setting for MD-102 is Mark devices with no compliance policy assigned as. If the organization uses Conditional Access to require compliant devices, setting unassigned devices to Compliant can create an access gap, because a device with no policy assigned is treated as compliant and can pass the access check without ever being evaluated. A security-focused design sets devices with no compliance policy assigned as Not compliant, then makes sure every supported platform has an assigned compliance policy before enforcing Conditional Access.

This single toggle is one of the most-tested compliance facts on the exam.

Device compliance policies are built per platform. Common examples include:

Compliance policies also include actions for noncompliance. The default action marks the device as noncompliant, and admins can add grace periods or user notifications. On the exam, a grace period means access might continue until the deadline expires unless Conditional Access and compliance state already mark the device noncompliant. A grace period is therefore a soft enforcement window, not an instant block.

Conditional Access requiring compliance

Microsoft's require device compliance with Conditional Access guidance warns that the policy will not function as intended without an Intune compliance policy. That warning is exam-relevant: never create a compliant-device Conditional Access policy in isolation, because devices with no policy may be treated as compliant or no device may report any status at all.

A strong rollout sequence is:

1. Create compliance policies for each supported platform.
2. Assign policies to pilot groups and verify devices report status.
3. Set the tenant behavior for devices with no assigned compliance policy deliberately.
4. Create Conditional Access in report-only mode or with a pilot assignment first.
5. Exclude emergency access (break-glass) accounts.
6. Target the intended cloud apps and device platforms.
7. Use the grant control Require device to be marked as compliant.
8. Monitor sign-in logs and compliance reports before expanding.

Be careful with broad policies. If a Conditional Access policy targets All cloud apps, Android, and browsers while requiring compliant devices or blocking access, Android Enterprise setup can be interrupted because authentication during enrollment uses browser-based flows. Microsoft documents that the Microsoft Intune cloud app may need to be excluded for those Android enrollment scenarios so the device can finish enrolling and become compliant.

Exam checklist

• If the question asks how to allow access only from devices that meet standards, combine an Intune compliance policy with a Conditional Access policy that requires a compliant device.
• If the question asks how to prevent enrollment, use enrollment restrictions, not compliance.
• If a device has no compliance policy assignment and still gets access, review the tenant compliance setting for unassigned devices.
• If users are locked out right after enforcing compliant-device access, check policy scope, emergency access exclusions, device compliance status, and whether enrollment or authentication apps were unintentionally blocked.
• Treat compliance as a reported state, not a configuration mechanism; a compliance policy reports BitLocker, but a configuration profile enables it.

A worked end-to-end scenario

Security wants SharePoint and Exchange Online reachable only from encrypted, up-to-date corporate Windows devices, while personal phones may use only protected mobile apps. Walk the layers. Encryption is enabled by a disk encryption configuration profile or endpoint security policy. Encryption and minimum OS are evaluated by a Windows compliance policy. The access decision is enforced by a Conditional Access policy that requires a compliant device for those cloud apps, with break-glass accounts excluded.

The personal-phone requirement is a different layer entirely: it is an app protection policy that keeps corporate data inside managed apps without enrolling the device, optionally paired with a Conditional Access policy for app protection. One business sentence, four distinct controls, each in its correct layer — that is exactly how the exam constructs its harder compliance questions.

Distinguishing the four common distractors

Four wrong answers recur on compliance questions. Enrollment restriction stops a device from enrolling; it never gates access for an already-enrolled device. Device category or device cleanup rules organize or remove device records; they do not evaluate security posture. Removing compliance policies to make devices "automatically compliant" is the opposite of secure and usually depends on the permissive tenant setting being left at its default. A configuration profile alone can turn on BitLocker or set a password rule, but without a compliance policy and Conditional Access, nothing blocks access when the setting is missing.

When a question asks how to gate access on device health, the answer is almost always the compliance-plus-Conditional-Access pair, sequenced so the compliance signal exists before the gate is enforced.