Conditional Access Policies

Conditional Access Policies in Microsoft Entra – A Complete Guide for SC-900

Why Conditional Access Policies Matter

In today's hybrid and cloud-first world, the traditional network perimeter no longer exists. Users access corporate resources from any device, any location, and at any time. This creates a significant security challenge: how do you ensure that only the right people, under the right conditions, gain access to the right resources?

Conditional Access Policies are Microsoft's answer to this challenge. They sit at the heart of Microsoft Entra's Zero Trust strategy and act as the if-then policy engine that evaluates every access request in real time. Understanding Conditional Access is essential not only for real-world security administration but also for passing the SC-900: Microsoft Security, Compliance, and Identity Fundamentals exam.

What Are Conditional Access Policies?

Conditional Access Policies are automated access control decisions within Microsoft Entra ID (formerly Azure Active Directory). They function as an if-then engine:

If a user wants to access a resource, then they must satisfy certain conditions before access is granted.

Think of Conditional Access as the gatekeeper that sits between the user's sign-in attempt and the resource they want to reach. It evaluates a set of signals, applies one or more conditions, and enforces access controls (also called grant or session controls).

Conditional Access Policies require at minimum a Microsoft Entra ID P1 license.

How Conditional Access Works – The Core Components

Every Conditional Access Policy is built from three main elements:

1. Signals (Inputs)
These are the data points that the policy engine evaluates when a user tries to sign in. Common signals include:

• User or group membership – Policies can target specific users, groups, or roles. For example, you might create a stricter policy for Global Admins than for standard users.
• IP location / Named locations – You can define trusted IP ranges or geographic locations. Access from outside corporate networks or from high-risk countries can trigger additional requirements.
• Device – The platform (Windows, iOS, Android, macOS, Linux) or the device compliance state (compliant, hybrid Azure AD joined, etc.).
• Application – The specific cloud app or action the user is trying to access (e.g., Microsoft 365, Azure portal, custom apps).
• Real-time sign-in risk and user risk – When integrated with Microsoft Entra ID Protection, policies can respond to risk levels (low, medium, high) detected through machine learning. For example, a sign-in from an anonymous IP address or an impossible travel scenario would raise the sign-in risk level.
• Client application – Whether the user is accessing through a modern authentication client, a browser, Exchange ActiveSync, or legacy authentication protocols.

2. Conditions (Evaluation Criteria)
Conditions define when the policy applies. They are essentially filters built from the signals above. You configure conditions such as:

• Device platforms (e.g., apply only to Android and iOS)
• Locations (e.g., apply only when outside the corporate network)
• Client apps (e.g., apply only to browser-based access)
• Sign-in risk level (e.g., apply only when risk is medium or high)
• User risk level (e.g., apply only when the user account is flagged as compromised)

3. Access Controls (Decisions / Enforcement)
Once the signals are evaluated and the conditions are met, the policy enforces one of the following decisions:

• Block access – Completely deny access to the resource. This is the most restrictive control.
• Grant access – Allow access but potentially require one or more additional controls:
  - Require multi-factor authentication (MFA)
  - Require device to be marked as compliant (via Microsoft Intune)
  - Require Hybrid Azure AD joined device
  - Require an approved client app
  - Require an app protection policy
  - Require password change (when user risk is detected)
• Session controls – Allow access but with restrictions on the session itself:
  - App-enforced restrictions (limited access in SharePoint Online)
  - Conditional Access App Control (routes sessions through Microsoft Defender for Cloud Apps for real-time monitoring)
  - Sign-in frequency (control how often users must re-authenticate)
  - Persistent browser session (control whether sessions persist after browser close)

The Flow of a Conditional Access Evaluation

1. A user attempts to sign in to a cloud application.
2. Microsoft Entra ID authenticates the user (first factor).
3. The Conditional Access engine collects all relevant signals (user identity, location, device state, app being accessed, risk level).
4. The engine evaluates all applicable Conditional Access Policies. Note: If multiple policies apply, all policies must be satisfied – policies are cumulative, and the most restrictive controls win.
5. Based on the evaluation, the engine either blocks access, grants access, or grants access with additional requirements (e.g., MFA prompt, device compliance check).
6. If the user meets all requirements, access is granted to the resource.

Key Concepts to Remember

• Policies are cumulative (AND logic between policies): If two policies apply to a user and one requires MFA while the other requires a compliant device, the user must satisfy both requirements.
• Within a single policy, multiple grant controls can use AND or OR logic: Administrators can configure whether the user must meet all selected controls (AND) or any one of them (OR).
• Block takes precedence: If any applicable policy blocks access, access is denied regardless of other policies that might grant it.
• Exclusions: You should always configure break-glass (emergency access) accounts and exclude them from Conditional Access Policies to prevent lockout scenarios.
• Report-only mode: Administrators can deploy policies in report-only mode first to evaluate their impact before actually enforcing them. This is a best practice for testing.
• Assignments: Every policy has assignments that define who the policy applies to (users/groups), what cloud apps or actions are targeted, and under what conditions.

Common Conditional Access Scenarios

• Require MFA for all administrators: Target the Directory Roles (e.g., Global Admin, Security Admin) and require MFA as a grant control.
• Block legacy authentication: Target all users, set the client apps condition to Exchange ActiveSync and other legacy clients, and set the access control to Block.
• Require compliant devices for accessing sensitive apps: Target a specific application (e.g., SharePoint Online) and require the device to be marked as compliant through Intune.
• Require MFA for risky sign-ins: Integrate with Entra ID Protection, set the sign-in risk condition to Medium and High, and require MFA.
• Restrict access by location: Define named locations for trusted corporate IP ranges and block or require MFA for access from outside those locations.

Conditional Access and Zero Trust

Conditional Access is a cornerstone of the Zero Trust security model. Zero Trust operates on the principle of never trust, always verify. Conditional Access enforces this by:

• Verifying identity explicitly through MFA and risk-based evaluation
• Using least privilege access by granting only the access needed under the right conditions
• Assuming breach by continuously evaluating sessions and enforcing controls in real time

Relationship with Other Microsoft Entra Features

• Microsoft Entra ID Protection: Provides risk signals (user risk and sign-in risk) that Conditional Access Policies can consume to make dynamic decisions.
• Microsoft Intune: Provides device compliance state information. Conditional Access can require devices to be compliant before granting access.
• Microsoft Defender for Cloud Apps: Conditional Access App Control routes sessions through Defender for Cloud Apps for real-time monitoring and control.
• Multi-Factor Authentication (MFA): MFA is one of the most commonly used grant controls within Conditional Access Policies.

Licensing Requirements

• Conditional Access requires Microsoft Entra ID P1 (included in Microsoft 365 E3, EMS E3, and other plans).
• Risk-based Conditional Access (using sign-in risk and user risk from ID Protection) requires Microsoft Entra ID P2 (included in Microsoft 365 E5, EMS E5).

---

Exam Tips: Answering Questions on Conditional Access Policies (SC-900)

Here are targeted tips to help you answer SC-900 exam questions about Conditional Access with confidence:

1. Know the if-then concept: Many questions test whether you understand that Conditional Access is an if-then policy engine. If a condition is met, then an access control is enforced. If a question describes a scenario where access should be restricted based on certain conditions, Conditional Access is almost always the answer.

2. Understand the difference between signals, conditions, and controls: The exam may present scenarios and ask what component is being described. Remember: signals are the raw data (location, device, user), conditions are the filters, and controls are the enforcement actions (block, grant with MFA, session restrictions).

3. Block access vs. Grant access with controls: If a question asks about completely preventing access from a certain location or for legacy authentication, the answer involves Block access. If a question asks about requiring additional verification, the answer involves Grant access with conditions (such as requiring MFA).

4. Cumulative policy enforcement: Remember that when multiple policies apply, the user must satisfy ALL of them. The most restrictive combination wins. This is a frequently tested concept.

5. Report-only mode: If a question asks about testing a Conditional Access Policy before enforcement, the answer is report-only mode. This allows administrators to see the impact without actually blocking or granting access.

6. Emergency/break-glass accounts: If a question asks about preventing lockout, look for answers that mention excluding emergency access accounts from Conditional Access Policies.

7. Licensing: If a question asks what license is needed for Conditional Access, remember it requires Entra ID P1. For risk-based Conditional Access (using ID Protection risk signals), Entra ID P2 is required.

8. Do not confuse Conditional Access with MFA alone: MFA is just one of many controls that Conditional Access can enforce. Conditional Access is the broader policy framework; MFA is a specific control within it.

9. Know the Zero Trust connection: If a question asks which feature enforces Zero Trust principles by verifying every access request based on multiple signals, Conditional Access is the answer.

10. Watch for distractor answers: The exam may offer options like Azure Policy, Network Security Groups (NSGs), or role-based access control (RBAC). These serve different purposes. Conditional Access is specifically about controlling access to cloud apps based on conditions at sign-in time.

11. Common scenario patterns to recognize:
- "Require MFA when signing in from outside the corporate network" → Conditional Access with location condition and MFA grant control
- "Block access from unmanaged devices" → Conditional Access with device compliance condition and block control
- "Require additional verification when a risky sign-in is detected" → Conditional Access integrated with Entra ID Protection (requires P2)
- "Prevent use of legacy authentication protocols" → Conditional Access with client apps condition set to legacy auth and block control

12. Remember the policy components in order: Assignments (who + what + conditions) → Access Controls (grant controls + session controls). This structure helps you quickly parse scenario-based questions and identify which component is being asked about.

By mastering these concepts and tips, you will be well-prepared to tackle any Conditional Access question on the SC-900 exam with confidence.