Conditional Access Assignments and Controls – A Complete Guide for SC-300
Why Conditional Access Assignments and Controls Matter
Conditional Access is the heart of Microsoft Entra ID's Zero Trust security model. It acts as the decision engine that evaluates every authentication request and determines whether to grant access, deny access, or require additional verification. Understanding assignments and controls is critical because they define who is affected, what they are accessing, under what conditions, and what happens when those conditions are met. For the SC-300 exam, this topic is heavily tested and appears across multiple question formats.
What Are Conditional Access Assignments?
Assignments are the conditions side of a Conditional Access policy. They define the scope — essentially answering the questions: Who? What? Where? When? How?
Assignments include the following components:
1. Users and Groups
You can include or exclude specific users, groups, directory roles, or guest/external users. Key options include:
- All users – applies to everyone in the tenant
- Specific users and groups – security groups, Microsoft 365 groups, or individual users
- Directory roles – e.g., Global Administrator, Security Administrator
- Guest or external users – B2B collaboration users, service provider users, etc.
- Exclusions – you can exclude emergency (break-glass) accounts or specific groups
2. Target Resources (Cloud Apps or Actions)
This determines what the policy applies to:
- All cloud apps – every application registered in Microsoft Entra ID
- Select apps – specific applications like Microsoft 365, Azure portal, etc.
- User actions – such as Register security information or Register or join devices
- Authentication context – used with sensitivity labels and Microsoft Purview
- Global Secure Access (preview) – for traffic profiles
3. Conditions
Conditions add contextual signals to the policy:
- User risk – based on Identity Protection; levels are High, Medium, Low, No risk
- Sign-in risk – also from Identity Protection; evaluates real-time risk signals like anonymous IP, atypical travel, malware-linked IP, etc.
- Device platforms – Android, iOS, Windows, macOS, Linux, or Windows Phone
- Locations – Named locations (IP-based or country-based); you can mark trusted locations
- Client apps – Browser, Mobile apps and desktop clients, Exchange ActiveSync clients, Other clients (legacy authentication)
- Filter for devices – uses device properties like compliance state, device OS, or extension attributes to dynamically include or exclude devices
- Service principal risk (preview) – risk level of workload identities
What Are Conditional Access Controls?
Controls define what happens when the assignment conditions are met. There are two types of controls:
1. Grant Controls
Grant controls either block or grant access with optional requirements:
- Block access – completely prevents access
- Grant access – allows access but can require one or more of the following:
• Require multifactor authentication (MFA)
• Require authentication strength – allows you to specify specific MFA methods (e.g., phishing-resistant MFA, passwordless)
• Require device to be marked as compliant – device must meet Intune compliance policies
• Require Microsoft Entra hybrid joined device
• Require approved client app – app must be on Microsoft's approved list
• Require app protection policy – an Intune app protection policy must be applied
• Require password change – forces user to change password (used with user risk policies)
When multiple grant controls are selected, you must choose:
- Require all the selected controls (AND logic)
- Require one of the selected controls (OR logic)
2. Session Controls
Session controls limit the experience within a cloud app after sign-in:
- Use app enforced restrictions – works with Exchange Online and SharePoint Online to provide limited access (e.g., browser-only with no download)
- Use Conditional Access App Control – routes sessions through Microsoft Defender for Cloud Apps for real-time monitoring and control
- Sign-in frequency – defines how often users must re-authenticate (e.g., every 1 hour, every 30 days)
- Persistent browser session – controls whether users remain signed in after closing the browser
- Customize continuous access evaluation – enables or enforces strict location enforcement with CAE
- Disable resilience defaults – prevents Azure from extending existing sessions during outages
How Conditional Access Policy Evaluation Works
1. A user attempts to sign in to a resource.
2. Microsoft Entra ID collects all signals: user identity, group membership, location, device state, application, client app, risk level, etc.
3. All Conditional Access policies are evaluated. Policies are NOT processed in order — all applicable policies are evaluated simultaneously.
4. If any policy results in Block access, access is denied immediately (Block always wins).
5. If multiple policies apply and grant access with different requirements, all requirements must be satisfied (AND across policies).
6. If no policy applies, the default behavior is to allow access (no MFA, no device requirements).
Important Concepts to Remember
- Block always wins: If one policy blocks and another grants, the user is blocked.
- Policies are additive: If Policy A requires MFA and Policy B requires a compliant device, the user must satisfy both.
- Report-only mode: Lets you test policies without enforcing them. Results appear in sign-in logs and the Conditional Access insights workbook.
- Emergency access accounts: Always exclude at least one break-glass account from Conditional Access policies to prevent lockout.
- Named locations: Must be created before they can be referenced in policies. Trusted locations can be used to skip MFA for corporate networks.
- Authentication strength: A newer feature that lets you require specific authentication methods rather than just any MFA method. For example, you can require phishing-resistant MFA (FIDO2, Windows Hello for Business, or certificate-based authentication).
- User risk vs. Sign-in risk: User risk is the overall compromise likelihood of the user account. Sign-in risk is the likelihood that a specific sign-in is not from the legitimate user. These are powered by Microsoft Entra ID Protection.
- Legacy authentication: Does not support MFA. Best practice is to create a policy that blocks legacy authentication protocols (Other clients).
Common Conditional Access Scenarios
• Require MFA for all administrators
• Require MFA for all users accessing Azure management
• Block legacy authentication
• Require compliant devices for accessing corporate apps
• Require MFA from outside trusted locations
• Require password change when user risk is high
• Require phishing-resistant MFA for sensitive applications using authentication strength
• Use session controls to limit downloads from unmanaged devices
Exam Tips: Answering Questions on Conditional Access Assignments and Controls
Tip 1: Remember that Block always wins. If a question describes a scenario where one policy blocks and another grants, the answer is always that the user is blocked.
Tip 2: Understand the difference between grant controls requiring ALL vs. ONE of the selected controls. The exam loves to test whether you know the AND/OR logic within a single policy's grant controls and the AND logic across multiple policies.
Tip 3: Know the difference between Require device to be marked as compliant (Intune compliance) and Require Microsoft Entra hybrid joined device. These are separate controls that serve different device management strategies.
Tip 4: When a question mentions unmanaged devices, think about session controls like app enforced restrictions (limited web-only access in SharePoint/Exchange) or Conditional Access App Control (Defender for Cloud Apps proxy).
Tip 5: Questions about risk-based policies will reference Identity Protection. User risk policies should require password change. Sign-in risk policies should require MFA. Know these recommended remediation actions.
Tip 6: Be aware that Conditional Access policies do not apply to service principals by default. Workload identity policies require a separate Workload Identities Premium license.
Tip 7: Understand authentication strength. If a question asks how to enforce phishing-resistant MFA specifically, the answer is to use authentication strength (not just require MFA, which allows any MFA method).
Tip 8: The exam may test Named Locations. Remember that you can define locations by IP ranges or by country/region. Trusted locations can be used in policy conditions to exclude corporate networks from MFA requirements.
Tip 9: Watch for questions about emergency access accounts. Microsoft best practice is to have at least two break-glass accounts that are excluded from all Conditional Access policies and do not rely on MFA or any single device.
Tip 10: When the question says without affecting the user experience for compliant devices, the policy likely needs to target non-compliant or unregistered devices using device filters or platform conditions, or use session controls rather than blocking access entirely.
Tip 11: Report-only mode is used to evaluate the impact of a policy before enforcement. If a question asks how to test a policy safely, report-only mode is the answer.
Tip 12: Pay close attention to exclusions in scenario questions. The exam often describes a situation where a specific group should be exempt. You must configure the exclusion correctly in the assignments section.
Tip 13: For questions about blocking legacy authentication, the correct condition is to set Client apps to Exchange ActiveSync clients and Other clients, and set the grant control to Block access.
Tip 14: Understand that sign-in frequency and persistent browser session controls manage how long tokens are valid and whether users stay signed in. These are session controls, not grant controls.
Tip 15: Remember that Conditional Access policies require at minimum a Microsoft Entra ID P1 license. Risk-based policies (user risk and sign-in risk conditions) require Microsoft Entra ID P2.
