We’re thrilled to announce authentication strength, a Conditional Access control that allows administrators to specify which authentication methods can be used to access a resource. For example, an administrator can allow any multifactor authentication (MFA) method to access most resources in the tenant but require phishing-resistant authentication methods when their users access highly sensitive resources.
“Requiring multifactor authentication” is the most popular control in Conditional Access, with about 35% of the policies using this control. Users can satisfy this requirement by using any valid combination of strong authentication methods like an old-school password and SMS or modern and stronger methods such as the Authenticator app or a FIDO2 security key.
Not all MFA methods are created equal. Over time, we’ve added new and modern authentication methods in Azure AD, and some are more secure than others. Authentication strength allows you to differentiate between these methods and use the most secure methods for the most sensitive resources.
To tell you more about enforcing specific authentication methods for your users, I’ve invited Inbar Cizer Kobrinsky and Namrata Kedia, Product Managers on Microsoft Entra, who will talk about how this game-changing feature will kickstart your journey toward phishing-resistant MFA.
We’re excited to share with you more about the public preview of Conditional Access authentication strength for internal and external users that was just announced at Microsoft Ignite. With this feature, administrators can control which authentication methods are used to access sensitive resources and start their journey for phishing-resistant MFA.
We’ve been beating the drum on enabling multifactor authentication (MFA) for quite some time now. In fact, this year we have enabled Security Defaults for customers who haven’t done so themselves. With the increase in MFA usage, we also see MFA attacks becoming more popular. Password attacks are still by far the most common identity attacks out there. You absolutely should enable MFA, but increasingly it’s important to protect key resources with MFA that can resist current attacks.
Your best choice is to use phishing-resistant MFA. These strong authentication methods help against phishing attacks where the user provides their credentials to the attacker or social engineered into approving authentication requests. With certificate-based authentication (CBA) now generally available in Azure AD, you have three phishing-resistant options to choose from: Windows Hello for Business, FIDO2 security key, and CBA. Now, the next step in protecting your users is to require these methods in critical use cases using Conditional Access authentication strength.
To get started with authentication strength, you can create a Conditional Access policy using any set of Conditional Access conditions and just require one of the built-in authentication strengths:
In this case, we’ll require the built-in phishing-resistant MFA strength to grant access. Users who are in scope for this policy will be required to use any phishing-resistant methods you have configured in the tenant before they can access the resource.
Figure 1: Create a Conditional Access policy using the built-in authentication strengths.
The built-in authentication strengths can help you quickly enforce the methods you need. During the private preview we were able to help a major US Government agency to migrate off AD FS. Authentication strength allowed the agency to enforce the usage of CBA through the phishing-resistant MFA authentication strength control in Conditional Access policy, which means Active Directory Federation Services (AD FS) was no longer required.
Figure 2: Manage authentication strengths in your tenant.
If you looked around the built-in authentication strengths and found you need another set of authentication methods, you can create your own custom authentication strength and choose the methods that will help you meet your requirements. You can even restrict access further by requiring specific FIDO2 keys using the Authenticator Attestation GUIDs (AAGUIDs).
Figure 3: Create a custom authentication strength, including FIDO2 restrictions.
Pim Jacobs, Principal Consultant at InSpark, who helps customers with their passwordless deployment, uses the authentication strength to enforce passwordless MFA:
"With the release of authentication strength in Azure AD we finally can ban the use of passwords for ourselves and
the customers we support. The most heard feedback we got during workshops about passwordless was ‘But that means
I can still use my password to sign-in. With authentication strengths, that doesn’t apply anymore!"
Authentication strength for external identities
You can now require your business partner (B2B) guests across all Microsoft clouds to use specific authentication methods to access your resources with Conditional Access authentication strength policies. This provides enhanced controls to administrators as they trust MFA performed by the external user in their home tenant using inbound cross tenant access policy.
Fabian Bader, a Cloud Architect at Glueckkanja-gab AG and a Microsoft Most Valuable Professional (MVP), uses authentication strength for external identities:
“Authentication strength is a game changer for us. We now can enforce the usage of FIDO2 security keys
for our administrative accounts and sensitive applications and define the exact MFA methods we want to allow for
all our internal users. And for External Identities we can safely trust MFA using cross-tenant access settings and
are still in full control of the authentication strengths.”
You can learn more about authentication strength here:
In the coming weeks, we will add new controls in the authentication methods policy to facilitate management of authentication methods available in Azure AD in one place. This update will provide you with granularity in managing the methods – for example, scoping methods to specific groups, not just all or no users. It will allow you to manage the usage of less secure methods, such as SMS, for all scenarios, and then add scenario-specific requirements using authentication strength. Together, these will give you the control you need to step forward into a passwordless and phishing-resistant future.