Intune Compliance Policies and Conditional Access: Safe Rollout

What you need before you start

This chapter has a narrow job: get from 'we have enrolled a test PC' to 'access can depend on device compliance, and we can undo it quickly if it goes wrong'. The lab is fictional - one Windows pilot device, a test user called Pilot User 01, and a handful of groups named in the next section. Use a lab or approved test tenant, not production.

We have not run these steps against a tenant or a physical device for this draft. Everything below comes from Microsoft's current documentation, and the portal labels may drift. Where something is an inference rather than documented behaviour, we say so.

• Licences: an Intune licence for the pilot users, plus Microsoft Entra ID P1 or P2 for Conditional Access. Intune compliance on its own does not need Entra ID P1, but Conditional Access does. Some Microsoft 365 plans bundle both, so check what your tenant actually holds rather than trusting the plan name. The Intune free trial includes a trial Enterprise Mobility + Security subscription with Entra ID P1 or P2, which suits a lab.
• Where to check licences: in the Microsoft Intune admin center, Tenant administration > Tenant status shows licence totals. For Entra, open Microsoft Entra ID > Overview in the Azure portal and look under Basic information.
• Permissions: an Intune role that can create and assign compliance policies; at least Conditional Access Administrator in Microsoft Entra to create or change Conditional Access policies; at least Reports Reader to read sign-in logs.
• Test kit: one Windows device enrolled in Intune with Pilot User 01 as its user, plus a second route that is definitely not enrolled (a personal PC or a private browser window) for the failure test.
• Security defaults: if the lab tenant relies on them, note that Microsoft says security defaults and Conditional Access are not meant to be combined. Moving from one to the other properly is a separate job that this guide does not cover.

What a compliant device does and does not prove

Two separate things are involved, and it helps to keep them apart. Intune compliance is a set of rules you write for a device. The device reports against them, and Intune records compliant or noncompliant. Conditional Access is the decision-maker in Microsoft Entra. When someone signs in, it can read that compliance result and allow or refuse access. Intune judges the device; Conditional Access decides what to do about the verdict.

A compliant tick therefore means one thing only: at its last check-in, this enrolled device met the rules you wrote. That is useful, and it is also easy to over-read. NCSC's zero trust principles treat device health as one of several signals feeding an access decision, alongside identity and other context, rather than a verdict that stands alone. That is the right way to think about compliance.

• It does not prove who is using the device. Compliance describes the machine, not the person. How strongly the person proved their identity is a separate control.
• It does not prove the device is clean. The Antivirus and Antispyware settings check that a registered security product is switched on and up to date. They do not check that nothing is wrong. A threat-based check needs Microsoft Defender for Endpoint integration, which is outside this chapter.
• It does not prove the answer is current. Reports reflect the last check-in. The BitLocker health attestation setting is only measured at boot, so a device can finish encrypting and still look noncompliant until it restarts. A device that stops reporting is treated as noncompliant once the compliance status validity period passes (30 days by default).
• It does not cover devices you have not enrolled. An unenrolled device has no compliance state at all, and by default a device with no compliance policy is counted as compliant. We deal with that default in the next sections.
• It does not cover other platforms. The policy in this guide is for Windows only. Android, iOS and macOS have their own compliance policies and their own Conditional Access quirks.

Set up the safety net before you build anything

Conditional Access can lock out everyone, including you. Microsoft's own troubleshooting guidance warns specifically against requiring a compliant device for all users and all resources, because users without an enrolled device are blocked from everything, including the Intune portal. We avoid that with three things: a small pilot group, groups for exclusions that exist before the policy does, and emergency access accounts that are proven to work.

This section sets up the groups. The emergency access accounts themselves are the one piece you must not skip, so check them first.

1. Confirm you have at least two emergency access accounts. Microsoft's guidance is that they are cloud-only accounts on the onmicrosoft.com domain with the Global Administrator role, protected by a phishing-resistant method such as a passkey (FIDO2), with credentials stored safely and not tied to one person or personal device. If you do not have them, stop and create them using Microsoft's emergency access guidance before going further. Then confirm each one can actually sign in.
2. In the Microsoft Entra admin center, go to Entra ID > Groups and create a security group for the emergency access accounts, for example CA-Exclude-EmergencyAccess. Add the accounts. Report-only policies do not need this exclusion, but putting it in place now means it cannot be forgotten on the day you enforce.
3. Create a second security group for pilot users, for example CA-Pilot-Users, and add Pilot User 01. Use ordinary non-administrator test users only. Keep every administrator account out of this group.
4. Create a third, empty security group for approved exceptions, for example CA-Exclude-Approved. Start a simple register alongside it recording, for each person who is ever added: who approved it, why, and the date it must be reviewed. Microsoft's advice is to use exclusions sparingly and remove people as soon as possible, and a register is what makes that realistic.

Create a modest Windows compliance policy in Intune

Every setting you require is a future reason for someone to be refused access, so start with rules your pilot device already meets and that you could explain to the person affected. You can always tighten later; loosening a rule after people have been locked out is a worse day.

Intune compliance policies are separate per platform, so this one targets Windows 10 and later. Assigning it to a user group means Intune checks all of that user's devices.

1. Sign in to the Microsoft Intune admin center and go to Devices > Compliance, then choose Create policy. For Platform select Windows 10 and later, then Create.
2. On the Basics tab, enter a name you will still recognise in six months, for example WIN - Baseline compliance - Pilot.
3. On the Compliance settings tab, start with Device Properties and set Minimum OS version. Intune wants the major.minor.build.revision format. To see exactly what that looks like for your pilot device, open Command Prompt on it and run the read-only command below. Use a value in that same pattern - the build your pilot already runs, or an older build you are prepared to defend - and compare the format with this output before copying any version number from a table.
   cmdCopy

   ver

4. Under System Security, set Encryption of data storage on a device to Require. Under Device Security, set Firewall, Trusted Platform Module (TPM), Antivirus and Antispyware to Require. Leave everything else Not configured for now. In particular, hold back Require BitLocker and Require Secure Boot: both rely on device health attestation, BitLocker is only measured at boot, and Secure Boot shows Not Compliant on hardware that does not support it.
5. On the Actions for noncompliance tab, keep the default Mark device noncompliant action but change its schedule from 0 days to a short grace period, say 2 or 3 days. At 0 the device is marked noncompliant immediately; with a grace period it shows as In grace period and keeps access until the period ends. You can also add a Send email to end user action, but that needs a notification message template created first, so treat it as optional for this lab.
6. On the Assignments tab, choose Add groups and select CA-Pilot-Users. Then go to Review + create and select Create.
7. On the pilot device, open the Company Portal app and sync, then in the admin center open the new policy from Devices > Compliance and look at its Monitor tab. Microsoft says a device can take up to 24 hours to appear in the policy's device status chart even when online, so this is a good moment to resist refreshing the page every thirty seconds. Success is the pilot device showing as Compliant. If it shows Not compliant, use View report and Per-setting status to find the failing setting and fix it on the device rather than loosening the policy.
8. Before changing the tenant-wide default, see what it would affect. In Devices > Compliance, open the Monitor tab and look at Devices without compliance. Every enrolled device listed there currently counts as compliant by default. Also open Entra ID > Conditional Access > Policies and check that no enforced policy already requires a compliant device. If one does, do not do the next step until those devices have a policy.
9. Now change the tenant-wide setting. Go to Endpoint security > Device compliance > Compliance policy settings and set Mark devices with no compliance policy assigned as to Not compliant, then save. This affects every enrolled device in the tenant that has no compliance policy and, once a Conditional Access policy that requires compliance is enforced, it decides whether those devices pass. Microsoft recommends this setting when you use Conditional Access, because otherwise an unmanaged-by-policy device sails through. To roll it back, set it to Compliant again.

Create the Conditional Access policy in report-only mode

Report-only mode evaluates the policy at real sign-ins and logs what would have happened, but enforces nothing. Nobody is blocked and nobody is prompted. Microsoft's own guidance is to confirm settings in report-only mode before moving a policy to On, and it is the main safeguard in this chapter. It does not cover everything: policies using the User Actions scope are not evaluated in report-only mode.

We scope this policy to the pilot group rather than All users, and to Windows only. That second choice is deliberate: Microsoft warns that report-only policies requiring a compliant device can prompt macOS, iOS and Android users to choose a device certificate even though compliance is not being enforced, and the prompts can repeat until the device is compliant.

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator. Go to Entra ID > Conditional Access > Policies and select New policy.
2. Give the policy a name that says what it does and how far it has got, for example CA01 - All resources - Require compliant device - Windows - Pilot - REPORT-ONLY. A sequence number helps when you are talking someone through the policy list over the phone.
3. Under Assignments, select Users or workload identities. Under Include choose Select users and groups and pick CA-Pilot-Users. Under Exclude choose Users and groups and pick CA-Exclude-EmergencyAccess and CA-Exclude-Approved. In a hybrid identity setup, also exclude the Directory Synchronization Accounts role under Directory roles.
4. Under Target resources, include All resources (formerly 'All cloud apps'). This is safe here only because the policy is limited to the pilot group and is not yet enforcing.
5. Under Conditions, open Device platforms, set Configure to Yes, include Windows and leave the others out. Note that this leaves other platforms ungoverned by this policy; a separate policy for unsupported platforms is a different job.
6. Under Access controls > Grant, choose Require device to be marked as compliant, then Select.
7. Set Enable policy to Report-only and select Create. Back on the Policies list, the new policy should show its state as Report-only. Do not set it to On yet.

Optional: create the same report-only policy with Microsoft Graph PowerShell

If you prefer a script, the policy above can be created through Microsoft Graph PowerShell. Use one route or the other: running the script after building the policy in the portal gives you a duplicate, because the command creates a new policy every time it runs. Conditional Access allows 240 policies per tenant in total, so tidy up duplicates.

What it needs: Policy.Read.All and Policy.ReadWrite.ConditionalAccess, and a signed-in user with a supported role such as Conditional Access Administrator or Security Administrator. Microsoft notes a known permissions issue that can prompt for consent to an additional permission, so read each consent prompt before accepting it. What it changes: it adds one policy in the report-only state (enabledForReportingButNotEnforced) and changes nothing else. We have not run this script, so try it in the lab first and check the result before relying on it.

You need the Microsoft Graph PowerShell SDK installed on the machine you run it from. Follow Microsoft's installation instructions if you do not already have it.

1. In the Microsoft Entra admin center, open each of the three groups and copy its Object ID from the Overview page. Keep them handy for the next step.
2. In a PowerShell session, sign in interactively and request the two scopes. This only opens a sign-in and consent flow; it does not change the tenant.
   powershellCopy

   Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.ConditionalAccess"

3. Edit the script so that YOUR_PILOT_GROUP_ID, YOUR_EMERGENCY_ACCESS_GROUP_ID and YOUR_APPROVED_EXCLUSIONS_GROUP_ID are replaced with the Object IDs you copied. Then run it once. It creates the policy in report-only state.
   powershellCopy

   $params = @{
       displayName = "CA01 - All resources - Require compliant device - Windows - Pilot - REPORT-ONLY"
       state = "enabledForReportingButNotEnforced"
       conditions = @{
           clientAppTypes = @("all")
           applications = @{
               includeApplications = @("All")
           }
           users = @{
               includeGroups = @("YOUR_PILOT_GROUP_ID")
               excludeGroups = @("YOUR_EMERGENCY_ACCESS_GROUP_ID", "YOUR_APPROVED_EXCLUSIONS_GROUP_ID")
           }
           platforms = @{
               includePlatforms = @("windows")
           }
       }
       grantControls = @{
           operator = "OR"
           builtInControls = @("compliantDevice")
       }
   }
   
   New-MgIdentityConditionalAccessPolicy -BodyParameter $params

4. List the policies in read-only fashion and check that CA01 is present with the state enabledForReportingButNotEnforced. In the portal it should appear as Report-only.
   powershellCopy

   Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, Id, State

Simulate sign-ins, then read the real report-only results

Two different tools answer two different questions. The What If tool tells you which policies would apply to a described sign-in. The sign-in logs tell you what actually happened to real sign-ins. Use both: What If to check the logic of your inclusions and exclusions, the logs to check how your real devices behave.

What If has limits. It does not model Conditional Access service dependencies, and for the target application it wants an application ID, because groups of apps such as Office 365 do not result in a match. Our reading, which is an inference rather than documented behaviour, is that it shows the policy would demand a compliant device but cannot tell you whether a particular device is compliant. That is what the real sign-ins are for.

These are the labels you will see in the Report-only tab of a sign-in event:

• Report-only: Success - the policy applied and the device would have passed, for example a compliant device.
• Report-only: Failure - the policy applied and would have blocked the sign-in, for example because the device is not compliant.
• Report-only: User action required - the policy applied but would have needed the user to do something, such as complete multifactor authentication. They are not prompted in report-only mode.
• Report-only: Not applied - the policy conditions did not match, for example because the user is excluded.

1. In the Microsoft Entra admin center, go to Entra ID > Conditional Access > Policies and select What If.
2. Run it for Pilot User 01. For the target resource use an application ID rather than a group of apps - the Exchange Online ID 00000002-0000-0ff1-ce00-000000000000 appears in Microsoft's own examples. Set the device platform to Windows and the client app to Browser. CA01 should appear under the policies that apply, with Require device to be marked as compliant listed as the grant control.
3. Run it again for a user in CA-Exclude-Approved (add a test user temporarily if the group is empty) and for each emergency access account. CA01 should be under the policies that do not apply, with the reason given. Then run it once more for Pilot User 01 with the device platform set to macOS. CA01 should not apply, because of the Windows-only condition. Microsoft recommends testing the exclusions as well as the inclusions, because other policies can still affect the excluded users.
4. Generate real sign-ins. As Pilot User 01, sign in to a Microsoft 365 web app from the enrolled, compliant device using Microsoft Edge signed in with the work account. If you use Chrome, it needs either the Microsoft Single Sign On extension or the CloudAPAuthEnabled policy before it can pass device identity, and Edge needs the user signed in to the browser. Then repeat the sign-in from a route that is not enrolled; a private browser window will do, because Microsoft says the device check fails in private mode or with cookies disabled.
5. Read the outcome. As at least a Reports Reader, go to Entra ID > Monitoring & health > Sign-in logs, find the two sign-ins and open the Report-only tab on each. The enrolled device should show Report-only: Success and the unenrolled route Report-only: Failure. If you see something else, the sign-in event's device details usually say why.
6. Leave the policy in report-only mode for a meaningful period. Microsoft's planning guidance suggests at least a week before enforcement. The Policy impact (preview) view in Conditional Access, available to those with at least the Security Reader role, summarises potential impact over the past 24 hours, 7 days or a month. Chase every Failure for a pilot user: either fix the device or record an approved exclusion.

Enforce for the pilot group, and how to roll back

Moving the policy from Report-only to On is the one genuinely disruptive step in this guide. It needs the Conditional Access Administrator role (or similar). The real impact: any pilot user on a device that is not enrolled, not compliant, or using a legacy authentication client that cannot pass device state loses access to every resource the policy covers, which here is All resources. Read the rollback options below before you start, so they are not something you are working out while someone is waiting.

Rollback, from least to most drastic:

• Put the policy back to Report-only (or Off) in Entra ID > Conditional Access > Policies. Microsoft's rollback advice is to disable the policy, which stops it applying while keeping it for later.
• If one person is stuck and the policy is otherwise working, add them to CA-Exclude-Approved. Record who approved it, why and the review date, and remove them as soon as the device is fixed.
• If no administrator can sign in, use an emergency access account to get in and change the policy. Afterwards, review how and why the account was used.
• If no one in the organisation can update the policy, open a Microsoft support request; Microsoft support can review and update a policy that is preventing access.

Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.ConditionalAccess"
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId YOUR_POLICY_ID -State "enabledForReportingButNotEnforced"

1. Check the evidence. Report-only has run for the period you chose, every Failure for a pilot user has a fix or a recorded exception, and no pilot user depends on a legacy authentication client. Confirm that no administrator account is in CA-Pilot-Users, and keep a separate administrator session open while you test.
2. Open CA01 in Entra ID > Conditional Access > Policies, set Enable policy to On and save. Rename it to remove REPORT-ONLY from the name.
3. Check access. Pilot User 01 should still reach Microsoft 365 from the compliant device. In the sign-in logs, the Conditional Access tab for that sign-in should now show CA01 with a result of Success, no longer prefixed with Report-only.
4. Check the refusal. Try the unenrolled route as Pilot User 01. The sign-in should be refused, and the log should show error 53000 (DeviceNotCompliant) for the failing sign-in. If you get nothing, check that the sign-in actually used the pilot account.
5. Test an emergency access account again now that a policy is being enforced, confirm it still gets in, and record the date. Microsoft recommends validating these accounts at least every 90 days, and whenever IT staff or subscriptions change.

If it does not work

The usual blockers for this exact task are below. Each one is cheaper to find in report-only mode than after enforcement.

• The pilot device never shows up in the policy's status: confirm it is enrolled and that Pilot User 01 is in CA-Pilot-Users, then sync from Company Portal. Policy reporting only updates when a device checks in, and a device that has not checked in since the policy changed can sit in Not evaluated.
• A device you believe is fine shows Not compliant: open the policy's Per-setting status. Firewall is a common culprit - if group policy sets Windows Firewall to allow all inbound traffic or turns it off, the Firewall requirement fails even if an Intune policy turns it on. A BitLocker health attestation requirement may also need a restart before the device reports correctly.
• Everything shows as failing in report-only: check the tenant-wide Mark devices with no compliance policy assigned as setting, then check that the device is actually in a group with a compliance policy assigned.
• Chrome fails the device check while Edge passes: Chrome on Windows needs the Microsoft Single Sign On extension or the CloudAPAuthEnabled policy. Edge needs the user signed in to the browser. Firefox needs Windows single sign-on enabled and a recent enough version.
• Users on macOS, iOS or Android are prompted for a certificate: that is the report-only prompt Microsoft warns about. Keep those platforms out of the policy, as the Device platforms condition above does.
• What If says the policy does not apply when you expect it to: check that you supplied an application ID rather than a group of apps, and that every sign-in detail the policy conditions on has been given.
• A user is blocked after enforcement and you are not sure why: ask for the user principal name, time, application and Correlation ID (the More details link on the error page shows most of this), then open the sign-in event in Entra ID > Monitoring & health > Sign-in logs and read its Conditional Access tab.