Managing Conditional Access for Devices. It solves a simple but critical problem: how do you let the right people access your company's data from their phones, laptops, and tablets while keeping hackers and unauthorised devices completely locked out? For anyone studying MD-102, this is the single most important concept to grasp, because it is the main way Microsoft recommends you protect your organisation in a world where employees work from anywhere.
Jump to a section
A simple way to picture Managing Conditional Access for Devices
Have you ever tried to get into a nightclub that had a really strict door policy?
That bouncer isn't just checking IDs randomly. They have a whole system: they scan your face against a pre-approved guest list, check that your ID is real and matches you, see if you're on any banned list, and then decide what wristband to give you based on who you are and what you're wearing. If you're a VIP member, you get a gold wristband that lets you onto the rooftop terrace. If you're a first-time guest on a guest list, you get a standard wristband and can access the main dance floor. If your ID is expired or you're not on any list, you're turned away at the door.
Now imagine you are the nightclub owner. You don't want to personally stand at the door for every guest, every night. Instead, you write a set of rules: 'If the person is on the VIP list AND they have a valid passport, let them in with a gold wristband. If the person is on the general guest list AND they are wearing smart shoes, let them in with a standard wristband. If the person is not on any list, deny entry.' That set of rules is your Conditional Access policy. The bouncer is Microsoft Entra ID enforcing those rules. The 'wristband' is the device compliance status — it determines what data a device can access once inside your network.
Conditional Access is a feature in Microsoft Entra ID that acts like a smart gatekeeper. Before a person can access something like your company email (Microsoft 365), a file in SharePoint, or a business app, this gatekeeper checks a bunch of conditions. It asks questions like: 'Is this person using a managed device that meets our security rules?', 'Is their location suspicious?', and 'Is the device operating system up to date?'. If all conditions are met, access is granted. If not, access is blocked, or the person is asked to do something extra, like sign in with multi-factor authentication (MFA).
Before Conditional Access existed, IT teams used a simpler approach. They either gave a user a username and password and trusted them completely (which was risky), or they blocked all external access entirely (which made working from home impossible). Conditional Access replaced that all-or-nothing approach with a flexible, rule-based system. The core philosophy is 'Zero Trust' — which means 'never trust, always verify'. Even if you are inside the corporate network, you still need to pass a check.
Let's break down the key pieces of a Conditional Access policy. Every policy has three main parts: Assignments, Conditions, and Grant Controls.
Assignments: This is the 'who' and 'what'. You specify which users or groups the policy applies to — for example, 'all employees' or just 'finance team'. You also specify which cloud apps the policy applies to — for example, 'Office 365' or 'Salesforce'.
Conditions: This is the 'when' and 'where'. It includes things like:
Location: Are they signing in from a trusted office IP address or from a coffee shop in another country?
Device platform: Is the device an Android, iOS, Windows, or macOS device?
Client app: Are they using a web browser, a mobile app, or a desktop application like Outlook?
Risk level: Does Microsoft's threat detection see something suspicious about this sign-in (like a leaked password)?
Grant Controls: This is what happens if the conditions are met. The options include:
Require MFA: Force them to provide a second factor like a code from an authenticator app.
Require device to be marked as compliant: The device must have passed a health check via Microsoft Intune.
Require hybrid Microsoft Entra joined device: The device must be joined to both your on-premises Active Directory and the cloud.
Require approved client app: They must use a specific app, like the Outlook mobile app, not a generic email app.
Block access: The final 'no' option.
The most important concept for the MD-102 exam is 'Require device to be marked as compliant'. This means the device must be enrolled in Microsoft Intune, and Intune must have checked that it meets your company's compliance rules. Those compliance rules might include: the device must have a PIN or password set, the device must not be jailbroken (iPhone) or rooted (Android), the operating system must be a minimum version (like iOS 16 or later), and the device must have antivirus enabled and up to date. If a device fails any of these checks, the user is blocked from accessing corporate data.
Think of compliance like a yearly car safety inspection. You take your car to the mechanic (Intune), they check the brakes, tyres, and lights (security settings). If everything passes, you get a sticker (compliant status). If the brakes are faulty, no sticker, and you cannot drive on the motorway (access to company data). Until you fix the brakes, you are stuck on local roads (limited access or no access).
Conditional Access works together with Intune. Intune is the tool that enforces the rules on the device (making it compliant), and Conditional Access is the gate that checks for that compliance status before granting access. You cannot have one without the other for device-based policies.
Identify the users and cloud apps to protect
Decide which groups of users (e.g., all employees, executives only) and which cloud apps (e.g., Office 365, all cloud apps) need the strictest device compliance rules. This determines the Assignments part of the policy.
Define the device compliance policy in Microsoft Intune
In the Intune console, create a compliance policy that specifies the security requirements for each device platform (Windows, iOS, Android). For example, require encryption, a minimum OS version, and a device password.
Create a Conditional Access policy in Microsoft Entra ID
Navigate to the Entra ID admin centre, go to Security > Conditional Access, and create a new policy. Set the Assignments to the users and apps from step 1. Set the Conditions (like device platform) and the Grant Control to 'Require device to be marked as compliant'.
Test the policy using the What If tool
Before enforcing the policy, use the What If tool in the Conditional Access blade. Enter a test user's details, the target app, and the device platform to simulate the sign-in and see which policies would apply. This catches misconfigurations early.
Enable the policy in Report-only mode first
Set the policy to 'Report-only' mode for a few days. In this mode, the policy logs what it would block without actually blocking anything. Review the logs to see if any legitimate users would have been blocked by mistake.
Enable the policy and monitor sign-in logs
Once you're confident the policy works, switch it to 'On'. Monitor the Microsoft Entra ID Sign-in logs daily to see which users are being blocked and why. Common issues include outdated OS versions or missing encryption.
Let's walk through a real-world scenario. Imagine you work for a company called 'GreenLeaf Consulting', which has 500 employees, all using company laptops (Windows 10) and personal phones (iPhones and Android devices). The IT team, which includes someone like you studying for MD-102, needs to make sure that only secure devices can access company email in Office 365.
Step 1: The IT administrator sets up a device compliance policy in Microsoft Intune. For Windows devices, the rules are:
- Require BitLocker (the full-disk encryption) to be enabled. - Require Microsoft Defender antivirus to be on and up to date. - Require the device to have a password of at least 8 characters. For iPhones, the rules are:
Require a passcode of at least 6 digits.
Require the OS to be iOS 16 or later.
The device must not be jailbroken.
Step 2: The same administrator creates a Conditional Access policy in Microsoft Entra ID. The policy is called 'Require compliant device for Office 365'. The assignments are set to 'All users'. The conditions are set to 'Office 365' as the target cloud app. The Grant control is set to 'Require device to be marked as compliant'.
Step 3: A user named Sarah tries to check her email on her personal iPhone. When she opens the Outlook app, the app asks her to sign in with her work credentials (e.g., sarah@greenleaf.com). After she enters her password, Microsoft Entra ID kicks in. It checks the Conditional Access policy and says: 'The policy says you need a compliant device. Is this device compliant?' Intune replies: 'Sarah's iPhone is not enrolled with Intune at all, so it has no compliance status.' The result: access blocked. Sarah sees a message on her phone saying 'Your organisation requires a managed device. Would you like to enrol this device?' She clicks enrol, and Intune walks her through installing a management profile. Once that profile is installed, Intune checks the device. The device passes all checks (it has iOS 16, a passcode, and is not jailbroken). Intune marks it as compliant. The next time Sarah tries to open Outlook, the Conditional Access policy runs again, Intune reports 'compliant', and Sarah gets access to her email.
Step 4: Another user, James, has a company-issued Windows laptop. He already has it enrolled in Intune. Everything is fine until he decides to turn off Windows Defender to try another antivirus program. The next morning, Intune checks the device and sees Defender is off. Intune marks the device as 'not compliant'. When James tries to access his email via the Outlook desktop app, Conditional Access blocks him. A message pops up: 'Your device does not meet your organisation's security requirements. Please contact your IT admin.' James calls the help desk, and an admin explains he needs to turn Defender back on. Once he does, Intune re-checks, the device becomes compliant again, and access is restored.
The IT team's daily tasks include:
Checking the 'Devices with compliance issues' report in Intune to see which users are blocked.
Reaching out to users whose devices are out of date or missing encryption.
Reviewing Conditional Access sign-in logs in Entra ID to see which policies are failing and why.
Adjusting compliance policies when new OS versions are released (e.g., adding iOS 17 as a minimum requirement).
This system saves the IT team hours of manual work. Without it, they would have to manually check every device, which is impossible for 500 people. With Conditional Access, the system enforces the rules automatically, 24/7.
The MD-102 exam tests 'Managing Conditional Access for Devices' heavily. Expect 3-5 questions directly about this topic, and the topic underpins many other scenario-based questions. The exam loves to test your understanding of the relationship between Intune and Microsoft Entra ID.
Key concepts the exam will test:
The difference between Conditional Access (the gate) and Compliance Policies (the device health check). You must know that compliance policies are defined in Intune, and Conditional Access uses that compliance status to grant or block access.
The exact Grant Controls available: 'Require device to be marked as compliant', 'Require Microsoft Entra hybrid joined device', and 'Require approved client app'. You must know when to use each one. For example, if a user is using a personal device that is not joined to the domain, you would use 'Require device to be marked as compliant' (not hybrid join).
The 'What If' tool in Entra ID. You will see a scenario where a user is having access issues, and the correct answer is 'Use the What If tool to simulate the sign-in and see which policy is blocking them'.
Location-based policies: understanding Named Locations (trusted IP ranges). The exam might ask: 'How do you allow access only from a company office? Answer: Create a Named Location with the office IP range and configure a Conditional Access policy to block access from other locations.'
Device platform conditions: the exam tests that you can differentiate policies for iOS, Android, Windows, macOS, and even Linux (though rare).
Common traps the exam sets:
Trap: 'Conditional Access is configured in Microsoft Intune.' Wrong. Conditional Access policies are configured in Microsoft Entra ID. Intune handles compliance, Entra ID handles the gate.
Trap: 'Require device to be marked as compliant is the same as requiring a hybrid join.' Wrong. A device can be compliant but not hybrid joined (e.g., a personal phone that is enrolled in Intune). Hybrid join means the device is joined to your on-premises Active Directory AND Microsoft Entra ID.
Trap: The exam might describe a scenario where a user is blocked but the device is compliant. The correct answer is often 'Check the sign-in logs in Entra ID to see which policy is blocking them, and then check the policy conditions (like location) to find the issue.'
Trap: They might ask 'Which license is required for Conditional Access?' The answer is: Microsoft Entra ID P1 or P2 (P2 includes Identity Protection risk-based policies). Without this license, Conditional Access policies cannot be created.
Key definitions to memorise:
Conditional Access: The policy engine in Entra ID that enforces access controls based on conditions.
Device Compliance Policy: A set of rules in Intune that a device must meet to be considered healthy.
Microsoft Entra hybrid joined: A device that is joined to both on-prem AD and Entra ID.
Named Locations: Predefined trusted IP ranges or countries you can use in policies.
Device Filter: A way to target specific device attributes (like OS version) in a Conditional Access policy.
Conditional Access is the gatekeeper in Microsoft Entra ID that enforces access rules based on conditions like device health, location, and user risk.
Device compliance policies are defined in Microsoft Intune and check if a device meets security rules (encryption, OS version, antivirus), but they do not enforce settings.
A Conditional Access policy has three core parts: Assignments (who and what), Conditions (when and where), and Grant Controls (what happens if conditions are met).
The most common Grant Control for device management is 'Require device to be marked as compliant', which blocks non-compliant devices from accessing cloud apps.
The 'What If' tool in Microsoft Entra ID lets administrators simulate a sign-in to see which Conditional Access policies would apply, making troubleshooting faster.
Microsoft Entra ID Premium P1 or P2 licenses are required to create and use Conditional Access policies.
Zero Trust is the foundational principle: never trust any device automatically, always verify compliance and identity before granting access.
Compliance and Conditional Access work together: Intune checks device health, and Entra ID uses that health status to grant or block access.
These come up on the exam all the time. Here's how to tell them apart.
Conditional Access Policy
Created in Microsoft Entra ID
Grants or blocks access based on conditions like device compliance, location, and risk
Uses Grant Controls like 'Require MFA' or 'Block access'
Device Compliance Policy
Created in Microsoft Intune
Checks device health (encryption, OS version, antivirus) to determine a compliance status
Does not grant or block access; it only provides a 'compliant' or 'non-compliant' status
Require device to be marked as compliant
Applies to any device enrolled in Intune (personal or company-owned)
Device must pass specific compliance rules (e.g., PIN, encryption)
Allows personal devices like iPhones to access corporate data if they are compliant
Require Microsoft Entra hybrid joined device
Only applies to devices joined to both on-premises Active Directory and Entra ID
Device is always company-owned and managed via Group Policy and Intune
Does not allow personal devices; only corporate Windows devices qualify
Report-only mode
Policy logs what it would block without actually blocking any user
Used for testing and validating policy before enforcing it
Does not affect user experience or access
Enabled (On) mode
Policy actively blocks or grants access based on conditions
Used in production after testing is complete
Directly affects user experience by enforcing Grant Controls
Named Location (trusted IP range)
A specific IP range defined in Entra ID, e.g., the company office IP
Used in policy to allow access only from that location
Helps reduce false positives for MFA prompts when users are in the office
Any location (all IPs)
No specific location defined; the policy applies everywhere
Used when you want to require MFA or compliance from all sign-ins globally
May cause users in the office to get extra verifications unnecessarily
Mistake
Conditional Access policies are the same as device compliance policies.
Correct
They are different. Compliance policies are defined in Intune and check device health (e.g., encryption, OS version). Conditional Access policies in Microsoft Entra ID use that compliance status to decide whether to grant access.
Both concepts sound similar and work together, so beginners assume they are the same thing. The exam tests this distinction frequently.
Mistake
If a device is compliant, a user can automatically access everything.
Correct
Compliance only satisfies part of a Conditional Access policy. The policy may also require MFA, a specific location, or an approved app. A compliant device alone does not guarantee access.
Beginners assume compliance is the only gate, but Conditional Access policies can have multiple conditions stacked together.
Mistake
You can create and manage Conditional Access policies from the Intune console.
Correct
Conditional Access policies are created and managed in Microsoft Entra ID (portal.azure.com > Entra ID > Security > Conditional Access). Intune only manages device compliance policies.
Intune has a prominent 'Conditional Access' menu item, which confuses people into thinking it's the main location.
Mistake
Blocking access via Conditional Access means the user cannot sign in at all.
Correct
Blocking access usually prevents access to the specified cloud app (like email), but the user can still sign into other apps not covered by the policy, or to the device itself.
The term 'block access' sounds absolute, but it is scoped to specific apps and conditions, not an account-wide ban.
Mistake
Device compliance policies automatically enforce settings like requiring a password.
Correct
Compliance policies only check if a setting is present; they do not enforce it. For enforcement, you need a separate device configuration policy (also in Intune).
The word 'policy' implies enforcement, but in Intune, compliance is a check, not a configuration push.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Conditional Access policies are created in the Microsoft Entra ID admin centre (security.microsoft.com or entra.microsoft.com), under Protection > Conditional Access. You manage them from the same place. Intune does not create Conditional Access policies.
A device compliance policy (created in Intune) checks if a device meets security rules like having encryption or a password. A Conditional Access policy (created in Entra ID) uses that compliance result to grant or block access to cloud apps. They work together.
You need Microsoft Entra ID Premium P1 or P2 licenses assigned to users. The free version of Entra ID (included with Office 365) does not support Conditional Access policies.
Yes. Set the Grant Control to 'Require device to be marked as compliant' or 'Require Microsoft Entra hybrid joined device'. A personal device can become compliant if enrolled in Intune and passes the compliance checks, but if it fails, access is blocked.
A device being compliant only satisfies the device condition. The Conditional Access policy may also require MFA, a specific location (like a trusted office IP), or an approved client app. Check the policy's Grant Controls and Conditions to see all requirements.
The What If tool is a simulator in the Entra ID Conditional Access blade. You can enter a user's details, a target app, and a device platform to see which policies would apply to that sign-in scenario. It helps troubleshoot access issues before enforcing a policy.
Create a Compliance Policy in Intune that applies only to Windows devices. Then create a Conditional Access policy that targets Office 365 apps and uses the Grant Control 'Require device to be marked as compliant'. Also add a condition for Device Platform to be Windows. This will block all non-Windows and non-compliant devices.
You've finished Managing Conditional Access for Devices. Continue through the MD-102 study guide to build a complete picture of the exam.
Done with this chapter?