Authentication Strengths in Condtional Access are a fun thing. You can use them to provide some extra security where it’s needed. In this blogpost, we’ll look at using authentication strengths in Condtional Access to make sign-ins with your admin accounts extra secure.
What are authentication strengths
Authentication strengths are esactly what you would expect by the name: they define how strong your authentication is. This has mainly to do with extra forms of authentication besides the password, so Multi-Factor Authentication, and if this MFA can be ‘stolen’ somewhere in the authentication process.
MFA
If you didn’t know it already, let me tell you know: authentication with just a username and password is not good enough anymore. You should be using MFA everywhere you can, including (or maybe even most importantly) in Entra ID.
Now, there are various ways to do MFA in Entra ID. What once started with a text message, can now be a notification in authenticator app, some form of passwordless authentication or a FIDO2-key or passkey. Not all these options have the same “strenght”. Some of them can be easily hijacked (you can do a simswap to get control of a mobile number and with that the tekst message with the token), others can be stolen using some form of social engineering. In the Uber hack for example, an attacker using stolen credentials to sign-in was met with an MFA-prompt. After some attempts, he contacted the owner of the account, pretended to be an IT support colleague and persuaded him to accept the next MFA prompt. Another way of gaining access is by using the concept of MFA Fatique.
As always, there is a trade-off between security and usability. You’ll need to find the sweet spot that offers the best security, with the best user experience. That basically depends on the risk: you might want to protect sensitive data in a better way than ‘regular’ data. This is where authentication strengths will help you.
Phishing resistant MFA
Entra ID has some Built-in authentication strengths that you can use in your Conditional Access policies. The top-level of these strenghts is called ‘phishing resistant MFA’. This basically means you perform your MFA in a way that it’s tied to your actual session.
Take for example an app notification with number matching in the authenticator app. You need to know the number to match and you can read it of your screen. But an attacker can also read this number from his (or her) screen and persuaded you to click the right number. You don’t need to physically be in front of the screen to perform this MFA.
With, for example, a FIDO2 security key however, you’ll need to physically insert the key into the computer your performing the authentication on. This proves the owner of the key is actually performing the authentication, being physically present. This means it’s phishing resistant.
With Conditional Access, you can create a rule that states that phishing resistant MFA is required for specific sign-ins.
Build a policy for protecting your admin sign-ins
You can use the authentication strengths to perform extra secure authentication for your admin-accounts. You might target this policy to ‘global admins’ in the users section, like in this example. Or you can target multiple admin-roles, specific users or groups, or find any other way to do this targetting.
Is suggest targetting all apps, but you could also target just the admin portal for example.
The access controls section is where the magic happens. In the grant part we can set the checkbox for require authentication strength and then select the phishing-resistant MFA option in the drop-down menu.
This will make sure that admins, when signing in, have to perform a phishing-resistant form of multi-factor authentication.
User Experience
For the end user, the experience is pretty straight forward. When signing in passwordless, Entra ID will recognize that your authentication was not strong enough and to do an other form of authentication. Once you plug in you FIDO2 key and (in my case, with the Feitian BioPass) providiong your fingerprint to show you actually are the correct user, authentication continues and you are logged in succesfully.
Wrap-up
This is just an example on how you can use authentication strenghts for extra security. You might vary in the assignment of the policy (will you target individual accounts, groups or certain RBAC roles, for example?), add some additional session controls (require sign-in every 4 hours or making sure that authentication is required when the browser is closed and reo-opend). Make sure have your functional and security requirements clear, and build out from there!