Deployment of 10 Essential Conditional Access Policies

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.

Risk detection
Possible attempt to access Primary Refresh Token (PRT)
Anomalous user activity
User reported suspicious activity
Additional risk detected
Leaked credentials
Microsoft Entra threat intelligence

 

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. 

Risk detection
Atypical travel
Anomalous Token
Token Issuer Anomaly
Malware linked IP address
Suspicious browser
Unfamiliar sign-in properties
Malicious IP address
Suspicious inbox manipulation rules
Password spray
Impossible travel
New country
Activity from anonymous IP address
Suspicious inbox forwarding
Mass Access to Sensitive Files
Verified threat actor IP
Additional risk detected
Anonymous IP address
Admin confirmed user compromised
Microsoft Entra threat intelligence

 

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.