Microsoft enforces tenant-level MFA in July! What should I know?

Upcoming July, 2024 will be a big deal for securing Microsoft tenants world wide. Microsoft announced on May 14th that they will enforce tenant-level (I like to say tenant-wide) MFA requirement for all Azure users. Let’s quickly look at this announcement!

The infamous announcement

Here’s the announcement. I left out the parts that explained how MFA works and why it is important. Obviously, we know that already.

This July, Azure teams will begin rolling out additional tenant-level security measures to require multi-factor authentication (MFA). Establishing this security baseline at the tenant level puts in place additional security to protect your cloud investments and company. MFA is a security method commonly required among cloud service providers and requires users to provide two or more pieces of evidence to verify their identity before accessing a service or a resource. It adds an extra layer of protection to the standard username and password authentication.

The roll-out of this requirement will be gradual and methodical to minimize impact on your use cases. The blog post below provides helpful information from the Azure product team to assist you in getting ready to MFA-enable your access to Azure services.  Going forward, the team will provide communications to you about your specific roll-out dates through direct emails and Azure Portal notifications. Expect these in the coming months.  

Read on to learn why and how MFA is important to securing customers on Azure and your workloads, environments, and users. If you do not want to wait for the roll-out, set up MFA now with the MFA wizard for Microsoft Entra.

-Microsoft

As you can see and read, this announcement does not give much explanation of what’s coming. No wonder the comment section started to fill with worrying comments like these…

Okay, so Microsoft executed the communication very poorly and people were confused. The specific phrase used in the topic was a disaster: “…require MFA for all Azure users” . I’m perhaps more patient myself and usually wait for a week or so for the initial storm to pass and then check what’s going on. I actually believe this to be a good thing, but I understand that the timeline is troublesome for companies around the world.

User and application scope

Included: All users, including guest users, that administer or view resources using Azure Portal, Azure CLI, Azure PowerShell or Terraform.

Excluded: All users who don’t login to Azure Portal or use command line tools or Terraform. Meaning your average M365 users. The non-admins.

Identity scope

Included: All user accounts, including your service accounts.

Excluded: Workload identities, like managed Identities, applications and service principals.

MFA methods

Included: All MFA methods that you have license for, have enabled and configured are supported and available for users.

Excluded: Only the ones you’ve excluded or disabled yourself as an admin.

Exclusions

Excluded: Logins to services and apps hosted in Azure are not in scope. They continue to operate as-is.

Impact

The change is cumulative by design, so if you have any Conditional Access policies that grant access to any of the aforementioned apps and you don’t require MFA, then this mechanism will kick in and require MFA on top of anything you have required on your CA policy.

As I’ve understood, the MFA required here is any MFA that is supported and available in Microsoft Entra. And we also know that not all MFA is equal. If you are requiring stronger MFA or phishing-resistant MFA using Authentication Strengths, then there’s no effect and this mechanism certainly does not downgrade any of your requirements. So if you require a FIDO2-based authentication then that’s what is required. Most restrictive control will apply.

Guest users who are logging in to your Azure portal are also subject to the change as already stated. Explore and consider the Cross-tenant access settings in Entra portal that allow you to configure an incoming trust-relationship to your partners. If you trust your partner MFA, the guest user completes the MFA in their home tenant and during the sign-in to your tenant the MFA is satisfied by the claim passed from the partner tenant. Otherwise the guest has to obey the controls of your tenant including this tenant-wide MFA requirement.

Opting out

Microsoft has communicated that there is no opt-out available. What they have stated is that they are working on an exception process for cases where there is no workaround available (meaning where a service account is a must).

Emergency access

Most tenants that have implemented emergency access have made so by creating one or two service accounts. Depending on when the emergency access was implemented there was a recommendation originally to not enroll MFA to those break-the-glass accounts. The recommendation has changed since, and guides to use MFA and to configure two different methods for these accounts in case one MFA method would have a service downtime, the other would likely continue to work.

But as these accounts are user accounts they are subject to the introduced change. So if you haven’t enrolled your emergency accounts to MFA yet, now is the time to do so. As these accounts usually have permanent privileged access you should also consider using phishing-resistant MFA methods and to implement sign-in monitoring and alerting.

Rollout timeline and prioritization

Gradual rollout will begin on July 2024. Microsoft will prioritize Azure Portal first to allow more time to change service account-based automation to use service principals instead. As the rollout is phased it will take some time, especially if the rollout encounters any major problems.

Summary

The change is part of the Microsoft’s Secure Future Initiative (SFI) which I endorse. The world of cybercrime is moving fast and impacting us more than ever before. We cannot drag our feet and make excuses for not making our digital estates more secure. As identity is in the forefront of any cloud service we must put more effort into protecting identities and access. I know we have done this many times already, but as the criminals are setting the pace, new protective innovations arise as well. While this is not a new but rather old innovation it is still not adopted as widely as needed. We need to do better.

Stay secure!

Tommi Hovi
Tommi Hovi
Articles: 16