Conditional access policies in Microsoft Entra ID allow for very granular security management. The problem is that organizations usually do not have conditional access policies properly defined. There tend to be blind spots, policies don’t cover all applications, all users, and all scenarios.
The real-world problems
Many organizations have conditional access policies defined but do not think about them properly. This is because they often target only specific applications or specific users. And when I ask them why the MFA policy only targets Office 365 for example, they tell me they don’t use anything else. Or when I ask why they only target one group of users, they tell me that other users don’t use cloud services.
But that’s just the wrong approach. You are not primarily protecting the services from your users, but from attackers. And just because you don’t use anything other than Office 365 doesn’t mean an attacker will not use it. Or just because some users don’t use cloud services doesn’t mean those accounts can’t be exploited by an attacker. If those apps or accounts exist in the cloud, they need to be protected whether regular users use them or not. Attackers are looking for the most insecure places, the weakest links.
At the outset, it should be said that this article is not “one size fits all”. Different organizations may have different requirements and expectations and conditional access policies set accordingly. So this article should serve more as an inspiration to think about whether you have built your conditional access policies correctly and comprehensively.
Before we start creating the actual conditional access policies, we need to prepare an “emergency plan”. When applying conditional access policies, you can easily find yourself locked out. You will create a policy that will apply to you and other administrators, but which cannot be satisfied. And thus you lose access to the tenant.
Microsoft support is able to resolve this issue, but it’s a significant complication, and it’s definitely better to prevent it. And that’s what break-glass accounts are for. I’ve written about managing break-glass accounts in one of my previous articles How to manage break-glass accounts in Microsoft Entra ID, so I’ll just remind you to have at least one break-glass account created before creating conditional access policies.
Break-glass accounts will be excluded from all conditional access policies.
Require MFA from non-compliant devices
Coverage of all possible scenarios/situations is essential for conditional access policies. That is, so that no blind spots remain. Unprotected applications, unprotected users, users in exclusions, etc. Because it is very easy to forget something when you start building policies incrementally for different scenarios. You’ll target different types of users, applications, platforms, but completely forget that there are other applications, other types of users, other platforms, etc. And attackers can find and exploit these coverage gaps.
That’s why it’s a good idea to start with some basic policy that defines the foundation of security and targets all applications, all users, and all scenarios. This basic policy may be, for example, requiring multi-factor authentication when accessing from non-compliant devices. This policy will be applied to all accounts and all cloud applications and will require multi-factor authentication if a given login attempt is not initiated from a compliant device.
This policy will therefore be applied to all users and all cloud applications. Only put the break-glass accounts in the user exclusions. In Conditions, I’m targeting the web browser and mobile and desktop apps, because Exchange ActiveSync and Other clients are completely blocked by another policy, see below.
In Filter for devices I have set this policy to apply to devices that are not marked as compliant. So I take the Property isCompliant, Operator is Not equals and the value is True. Someone might think that this can be done the other way around, i.e. isCompliant Equals False. But this could potentially be a weak point, because if the compliance status failed to load for whatever reason, this requirement would be met and MFA would not be required afterwards. So if we check the compliance status as isCompliant Not equals True, we are sure that we are taking the safer route and anything that is not explicitly compliant will require MFA.
Lastly, just set the Grant section to require MFA. In general, I always recommend using Authentication Strength instead of the generic Require multifactor authentication, because Authentication Strength allows you to define what specific types of authentication you require.
Require MFA for admins
Another baseline policy should be requiring MFA for administrators. The difference from the previous policy is that the previous policy targeted all users but required MFA only from non-compliant devices. This policy will target only administrators, but will instead require MFA at all times, including from compliant devices.
Because administrators are highly privileged accounts, their security must be greater than for regular users. Therefore, MFA should always be required regardless of whether it is accessed from a compliant device or not.
We will therefore target privileged roles within the policy. The important thing here is to actually target roles, not specific users or user groups. This can again cause gaps where you assign an admin role to someone but forget to add the account to the policy.
You should at least select these roles:
- Global Administrator
- Application Administrator
- Authentication Administrator
- Billing Administrator
- Cloud Application Administrator
- Conditional Access Administrator
- Exchange Administrator
- Helpdesk Administrator
- Password Administrator
- Privileged Authentication Administrator
- Privileged Role Administrator
- Security Administrator
- SharePoint Administrator
- User Administrator
In general, you should select the roles that you use. If you select all roles, you definitely won’t make a mistake. Don’t forget to put your break-glass account in the exclusions.
In cloud apps, select all apps. And under Grant, select Require Authentication Strength.
Block Exchange ActiveSync and legacy authentication protocols
Exchange ActiveSync is a protocol used by some alternative mail applications such as Apple Mail, Samsung Mail and others. Official Microsoft applications do not use Exchange ActiveSync and do not need it for anything. And unused stuff is good to disable.
Legacy authentication, referred to as “Other clients” in conditional access policies, are applications that use POP3, IMAP and SMTP. These protocols don’t support modern authentication at all, so you can’t enforce multi-factor authentication on these protocols at all. Even attackers know this, so the vast majority of attacks are directed at legacy authentication protocols, because there you just need to know/crack the password and nothing else stands in the way. Legacy authentication should always be disabled.
In this policy, we will again target all users. There’s no need to put the break-glass account in the exclusions here either, as it should never use Exchange ActiveSync or legacy authentication. We will also target all applications.
Under Conditions – Client apps we will select Exchange ActiveSync clients and Other clients. Under Grant, we will select Block access.
Block access from unknown platforms
Organisations have platforms that they officially support and manage. These are usually Windows, macOS, iOS/iPadOS and Android. Other platforms tend to be unmanaged and therefore unsupported.
Again, unsupported stuff is good to disable completely. And this applies to platforms as well. So we create a conditional access policy that disables everything not listed above. Of course, modify the list of platforms you support to suit your needs. For example, if you don’t use macOS in your organization, remove it from the list os it is blocked when authenticating with Microsoft Entra ID.
Within users, we will again target all users and add the break-glass account to the exclusions. In cloud applications, we will target all cloud applications.
Under Conditions, go to Device platforms and under Include select Any device and under Exclude select the platforms you support. So in my case Andoid, iOS, Windows, macOS. The reason it’s done this way is because we want to block everything except the ones we select – that’s why the supported platforms are in the exclusions.
Now under Grant, select Block access. This will ensure that access is blocked from all platforms except those explicitly selected in the exclusions.
Require MFA for device join
One thing that is often forgotten is the registration of devices. Most organizations allow all users to register devices to Microsoft Entra ID. At that point, the device potentially becomes a compliant device across the entire organization, which will likely satisfy some conditional access policies, see the policy above for example on MFA for regular users not required from compliant devices. It is then significantly easier to attack other accounts within the organization from such a device.
Device registration by an attacker is an thing we see very often during incident response for the very reason mentioned above. If the device registration process is not secure (or completely disabled) for normal users, an attacker can simply obtain/crack the password of any user in the organisation, allowing them to register their own device and then attack other accounts and services from that device with much greater ease.
This policy will therefore again target all users. A break-glass account does not need an exclusion here. Under Target resources in the top drop-down, select User actions and then select Register or join devices as the action. Under Grant, select Require Authentication Strength to require MFA.
Secure MFA enrollment
In order to use MFA, users must first register. However, there may be a problem that a potential attacker can register for MFA too if they already have access to the identity. Again, this is something we commonly see during incident response, that attackers register their own authentication methods for MFA to be able to meet the MFA requirement for accessing applications and services.
Therefore, the actual process of registering MFA needs to be secured as well.
Thus, we create a conditional access policy that targets all users except the break-glass account and except external users. Here it is important to exclude external users, as they are unlikely to be able to meet the requirement for MFA registration.
In the Target resources section, select User actions from the dropdown menu and choose Register security information. The question then becomes how you are realistically able to secure the MFA registration process. In general, I would recommend requiring a compliant device or MFA. Requiring an MFA may seem like a nonsensical requirement when it is the MFA registration process. However, it is possible that the user already has an MFA method registered (such as a phone number) and is just adding another method (such as Microsoft Authenticator).
In the Conditions section, select Filter for devices and set Property to isCompliant, Operator to Not equals and Value to True. Same principle as we set in the policy requiring MFA for all users above. And in the Grant section, set Require Authentication Strength.
The above setting will ensure that if the user is accessing from a compliant device, then they will not be required to MFA to register authentication information. If the user is accessing from a non-compliant device, MFA will be required to register additional authentication information.
Require compliant devices for application access
Access from applications means that the application is registered and has received a Primary Refresh Token. It also means that the login in that application is permanent – no re-authentication is required. And it also means that the app is likely to sync some data to the device. Whether that’s files via OneDrive or emails via Outlook.
For the above reasons, it is desirable that application access is only possible from compliant (managed) devices. Otherwise, there is a risk that sensitive corporate emails or documents from OneDrive/SharePoint may get onto an unmanaged device that you don’t control. For example, this could be an employee’s private computer, but it could also be a shared computer within the family or, heaven forbid, a completely foreign device. And it’s probably not desirable to have a permanently logged-in corporate account and synchronized corporate data on such a device.
In general, I recommend splitting the policy into two policies. One policy will target mobile devices (probably Android and iOS). The other policy will target computers (probably Windows and macOS). This is more for practical reasons and for reporting, but feel free to put both mobile devices and computers into one policy.
And if you’re wondering what happens to devices that aren’t compliant and try to connect from an app or already have an app added, then there’s nothing to worry about. Within the official Microsoft apps, a simple wizard will appear to guide the user through the process of enrolling that device to Microsoft Intune. So you can apply this policy relatively easily even if you already have devices that connect from apps, but they may not all be registered in Intune at the moment.
The new policy will again target all users with the exclusion of break-glass accounts. The policy will again target all cloud applications.
If you want to have a separate policy for desktop and mobile devices, configure the device platforms accordingly in the Conditions section. If you want to have one policy common to both mobile devices and computers, then you do not need to configure the device platforms.
However, in the Conditions section, it is important to configure that the policy targets Mobile apps and desktop clients.
In the Grant section, set that a compliant device is required.
Session lifetime for non-compliant devices
Limiting session lifetime on non-compliant devices is a similar scenario to the example above. Only in this case we are targeting web browsers where we want to limit how long a session can remain active.
Again, the idea is that by default, users can remain permanently logged in to the web browser. All they have to do is select the “Keep me signed in” option during login, which ensures that even after closing the browser or restarting the computer, the user remains permanently logged in. This can be a security risk not only on users’ private devices, but imagine a user staying logged in this way on, for example, someone else’s computer or, heaven forbid, a shared computer somewhere in a hotel lobby or internet café.
From the above, it’s a good idea to limit how long a user can stay logged into a web browser on an unmanaged device. After a set period of time, the user is automatically logged out, which significantly reduces the risk of account misuse.
Create a new conditional access policy that again targets all users except the break-glass account. Here it depends on how your external collaboration works and if you want to exclude external users as well. But I usually recommend leaving external users included in this policy.
The policy will target all cloud applications. Under Conditions – Client apps, select Browser. And since we are only targeting unmanaged devices, we will need to set the Filter for devices and choose Property = isCompliant, Operator = Not equals and Value = True. Same setting as multiple times above.
In the last section, we open Session and set the Sign-in frequency to Periodic reauthentication and select the time after which the user should be automatically logged out of the web browser on an unmanaged device. I usually recommend 1-2 hours, which should be enough to do the bare minimum on an unknown device. And last, check the Persistent browser session option and choose Never persistent. This means that the user will not see the Keep me signed in option on the login screen at all, and the account is automatically logged out when the web browser is closed.
Other conditional access policies
The above policies should be a staple in any organization. Other policies are up for consideration and specific scenarios. It also depends on the licenses whether you have a P1 or P2 of Microsoft Entra ID, as P2 licenses allow you to apply conditional access policies based on user risk or logon activity risk.
Bellow is a list of other potential conditional access policies to consider:
- Require phishing-resistant MFA for global admins
- Require compliant device for admins
- Require phishing-resitant MFA for admin portals
- Require compliant device for admin portals
- Require PAW/SAW/CSM for admins
- Require PAW/SAW/CSM for admin portals
- Require MFA when sign-in risk is detected
- Block authentication when sign-in risk is high
- Set sign-in frequency to every time when sign-in risk is detected
- Require password change when user risk is high
- Block file downloads on non-compliant devices
As I mentioned at the beginning, the above examples are not a definitive solution for all problems in all organizations. The goal of this article is to provide education and inspiration on conditional access policies and cloud identity security in general.
Every organization is individual, requiring individual approaches and individual policies. If you are not sure how a policy will impact your users, you can enable it in report-only mode before you start enforcing it.
Be very careful about exclusions though. Very often I see dozens, if not hundreds, of users in exclusions and no one even knows exactly why. Every exclusion should be well justified at any time, and there should optimally be some other restriction for every exclusion. For example, do you need to send emails from a service via SMTP? Fine, put that account in the exclusions for the legacy authentication policy, but create a new policy for that account that, for example, restricts the use of that account from only one specific IP address.
And if you feel I’ve forgotten something or want to discuss a particular scenario of yours, let me know via the contact form 🙂