Microsoft will require MFA for all Azure users
Published May 14 2024 03:47 PM 96.8K Views

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.

 

- Erin

 

How MFA works

Multi-factor authentication (MFA) is a security method that requires users to provide two or more pieces of evidence to verify their identity before accessing a service or a resource. The evidence can be something the user knows (such as a password or a PIN), something the user has (such as a phone or a token), or something the user is (such as a fingerprint or a face scan).

 

MFA adds an extra layer of protection to the standard username and password authentication, making it harder for attackers to compromise accounts and steal data. MFA can also help prevent unauthorized access due to phishing, credential stuffing, brute force, or password reuse attacks.

 

Entra ID supports various MFA methods, such as Microsoft Authenticator app, SMS, voice call, and hardware tokens. Users can choose the method that suits their preferences and needs.  Admins can also use Entra ID Conditional Access policies to tune when MFA is required based on signals such as the user’s location, device, role, or risk level.

 

Why MFA is important for Azure tenant security

The need for MFA is more important than ever, as cyberattacks are becoming more frequent, sophisticated, and damaging. According to a report by Microsoft, 99.9% of compromised accounts did not use MFA. The report also found that MFA can block more than 99.2% of account compromise attacks, making it one of the most effective security measures available. 

 

The rise of the hybrid workforce and accelerated digital transformation of businesses by the COVID-19 pandemic expanded risk scenarios for employees and companies. Today, more people work outside of the office and access data and applications from various devices and locations. All of this has increased the attack surface and the potential for unauthorized access, as users may use unsecured networks, devices, or passwords. MFA can help mitigate these risks by adding an extra verification step and preventing access from unknown or suspicious sources.

 

MFA is also a key component of identity and access management, which involves ensuring that only authorized and authenticated users can access the services and resources. One of the three areas of engineering advancements within Microsoft’s Secure Future Initiative focuses on implementing new identity protections and MFA at the tenant level helps you with identity protections. MFA not only reduces the risk of account compromise and data breach, but it also helps you comply with various security standards and regulations, such as PCI DSS, HIPAA, GDPR, and NIST.

 

Don’t wait to set up MFA

To help you keep users and data safe, MFA is now available and free for you to enable at the tenant level. You can set up MFA today with the MFA wizard for Microsoft Entra.

 

If you have additional questions, please review the MFA FAQ on Microsoft Learn for more information and learn more about the Secure Future Initiative and Microsoft’s built-in security features here.

84 Comments
Iron Contributor

1. Really all users, no exception (e.g. service accounts)?

2. "Azure users"? or all users (with guests) in Entra tenant?

3. Which MFA authentication methods will be allowed or enforced?

Bronze Contributor

Our USERS are already using MFA.

What about SERVICE type accounts? We limit those to only login from our on-premise devices. Hope you aren't requiring more.

What about GUESTS? Our guests are often elderly or technically challenged. Force MFA on them as well?

Brass Contributor

Yeah, what about students who aren't allowed mobile phones in the classroom?

Brass Contributor

Can you be a little bit more specific on how this measure will be enforced at the tenant level? As an Entra ID admin I'm happy this the decision but I'm also worried as this can cause issues for legitimate MFA exceptions on some accounts.

 

Will Microsoft use managed conditional access rules or enforce this using the security defaults, etc?

Steel Contributor

I second students as well. It's hard enough for us to get them to read their Email but a rollout of this size will be trouble for our K-12 district IT staff. Student populations are often seven or ten times larger than faculty and that was a challenged when we rolled that out to them two years ago. I hope we have some control, maybe an acknowledgement type check box?

Brass Contributor

This would be phenomenally difficult for us - we are a Trust of Special Educational Needs schools and as such, would be unable to facilitate this at all with our students. This should be obvious to Microsoft and in spite of the clear security advantages of MFA for staff and other connected adult accounts, we would be at odds with our student base and their ability if we were to enforce this kind of security requirement at login etc. Can I ask if this is controllable using conditional access in some way??

Copper Contributor

Wait what?? Whilst as a Cyber Security engineer I totally agree with the ethos of this suggestion; WAY more detail and context is required? How is this getting delivered...Microsoft Conditional Access policy? (Can we turn off). Will there be an exception process for "service accounts", "guest accounts" or others? How are you going to deal with use-cases where MFA cannot be utilised? What MFA method is going to get enforced, can we choose?

Copper Contributor

Consider additional options for education segments like several have already commented about.  We also need more details asap so we can prepare and budget for any additional expenses.  Starting in July is not a lot of time.

Copper Contributor

IT for a school, policy is no mobile phones for students! Will Microsoft be offering subsidised or free FIDO2 keys to students? im hoping this is a badly worded will only affect 'securty defaults' tenants. Would also like to see conditional acess offer a way to disable the requirement. e.g the photocopiers have a login to save scans in users onedrive's directly. Curently this 'user' can bypass MFA for that specific account by login source IP adress. certain othere will have many similar non MFA frendly accounts in use.

Copper Contributor

How is this going to work in schools.... I have students with accounts in year 1 all the way up to year 11 plus special education schools. Its not going to be possible. This enforcement will force schools to move to Google!

Copper Contributor

What about service accounts?

Iron Contributor

Excuse me?

 

You say "at the tenant" level, but also say "for all Azure users." You need to clarify which it is - just when users access, say, the Azure portal? Or are you talking all users in Microsoft 365/Entra ID? The former is fine, the latter is a bombshell that is going to turn every IT department upside down.

Brass Contributor

What about the break glass accounts?

We are using conditional access policies to require MFA, how is it going to work with this announcement?

Copper Contributor

Can someone point me to an official Microsoft notice of this change. Whilst I'm a big advocate for MFA, I find it hard to believe all users will be forced to use MFA without a proper consultation and transition period from Microsoft? As others have stated, how does this work with service and break glass accounts? Most schools operate a no-mobiles policy meaning auth apps would not be suitable, leaving only FIDO2 keys or conditional access. 

Copper Contributor

This needs way more information that what we have gotten here before you can even think about rolling something like this out.

 

What about service account? What about special needs users who might not be able to fully use MFA methods? What about emergency access accounts?

 

 

Copper Contributor

So we use OKTA as our source of truth. There does not seem to be a way to exempt some of the security score DINGs when MS thinks we are not applying best practice. OKTA demands NO 2FA enabled for the service account, so we lock it down based off IP address only allowing requests from OKTA on that account. Forcing 2FA would completely break our integration and make service accounts for other integrations fail. It's time for MS to admit and support instances where MS is NOT the Source of Truth. I really hope this gets addressed and there is a service account exception.

Brass Contributor

Hello,

how these changes align with other products like PingID which are enabled and set as default MFA in our company? Are there any controls over this enforcement? 

Thanks. 

Copper Contributor

I see this article was updated this morning (5/15/24) and none of the questions have been answered. This article is extremely vague for something that could potentially have a massive impact on any org using Azure logins. I just want to know if this only applies to all AZURE logins, or all ENTRA logins. This article gives 2 sentences explaining what they're changing and the rest anyone could just ask ChatGPT to answer. Can you please get an article out for admins detailing the specific changes, and how it will affect organizations? 

Copper Contributor

This article is extremely vague as many has already described. My first thought was wait a second, we are unable to use Microsoft Entra's MFA solution because the Conditional Access is locked behind the Entra ID Premium license. There for, I cannot enable and target a hardware token for registration in Entra for all users or a specific group of users as a requirement. It's only optional. 

 

Service accounts are another huge concern for me. How many tokens am I going to need from Microsoft just to run my every day? Or better yet, am I going to be spending all day pressing the token button just to complete my daily task?

 

I'm a little picky here, however, Microsoft recently rebranded Azure to Entra. So, are we talking Entra or Azure? Are they the same or is there a new product in the market that I was not aware of.

 

Don't get me wrong, as a security person, I am all for MFA. However, it should be done right, with proper documentation. We use an on-prem hardware token for MFA. No BYOD is allowed. Our employees cannot download the Microsoft Authenticator app onto their personal phones, as that is a violation. Plus, that app would only work for one thing, Entra. 

Copper Contributor

This is not the right way to do this.  Requiring an authentication app when not everyone will have access to an authentication app is ludicrous.  At a minimum, you should leave texting as an MFA option.

Copper Contributor

IT Manager at a school here - this is going to truly mess us up as phones are banned by our government in schools. Guess we have to switch to google services now? Cheers Microsoft for another painful change

Copper Contributor

This is missing so much critical information. What about service or break glass accounts? I can't convince every customer to go for Business Premium. Security Defaults doesn't allow exclusions and makes things complicated enough, if this adds another level and enforces MFA it will actively break stuff.

Copper Contributor

This needs much more clarification. If this is a blanket change as this posts suggests, then it will prevent at least 350 of my younger users who do not have mobile phones from using Microsoft 365 services, unless the company is planning on providing hardware.

Copper Contributor

The report starts really well with

 

'MFA can block more than 99.2% of account compromise attacks, making it one of the most effective security measures available'.

 

followed in the same sentence with

 

' MFA can block more than 99.9% of account compromise attacks, making it one of the most effective security measures available'

 

Brass Contributor

Good, finaly! :)
However, i belive this is only for Azure services (ie: same as CA006 and CA016, Azure management API and Azure admin portals).
or, as many has asked before, will it be enforced for all accounts in Entra? (Microsoft has said before that Entra is not an Azure service).

Microsoft

MFA will be required when logging in to the azure portal (portal.azure.com) and the entra portal (entra.microsoft.com). 

Copper Contributor

This seems so vague! What about k12? Will this affect SAML for kindergartners?

Steel Contributor

Microsoft, slow your roll. We've been using Conditional Access Custom Controls for implementing Duo, and have been *begging* for native support for like 4 and a half years since the original announcement right before COVID hit.

https://techcommunity.microsoft.com/t5/microsoft-entra-blog/public-preview-external-authentication-m...

And now you're enforcing this MFA requirement (which custom controls don't satisfy) in roughly 2 months, while external authentication has been in Public Preview for like.. a week or two?  That is basically ZERO time for proper change management, testing, and deployment to happen at a scale like ours. (Higher ed, tens of thousands of users) Good grief.

Steel Contributor

I know this post is very vague and non-specific, but I am fairly sure this applies to admin / Azure Portal users. If you go to the link Microsoft 365 admin center it shows this:

BrianHoyt_0-1715872627005.png

It is talking about admins not "ALL" users.

Brass Contributor

@ajc196You know you can bring 3rd party providers into Entra ID Authentication Methods right? it went live a month ago.
I have multiple tenants that have migrated DUO already and it works really smooth (it was half a days work).
https://techcommunity.microsoft.com/t5/microsoft-entra-blog/public-preview-external-authentication-m...

@Tom_C241Thanks for clarifying, then my hunch was correct except for the management API.  ie: Only admin portals (entra/azure).

Copper Contributor

I am curious if Microsoft has taken into consideration the change control processes and requirements of many organizations, where review is required?

Also, many organizations requiring a testing period and have update their operational documentation.

 

Just a two month window seems unreasonable for many customers, not being able to fully understand the downstream impact of this change.

Not to be a conspiracy theorist, and I applaud the use of MFA, but this rushed requirement seems to be something that may be getting driven by something else behind the scenes.

Bronze Contributor
Not to be a conspiracy theorist, and I applaud the use of MFA, but this rushed requirement seems to be something that may be getting driven by something else behind the scenes.

You may have read in recent news articles how Microsoft servers were hacked because some of the accounts that were infiltrated were lacking MFA and that as a result Microsoft staff (possibly high level) mailboxes were accessed.

 

 

Microsoft

Hello everyone, my name is Naj Shahid and I am a product manager in Azure leading this initiative. I am sharing some information below that should help with your questions.

 

  • Scope: All users signing into Azure portal, CLI, PowerShell, or Terraform to administer Azure resources are within the scope of this enforcement.
  • Impact on end users: Students, guest users and other end-users will only be affected if they are signing into Azure portal, CLI, PowerShell or Terraform to administer Azure resources. This enforcement policy does not extend to apps, websites or services hosted on Azure. The authentication policy for those will still be controlled by the app, website or service owners.
  • Exclusions: Service principals, managed identities, workload identities and similar token-based accounts used for automation are excluded. Microsoft is still gathering customer input for certain scenarios such as break-glass accounts and other special recovery processes.
  • MFA Methods: All supported MFA methods are available for you to use.
  • Exceptions: While there will be no opt-out, an exception process will be provided for cases where no workaround is available. Details for the exception process will be shared via official notifications.
  • Timeline: Beginning July 2024, a gradual rollout of this enforcement for portal only will commence. Once we have completed the rollout for portal, a similar gradual rollout will start for CLI, PowerShell and Terraform. We understand the impact this enforcement could have on automated scripts using user identities and thus are prioritizing enforcement for Azure portal to provide additional time to adapt if needed.  
  • Communication: Microsoft will send detailed information and timelines through official emails and notifications with advanced notice to ensure customers are well informed and prepared. The purpose of this blog post was to generate awareness about this upcoming change and help you prepare for transition to multi factor authentication.

 

As Erin mentioned in the post above, don’t wait to set up MFA. Keep users and data safe by setting up MFA with the MFA wizard for Microsoft Entra. Microsoft recommends examining which Entra IDs are used with dev ops and API access to Azure Resource Manager. As needed, learn how to replace user identities with service principals and managed identities.

 

Sincerely,
Naj Shahid

Principal Product Manager

Microsoft Azure

Copper Contributor

Hi @Naj Shahid-san, thank you for providing additional guidance on this matter.
However, it seems that some of the information I am looking for is still missing. Would it be possible to get answers to the following questions?

 

Scope: All users signing into Azure portal, CLI, PowerShell, or Terraform to administer Azure resources are within the scope of this enforcement.

Specifically, how will it be implemented?
- Through control functions on the Azure side or Entra ID managed conditional access?

 

Timeline: Beginning July 2024, a gradual rollout of this enforcement for portal only will commence. Once we have completed the rollout for portal, a similar gradual rollout will start for CLI, PowerShell and Terraform. We understand the impact this enforcement could have on automated scripts using user identities and thus are prioritizing enforcement for Azure portal to provide additional time to adapt if needed.  

What I need is not a gradual "forced" rollout, but a control option to enable it myself when needed.

Do you plan to provide such a feature?

Iron Contributor

Then you absolutely MUST STOP throttling authentication. It should never be subject to any throttling mechanisms. It's unscrupulous and forces longer authentication processes, making it wholly detrimental to your declared goals. Push auth number matching breaks.

Copper Contributor

"Establishing this security baseline at the tenant level..."

 

Should it be read as, it is only for logins at the Azure Portal?

Iron Contributor
@ajc196 You can move your Duo custom control to EAM right now, here are my guided steps on the process > https://ourcloudnetwork.com/configure-external-authentication-methods-in-entra-id-with-duo-security

 

Copper Contributor

THANK YOU Microsoft.

This change is long waited.

Have you informed partner like Coreview about this change? Today they are using service account to login on tenant, it means they need to move to service principal in less than two months and this is for all their clients.

I like the idea of killing service accounts which most of the time are just admin account but the timeframe is pretty low here and it may be challenging.

 

If you want my point of view? Start by giving more transparency to customer on secure score in defender. There are a lot of entra related controls here and none of them provide a view on exposed entities.

You want to improve MFA for azure? Show non compliant login in a simple view 

Want to go cloud only for administrator? Provide the listing of accounts non compliant and not just a score which says compliant or not without details.

 

It's how client can improve their tenant, they need those score but need as well transparency on the scoring to know where it fail.

Brass Contributor

@sukank_ I would ask the same question. I guess there's no CA involved with this. Microsoft states there's no OPT-OUT possible. When they use CA policies you can control them and still OPT-OUT. 

 

On topic:

I think we need to accept the fact that this is happening. The scope is limited to All users signing into Azure portal, CLI, PowerShell, or Terraform which are basically administrator things. You should already require MFA for things like this so nothing should really be different from now for most of us.

Brass Contributor

MICROSOFT, PLEASE EXPLAIN THIS IN THE FORM OF A 'CONDITIONAL ACCESS' RULE - I AM NOT SAYING THIS *IS* A CONDITIONAL ACCESS RULE, BUT EXPLAINING THIS CHANGE IN THE FORM OF A CONDITIONAL ACCESS RULE WILL HELP PEOPLE HERE UNDERSTAND WHAT YOU ARE SAYING.

 

IS MICROSOFT SAYING...

 

sectionsubsectionparametervalue
AssignmentsUser and Groupsincludeall users
  excludeno one
 cloud apps or actionsincludeall apps
access controls- grant
  require multi-factor authenticationtrue
  enable policyon

 

Copper Contributor

Ok, Microsoft, this is insane. And i don't mean to say that in a positive way. This is the second thing that takes away any control on MFA that the paying customer had.

 

First MSFT thought it would be a great idea to label Windows Hello PRT's to be 'as strong as' Authenticator MFA with no way around to enforce Authenticator MFA as mandatory step even when we want to use Hardware Tokens. Filed as a DCR last year still nothing has happened.

 

Now, ladies and gentlemen, MSFT thought of a new way to bash their valuable customers (their only right to exist) by forcing something that we cannot opt-out from for reasons only the customer can judge. The stated timeline is in our humble opinion, quite opportunistic and idiotic.

 

My advise to you, MSFT, start listening to your customers and hear them out. We have multiple use cases where we cannot comply with this new idea of you. We just need the opt-out.

 

Copper Contributor

Can you please share the Micrososft Official announcemenet link ?

Iron Contributor

Its about time. This should have been done a while ago. Good job!

Copper Contributor

That's phenomenally poor communication, thanks @Naj Shahid for elucidating some points.

Steel Contributor

Yep, that's the main takeaway here -- We need more detailed announcements in the first place to avoid the confusion we see in the comments here. This is the Tech Community, we know what MFA is and why it's important.  But that's 80% of this "announcement", rather than explicit details about the change you're actually announcing.

Thanks @Naj Shahid for clarifying the scope and that this is not for every authentication that touches Entra ID!

 

Steel Contributor

Also, is there going to be an easier way to disable stuff like Azure Powershell for staff. It's a frequent target

Brass Contributor

This kind of announcements without technical details on how this will be implemented are really bad. 
Are you aware that Entra ID is used by 80% of companies worldwide and a small change, if not well managed, can have impact on the whole world economy? 
Please share more details thanks.

Copper Contributor

So how can I after MFA is enforced for all users run my Azure DevOps PAT management automation in an AzureDevOps pipeline? The documentation states that when MFA is enabled I need to follow the Authorization Code flow, but that entails interactive login and will enforce MFA? Using an entraID account that has an AD token is the only supported way to manage Azure DevOps PATs ... so unless I am mistaken in my understanding, this will break. Please advise! Help?

The announcement says that Microsoft is enforcing MFA for access to Azure administrative interfaces like the portal. I don't think it will affect Azure DevOps, but it would be good for Microsoft to confirm. But maybe those DevOps users should use MFA (enforced by CA policies) anyway to avoid the possibility of accoint compromise? 

Version history
Last update:
‎May 17 2024 09:23 AM
Updated by: