But have you turned multifactor authentication ALL the way on?

Back to Blog
Turn your MFA up to 11

But have you turned multifactor authentication ALL the way on?

Do you remember just a short time ago, Microsoft would claim that switching on Multi-factor Authentication (MFA) prevents 99.9% of identity-based attacks? Well, the times they are a-changin. I do not know what they would report today for a percentage of attacks which are thwarted by MFA alone, but I can tell you it wouldn’t be 99.9%. I think most of you reading this blog have probably even experienced or heard by now of an attack where MFA was enabled, but the bad guy got in anyway.

The current state of affairs was inevitable of course: when we move our defenses up, the evildoers don’t just throw in the towel and go away, they simply adapt their methods. Thus, we have seen a steady rise during the pandemic years of more sophisticated phishing techniques, where users are tricked into giving up, approving, or passing time-bound access codes onto a third-party. We also see a rise of Man-in-the-Middle (MITM) attacks where a user interacts with fake (but very convincing) login pages that include MFA prompts and everything.

So what are we to do?

First, do not be discouraged: this process of “one-upmanship” is only natural. The good news is that having more than one proof of identity in place is still the foundation from which you must build. Moving away from passwords and towards MFA or even passwordless authentication is still the right path, but you have to be willing to stay nimble and introduce additional iterative changes as we move forward in time.

The tools to do the job are already available and waiting for you. In the world of Azure AD and Microsoft 365, this means revisiting our Conditional Access (CA) policies and reconsidering our authentication methods.

I assume most of my readers already know about the Security Defaults, or these four equivalent CA policies:

Once you have these basic scenarios covered, we have number of other holes to plug. In the following paragraphs, I will recommend some additional settings and policies to further cement your foundation and prevent some of the latest attack methods we have been seeing in the wild, with a bit of commentary explaining each.

1. Update your authentication methods (number matching, etc.)

Microsoft recommends updating your policies for the Microsoft Authenticator app so that users are required to do number matching when logging into cloud resources. In other words, instead of just tapping “Approve” when the app notification comes up (which many people will do quickly by automatic reflex, or eventually after a flood of continuous prompts), they will be forced to identify the correct number which is being displayed to them.

Number matching

This helps prevent what Microsoft calls “MFA fatigue,” or illegitimate authorizations due to automatic muscle memory.

This setting will become the default experience on February 27 of 2023, but you can turn it on sooner if you like from Protect & secure > Authentication methods > Microsoft Authenticator in the Entra portal. On the Configure tab, you can move from Microsoft managed to Enabled.

Enable number matching

You can also choose to turn on Show the application name…, as well as the option to Show geographic location… These toggles will give the user more context about the sign-in attempt whenever an authenticator prompt occurs. Be sure to save any changes you make on this screen.

Back on the Enable and Target tab, you can optionally move to passwordless Authentication mode, where the authenticator app is the primary authentication method instead of the password. This experience will use the number matching challenge by default, and it will also reduce password prompts in general.

Move to passwordless

2. Enable Temporary Access Pass

I also recommend turning on Temporary Access Pass, which is also found under your Authentication methods. This allows administrators to grant time-bound access codes for sign-in purposes, particularly when the end user is unable to use their multi-factor device, or if they need to update their authentication methods at https://aka.ms/mysecurityinfo.

Temporary Access Pass (TAP)

For example, imagine that one of your users had to get a new phone and they no longer have access to the authenticator app from their old phone anymore.

Once this policy is configured, administrators can go issue TAPs to any user right from the Azure AD or Microsoft Entra portal. The same process can also be used during the initial onboarding, when users go to set up their authentication methods for the first time.

Issuing a TAP

3. Protect registration of security information

If you enabled TAP as I suggested above, then you should also enable a Conditional Access policy called Securing security info registration, which means that in order to access the security info registration page, a user will need a valid TAP issued by their administrator. I suggest you also have a process in place for requesting and distributing these TAPs securely, in order to prevent illegitimate requests from going through; for example, confirmation of identity via a phone call or video chat with the helpdesk.

This policy is also available from the CA templates (under Identities):

Securing security info registration

Note that the templated policy also excludes any trusted locations that you specified (so that users could set up their authentication methods from the corporate offices, but not from home or some other public wi-fi, for example).

4. Require MFA to register or join devices

Certain scenarios are not covered by the CA policies outlined earlier. One such scenario is the registration or joining of devices to Azure AD. There is a special policy just for that purpose that you must deploy.

This can also be found as a setting under Devices > Device settings in the Azure AD admin center. But these days Microsoft recommends using the equivalent CA policy in its place (therefore the option on this page should be set to No rather than Yes).

Device setting to Require MFA (deprecated)

For some reason the required settings for this CA policy are not detailed on Microsoft Learn, even though Microsoft recommends moving to it, but here are the settings you will need:

  • Users: All users, exclude emergency access accounts
  • Cloud apps or actions: User action > Register or join devices
  • Conditions: None
  • Access Controls: Grant > Multi-factor authentication

5. Require MFA for Intune enrollment

MFA for Intune enrollment is a separate requirement and not something that is completely covered by any of the above policies. For example, a device which has already been authenticated for another application may be able to enroll without being prompted again unless this policy is in place.

I spoke with someone on Microsoft’s DART team recently, and he explained how this loophole had been used in the wild: in many organizations where CA has been previously implemented, a managed device tends to have greater access than unmanaged devices, with fewer prompts for MFA. But if an unmanaged device has even a little bit of access already, it is possible in some cases to elevate the device by enrolling it without encountering another MFA challenge. At this point the sphere of access has been expanded. Keeping this next policy in place will prevent this unauthorized ‘escalation’ scenario.

  • Users: All users, exclude emergency access accounts
  • Cloud apps or actions: Cloud apps > Microsoft Intune Enrollment
  • Conditions: None
  • Access Controls:
    • Grant > Multi-factor authentication
    • Session > Sign-in frequency set to Every time

6. Add device-based CA policies

This is something I have long advocated for. I recommend turning on a device-based access policy for at least Office 365. This way, access to corporate resources such as email can become contingent on registering devices with Azure AD or even enrolling your devices with Intune. The two primary benefits here are:

  1. You get pretty decent assurances that the inventory of devices you see in the portal is reflective of the actual physical devices out in the world (having an accurate and up-to-date inventory is necessary for good security), and,
  2. many of the current Man-in-the-Middle attacks are instantly thwarted, because the “middle” devices that are being used by attackers are not part of your inventory of pre-registered or enrolled devices.

Therefore, even if an attacker successfully phishes someone in your organization and tricks your end users into round-tripping an MFA code or approval notification, the unauthorized access request access would be denied by the device authentication requirement.

There are a couple of different approaches to accomplish a device-based authentication policy, but most organizations will aim for “Require compliant devices,” which looks like this:

  • Users:
    • All users (or a targeted group of your choice)
    • Exclude emergency access accounts
  • Cloud apps or actions:
    • Cloud apps > Office 365
  • Conditions:
    • Device platform: Select the platforms you intend to protect
  • Access controls:
    • Grant > Require device to be marked as compliant

With this policy in place, it is also necessary to prepare Compliance policies within Intune for each device platform you intend to support. End users must then download and sign-in to the Company portal app in order to complete device enrollment. The details around setting up Intune and enrolling devices is beyond the scope of this article, but I can recommend my courses or written guides on these topics for more information.

However, we must recognize that some organizations are not yet ready to implement Intune, or even if they are, they will not be ready to require device compliance across the board right away, and that is okay. In this case, I can recommend another policy which will prevent unauthorized device access based on device filters. We call this policy “Block unregistered devices.”

Block unregistered devices using filters

  • Users:
    • All users (or a targeted group of your choice)
    • Exclude Emergency access accounts and all Guest & External users
  • Cloud apps or actions:
    • Cloud apps > Office 365
  • Conditions:
    • Device filters:
      • Exclude devices where trustType Equals Azure AD Joined, Azure AD Registered, or Hybrid Azure AD Joined
    • Access controls:
      • Block access

In this case you do not need to have devices enrolled with Intune, however, the devices must be registered or joined to Azure AD before they can gain access to data in Microsoft 365 services such as Exchange or SharePoint Online.

I also recommend blocking device platforms that you do not intend to support, which I have outlined here (Microsoft has also since added this to their “common” CA policies on Learn); this policy does not require enrollment or compliance checks, either. These policies are sometimes an easier place to start out.

7. MFA for guests

Generally speaking, I like to keep my “guest-specific” policies separate from my internal user policies. Therefore, any policies targeting internal users will normally exclude guest & external users. If I want to deploy policies specifically against guests, those will be their own policies that I can turn on or off without impacting my “standard user” CA policies.

MFA for guests

You will notice that there is one such policy available via the templates provided by Microsoft: Require multifactor authentication for guest access.

However, before enabling this policy, I tell all my customers to enable the cross-tenant MFA settings. In case you didn’t know about these, navigate in the Microsoft Entra portal to External Identities > Cross-tenant access settings. Click Edit inbound defaults then go to the Trust settings tab.

Cross-tenant MFA settings

By checking these boxes, you are telling your tenant to respect MFA claims that have already been validated in other Azure AD tenants. In other words, if you deploy a Conditional Access policy in your own tenant that requires MFA for guests, those guests will not be double prompted if they have already satisfied MFA claims in their own (home) tenant. Completing this step also happens to be a pre-requisite for our last recommendation (though I have no idea why this is so).

8. Require stronger authentication

If your organization is ready to adopt passwordless methods of authentication using the Microsoft authenticator app, and/or FIDO2 keys such as Yubikey, then you have another option to consider. This past fall just prior to Ignite, we gained the ability to distinguish between authentication methods based on authentication strength.

Previously, any type of MFA was treated equally by Conditional Access requirements: so an SMS code was considered just as good as the authenticator app or even a FIDO2 key. But in reality, not all authentication methods are created equally. With a FIDO2 key for example, the key material is non-exportable. In other words, an attacker would have to physically steal your key in order to use it to gain access as you. It is therefore considered “phish resistant.”

I suggest taking a crawl-walk-run approach; if you are considering switching to stronger authentication you may want to identify specific use cases or groups to pilot the experience before pushing it out org-wide. For example, if you have to distribute physical keys, how does that process work? What happens if someone loses a key? Etc. These questions will be easier to sort out on a smaller scale, which will help you develop a system for more widespread adoption.

Here is an example of upgrading a policy where you require stronger authentication for specific admin roles:

  • Users: Select users and groups > Directory roles (select any groups or roles you require)
  • Cloud apps or actions: All cloud apps
  • Conditions: None
  • Access controls: Require authentication strength (select your desired strength)

Upgrade your authentication strength

Note that you may have additional steps to configure the passwordless or FIDO2 experiences before enabling these CA policies.

9. Fancier subscription, fancier options

If you are the lucky owner of the more expensive E5 subscription, then you also have access to “risk-based” Conditional Access policies, as well as a bunch of other upgrades that are well beyond the scope of this article. Once again, the Conditional Access templates are the easiest way to get moving on some of these features.

E5 risk-based policies

Note: If you buy licenses to support these features for just your administrator accounts (as some organizations do), just be sure that when you deploy the policies, they are scoped to only those users who are licensed for the features. This way, you stay in compliance with Microsoft’s licensing guidelines.


The principles of Zero Trust remain unchanged. In the past, we would have simply enabled MFA, or the equivalent of Security Defaults, and felt that we had fulfilled the spirit of the “Verify Explicitly” pillar, but as we have seen, that may not be enough anymore on its own.

Zero Trust Principles

As the game has changed, so have our tools. In order to have more confidence that our “Verify Explicitly” principle is being met, we just want to put in place a few additional measures, for example:

  • get users to slow down by adding a number-matching requirement on the Authenticator app
  • better protect the MFA registration process itself with Temporary Access Pass
  • require a strong authentication challenge anytime a device is registered, joined or enrolled for management
  • evaluate the device as part of your authentication challenge
  • even require a stronger level of authentication such as phish-resistant, hardware-based FIDO2 keys

And of course, do not forget to address the other two pillars of Zero Trust, either! I will soon release updates to my famous Best Practices Checklists and other written guides to reflect more of what we learned over the last year. If you already own a copy, then congrats! Your free updates will be arriving sometime in the next month or so. If you want to join thousands of other happy readers, I encourage you to subscribe, check out the store, or even consider joining our SquareOne community.

We are living in a different world now than the one we had 10 or even just 5 years ago. I wonder what it will look like 5 or 10 years from now? It’s part of what makes our jobs stay evergreen, I suppose. Staying up to date in the day-to-day and month-to-month, of course, is going to be the key challenge for most of us. I suppose this article, too, could go out of date pretty quickly after its printing. But do not be discouraged: it just means that we must always be aware, ready, and willing to make iterative changes over time.

If you see any omissions in the policies or settings I discussed in this article, be sure to comment below! We would love to learn from you out there in the audience, as well!

Comments (10)

  • Darren Zappa Reply

    Good stuff Alex – Merry Xmas

    December 9, 2022 at 6:26 pm
    • Alex Fields Reply

      Thanks, and Merry Christmas to you as well!

      December 12, 2022 at 11:49 am
  • Daniel Powell Reply

    The Securing security info registration policy has always confused me. I thought this meant MFA is required to access the mysecurityinfo page, which I never saw the point of because of the MFA enabled for all users is, pretty much, always enabled.

    But sounds like I’ve not understood this right, with the Protect registration of security information CA template enabled the user needs a TAP to access? ?

    December 13, 2022 at 7:28 am
    • Alex Fields Reply

      We have a separate policy for security info registration because that page is not covered by the selection “All cloud apps”; so when you create a policy to enable MFA for all users / all cloud apps, technically that page is not in scope. Therefore, we have this “user action” policy to cover this scenario. Since the MFA registration page is often accessed before any MFA methods exist, or, when you lose your primary method and need to go edit them, the TAP is the ideal method for sign-in to the security info registration page.

      December 23, 2022 at 3:04 pm
  • Brian Reply

    This is just an abbreviated post, since my last one (I think) was invalidated with a WordPress nonce error.

    Re 2nd half of #6, for those without Azure AD Registered devices (which is a minority for us but non-zero) it results in: “You cannot access this right now. Your sign-in was successful but does not meet the criteria to access this resource. For example, you might be signing in from a browser, app, or location that is restricted by your admin.”

    The user is given no path forward, so we’ll have to retreat on this policy until we can prepare users with full instructions on Windows (that one is in Settings, Accounts), Android, and iOS (on the latter two even I don’t know offhand where to go). It’s a little surprising that MS just leaves people hanging without direction.

    January 1, 2023 at 8:24 pm
    • Brian Reply


      That answers the Android/iOS method, but MacOS/Linux are very puzzling because they require Company Portal/Intune. That seems to be suggesting that for those two platforms there’s no method to Azure AD Register without Intune, when of course the point of the policy is for people not wanting to use Intune. So unless I’m missing something, it would seem that further exclusions would need to be made for those two platforms.

      January 3, 2023 at 7:32 pm
      • Alex Fields Reply

        Yes, the best support for devices is still found in iOS/Android and Windows. As they opened up support for Mac, Linux, etc. it seems they rely pretty heavily on Intune/MDM enrollment. Would be nice if we had the same support everywhere (e.g., MAM capabilities across the board, etc.), but alas, no. That having been said the vast, vast majority of businesses I deal with do stick with Windows when it comes to company issued devices, and then of course (mostly BYOD) iOS/Android devices as well. So for example when I deploy the policy to block unsupported device platforms I am generally blocking Linux, Mac, etc. anyway. I think there is another article somewhere (and maybe it’s time to drop another) that lays out the limitations we have with regard to these platforms, and I suggest the only real options here are: block access, or enroll for MDM before granting access. Even with MDM we still don’t have nearly the control and options that we do with the other three platforms, so it is a bit lackluster. But at least we can require encryption for each device type, and that is something.

        January 29, 2023 at 11:45 am
  • [m365weekly] #106 – M365 Weekly Newsletter Reply

    […] But have you turned multifactor authentication ALL the way on? Are you still relying on MFA alone to protect your identity? Think again. With the rise of sophisticated phishing techniques and Man-in-the-Middle attacks, it’s time to take a closer look at your authentication methods and fortify your defenses. Discover the latest tools and policies to keep your identity safe in the ever-evolving world of cyber security […]

    January 23, 2023 at 1:30 am
  • Brian Reply

    It’s all surprisingly complicated and subtle.

    Another aspect of this is the favoritism shown Edge when the #6 (part 2) policy is in place: on Windows, Firefox and Chromium (including Chrome but excluding Edge) browsers can no longer log in. That’s puzzling to say the least, until you find that in Firefox’s case you need to enable a particular one of its settings (“Allow Windows single-sign on”) and for Chrome you need to install either the “Microsoft 365” or “Windows Accounts” extensions.

    February 18, 2023 at 4:52 pm
  • Joshua Price Reply

    In migrating from the per-user legacy MFA to Conditional Access Policy-based MFA, we realized there is no longer an authentication method listed for Application Passwords (for service accounts).

    I have an open ticket with MS about this now, but they’re trying to guide me backwards, back to the per-user MFA.

    What is a better approach to service accounts?

    July 20, 2023 at 2:26 pm

Leave a Reply

Back to Blog

Helping IT Consultants Succeed in the Microsoft Cloud

Have a Question? Contact me today.