Microsoft Entra ID is a critical component of modern identity and access management. It acts as a front door to your applications and data by providing secure and auditable identity management. One of Entra ID’s key capabilities is Conditional Access (CA).
CA allows you to require specific authentication controls. It also lets you make policy decisions based on many signals, such as who is logging in, where the request is coming from, which app is being accessed, and more.
The most common policy is to require multifactor authentication (MFA) for logon, regardless of where a user is located or what resource they are accessing. Any authentication methods a user has registered can be used for MFA. But what if your internal or regulatory compliance requirements stipulate using a specific type of MFA with certain applications? With Entra ID’s built-in authentication strengths, you can!
Understanding Authentication Strengths
Entra ID’s authentication strengths feature allows you to create groupings of individual authentication methods into a single strength that can then be applied on CA policies. For instance, for a highly sensitive financial application you might require access via a passwordless authentication method, such as FIDO2 keys or Windows Hello for Business, but not SMS (text message), phone call, or even Microsoft Authenticator push notifications. (For a detailed explanation of passwordless authentication, read “3 Components of Cloud Authentication: Enterprise SSO, Zero Trust, Passwordless“). With authentication strengths, you can define a strength that includes only those specific methods, then create a CA policy that requires the use of that authentication strength.
| Authentication Methods | MFA | Passwordless MFA | Phishing-resistant MFA |
| FIDO2 security key | ☑️ | ☑️ | ☑️ |
| Windows Hello for Business | ☑️ | ☑️ | ☑️ |
| Certificate-based authentication (multifactor)[i] | ☑️ | ☑️ | ☑️ |
| Microsoft Authenticator (phone sign-in)[ii] | ☑️ | ☑️ | |
| Temporary Access Pass (one-time use AND multi-use) | ☑️ | ||
| Password + something you have[iii] | ☑️ | ||
| Federated single-factor + something you have[iv] | ☑️ | ||
| Federated multi-factor | ☑️ | ||
| Certificate-based authentication (single-factor) | |||
| SMS sign-in | |||
| Password | |||
| Federated single-factor |
[i] CBA can be used for either MFA or single-factor and is configurable by the certificate issuer.
[ii] Phone sign-in refers to using Microsoft Authenticator for full passwordless authentication, not just as an MFA method.
[iii] Something you have refers to one of the following methods: text message, voice, push notification, software OATH token, or hardware OATH token.
[iv] Federated authentication allows for the use of MFA or single-factor from a federation provider in addition to or in place of Entra ID authentication factors.
Enabling and Applying Authentication Strengths
The authentication strengths feature is enabled out-of-the-box in a Microsoft Entra tenant, but it must be assigned to CA policies to be used. If you have already been using CA policies, then you can begin to migrate to authentication strengths.
The first step is to evaluate the built-in authentication strengths to see if they fit your needs. By default, the feature includes all forms of MFA, passwordless MFA, and phishing-resistant MFA.
You can’t modify these built-in authentication strengths. However, you can create additional authentication strengths as needed, and you can add any combination of methods.
For example, suppose you want to create an authentication strength that requires phishing-resistant MFA, but you also want to allow for a one-time Temporary Access Pass or certificate-based authentication. You can create a custom policy and select only the specific methods you want.
Once you’ve identified the authentication strengths you want to use and created any custom strengths you need, you can start assigning them to CA policies. For example, suppose you want to replace your catch-all “Require MFA” policy (you do have a catch-all policy that applies to everyone except break-glass accounts, right?); you can just modify the existing policy to require the new strength. Or if you want to be more cautious, you can create a new policy in report-only mode. Let it run for a few weeks and make sure it’s working as you expect, then toggle your new CA policy into active mode.
After an initial first-factor authentication (e.g., logging in to Entra ID with a username and password), Entra ID’s CA policy engine evaluates all the CA policies; identifies which ones are in scope for this request based on the current combination of user, app, and other configured conditions; then adds together all the grant or block controls on each policy. The result is a cumulative list of all the controls the request must meet. If you have multiple authentication strengths configured on different policies that are affecting this request, you must meet the requirements for each of them—not just one.
For example, suppose you create a CA policy that applies to a sensitive app and requires a custom authentication strength with just passwordless methods enabled. You also have a catch-all MFA policy that applies to everyone and everything and uses the built-in MFA authentication strength. When the CA policy engine runs during a sign-in request to your app, the list of controls that need to be met will include both the generic MFA authentication strength and your custom authentication strength. Since MFA alone doesn’t satisfy both strengths, a passwordless method must be used. The passwordless method also satisfies the MFA requirements.
Implementation Best Practices
The most important thing to watch for is whether your users have the most robust methods enabled and registered. If a CA policy requires only methods that a user hasn’t registered, then the user can’t fulfill the MFA requirements and therefore can’t access whatever apps the policy applies to. At best, the user will just need to register one of the appropriate methods. At worst, they will be completely blocked and unable to proceed.
A blocked end user may see text such as the following:
Your sign-in was blocked
We are currently unable to collect additional security information. Your organization requires this information to be set from specific locations or devices.
Before you start customizing and applying new authentication strengths, you should evaluate which authentication methods are enabled for your users and which methods the majority of your users are actually registered for. Just because Microsoft Authenticator is enabled for all users doesn’t mean that all users have it registered, unless you’ve gone through a registration campaign or otherwise required registration. If you want to analyze your environment, you can use the User registration details section in the authentication methods blade in the Entra ID portal.
Don’t create more authentication strengths than you need. Having a few well-defined strengths will be easier to manage going forward, whereas having many granular or monolithic strengths can make it difficult to understand effective CA requirements.
Conclusion
Migrating Entra ID’s CA policies to leverage authentication strengths will allow you to be more specific about the authentication methods used by your users across your environment. By aligning authentication requirements with the sensitivity of resources, organizations can fortify their security posture and more readily meet regulatory compliance requirements or internal security requirements when specific authentication methods are required. Using a planned approach for implementation can ensure a smooth migration from simply requiring MFA to using the best authentication methods for the apps that need them, while still allowing for a balance of security and convenience for most of your apps.
If you need help in applying Microsoft Entra ID’s authentication strengths feature, please reach out to the experts at Ravenswood Technology. We’re here to help!
