Conditional Access is an identity control, and it belongs to whoever owns identity. What the endpoint estate owns is the signal that control reads. That distinction sounds academic right up until the morning a policy denies a laptop your own console is happily reporting as fine.
This phase used to hold the whole Conditional Access story. It no longer does. Policy design, the persona and tier model, the framework I ship, the ring rollout and the operating runbook have moved to their own guide, because a policy set that governs every identity in the tenant is not a subsection of an endpoint deployment. What stays here is the part that is genuinely about devices, and it is the part I see designed worst.
Two owners, one decision
I have watched this go wrong the same way in several tenants. The endpoint team notices that an unmanaged laptop can reach SharePoint, so the endpoint team writes a Conditional Access policy. It is a reasonable reaction to a real gap, and what it produces over eighteen months is a policy set with no single author, no naming discipline, and no surviving record of why any given exclusion group exists. The opposite failure is quieter and I think more common. An identity architect writes a clean policy requiring a compliant device, without knowing that in this particular tenant “compliant” means the machine has a PIN and spoke to the service sometime this week.
The authority split that actually works is narrow and worth stating plainly. The decision belongs to identity: which personas exist, which controls they face, what an exception costs and who approves it. The evidence that decision runs on is manufactured here, and manufacturing it is a design responsibility with its own surface. Which devices carry an Entra identity at all. What the compliance rules assert, in the sense of what a reader should believe about a machine when the service calls it compliant. How fast a change on the device becomes a change in the claim. And what the tenant decides about a device nobody ever told what compliance means.
None of those four are Conditional Access settings. All four determine what a Conditional Access policy can truthfully decide.
Compliance is a claim, and you are the one signing it
Intune does not enforce access. It reports. Compliance is evaluated against the rules you wrote, the result is sent to Microsoft Entra ID and held on the device object, and Conditional Access reads it there when it evaluates the grant control named Require device to be marked as compliant. That is the whole mechanism, and the consequence people skip past is that the control carries exactly as much weight as the rules behind it and not one gram more. Require a compliant device, back it with a compliance policy that checks a minimum OS build, and you have formally told the identity system that an unencrypted, unpatched, locally-administered machine is trustworthy. The policy will do its job. It will grant.
The grant control is only ever as strong as the compliance policy standing behind it, and the identity team cannot see that policy from where they are sitting.
Two structural facts follow, and both shape the deployment sequence rather than a setting. A device must be registered in Entra ID before it can be marked compliant at all, which makes device identity the prerequisite for the entire seam rather than a detail of enrolment. And the control only understands device state where device state exists: Windows 10 and later, iOS, Android, macOS and Ubuntu, enrolled in Intune, with Windows additionally able to receive a verdict from a non-Microsoft MDM through the compliance partner mechanism. Everything outside that set is governed by a different control or by nothing, and if your estate has meaningful population outside it, you found that out here rather than during the rollout.
The claim has an age
Compliance is agent-reported, so the claim in the token is a statement about the last time the device spoke, not about the device right now. Microsoft’s own figures are the ones to design against. Ordinary maintenance syncs land at roughly eight-hour intervals across every platform, and a device is permitted only one maintenance sync every six and a half hours no matter what the client would prefer. Freshly enrolled devices behave completely differently for a while: Windows and Android check in every three minutes for the first quarter of an hour, then every fifteen minutes for two hours, before settling to the ordinary rhythm. iOS and macOS run the fifteen-minute cadence for an hour and then settle.
So an access decision taken at nine in the morning can rest on evidence gathered at three. That is the honest bound on what the control promises, and it is why I never describe a compliant-device requirement as real-time posture to a client. Microsoft has been closing the gap. Compliance state is now evaluated continuously as device state changes, and supported Windows devices can proactively ask for re-evaluation when something changes locally instead of waiting for the next scheduled check-in. That last capability is in preview as I write this, which means it is worth knowing about and not yet worth designing around.
The other half of the age problem is grace periods, which exist precisely because the instant a rule tightens, a population of devices is non-compliant through no fault of anyone’s. A device with an unexpired grace period reports as InGracePeriod, and that state satisfies nothing on its own. Where this catches people is the arithmetic when several compliance policies target one device. Intune assigns severity to each state, from Unknown at the bottom through NotApplicable, Compliant, InGracePeriod and NonCompliant up to Error, and the device takes the highest severity of any policy touching it. The worst state wins, and Error outranks outright non-compliance. A custom compliance script whose output runs past the 2,048 character ceiling returns invalid JSON, raises error 65009, and puts the device in Error. That machine now fails a Conditional Access grant for a reason that has nothing whatsoever to do with its security posture, and the sign-in log will tell the identity team the device is not compliant.
What silence means in your tenant
There is a single tenant-wide setting, Mark devices with no compliance policy assigned as, that decides the verdict for any device no compliance policy targets. It takes one of two values and it is a genuine posture decision wearing the clothes of a configuration option.
Set it to compliant and every hole in your assignment coverage becomes an open door that reports green. A device that slipped between two dynamic groups, a platform you forgot, a new enrolment profile nobody wired up: all of it sails through a policy that requires a compliant device, because nothing ever said otherwise. Set it to non-compliant and an assignment mistake locks people out, which you will hear about within the hour. I choose the second and accept the noise, because a coverage gap that announces itself is a coverage gap you fix, and the alternative is a control that has been quietly permissive for a year. This is the same argument as the default-deny posture everywhere else in the estate, and it is worth having explicitly with whoever owns the Conditional Access policy set, because the value of this setting silently changes the meaning of their policy.
Where the seam leaks
A few edges are worth carrying in your head, because each one has cost me a support call. Requiring a compliant device does not block Intune enrolment, and it does not block the Intune Web Company Portal. Microsoft states this deliberately, and it kills the most common objection raised in design workshops. Enrolment does get blocked by other Conditional Access policies, particularly the ones that demand multifactor authentication at registration, and that is a real design problem with a real answer rather than a myth. It gets its own article in this phase.
Microsoft Edge running InPrivate on Windows is treated as a non-compliant device, which surprises people who assume the device claim is a property of the machine rather than of the session. On iOS, Android, macOS and some non-Microsoft browsers, Entra ID identifies the device using a client certificate issued at registration, and the user has to select that certificate the first time they sign in through the browser. Nothing is broken when that prompt appears, but the service desk needs to know it is coming.
The one with the longest reach is cross-tenant trust. Through cross-tenant access settings you can choose to accept another organisation’s device compliance claims for their users coming into your resources. That is a decision to trust an assertion produced by a compliance policy you did not write, cannot read, and will not be told about when it changes. There are relationships where I would take that trade, and I have never taken it without naming it out loud first.
What this phase covers from here
Policy design lives in the Conditional Access guide, along with the persona and tier model, the framework I publish, and the runbook for operating it. What Phase 2 owes this phase, meaning the registration, break-glass and legacy-authentication work that has to be true before any of it, is already written up in Conditional Access Prerequisites.
The rest of this phase stays on the device side of the seam. Compliance as a signal gets a proper treatment of its own: what the rules should assert, how the evaluation loop behaves under change, and how to write a compliance policy that a Conditional Access author can actually rely on. Then onboarding, which is where the seam is under the most tension, because a device being built has no compliance state yet and a user being onboarded has no credential yet, and the policies protecting that bootstrap are the ones most often turned off and never turned back on. That article gets a build sheet. Global Secure Access closes the phase, scoped to the part the endpoint estate owns, which is a client with no auto-update and therefore a version-ringing duty that belongs to whoever runs Intune.
