Microsoft Causes Fuss Around Azure MFA Announcement

Azure MFA Required for Connections from July 2024

Updated

Microsoft’s May 14 announcement that they will require multifactor authentication (MFA) for access to Azure services certainly kicked up a heap of questions. The sad fact is that Microsoft has a good message to communicate around increasing the security of connections to the Azure portal (and assumedly for Azure PowerShell sessions) but failed miserably to communicate that message.

After reading the announcement, my take is that Microsoft will deploy the requirement for MFA for connections to Azure services from July 2024 onward. Microsoft says that they will communicate with tenant administrators with details about what they plan to do and when they will do it, and that the deployment will be “gradual and methodical to minimize impact on your use cases.”

The Reasons to Use Multifactor Authentication

Excellent reasons exist to use MFA to protect connections. Anyone who uses basic authentication (username and password) for administrator accounts (or any user account) is playing with fire because their account is a prime target for compromise. Microsoft cites two different numbers (99.2% and 99.9%) for the ability of MFA to block attacks like password sprays (I’ve seen both figures cited elsewhere), but this slip of the pen doesn’t matter.

What does matter is that MFA offers better protection for account compromise, especially if you use strong authentication methods like the Microsoft Authenticator app, including the recently-added support for passkeys.

Another important point is that the Entra ID community is not doing a great job of deploying and using MFA. According to Microsoft VP for Identity Security Alex Weinert, MFA protected 38% of Entra ID accounts in February 2024. Perhaps the recent announcement of support for external authentication methods will help drive the percentage higher because organizations can leverage investments in MFA solutions that don’t come from Microsoft.

Communication Issues Around Azure MFA

Good as MFA undoubtedly is, Microsoft just didn’t get their point across.

First, Microsoft didn’t clarify which users will need to use MFA. Including the phrase “for all Azure users” in the announcement title made a major contribution to the confusion. My understanding is that MFA will be required to connect to the Azure portal, so that limits the set of affected users to people who sign into the Azure portal to work with subscriptions, resource groups, automation accounts, billing, and so on. In short, not your average Microsoft 365 user (who probably don’t know or want to know about the Azure portal).

Update: Microsoft posted a comment to the article saying that MFA applies to, “All users signing into Azure portal, CLI, PowerShell, or Terraform to administer Azure resources are within the scope of this enforcement.”

Second, Microsoft didn’t say how they will enforce MFA. The text points to the MFA setup wizard in the Microsoft 365 admin center (Figure 1), which focuses heavily on enforcing MFA through conditional access policies.

Conditional access policies work very well, but they require Entra ID P1 licenses. This is probably not an issue in enterprise tenants where Entra ID premium licenses cover many different features, but it could be a problem for small businesses. It’s the same issue around imposing extra cost that occurs in Microsoft’s campaign to move Office 365 per-user MFA to conditional access policies.

Perhaps Microsoft plans to use a mechanism like the way Security Defaults requires accounts with administrator roles to use MFA with the Authenticator app. In other words, no conditional access policies and no need for premium licenses. Of course, if organizations want to use conditional access policies to enforce MFA for inbound connections they can do so and fulfil the requirements of Azure. Microsoft says that no-opt is available except through an exception process that isn’t yet defined.

A long time ago when I started to write magazine articles, an editor told me not to assume that the reader understood the topic I wrote about and to answer questions in the text that I assumed people already knew the answers to. That good advice has stood the test of time. I often feel that Microsoft communicates in a way where they assume the target readership understands the full context of the topic being discussed. It would be nice if they wrote text that is a lot more specific and complete.

Rushing to Embrace Security

Microsoft’s Security Future initiative is a worthy venture, but it seems like Microsoft engineering groups are rushing to implement blocks to meet their schedule rather than understanding that announcing what could be a major change in mid-May for implementation in July (initially for the Azure portal) is not appreciated by customers. It’s not as if tenant administrators only need to concentrate on securing Azure better. Every engineering group in the Microsoft 365 ecosystem is tightening security and the cumulative workload created for tenant administrators is something that I don’t think individual program managers contemplate.

The net is that no one can argue against better security connections to Azure services if implemented in a measured and well-communicated manner. It seems like Microsoft’s May 14 announcement was a tad rushed and that’s a real pity.

---

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.