# Managing Conditional Access for Devices

> Chapter 14 of the Courseiva MD-102 curriculum — https://courseiva.com/learn/md-102/managing-conditional-access

**Official objective:** 4.1 — Implement Conditional Access policies with device compliance

## Introduction

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.

## The Nightclub Bouncer Analogy

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.

## Core explanation

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.

## Real-world context

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.

## Exam focus

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: Azure AD Premium 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.

## Step by step

1. **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.
2. **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.
3. **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'.
4. **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.
5. **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.
6. **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.

## Comparisons

### Conditional Access Policy vs Device Compliance Policy

**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 vs Require Microsoft Entra hybrid joined device

**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 vs Enabled (On) mode

**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) vs Any location (all IPs)

**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

## Diagram

_This flowchart shows how a user's attempt to access Office 365 is checked by Conditional Access in Entra ID, which then uses the device compliance status from Intune to grant or block access._

```mermaid
flowchart TD
    A[User tries to access Office 365] --> B{Entra ID checks Conditional Access policy}
    B -->|Policy: Require compliant device| C{Is device compliant?}
    C -->|Yes - device enrolled in Intune and passes checks| D[Grant access to email and files]
    C -->|No - device not enrolled or fails checks| E[Block access, show remediation message]
    E --> F[User enrols device or fixes issues via Intune]
    F --> C
```

## Common misconceptions

- **Misconception:** Conditional Access policies are the same as device compliance policies. **Reality:** 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.)
- **Misconception:** If a device is compliant, a user can automatically access everything. **Reality:** 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.)
- **Misconception:** You can create and manage Conditional Access policies from the Intune console. **Reality:** 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.)
- **Misconception:** Blocking access via Conditional Access means the user cannot sign in at all. **Reality:** 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.)
- **Misconception:** Device compliance policies automatically enforce settings like requiring a password. **Reality:** 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.)

## Key takeaways

- 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.

## FAQ

**Where do I create Conditional Access policies?**

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.

**What is the difference between a device compliance policy and a Conditional Access policy?**

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.

**What license do I need to use Conditional Access?**

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.

**Can I use Conditional Access to block access from personal devices?**

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.

**Why would a user be blocked even though their device is compliant?**

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.

**What is the 'What If' tool in Conditional Access?**

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.

**How do I allow only company-issued Windows devices to access email?**

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.

## Check your understanding

1. **What Microsoft tool do you use to create a device compliance policy?**

   Answer: Microsoft Intune. Compliance policies are defined in the Intune admin centre under 'Endpoint Security' or 'Devices'.

2. **What license is required to create Conditional Access policies?**

   Answer: Microsoft Entra ID Premium P1 or P2. Without these licenses, the Conditional Access blade will not be available.

3. **A user's iPhone is compliant with your Intune policy, but they are still blocked from accessing email. What is the most likely cause?**

   Answer: The Conditional Access policy may also require MFA, a specific location, or an approved app. Check the policy's Grant Controls and Conditions for additional requirements.

4. **What is the purpose of the 'What If' tool in Conditional Access?**

   Answer: It simulates a user sign-in to show which policies would apply, helping administrators troubleshoot access issues before enforcing a policy.

5. **True or False: A device that is Microsoft Entra hybrid joined is automatically considered compliant.**

   Answer: False. Hybrid join is a device identity state, not a compliance status. The device must still meet the compliance policies defined in Intune to be marked as compliant.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/md-102/managing-conditional-access