Introduction

In this blog post, I focus on the top things that you might not be doing (yet) in Entra Conditional Access. It is not an exhaustive list, but it is based on my experience assessing many different Entra ID, formerly Azure AD, environments as a consultant at NVISO Security.

The following points are, in my opinion, some of the most important security controls that can be enforced and configured using Conditional Access to improve the overall security posture of your Azure or Microsoft 365 tenant. Note that items do not have a particular order in the list. They are all more or less equally important to correctly protect and secure identities in Entra ID as some might rely on others to be fully functional in terms of security or have the intended effect.

Please do keep in mind that this article focuses on features that require the Entra ID Premium P1 and P2 licenses . Therefore, if none of those licenses are available, check my previous blog post on how to protect identities in Entra ID Free: https://blog.nviso.eu/2023/05/02/enforce-zero-trust-in-microsoft-365-part-1-setting-the-basics/.

Additionally, should you need any introduction to what Entra Conditional Access is and which security controls are available, feel free to have a look at this post: https://blog.nviso.eu/2023/05/24/enforce-zero-trust-in-microsoft-365-part-3-introduction-to-conditional-access/.

Entra Conditional Access security controls

Enforce strong authentication for all users

License requirement: Entra ID Premium P1

Strong authentication, such as Multi-Factor Authentication (MFA), represents a huge improvement to the security posture of your identities. Indeed, according to Alex Weinert, based on studies conducted by Microsoft, the Director of Identity Security at Microsoft, using MFA reduces the likelihood of an account breach by 99.9% (reference: Your Pa$$word doesn’t matter – Microsoft Community Hub).

Before diving into more details, where are the main Multi-Factor Authentication types available?

• Something you know: password, passphrase, PIN, etc.
• something you have: a phone, an application, a token, etc.
• Something you are: biometrics, such as fingerprint, facial recognition, etc.
• Somewhere you are: IP address, geolocation, etc.
• And, something you do: set of actions and recognizable patterns of behavior.

Most of them are available or can be enforced in Microsoft Entra, with the exception of “something you do”, which is the least common authentication type nowadays.

Moreover, Multi-Factor Authentication is usually considered as relatively easy to implement compared to other solutions such as passwordless authentication as it does not (always) require the provisioning of additional hardware and software components, for instance. Indeed, MFA requirements can be satisfied using SMS, a phone call, or an application on a mobile phone. I will not go into the details of passwordless versus multi-factor authentication in this blog post, as each method has its own advantages and disadvantages.

So, if you are not doing it yet, make sure that all identities are regularly prompted multi-factor authentication when they are authenticating to your environment. There might be some exclusions for break-the-glass (emergency accounts) or service principals, but these should be documented and monitored to detect suspicious and anomalous activities.

The easiest way to enforce MFA in Entra Conditional Access is to create the following Conditional Access policy:

Note that in this case, “All users” also includes B2B users.

Once the policy is enabled, MFA will be required for all users when authenticating to a cloud application using their company account. The MFA method, such as SMS, call, Microsoft Authenticator, Security Keys, etc., will depend on the configured policies in your environment. There are diverse ways to manage authentication methods in your environment. Some of them will be deprecated in the near future and combined into one unified configuration panel, which is Microsoft Entra Authentication Methods.

First, we have the legacy MFA settings, which are going to be deprecated end September 2025, as you may have guessed based on the name. They can be configured by going to Entra ID > Security > Multifactor authentication > Additional cloud-based multifactor authentication settings:

Then, we have the possibility to configure the Self-Service Password Reset (SSPR) policy. The SSPR policy will be phased out at the same time as the legacy MFA settings in September 2025. However, it can be configured here: Entra ID > Password reset > Authentication methods:

As mentioned above, the Microsoft Entra Authentication Methods policies will be replacing the legacy MFA and SSPR policies after their deprecation date. The new policy can be configured in Entra ID > Protection > Authentication methods > Policies:

It is recommended to migrate to the new authentication methods policy as it provides better control and granularity over authentication methods. For that purpose, Microsoft provides a way to manage the migration to the new method. The different stages of the migration allow to start configuring the new policies but still respect the legacy MFA and SSPR policies and can be summarized in the following table:

Option	Description
Pre-migration	The Authentication methods policy is used only for authentication. Legacy policy settings are respected.
Migration in Progress	The Authentication methods policy is used for authentication and SSPR. Legacy policy settings are respected.
Migration Complete	Only the Authentication methods policy is used for authentication and SSPR. Legacy policy settings are ignored.

Note that before the migration, all policies are merged together, and all authentication methods are respected. This means that users will be able to use any authentication methods enabled in any of those policies.

Regarding which authentication methods should be enabled for users, we recommend using stronger methods such as Microsoft Authenticator, security keys, One Time Passcode (OTP), Windows Hello, and certificate-based authentication. SMS and Voice methods are not the preferred ones as they are prone to different attacks. This does not mean that the other methods, listed as better and best below, cannot be targeted. This is why it is important to make sure that additional security controls have been implemented to make them more secure.

Make sure guest users are always authenticating with MFA

License requirement: Entra ID Premium P1

During security assessments, we have seen that, in some cases, MFA was not enforced on guest users. Indeed, in some configurations, they were either not included or excluded from Conditional Access policies enforcing strong authentication. The reason was that MFA was already enforced in their home tenant and guest users were prompted MFA twice, impacting user experience.

However, guest users can bypass the MFA control from their home tenant if they directly access the resource tenant. For instance, if I want to access a Tenant B Azure environment using an account in Tenant A, I could do it in two different ways:

1. Login to the Azure Portal of Tenant A and use the switch button to access Tenant B, also known as the resource tenant. When doing so, I first need to satisfy all the requirements from the Tenant A, meaning password authentication (i.e., primary authentication) and then strong authentication with MFA (i.e., secondary authentication). Then, if MFA is not enforced for my account in the resource tenant, I will simply click on switch and get access without any further authentication requirements. Note that a user password is always managed in their home tenant and not in the resource tenant;
2. Instead of accessing the resource tenant from my home tenant, I will directly browser to https://portal.azure.com/@tenantb.onmicrosoft.com. When clicking enter, I will be redirected to my home tenant for the primary authentication. Secondary authentication on my home tenant will not apply as I am not accessing a cloud application of my Tenant A. As MFA in the resource tenant is not enforced on my account, I will gain access to the environment without any further authentication requirements, “bypassing” MFA from my home tenant.

Because of that, MFA should be enforced in the resource tenant (too) to prevent that a user account with a compromised password that has been invited as a guest user in your tenant could access your environment without any restrictions.

To tackle the issue of double MFA prompt, Microsoft introduced the cross-tenant access settings which allows to trust the MFA claims of trusted external Entra ID tenants. This can be configured for different tenants individually or by default to apply to all B2B users from any tenants. We do not recommend trusting MFA claims from all external Entra ID tenants as you do not know how external identities are managed in their home tenant. However, this could be configured for trusted partners with whom you have a long-term collaboration and trust the way they secure and protect their identities. The authentication flow using cross-tenant access policies (XTAP) can be represented as follows:

In this case, the user requests access to Tenant B resources from Tenant A. Therefore, they first need to perform primary authentication and satisfy Conditional Access policies, i.e., secondary authentication, in their home tenant. If satisfied, the flow continues. Then, when accessing the Tenant B, where XTAP policies to trust MFA from Tenant A have been configured, the authentication claim issued by Tenant A is validated against Tenant B Conditional Access policies. If satisfied, access to the resource tenant applications is granted.

Block legacy authentication protocols

License requirement: Entra ID Premium P1

Legacy authentication refers to authentication that does not support multi-factor authentication, as well as other controls, such as sending the device compliance or join status. Therefore, when using legacy authentication, users are only prompted for their password to sign-in. However, based on Microsoft, 97 percent of credential stuffing attacks use legacy authentication, and more than 99 percent of password spray attacks also use legacy authentication protocols.

To block such attacks, Microsoft started disabling Basic Authentication for Exchange Online in all Microsoft 365 tenants regardless of usage, except for SMTP Authentication, as of October 1, 2022.

To control the use of legacy authentication protocols across your Microsoft 365 environment, we recommend configuring a Conditional Access policy. There are two approaches for creating this policy: directly or indirectly blocking legacy authentication protocols.

• The following policy can be used to directly block legacy authentication (recommended):

• To indirectly block legacy authentication, the grant control could be set to “Require multi-factor authentication”, “Require device to be marked as compliant”, and/or “Require Microsoft Entra hybrid joined device” instead of “Block”.

Using a dedicated policy to block legacy authentication is recommended as exclusions on users, applications, locations, etc., that may apply for the above grant controls might not apply to the use of legacy authentication protocols in your environment.

Regularly force users to reauthenticate

License requirement: Entra ID Premium P1

Next to strong authentication, authentication session management, or sign-in frequency, is also important. The sign-in frequency will define how often users must re-authenticate to keep access to your environment.

While requiring users to regularly reauthenticate might cause frustration and impact user productivity, it can effectively increase the overall security posture of an environment. Setting a proper sign-in frequency can help preventing unauthorized access to sensitive resources or information. By default, the sign-in frequency in Entra ID is 90 days. 90 days might be just fine for specific use cases, but I highly doubt that it will be considered as safe to use for most organizations for every use case.

It is important to note that when configuring such controls, we should not go too far and not be disruptive to users, as they will probably tend to find alternatives or “hacks” to bypass controls. Because of that, the sign-in frequency, to be effective in my opinion, should be based on conditions. For example, a user authenticating from a managed device in a trusted location represents an overall smaller risk than the same user authenticating from an unmanaged device outside of a trusted location. As a result, the sign-in frequency in the first scenario could be lower than for the second one. Moreover, an administrator assigned to the Entra ID Global Administrator role should also not have the same sign-in frequency as a standard user with no privileges. By implementing a proper sign-in frequency, it helps enforcing the principle of Zero Trust in the environment as access to resources is regularly challenged based on the context and signals.

How can the sign-in frequency be configured in Entra ID? Well, here also, we have different possibilities. First, we have the legacy setting in the per-user MFA portal:

As you can see in the above screenshot, this setting will apply tenant-wide and for all scenarios. Therefore, for more advanced configurations and reduce or increase the number of times users are prompted to reauthenticate based on different signals (i.e., location, device, risk, application, privileges, etc.), Entra Conditional Access policies should be used. Indeed, they allow for more granular configurations as we can target specific applications and users, and configure various conditions.

Note that both settings should not be configured. Indeed, if Conditional Access is used to manage the sign-in frequency, which is greatly recommended, the legacy setting should be turned off to avoid impacting end users with unexpected MFA prompts, for example. If you want to know more information about this, I have already discussed those specificities in previous blog posts (e.g., https://blog.nviso.eu/2023/05/24/enforce-zero-trust-in-microsoft-365-part-3-introduction-to-conditional-access/). Feel free to check them out.

Besides this, it is also possible to let users the possibility to trust the device they are using when authenticating. This is represented by the “Stay signed in?” checkbox when authenticating. This checkbox can be controlled in Conditional Access policies or at the tenant level. In Conditional Access, this behavior can be configured in the Session controls, by setting the ‘Persistent browser session‘-option to Always or Never persistent:

At the tenant level, it can be configured in the User settings by setting the Show keep user signed in toggle to On or Off:

In brief, defining the sign-in frequency and the browser persistence will vary for every organization. However, it is recommended to define it for every use case, such as user, including guest user, or administrative access, and access to sensitive resources or information, from managed or unmanaged devices, from trusted or untrusted locations, etc.

Restrict sensitive user actions

License requirement: Entra ID Premium P1

User actions in Entra Conditional Access policies represent actions that are performed by users, as its name suggests :). At the time of writing, Entra Conditional Access only supports two user actions, namely, register security information, and register or join devices to Entra ID. To better understand why those actions should be protected, let’s see what they actually mean:

• Register security information refers to the enrollment of an authentication method using the combined registration. In other words, it covers the action of a user adding an MFA method for their account. If registering security information is not restricted, attackers that would have compromised a user password might be able to register their own MFA to gain access to other cloud applications;
• Register or join devices to Entra ID allows users to register or join a device to your Entra ID tenant. If device registration or join has not been restricted, someone might abuse it to register a device, get it enrolled in Microsoft Intune, assuming Automatic Enrollment is being used, get the configuration profiles and compliance policies assigned and finally gain access to protected resources that require a compliant device.

Because of that, it is usually recommended to restrict those actions by requiring strong authentication and / or by requiring users to be in a trusted location. Note that the “Devices to be Microsoft Entra joined or Microsoft Entra registered require multifactor authentication”-setting in Entra ID should be set to ‘No’ first, before configuring a Conditional Access policy to require MFA on device join or registration.

These restrictions will vary depending on your organization’s security requirements. Additional restrictions can be configured for registering or joining a device in Entra ID device settings.

Configure restrictions on service accounts

License requirement: Entra ID Premium P1 & Entra ID Workload Identities Premium

In Entra ID, there are three types of service accounts: user-based service accounts, service principals, and managed identities. These identities are not meant for human access but represent an instance of an application used to access Entra ID or Azure resources such as services, APIs, etc.

A user-based service account is simply a standard user account used as a service account. One common example is the Directory Synchronization Account which is used in hybrid environments. However, creating such accounts for your applications is not recommended as their passwords must be stored somewhere and managed making them more prone to credentials leak. If such accounts are used, their sign-ins should be restricted to specific locations and/or devices. This can be done using a Conditional Access policy.

Then, service principals are a representation of an application object in Entra ID. These service accounts have two authentication methods available: secret- and certificate-based authentication. Certificate-based authentication is recommended as it cannot be (accidentally) hardcoded in the application code, making it less prone to credential leaks. Sign-in attempts from service principals can be covered by Conditional Access policies but it requires additional Entra ID Workload Identities Premium licenses. If available, it is recommended to restrict the use of the service principals to strict locations to prevent abuse in case of credential leak. Risk-based policies for service principals are also available and should be considered. For instance, access from service principals associated with a medium or high risk could be blocked:

Finally, managed identities are identities that can be associated with Azure resources to access other resources or services. They are considered as the most secure option as you do not have to manage any credentials for them. They cannot be covered by Conditional Access.

Further resources on how to secure those identities can be found below.

Enforce restrictions based on user risk, and sign-in risk

License requirement: Entra ID Premium P2, very limited feature in Entra ID Premium P1

Last but not least, Entra Identity Protection signals can be included to Entra Conditional Access to automatically act upon user and sign-in risk. Identity Protection is a service that allows organizations to identify, investigate, and remediate risks related to identities. Entra Identity Protection calculates user and sign-in risk based on real-time and offline detections, such as anomalous token, atypical travel, credentials leak, possible attempt to access Primary Refresh Token (PRT), etc. The full list of detections for both Premium P2 customers, and Free or Premium P1 customers are available in the ‘Resources’-section.

To integrate Identity Protection signals into Conditional Access policies, Entra ID Premium P2 licenses are required. Note that it is recommended to use Conditional Access policies instead of the Identity Protection policies directly as Conditional Access allows for better granularity and more control over the configuration.

As a standard recommendation, user sign-ins that are associated with a medium or higher risk should require users to perform MFA. On the other hand, users associated with a high risk, should, at least, be requested to change their password.

Once implemented, it allows to reduce the risk of unauthorized access in case of account compromise or suspicious activities. Moreover, users with credentials that have leaked can be required to change their password to make sure their account cannot be abused.

Conclusion

The above security controls can help your organization enhance its cloud and identity security posture. Indeed, as identities have become the new perimeter in cloud environments, it is essential to implement strong controls around identities to safeguard your sensitive and critical resources. The above list highlights basic but important controls that should be considered when designing or reviewing your Entra Conditional Access implementation.

While this list is not exhaustive and there are many more essential security controls to take into account, it can already be used to strengthen the defenses of your cloud environment. If some of these controls are not implemented yet in your environment, I highly encourage you to reevaluate your current controls and investigate the different capabilities discussed above.

At NVISO Security, we have built an expertise reviewing cloud environments and we have designed and implemented Entra Conditional Access policies on numerous occasions. If you want to know more about how we can help you in the journey of building or strengthening your cloud environment, feel free to connect on LinkedIn or visit our website at https://www.nviso.eu.

Resources

You can contact me on LinkedIn should you have any questions or remarks. My contact details can be found below.

Additionally, if you want to get a deeper understanding of some of the topics discussed in the blog post, all the resources that I have used can be found below:

• What authentication and verification methods are available in Microsoft Entra ID?: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods
• Manage authentication methods for Microsoft Entra ID: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods-manage
• Authentication and Conditional Access for External ID: https://learn.microsoft.com/en-us/entra/external-id/authentication-conditional-access
• Block legacy authentication with Microsoft Entra Conditional Access: https://learn.microsoft.com/en-us/entra/identity/conditional-access/block-legacy-authentication
• Configure authentication session management with Conditional Access: https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-session-lifetime
• Conditional Access: Target resources – User actions: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-cloud-apps#user-actions
• Conditional Access for workload identities: https://learn.microsoft.com/en-us/entra/identity/conditional-access/workload-identity
• Securing managed identities in Entra ID: https://learn.microsoft.com/en-us/entra/architecture/service-accounts-managed-identities
• Securing service principals in Entra ID: https://learn.microsoft.com/en-us/entra/architecture/service-accounts-principal
• What are risk detections?: https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks

About the author