In my previous blog post Entra ID: 🔒Lock It or Lose It #1 - The Basics, I covered Entra’s default settings, and my recommendations regarding roles and admins and emergency access accounts. Now, let’s cover another section which a lot of organizations are struggling with: Authentication Methods.

Per-user MFA ➡️ Authentication Methods

Legacy or “Per-user” MFA is the clunky, old-school way of doing things. Enabled one user at a time through the legacy MFA portal in Entra ID, it’s a relic from Azure AD’s early days. It ties MFA to individual profiles with minimal control. Think app passwords and basic methods like SMS or simple push. This setup doesn’t scale. It doesn’t integrate with Conditional Access, leaving you with a fragmented, outdated system. And forget about phishing-resistant Passkeys or centralized enforcement. Those aren’t even an option here.

Microsoft is pulling the plug on this, along with legacy Self-Service Password Reset (SSPR), by September 30, 2025. That’s your deadline to migrate to modern Authentication Methods in Entra ID. Act now, or risk getting stuck with a broken setup.

Start by reviewing the Legacy MFA settings. In the Microsoft Entra admin center. Go to Protection > Users > All users > in the top menu, look for Per-user MFA. This opens the legacy MFA portal. Now, check for any users that are either enforced or enabled and make sure to document them. There are also certain scripts for this.

Next, open the Service settings and document any current policies and methods you have:

Lastly, check your current Self-Service Password Reset (legacy) settings. As Microsoft clearly states, these settings can now be managed in one converged policy.

Now is a great time to get ahead of the curve and shift away from traditional MFA methods like SMS and voice calls, which are increasingly susceptible to risks such as interception and phishing. Incorporating this into your change management strategy and sharing a clear roadmap with your end users will help smooth the transition. I’d suggest disabling authentication options like SMS, voice calls, and email unless there’s a specific need for them or at least restricting their use to a defined group of users with limited alternatives.

Once you have decided what you want to go with, you can then either go with the automated migration, by selecting Begin automated guide – or do it manually, by clicking on change.

Do the inventory work

Before deciding which authentication methods to enable or disable in your tenant, do a full inventory of what your users currently have registered. This gives you a clear picture of where you stand, helps you plan better, and ensures users aren’t caught off guard by any changes. Plus, it makes it easier to guide them toward more secure authentication methods. You can find all the details you need in the User registration details pane.

Entra Authentication Methods

Passkey (FIDO2)

I’m a big fan of passkeys. It’s an awesome way to boost security because it’s phishing-resistant. Now, this blog post isn't here to dive into all the technical, nitty gritty details on how they work. Besides, there’s already plenty of documentation out there on this subject. Just check out Microsoft Learn if you're looking for a deep dive.

But here’s my take: Try to move as many users as you can to passkeys. It’s hands down one of the most secure methods of authentication out there. And with passkey support in Microsoft Authenticator, you no longer need to rely on physical hardware keys for your users. But on a quick side note…don’t skip physical keys (FIDO2) for emergency access accounts. Check out my previous blog post on why.

Recommended settings

1️⃣ Allow self-service set up = Yes
We want to enable users to actually start using Passkeys by letting them set this up themselves, so this is a no-brainer.

2️⃣ Enforce attestation = Yes
If you want to ensure that a FIDO2 security key or passkey provider is legitimate, set Enforce attestation to Yes. This ensures that only genuine devices from approved vendors are used.

3️⃣ Enforce key restrictions = No
The Enforce key restrictions setting should be set to Yes only if you want to allow or disallow specific security key models or passkey providers, identified by their AAGUID (Authenticator Attestation GUID). However, it’s generally recommended to set this to No, unless you have a specific need to restrict certain devices. Setting it to No allows more flexibility, ensuring that a wider range of approved security keys and passkey providers can be used without unnecessary restrictions.

Microsoft Authenticator

Recommended settings

1️⃣ Allow use of Microsoft Authenticator OTP = No
I usually make sure to have this turned off. OTP dates back from the beginning days of Authenticator and is not the most user-friendly experience. It kind of goes against the whole idea of moving towards a more passwordless strategy as well.

2️⃣ Require number matching for push notifications = Enabled
I recommend to enable this for all users. Instead of simply tapping "Approve" on a notification, the user must enter a two-digit number displayed on the login screen into the Authenticator app. This ensures that the person approving the request is actively involved in the login process and isn’t just blindly accepting a random prompt.

3️⃣ Show application name in push and passwordless notifications = Enabled
I recommend to enable this for all users. It gives users more context before approving a sign-in request. Instead of just seeing a generic MFA prompt, they can see which app or service is requesting access, helping them detect suspicious or unexpected login attempts.

4️⃣ Show geographic location in push and passwordless notifications = Enabled
I would start by enabling this for all users. Here they can see where the login attempt is coming from, geographically, helping them detect any suspicious or unexpected sign-ins. If you for some reason can’t enable this for all users (I’ve ran into some support cases…), you can simply exclude them from this feature.

5️⃣ Microsoft Authenticator on companion applications = Disabled
This feature is mainly aimed at Authenticator Lite for Outlook Mobile. I tend to leave this disabled, since most organizations need the capabilities of the full Authenticator app.

SMS

Ideally, this should be disabled entirely since it’s vulnerable to interception and social engineering attacks. But in reality, many organizations - especially medium to large businesses - are stuck with a hefty legacy MFA footprint. Moving users away from outdated methods isn’t always easy. For those facing this challenge, a phased approach is the way to go. Start by creating an exception group that allows SMS for now. Over time, as more users adopt modern authentication methods, this group will shrink, making the transition much smoother.

🤷‍♂️ Use for sign-in
With this setting enabled, users can log in without needing a username or password. Just their phone number. After an admin sets up their account, they enter their number at sign-in, get a verification code via SMS, and boom, they’re in. Well… sort of. If you don’t have any other security measures enforcing MFA, that is.

Beyond several known issues and limitations, this really isn’t something I’d recommend enabling in the first place. Especially if you're trying to steer users toward more secure authentication methods.

❓ SMS: Enable vs Disable

If you choose to disable SMS completely, keep in mind that it will affect all users, including guests. It also impacts Self-Service Password Reset (SSPR) - meaning users won’t be able to use SMS for MFA or to reset their passwords (if that feature is enabled). So, before making the switch, make sure you’ve got alternative methods in place!

Temporary Access Pass

TAP is a great way to onboard or reboard your users, instead of providing them with just a single factor authentication method (password). I will be writing a separate blog post on this subject soon.

Hardware OATH tokens (Preview)

Hardware OATH tokens are physical devices that generate time-based one-time passcodes (TOTP) for authentication. Unlike software-based TOTP solutions (like Microsoft Authenticator), these tokens don’t rely on a smartphone or an ap. They simply display a six-digit code that refreshes every 30 seconds.

If there is a business need, enable this for a selected group of users only.

Third-party software OATH tokens

Third-party software OATH tokens are TOTP-based authentication apps that generate one-time passcodes for MFA, similar to Microsoft Authenticator. Providers like Google Authenticator, Authy, and Duo Mobile offer these apps, but they often lack additional features found in Microsoft Authenticator, such as push notifications and seamless integration with Entra ID…resulting in a less streamlined user experience.

Unless there’s a specific business need, I wouldn’t recommend relying on third-party software OATH tokens.

Voice Call

Just like SMS, Voice Call is another legacy MFA method. and honestly, it’s pretty outdated. It comes with the same security risks, like being vulnerable to interception and social engineering attacks. That said, if your organization still has a business need for it, I’d recommend handling it the same way as SMS: use an exception group to limit access and keep it tightly controlled.

Email OTP

Email one-time passcodes can only be used for Self-Service Password Recovery. They can't be used as an authentication method for internal users in Microsoft Entra ID. They are strictly designed for B2B guest users who don’t have another authentication method available.

External users

The email one-time passcode feature is a method for B2B collaboration users who can’t sign in through Microsoft Entra ID, a Microsoft account or social logins such as Google or Facebook. When a guest tries to access shared resources or redeem an invite, they can request a temporary passcode sent straight to their email.

IMPORTANT: The email one-time passcode feature is now turned on by default for all tenants, created after March 2021 and for any existing tenants where you haven’t explicitly turned it off.

Email for SSPR

I recommend against using email for password resets. Users tend to register their personal email, like Hotmail or Gmail, which creates a security risk. If a threat actor gains access to that personal account, they could reset the password and move one step closer to taking over the user’s account. The best approach is to disable this feature entirely and rely on more secure password reset methods.

Certificate-based authentication

Certificate-Based Authentication (CBA) allows authentication using X.509 certificates directly through Entra ID, offering phishing-resistant authentication by leveraging certificates issued from a trusted Public Key Infrastructure (PKI). It’s an excellent choice for scenarios where passwordless authentication is a priority, but it does come with its complexities. If there’s a clear business need, like compliance requirements or integration with existing PKI-based authentication systems, CBA can be a solid option that enhances your security strategy. Just be mindful that it requires careful planning and infrastructure management.

QR code (Preview)

QR Code Authentication is a straightforward authentication method designed with frontline workers in mind. It uses a unique QR code paired with a numeric PIN. The QR code acts as the user’s identifier and is specific to each individual. It can be generated and printed through the Microsoft Entra admin center, My Staff, or Microsoft Graph. For added convenience, it can be attached to a badge or any wearable item. An Authentication Administrator provides a temporary PIN to the user, who then changes it upon signing in. This PIN is personal, known only to the user, and is linked exclusively to the QR code. It cannot be used with other identifiers like a username or phone number. QR code authentication is a single-factor method, where the PIN (something you know) serves as the credential.

This one is still in preview, so I wouldn’t recommend enabling it for any users other than for test purposes.

Additional settings

Report suspicious activity

The ‘Report Suspicious Activity’ feature in Entra ID enables users to flag any suspicious authentication attempts, helping to enhance overall security. If a user reports an unusual request, their risk profile is elevated, triggering security protocols. Depending on your organization’s security policies, this may result in the user being temporarily restricted or asked to verify their identity through additional steps.

I would suggest enabling this feature for a pilot group first, and evaluate it, before rolling it out tenant-wide.

System-preferred MFA

System-preferred MFA ensures users sign in using the most secure method they've registered. This is particularly important for users relying on telecom-based methods like SMS, as it helps promote safer options. By enabling system-preferred MFA, administrators can steer users away from less secure methods, like SMS, and prioritize stronger authentication methods.

For example, if a user has both SMS and Microsoft Authenticator push notifications set up, system-preferred MFA will first prompt them to use the more secure push notification method. While they can still choose another method, the system encourages them to start with the most secure option they’ve registered.

My recommendation is to enable this for all users.