Plan a Conditional Access deployment
Planning your Conditional Access deployment is critical to achieving your organization's access strategy for apps and resources. Conditional Access policies provide great configuration flexibility. However, this flexibility also means you should plan carefully to avoid undesirable results.
Microsoft Entra Conditional Access combines signals such as user, device, and location to automate decisions and enforce organizational access policies for resources. These Conditional Access policies help you balance security and productivity, enforcing security controls when needed and staying out of the user’s way when not.
Conditional Access is the basis of Microsoft’s Zero Trust security policy engine.
Microsoft provides security defaults that ensure a basic level of security enabled in tenants that don't have Microsoft Entra ID P1 or P2. With Conditional Access, you can create policies that provide the same protection as security defaults, but with granularity. Conditional Access and security defaults aren't meant to be combined as creating Conditional Access policies prevent you from enabling security defaults.
Prerequisites
- A working Microsoft Entra tenant with Microsoft Entra ID P1, P2, or trial license enabled. If needed, create one.
- Administrators who interact with Conditional Access must have one of the following role assignments depending on the tasks they're performing. To follow the Zero Trust principle of least privilege, consider using Privileged Identity Management (PIM) to just-in-time activate privileged role assignments.
- Read Conditional Access policies and configurations
- Create or modify Conditional Access policies
- A test user (not an administrator) that allows you to verify policies work as expected before deploying to real users. If you need to create a user, see Quickstart: Add new users to Microsoft Entra ID.
- A group that the test user is a member of. If you need to create a group, see Create a group and add members in Microsoft Entra ID.
Communicating change
Communication is critical to the success of any new functionality. You should proactively communicate with your users how their experience changes, when it changes, and how to get support if they experience issues.
Conditional Access policy components
Conditional Access policies answer questions about who can access your resources, what resources they can access, and under what conditions. Policies can be designed to grant access, limit access with session controls, or to block access. You build a Conditional Access policy by defining the if-then statements like:
| If an assignment is met | Apply the access controls |
|---|---|
| If you're a user in Finance accessing the Payroll application | Require multifactor authentication and a compliant device |
| If you aren't a member of Finance accessing the Payroll application | Block access |
| If your user risk is high | Require a multifactor authentication and a secure password change |
User exclusions
Conditional Access policies are powerful tools, we recommend excluding the following accounts from your policies:
- Emergency access or break-glass accounts to prevent lockout due to policy misconfiguration. In the unlikely scenario all administrators are locked out, your emergency-access administrative account can be used to log in and take steps to recover access.
- More information can be found in the article, Manage emergency access accounts in Microsoft Entra ID.
- Service accounts and Service principals, such as the Microsoft Entra Connect Sync Account. Service accounts are non-interactive accounts that aren't tied to any particular user. They're normally used by back-end services allowing programmatic access to applications, but are also used to sign in to systems for administrative purposes. Calls made by service principals won't be blocked by Conditional Access policies scoped to users. Use Conditional Access for workload identities to define policies targeting service principals.
- If your organization has these accounts in use in scripts or code, consider replacing them with managed identities.
Ask the right questions
Here are some common questions about Assignments and Access Controls. Document the answers to questions for each policy before building it out.
Users or workload identities
- Which users, groups, directory roles, or workload identities are included in or excluded from the policy?
- What emergency access accounts or groups should be excluded from policy?
Cloud apps or actions
Will this policy apply to any application, user action, or authentication context? If yes:
- What applications or services will the policy apply to?
- What user actions are subject to this policy?
- What authentication contexts will this policy be applied to?
Filter for applications
Using filter for applications to include or exclude applications instead of individually specifying them helps organizations:
- Easily scale and target any number of applications.
- Easily manage applications with similar policy requirements.
- Reduce the number of individual policies.
- Reduce errors while editing policies: No need to add/remove applications manually from the policy. Just manage the attributes.
- Overcome policy size constraints.
Conditions
- Which device platforms are included in or excluded from the policy?
- What are the organization’s known network locations?
- What locations are included in or excluded from the policy?
- What client app types are included in or excluded from the policy?
- Do you need to target specific device attributes?
Block or grant controls
Do you want to grant access to resources by requiring one or more of the following?
- Multifactor authentication
- Device marked as compliant
- Using a Microsoft Entra hybrid joined device
- Using an approved client app
- App protection policy applied
- Password change
- Terms of Use accepted
Block access is a powerful control that you should apply with appropriate knowledge. Policies with block statements can have unintended side effects. Proper testing and validation are vital before you enable the control at scale. Administrators should use tools such as Conditional Access report-only mode when making changes.
Session controls
Do you want to enforce any of the following access controls on cloud apps?
- Use app enforced restrictions
- Use Conditional Access App control
- Enforce sign-in frequency
- Use persistent browser sessions
Combining policies
When creating and assigning policies, you must take into account how access tokens work. Access tokens grant or deny access based on whether the users making a request have been authorized and authenticated. If the requestor can prove they're who they claim to be, they can access the protected resources or functionality.
Access tokens are issued by default if a Conditional Access policy condition does not trigger an access control.
This policy doesn’t prevent the app having its own ability to block access.
For example, consider a simplified policy example where:
Users: FINANCE GROUP
Accessing: PAYROLL APP
Access control: Multifactor authentication
- User A is in the FINANCE GROUP, they're required to perform multifactor authentication to access the PAYROLL APP.
- User B is not in the FINANCE GROUP, is issued an access token and is allowed to access the PAYROLL APP without performing multifactor authentication.
To ensure users outside of finance group can't access the payroll app, a separate policy could be created to block all other users, like the following simplified policy:
Users: Include All Users / Exclude FINANCE GROUP
Accessing: PAYROLL APP
Access control: Block access
Now when User B attempts to access the PAYROLL APP they're blocked.
Recommendations
Taking into account our learnings in the use of Conditional Access and supporting other customers, here are a few recommendations based on our learnings.
Apply Conditional Access policies to every app
Ensure that every app has at least one Conditional Access policy applied. From a security perspective it's better to create a policy that encompasses All resources (formerly 'All cloud apps'), and then exclude applications that you don't want the policy to apply to. This practice ensures you don't need to update Conditional Access policies every time you onboard a new application.
Tip
Be very careful in using block and all apps in a single policy. This could lock admins out, and exclusions cannot be configured for important endpoints such as Microsoft Graph.
Minimize the number of Conditional Access policies
Creating a policy for each app isn’t efficient and leads to difficult administration. Conditional Access has a limit of 195 policies per-tenant. This 195 policy limit includes Conditional Access policies in any state including report-only mode, on, or off.
We recommend that you analyze your apps and group them into applications that have the same resource requirements for the same users. For example, if all Microsoft 365 apps or all HR apps have the same requirements for the same users, create a single policy and include all the apps to which it applies.
Conditional Access policies are contained in a JSON file and that file is bound to a size limit we don't expect a single policy to grow beyond. If you use a long list of GUIDs in your policy, you might hit this limit. If you encounter these limits, we recommend alternatives like:
- Use groups or roles to include or exclude Users instead of listing each user individually.
- Use filter for applications to include or exclude applications instead of individually specifying them.
Plan for disruption
To reduce the risk of lockout during unforeseen disruptions, plan resilience strategies for your organization.
Enable protected actions
Enabling protected actions puts another layer of security on attempts to create, modify, or delete Conditional Access policy. Organizations can require a fresh multifactor authentication or other grant control before modifying policy.
Set naming standards for your policies
A naming standard helps you to find policies and understand their purpose without opening them in the Azure admin portal. We recommend that you name your policy to show:
- A Sequence Number
- The cloud apps it applies to
- The response
- Who it applies to
- When it applies
Example: A policy to require MFA for marketing users accessing the Dynamics CRP app from external networks might be:
A descriptive name helps you to keep an overview of your Conditional Access implementation. The Sequence Number is helpful if you need to reference a policy in a conversation. For example, when you talk to an administrator on the phone, you can ask them to open policy CA01 to solve an issue.
Naming standards for emergency access controls
In addition to your active policies, implement disabled policies that act as secondary resilient access controls in outage or emergency scenarios. Your naming standard for the contingency policies should include:
- ENABLE IN EMERGENCY at the beginning to make the name stand out among the other policies.
- The name of disruption it should apply to.
- An ordering sequence number to help the administrator to know in which order policies should be enabled.
Example: The following name indicates that this policy is the first of four policies to enable if there's an MFA disruption:
- EM01 - ENABLE IN EMERGENCY: MFA Disruption [1/4] - Exchange SharePoint: Require Microsoft Entra hybrid join For VIP users.
Block countries/regions from which you never expect a sign-in
Microsoft Entra ID allows you to create named locations. Create the list of countries/regions that are allowed, and then create a network block policy with these "allowed countries/regions" as an exclusion. This option creates less overhead for customers who are based in smaller geographic locations. Be sure to exempt your emergency access accounts from this policy.
Deploy Conditional Access policies
When you're ready, deploy your Conditional Access policies in phases.
Build your Conditional Access policies
Refer to Conditional Access policy templates and Common security policies for Microsoft 365 organizations for a head start. These templates are convenient way to deploy Microsoft recommendations. Make sure you exclude your emergency access accounts.
Evaluate the policy impact
We recommend that you use the following tools to evaluate the effect of your policies both before and after making changes. A simulated run gives you a good idea of the effect a Conditional Access policy has, it doesn't replace an actual test run in a properly configured development environment.
- Report-only mode and the Conditional Access insights and Reporting workbook.
Test your policies
Ensure you test the exclusion criteria of a policy. For example, you might exclude a user or group from a policy that requires MFA. Test if the excluded users are prompted for MFA, because the combination of other policies might require MFA for those users.
Perform each test in your test plan with test users. The test plan is important to have a comparison between the expected results and the actual results. The following table outlines some example test cases. Adjust the scenarios and expected results based on how your Conditional Access policies are configured.
| Policy | Scenario | Expected Result |
|---|---|---|
| Device management | Authorized user attempts to sign in from an authorized device | Access granted |
| Device management | Authorized user attempts to sign in from an unauthorized device | Access blocked |
Deploy in production
After you confirm impact using report-only mode, an administrator can move the Enable policy toggle from Report-only to On.
Roll back policies
In case you need to roll back your newly implemented policies, use one or more of the following options:
Disable the policy. Disabling a policy makes sure it doesn't apply when a user tries to sign in. You can always come back and enable the policy when you would like to use it.
Exclude a user or group from a policy. If a user is unable to access the app, you can choose to exclude the user from the policy.
Caution
Exclusions should be used sparingly, only in situations where the user is trusted. Users should be added back into the policy or group as soon as possible.
If a policy is disabled and no longer required, delete it.
Troubleshoot Conditional Access policies
If a user has an issue with a Conditional Access policy, collect the following information to facilitate troubleshooting.
- User Principal Name
- User display name
- Operating system name
- Time stamp (approximate is ok)
- Target application
- Client application type (browser vs client)
- Correlation ID (this ID is unique to the sign-in)
If the user received a message with a More details link, they can collect most of this information for you.
Once you collect the information, see the following resources:
- Sign-in problems with Conditional Access - Understand unexpected sign-in outcomes related to Conditional Access using error messages and Microsoft Entra sign-in log.