Device-Based Conditional Access in Entra ID: A Practical Policy Walkthrough

Device compliance is a status field until something enforces it. Conditional Access in Microsoft Entra ID is where that status turns into real access control — the point where a non-compliant Mac or an unmanaged Windows laptop is actually told no. After building these policies for organizations running Jamf and Intune side by side, here is a practical walkthrough that keeps the wrong devices out without locking out your own administrators.

Prerequisites, in order

• Devices are registered or joined to Entra ID — Entra joined or hybrid joined for Windows, Intune-enrolled for mobile, and for Macs the Jamf Pro conditional access connection so Jamf compliance is visible to Entra.
• Compliance policies exist and are producing accurate compliant / non-compliant results you trust.
• You have named break-glass accounts (see below) before you write a single policy.

The anatomy of a policy

Every Conditional Access policy is the same five-part sentence: for these users, accessing these resources, under these conditions, require these grant controls — or block. Read each policy back to yourself in that form before you enable it. Most misfires come from a “users” scope that is broader than intended or a “resources” scope set to All resources when it should have been one app.

The core device policy

The workhorse policy for most organizations: for all users, accessing all cloud apps, require the device to be marked compliant or Entra hybrid joined. That single policy means a login from an unmanaged or non-compliant machine cannot reach Microsoft 365 or any integrated application, regardless of whether the password and MFA were correct.

Build it in report-only mode first. Leave it there for at least a week and read the workbook: every user it would have blocked is a support ticket you get to prevent now instead of triage later.

Platform coverage and the gaps

• Windows: compliant via Intune, or hybrid joined — well covered.
• macOS: compliant via the Jamf connector, or via Intune if you manage Macs there. Confirm the Jamf connection is healthy before you enforce, or every Mac becomes non-compliant at once.
• iOS and Android: compliant via Intune, often paired with app protection policies.
• The unknown-platform gap: Linux, and anything not covered above. Decide explicitly whether those are blocked or allowed through a separate policy — do not leave it to chance.

Break-glass accounts are non-negotiable

Create two cloud-only global administrator accounts with long random passphrases, excluded from every Conditional Access policy you build. Store the credentials offline, monitor them for sign-ins, and test them quarterly. The day a policy change locks everyone — including you — out of the tenant, these accounts are the only way back in. Every organization that skipped this step learned why the hard way.

The lockout traps

• The registration chicken-and-egg: marking a device compliant may require enrolling it, but the enrollment flow itself can be blocked by your device policy. Exclude the enrollment and registration endpoints, or scope a carve-out for the join process.
• New employees: day-one users with no compliant device yet. A short onboarding policy or a time-boxed exclusion group keeps them from being stuck at the door.
• Guests and partners: external identities usually should not be held to your device compliance standard — handle them in their own policy.
• Service accounts and automation: non-interactive sign-ins that will never have a compliant device. Move them to workload identities or a tightly scoped exclusion with named IPs.

Layer the other controls

Device compliance is one grant control among several. Combine it with MFA for all users, sign-in risk and user risk conditions from Entra ID Protection, and session controls that limit or block downloads on unmanaged browsers. Keep each concern in its own policy rather than one giant rule — you will thank yourself when you need to change just one of them.

Monitor after you enforce

Live in the sign-in logs for the first few days after moving a policy out of report-only. Use the “what if” tool to simulate a user and see which policies apply, and keep the Conditional Access workbook pinned. Failures will cluster — a department, a device type, a stale compliance signal — and the pattern tells you exactly what to fix.

Bottom line

Conditional Access is what makes all your compliance work matter. Start from one clear policy — require a compliant or hybrid-joined device for everything — prove it in report-only, protect the join and onboarding flows, and never enable a policy without break-glass accounts excluded. Done carefully, it is the difference between knowing a device is non-compliant and actually stopping it.