Deploying Conditional Access in your organization can be (and should be) a rather long task. This is because rushing into enforcing strict access controls may result in preventing your legitimate business and IT users connect to your systems and applications.
There are however some Conditional Access Policies which may be called as the best practices of Conditional Access. These policies are less risky because they target identified bad access attempts rather than creating permissive access policies that depend on a careful and long analysis of your company’s access patterns.
The best part about the mentioned policies is that Microsoft has also understood the importance of enforcing these policies and made them available in form of templates. Conditional Access administrators are given the chance to use predefined templates and to make the necessary changes specific to their organizations to quickly deploy the policies.
Important Considerations
A more careful approach in deploying the Conditional Approach Policies would be to deploy all the policies in “Report-only” mode. This is especially recommended for administrators and organizations that are in the beginning of their Conditial Access policy creation journeys. After checking the results of report-only mode at least for a week, it is totally safe to enforce the policy in “On” mode.
Another critical point is the impact on 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 into systems for administrative purposes. Service accounts like these should be first identified and then excluded since MFA can’t be completed programmatically. This way, calls made by service principals won’t be blocked by Conditional Access policies scoped to users.
If your organization has these accounts in use in scripts or code, consider replacing them with managed identities. As a faster but less ideal workaround, you can exclude these specific accounts from the baseline policy.
Finally, bear in mind that Conditional Access policies support only built-in roles. Conditional Access policies are not enforced for other role types including administrative unit-scoped or custom roles.
Conditional Access Policies
1. BASIC: Require multifactor authentication for Administrators.
This conditional access policy is the most basic form of security hardening for your administrator users.
The rule logic is given below. Note that this policy is basic in its functionality. It only enforces multifactor authentication for the administrator roles without requiring any strength when it comes to the MFA methods.
| Administrator Roles |
| Global Administrator |
| Security Administrator |
| Exchange Administrator |
| Conditional Access Administrator |
| Helpdesk Administrator |
| Billing Administrator |
| User Administrator |
| Authentication Administrator |
| Application Administrator |
| Cloud Application Administrator |
| Password Administrator |
| Privileged Authentication Administrator |
| Privileged Role Administrator |
| Policy Name | Require Multifactor Authentication for Admins |
| Assignments | |
| Excluded Users | Conditional Access Admin |
| Included Users | Above roles |
| Cloud Apps | All apps |
| Access Controls | |
| Grant Access | Require multifactor authentication |
2. BASIC: Require multifactor authentication for Azure Management
This policy is like the first policy. The only difference is that this policy is specific to the Microsoft Azure Management app rather than the roles. Any user accessing the Azure Management portal will be required to authenticate using multifactor authentication.
| Policy Name | Require Multifactor Authentication for Azure Management |
| Assignments | |
| Excluded Users | Conditional Access Admin |
| Included Users | All |
| Cloud Apps | Microsoft Azure Management |
| Access Controls | |
| Grant Access | Require multifactor authentication |
*We strongly recommend eliminating outdated MFA methods like SMS by selecting Require Authentication Strength box instead of Require Multifactor Authentication box as it can be seen below and select “Passwordless MFA”.
3. BASIC: Block Legacy Authentication
Due to the increased risk associated with legacy authentication protocols, we recommend you block authentication requests using these protocols and require modern authentication. For more information about why blocking legacy authentication matters, please check this article.
| Policy Name | Require Multifactor Authentication for Admins |
| Assignments | |
| Excluded Users | Conditional Access Admin |
| Included Users | All Users |
| Cloud Apps | All apps |
| Legacy Authentication Clients | Exchange active sync clients
Other clients |
| Access Controls | |
| Block Access | Selected |
This policy needs specific attention as contrary to the previous policies, this is a block policy. We recommend you to first use “Report-Only” mode and monitor before enforcing it in “On” mode.
4. BASIC: Require multifactor authentication for Microsoft Admin Portals
This policy aims to secure access to Microsoft admin portals like Microsoft Entra ID, Microsoft 365 Defender, Exchange Online, and Microsoft Purview portals among many others.
| Policy Name | Require Multifactor Authentication for MS Admin Portals |
| Assignments | |
| Excluded Users | Conditional Access Admin |
| Included Users | Global Administrator
Security Administrator Exchange Administrator Conditional Access Administrator Helpdesk Administrator Billing Administrator User Administrator Authentication Administrator Password Administrator Privileged Role Administrator Privileged Authentication Administrator |
| Cloud Apps | Microsoft Admin Portals |
| Access Controls | |
| Grant Access | Require authentication strength (Passwordless) |
5. BASIC: No persistent browser session.
This Conditional Access Policy helps protecting user access on unmanaged devices by preventing browser sessions from remaining signed in after the browser is closed and setting a sign-in frequency to 1 hour.
| Policy Name | No Persistent Browser Session |
| Assignments | |
| Excluded Users | Conditional Access Admin |
| Included Users | All Users |
| Cloud Apps | All Apps |
| Include Filtered devices in policy | device. trustType -not equals “ServerAD” –
or device. isCompliant -not equals True |
| Access Controls | |
| Sign-in Frequency | 1 hour |
| Persistent Browser Session | Never persistent |
6. BASIC: Block Access by Location
There are many organizations which are serving within a specific geographical region. It is also required in some industries like finance to put some technical controls in place to avoid doing business.
It might be wise to start with restricting access to all cloud applications originating directly from blacklisted countries in your organization.
A stricter version of this rule can be applied to administrative access to your applications by only allowing connections from the countries where your admins reside.
It is very important to know that this policy is not protecting your applications from a potential Distributed Denial-of-Service (DDOS) attack. This policy can also be circumvented by attackers using web proxies located in permitted countries. It is still a good practice to use it to reduce noise.
Before passing directly to the policy configuration, Blocked Countries should be defined in the “Named Locations” section as shown below.
| Policy Name | Block Access by Location |
| Assignments | |
| Excluded Users | Conditional Access Admin |
| Included Users | All Users |
| Cloud Apps | All Apps |
| Conditions | |
| Locations | Blocked Countries |
| Access Controls | |
| Grant | Block Access |
7. BASIC: Require Password Change for High-Risk Users
Microsoft collaborates with researchers, law enforcement, and other trusted sources to find leaked username and password pairs. Organizations with Microsoft Entra ID P2 licenses can create Conditional Access policies based on identified leaked accounts.
The list of activities that define the risk level of a user is given in the table below. Microsoft does not detail the risk level of each action and uses a calculation of its own.
This Conditional Access policies forces user accounts that are known to be breached to reset their passwords.
| Policy Name | Require Password Change for High-Risk Users |
| Assignments | |
| Excluded Users | Conditional Access Admin |
| Included Users | All Users |
| Cloud Apps | All Apps |
| Conditions | |
| User Risk | High |
| Access Controls | |
| Grant | Require password change |
8. BASIC: Require Multifactor Authentication for Risky Sign-Ins
Microsoft uses several behaviors to assign a risk score to user sign-in activities. Unfortunately for us, they do not disclose what level of risk they assign for each activity, but you can find the list of activities below.
The policy below follows the risky sign-in activities and forces your risky sign-in users to multifactor authentication in case you do not enforce multifactor authentication to all of your users by default.
| Policy Name | Require Multifactor Authentication for Risky Sign-Ins |
| Assignments | |
| Excluded Users | Conditional Access Admin |
| Included Users | All Users |
| Cloud Apps | All Apps |
| Conditions | |
| Sign-In Risk | High
Medium |
| Access Controls | |
| Grant | Require authentication strength (Passwordless MFA) |
9. INTERMEDIATE: Require stronger MFA for Administrators
This policy is the more secure version of policy number 1. The difference between the 2 policies is for certain administrator roles, like Global Administrator and Security Administrator, you might require either Passwordless MFA (Authenticator App) or the most secure form of MFA which is called Phishing Resistant MFA which includes physical keys (like YubiKey) or Windows Hello for Business (Advanced Biometric Authentication where biometric information is securely stored in your computers TPM2.0 chip).
More information on Phishing Resistant MFA can be found in this link.
| Policy Name | Require Stronger Multifactor Authentication for Admins |
| Assignments | |
| Excluded Users | Conditional Access Admin |
| Included Users | Global Administrator
Security Administrator Exchange Administrator User Administrator Authentication Administrator Password Administrator Privileged Role Administrator Privileged Authentication Administrator |
| Cloud Apps | All apps |
| Access Controls | |
| Grant Access | Require authentication strength (Passwordless MFA) |
10. INTERMEDIATE: Require compliant or hybrid Azure AD joined device for Administrators.
Accounts that are assigned administrative rights are frequently targeted by attackers. Requiring users with these highly privileged rights to perform actions from devices marked as compliant or Azure AD hybrid joined can help limit possible exposure.
The resulting policy would look like as below.
| Policy Name | Require Compliant or Hybrid Azure AD joined devices for Admins |
| Assignments | |
| Excluded Users | Conditional Access Admin |
| Included Users | Global Administrator
Security Administrator Exchange Administrator User Administrator Authentication Administrator Application Administrator Cloud Application Administrator Password Administrator Privileged Role Administrator Privileged Authentication Administrator |
| Cloud Apps | All apps |
| Access Controls | |
| Grant Access | Require device to be marked as compliant.
OR Require Microsoft Entra hybrid joined device |
Conclusion
This article details 10 best practice Conditional Access Policies that can be easily activated to protect the most important parts of many organizations. Microsoft’s own suggestions are followed but also customized to make them stronger wherever possible and wherever it makes sense.
Please contact us for your queries and deployment support.
