SMS Gets Hacked, FIDO2 Doesn't: Why Your MFA Isn't Good Enough

[00:00:00]A text message to your phone counts as MFA. So does an authenticator app push notification, a 502 security key, and Windows Hello for Business. But here's the thing, they're not all the same level of protection. An SMS code can be intercepted and a push notification can be approved by accident or under pressure, but a 502 key, it can't be fished. Period. In this video, we're breaking down the difference between MFA methods, why it matters in today's threat landscape, and how to enforce the right level of protection using Microsoft Enter ID and conditional access.

[00:00:40]Hey everyone, I'm Travis and welcome back to the channel. This is the fourth video in a series on Microsoft Enter ID, MFA, and conditional access. So far, we've covered why passwords alone don't cut it anymore, built a conditional access policy, then layered in realworld protections like blocking legacy authentication, restricting access by location, and locking down privileged accounts. If you missed those, check the links in the description below. In this video, we're going deeper on MFA itself.

[00:01:08]We'll walk through authentication methods available in enter ID. Talk about why some are stronger than others and then jump into the portal to configure authentication methods and enforce fishing resistant MFA for global administrators. And before we get into it, please don't forget to like, subscribe, and share this with someone who can use it. Check out my courses.

[00:01:29]The links are in the description below.

[00:01:31]And a big thanks to all my channel members. Your support is appreciated.

[00:01:34]When people hear MFA, they may think about a six-digit code that's sent by text message. And yeah, that counts as a second factor. But attackers have evolved, and some authentication methods that used to be secure are now easily bypassed. So, let's talk about the MFA methods in Enter ID from the least secure to the most secure. So, you know exactly what we're working with. SMS and voice calls used to be a common MFA method. The user gets a code, types it in, and they're authenticated. But here's the problem. SMS is vulnerable to SIM swapping. That's where an attacker convinces a carrier to move a number to their SIM card. Once they've got the number, they've got the codes. It's also vulnerable to real-time fishing where attackers sit between the user and the real login page, capture the code, and use it to gain access. So, yes, SMS and voice are better than nothing, but they shouldn't be your primary MFA method, especially for highly privileged accounts. Microsoft recommends phasing these out when possible. Next up is OOTH software tokens. These are timebased one-time passwords we get from apps like the Microsoft Authenticator app or Google Authenticator. Simply open the app, read the code, and type it in.

[00:02:48]These are definitely stronger than SMS because the code is generated locally on the user's device, not sent over the network. But they still share a key weakness. a user can be tricked into entering that code on a fake login page and the attacker can replay that in real time. So, while they may be better, they're not considered fishing resistant. Now, let's talk about push notifications in Microsoft Authenticator. This is where things get more convenient. You get a prompt, tap approve, and you're in. But without context, this opens the door to MFA fatigue attacks, where attackers spam approval requests, hoping users will eventually hit approve just to make it stop or maybe approve it by mistake.

[00:03:31]Microsoft addressed this with number matching and additional context. With number matching, the user sees a number on the sign-in screen and enters that same number in the app before approving.

[00:03:42]That completely breaks fatigue attacks because the user has to see the number to approve the sign-in request. And on top of that, it can show additional contacts like the application used and the sign-in location. So users can make a more informed decision. Number matching is now enabled by default in the Microsoft Authenticator app and cannot be disabled. That's a very good thing. The Microsoft Authenticator app also supports passwordless sign-ins. So instead of entering a password, users enter a username, get a prompt, match the number, and they're in. That removes the password entirely from the equation, which is really convenient, but it's still not considered fully fishing resistant because the approval happens on a separate device from the sign-in. A user can still be tricked into approving something. There's still a risk. At the top of the secure MFA stack, we've got fishing resistant authentication, 502 security keys, and Windows Hello for Business. These are the gold standard for high-v value accounts, and they work fundamentally different from the other methods we've discussed. The authentication is cryptographically tied to the exact site the user is signing into. There's no code to intercept, no push notification to approve, and there's no way the attacker can redirect the process to a fake site because the verification only works on the exact domain it was registered with. If the domain doesn't match, the authentication simply doesn't work. That's why these methods are considered fishing resistant. For high-v value accounts like the global administrator, this should absolutely be enabled. And that's exactly what we're going to enforce in the demo. In enter ID, the authentication method policy is where you control which MFA methods are available across the tenant. This is the modern approach and it replaces legacy per user MFA settings. From here, you can enable or disable methods globally or target specific users or groups. So maybe you allow PHTO2 keys for your IT team while keeping authenticator available for everyone else. Or maybe you disable SMS entirely except as a fallback. This is where your MFA strategy really takes shape. Now, let's talk about authentication strengths.

[00:05:53]This feature in conditional access lets you require specific types of MFA, not just any MFA. That's how you enforce stronger authentication where it matters the most. Microsoft gives you three built-in options. There's standard MFA, which allows any method. There's passwordless MFA, which includes authenticator, passwordless, phto2, and Windows Hello. And there's fishing resistant MFA limited to 502 keys and Windows Hello for Business. You can also create custom authentication strengths if you want even more control. We'll use the authentication strengths in the demo to lock down global administrator accounts. Elevated rights to manage MFA are required if you want to follow along. Let's go build these in the Entra portal. Here we are at Enter ID in the Azure portal. You could also use the admin portal at admin.microsoft.com.

[00:06:45]We have three things to cover in the demo. Configuring the authentication method policy. Reviewing the built-in authentication strengths and creating a custom one. And then building a conditional access policy that enforces fishing resistant MFA for global admins.

[00:07:00]Let's start with authentication methods.

[00:07:02]In enter ID, select security under manage.

[00:07:07]From here, select authentication methods under manage. This shows a list of available authentication methods. 502 security key, Microsoft authenticator, SMS, temporary access pass, hardware oath tokens, software OOTH tokens, voice call, email one-time password, certificate-based authentication, verified ID, and QR code. Notice we can also see the target and that not all of them are enabled. Select Microsoft Authenticator to open its settings.

[00:07:41]This is enabled for all users and we can also see the authentication modes available for this option. It's set to any. Let's go to the configure tab.

[00:07:52]Authenticator one-time password is enabled. And also notice that number matching for push notifications is enabled and cannot be disabled. There's also additional context options for showing the application's name and geographic location for notifications.

[00:08:09]These options can be enabled, disabled, or managed by Microsoft. When Microsoft Manage is selected, Microsoft will enable and disable this feature based on the current threat landscape. There's also an option to allow authentication on companion apps. This is sometimes called authenticator light. It allows users to respond to MFA prompts without leaving an app. Outlook for iOS and Android, for example. Let's move back to methods and select SMS.

[00:08:39]For most organizations, SMS should be disabled or limited to a fallback group.

[00:08:43]Also, Microsoft announced they're retiring SMS and voice starting in September of 2026. I'll add a link to more information in the description below. If your organization is planning to move away from SMS, do it in phases.

[00:08:57]Enable stronger methods first, then communicate the change to the users.

[00:09:02]Give them time to register and then disable SMS. Cutting SMS without a transition plan will generate help desk calls. Let's go back to the methods list and select ph2 pass key.

[00:09:14]Here again this can be enabled for all users or a specific group. Enable it for all users if not already enabled. We can also add exclusions if needed. We can also select different Pasi profiles for different users and groups. If we go to configure self-service setup is enabled and we can create different profiles. We'll use the default profile in this lab. If you did make any changes, select save and then return to the authentication methods policy screen. Now let's look at authentication strengths. This is where we define the specific MFA method combinations we want to enforce in conditional access. Let's go to conditional access and from here we'll select authentication strengths under manage.

[00:10:03]There are three built-in authentication strengths. MFA, passwordless MFA and fishing resistant MFA. Open the fishing resistant MFA built-in strength. This option only includes 502 security keys, Windows Hello for Business, and certificate-based authentication. We cannot edit the built-in strings. We'll close that and select new authentication string to create a custom one.

[00:10:30]Name it something descriptive. For example, passwordless fishing resistant MFA. This name is abbreviated because there's a 30 character limit. We can add a description as well. Next, we'll select the authentication strengths.

[00:10:45]Select 502 pass key, Windows Hello for business and Microsoft authenticator under passwordless.

[00:10:52]Select next. From here we can review the combination of authentication strengths.

[00:10:58]It shows Microsoft authenticator or 502 pass key or Windows Hello for Business.

[00:11:04]Select create to create that new authentication strength.

[00:11:09]Now the new custom authentication strength appears in the list with the built-in options. The custom strength created here is useful for scenarios where you want to require strong MFA but also allow passwordless authentication as an option for users who don't yet have a 502 key. The built-in fishing resistant MFA strength is the strictest option and the right choice for global admin accounts. In the previous video, we built a policy that requires MFA for privilege roles. We're going to update that policy now to require fishing resistant MFA rather than accepting any MFA method. From conditional access, go to policies, then open and edit the require MFA for privilege roles policy created in the previous video.

[00:12:00]Under access controls, select grant control.

[00:12:04]Change the grant from require multiffactor authentication to require authentication strength. And notice that you can't use both. Require MFA has to be disabled first.

[00:12:17]Select fishing resistant MFA from the list. Now we'll select select to confirm the control. Verify the policy is set to report only before saving. This is important especially if the administrators affected by this policy have not yet registered for passwordless authentication required by the authentication strength in the policy. I strongly recommend getting a 502 hardware key and use that to set up passwordless authentication on a global admin account before turning this policy on. Verify this policy is set to report only and then select save. That will update our policy. Next, we'll test the policy. Open the what if tool and test with a global administrator account.

[00:13:08]Let's select Azure graph this time. For the cloud app for the device platform, we'll select Windows.

[00:13:17]The client app will be browser.

[00:13:20]We can leave the rest blank and hit what if. Notice that two policies apply and we have two grant controls. When this happens, the controls are merged. If there were any blocks, the user would be blocked. No exception. Here it's requiring MFA as well as fishing resistant MFA. So those combined would mean we require fishing resistant MFA.

[00:13:42]We can close that. One important note before switching this policy from report only to on. Make sure your privileged account users have registered a 502 security key or Windows Hello for Business. If you enforce fishing resistant MFA before users have registered a qualifying method, they may not be able to sign in. I want to repeat that because this is the type of change that could lead to locking global admins out of a tenant. Verify the global admin account has registered for Windows Hello for Business Platform credentials, 502 Pasi or certificate-based authentication before enabling the policy. This is in addition to including the break glass account exclusion in the conditional access policies. We want to avoid using those accounts. Let's finish by looking at the MFA registration experience from the users's perspective. This is what users will see when they set up or update their authentication method.

[00:14:40]We'll open a private window and navigate to aka.m/mycurity info. This browser is signed in as a test user, a global admin for this example. The user is already enrolled in MFA, but because of the changes, when I log in, it's requiring an additional sign-in method. For this example, I'm going to use pass key in Microsoft Authenticator. We'll follow the prompts on the screen to create a pass key in the authenticator app. I'll go to the app and open up the user and select the option to create a pass key. I have to reauthenticate. It's having me verify that I'm signing in. And that creates the pass key. Now we'll go back to the browser and select next and it shows the pass key is created.

[00:15:25]Now from security info we can see the registered sign-in methods. If we want to add additional we can select add sign-in method and this gives us the available options for sign-in methods.

[00:15:37]That's the registration experience for a pass key with the Microsoft authenticator app. All right let's wrap this up. Not just the video but the entire series. In the first video, we broke down why passwords are no longer enough and enabled security defaults to kick off MFA registration. In the next video, we built our first conditional access policy, used report only mode, and enforced MFA safely. After that, the video stepped into realworld scenarios, blocking legacy authentication, restricting access by location, and protecting privileged accounts, and validating everything with the whatif tool. And in this video, we took it further. We broke down MFA methods, configured authentication method policies, built an authentication strength, and enforced fishing resistant MFA for admins. So, if you followed along, you now have a solid conditional access setup based on zero trust principles. You've got MFA enforced, legacy authentication blocked, location controls in place, fishing resistant MFA for privileged users, and a break glass account just in case. That's a strong security posture and it all starts with understanding the risk. If you found this series helpful, please make sure to like, subscribe, and share with someone who may be interested. Thanks for watching and I'll see you in the next