Not all authentication methods are created equal. Microsoft Digital Defense report from 2023 lists multi-factor authentication as one of five key protection controls against cyber attacks. As leaks like recent Okta and LastPass breaches are becoming more and more common, authenticating with password alone seems absurd to me. Even if it’s a really good one. I would take authentication safeguarding a step further by removing weak authentication methods altogether. Let’s start!
Setting the goal
In part 1 of the blog series we will go through the authentication methods we currently have and dig into the problem passwords face today. Then we’ll do a comparison of them and deduce which ones are good enough that we want to let our users use them and I’ll introduce some (dare I say) classic articles around this topic. At last, we’ll look what places we have for controlling authentication methods.
Authentication methods in Microsoft Entra ID
Let’s take a look what authentication methods we have available. The following table consolidates all authentication methods and scores their presumed level of security. It also presents if the method can be user for primary authentication during a sign-in event, or as secondary authentication method required by MFA challenge or during SSPR flow. High-lighted ones are phishing-resistant methods.
| Authentication method | Security | Primary authentication | Secondary authentication |
|---|---|---|---|
| FIDO2 Security key | High | Yes | MFA |
| Windows Hello for Business | High | Yes | MFA with limitations |
| Certification-based authentication | High | Yes | No |
| Microsoft Authenticator (Push) | High | No | MFA and SSPR |
| Microsoft Authenticator (Passwordless) | High | Yes | No |
| Authenticator Lite | High | No | MFA |
| Temporary Access Pass (TAP) | Medium | Yes | MFA |
| OATH hardware tokens | Medium | No | MFA and SSPR |
| OATH software tokens | Medium | No | MFA and SSPR |
| SMS | Medium | Yes | MFA and SSPR |
| Voice call | Medium | No | MFA and SSPR |
| Password | Low | Yes | No |
In addition to listed methods there are some legacy verification methods that might still be enabled on your environment. Needless to say, security questions are a bad idea and you should absolutely get rid of them completely as they are guessable and the information for those questions can be nowadays be gathered from social media and elsewhere from internet.
- Security questions (used by SSPR)
- Email address (used by SSPR)
- App passwords (used by legacy apps that don’t support modern authentication)
Why passwords are not safe enough?
The security classification is from Microsoft documentation and it tells us that passwords are on the bottom of the authentication methods arranged by their security. But why? I can require very long and very complex passwords, right? Those must be secure? And in a way, yes, long and complex password is better then short and too plain. Or, wait a second, I can also require users to change their passwords once a month and that will keep their password fresh and secure, right? Again, kind of, but it’s not only an upside to require password change. Let’s consider how humans behave, as we also qualify for that group so we should be able to figure out how their thought patterns.
Case A: Users who are not interested in security one flying f—
First day at work they get their initial password. At first login they are required to change it. They try their usual password patterns to find out your password complexity requirements. I don’t care what requirements you might have, a user always finds a way to make that seemingly complex password easily guessable if they want to. 30 days goes by and their required to change the password. What do they do? They’ve already invested the last 30 days to remember the password, because retrieving it from a password manager is too much work. So they iterate a number or a special character or even a word, usually at the end of the password. The habit to generate a more complex and more secure password that would be genuinely harder to crack just isn’t there and there’s nothing you can do about it.
Case B: Users who are more tech-savvy and understands the need for security
Initial password needs to be changed. They’re waited this the whole weekend and they want to change that insecure initial password quickly to a complex, hard-to-guess, randomly generated password that they have no change remembering from memory. They retrieve it from the password manager every time. When the first password change comes up, they breeze through it generating a new randomly generated password and move on feeling good about themselves.
Let’s dig in to the Case A. User had a weak password, they made it memorable despite your complexity requirements. Password change did not upgrade the security of the password, because the user habit and laziness did not allow it. I don’t see most users just picking the habit up either. In Case B user set a good password to begin with. Password change did not upgrade the security of the password as it stayed the same. But as time goes by and the password changes start to pile up month after month the fatigue sets in and there’s that password change that comes at the wrong time when the user is in a hurry to an important meeting and they set it to their pet name + current year + ‘_!’ and swear they’ll change it later…or maybe not.
Conclusion: complexity requirements are nice, but users know how to work around them. Password change requirement is a nice idea, but usually does not result in better passwords. The real problem with passwords is that even a good password does not matter if a users can be phished to hand over their credentials or the password can be stolen using Adversary-in-the-Middle (AiTM) attacking tooling. The problem with password is that is not bound to anything, like a managed device with TPM or certificate, so it will always be vulnerable to various password attacks and no restrictions for the password use apply.
Reading recommendation! VP Director of Identity Security @ Microsoft, Mr. Alex Weinert has two great articles: ‘Your Pa$$word doesn’t matter’ that nicely describes the inevitable problem with passwords and another one: ‘It’s time to hang up on Phone Transports for Authentication’ which depicts why public telephone networks are not suitable or secure for modern-day authentication. Link to the articles here and here
Note! It’s not yet possible to disable password authentication method altogether in Microsoft Entra ID. Thus, other ways to improve authentication security must be found.
What methods should we use?
I’m referring here to Microsoft’s classic picture of authentication methods which presents our usual suspects. Bad and Good categories are not good enough and preferably I recommend to strive for the Best category that includes phishing-resistant methods. Moving away from in-use methods in a organization is never easy and should be planned and communicated carefully.
Authentication method controls in Microsoft Entra ID
In my previous blog post I went through authentication method policies and different places that control what methods are available and to whom. Let’s recap that here.
Per-user MFA legacy site controls the use of App passwords, trusted IPs (the ‘get-out-of-jail’ card against MFA requirement), verification options (voice call, SMS, mobile app push notification and OTP from mobile app or hardware token). Recommendation: migrate authentication methods away from this portal so that you get single-pane of glass experience controlling authentication methods. And your less-experienced admin colleagues might not even be aware that this place exists with fishy looking legacy URL (account.activedirectory.windowsazure.com)
Password reset (SSPR) blade in Entra ID controls authentication methods for password recovery situations. Same recommendation apply: migrate away from these controls.
Authentication method | Policies in Microsoft Entra ID is a third place where you can set these controls. It will be the only place where to control unified authentication methods as other legacy controls will be deprecated on September 30th, 2025.
Start planning a migration towards the unified authentication method policies to allow yourself easier limit the weak authentication methods.
Summary
First we took a look at the methods available and where those methods can be used. Secondly we discussed the inherent problem with passwords and why it’s not enough anymore. Then we checked what methods we can pair with password to make it safer, but really, drive your organization towards the passwordless authentication. And at last, we went through the different controlling views and sites that we want to get rid of and only use the unified authentication method policies view to control our organization wide methods, not only for primary authentication, but for MFA and SSPR (secondary authentication) also.
In the next part we’ll dig deeper into those individual methods and other controls for safeguarding the authentication event.
Stay secure!
