Microsoft recently notified customers of upcoming changes to enforce multi factor authentication (MFA) for all identities signing into Azure with no exceptions. Enforcing MFA makes good sense, Microsoft reports that 99.9% of identity-based attacks are mitigated when an identity is protected with MFA, and therefore this is a change with huge benefit to uplift Azure environments still needing to improve MFA coverage to reduce the attack surface.

If you haven’t seen the notification published by Microsoft, be sure to check the Microsoft 365 notification center for more information, including dates for when your tenant will be impacted, and a link to more information. The notification center can be found at https://admin.microsoft.com, located under the health section.

Working regularly with customers, we know that this change is going to have impact, and effort will be required to plan, prepare and implement. Microsoft advises this will be a rolling change to assist with this, but nevertheless the impact will be felt sooner rather than later. Changes have already begun rolling out to tenants from July 2024 and will conclude early 2025.

The initial phase of the change enforces MFA for several administration portals, including Azure portal, Entra Portal, and Intune Portal, and the second phase scheduled for early 2025 affecting Azure command line interface (CLI), Azure PowerShell, and Infrastructure as Code (IaC) tools.

With a short timeframe for these changes to be enforced, it’s important to begin planning and remediating potential impacts sooner than later.

Impact?

Microsoft’s decision to enforce MFA to access Azure is an excellent decision. It closes the gap for identities that should have been MFA enabled and yet were not, but in doing so, there are impacts.

Planning, planning, and more planning.

There are several key areas to consider when implementing a change such as this, some of the questions to ask yourself include:

• Which identities will be affected by this change?
• What purpose do these identities service? Admin account, service account, etc.?
• Will an application or service be affected? Will something stop working if I don’t make the necessary changes?

Remember, to help plan this change, you can align your migration approach to match Microsoft’s multi-phase schedule, it doesn’t need to be a big bang approach. Start with the Azure portals, then later Azure CLI, etc. And if for some reason if you need, Microsoft does have an option to postpone the enforcement, however if possible don’t delay because if you do this now, you’ll be in a better position later, and have a more secure Azure environment.

When considering identities that will be impacted, think about all the identities in use, not just including people who sign in, but also service accounts, etc. So, if you’re using user accounts for automation or other purposes, then you’ll need to consider what to do in this scenario. However, if you’re using workload identities, such as a service principal or managed identity then these will not be affected.

And if you don’t prepare and register accounts for MFA? Once enforcement begins, those will be prompted to register prior to being granted access. This could be problematic, and break functionality somewhere in your environment.

Sure, but how am I going to know which accounts will be affected?

You will have sufficient information on hand to help identify the identities to be remediated. This includes reviewing each identity to determine if multi factor authentication is enabled and reviewing MFA gap reports, or sign-in logs to understand the big picture.

To get the most out of reporting, and Entra ID P1 license or greater is required as this will give you more information about each identities sign-in activities over a longer time.

Microsoft have provided the following information to assist:

• PowerShell script to report identity MFA settings: https://aka.ms/AzMFA
• MFA gaps workbook: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/workbook-mfa-gaps

The PowerShell script is limited to reporting on identities that have signed into the Azure portal, Azure CLI, or Azure PowerShell within the last 30 days and identifies:

• Whether the account is MFA capable
• Authentication methods currently configured for each account
• Whether MFA was used within the last 30 days for each portal

The MFA gaps workbook may be more to your liking if you prefer to use a Microsoft Entra workbook that leverages a log analytics workspace that has ingested sign-in information. The workbook will provide you information for sign-ins not protected by:

• Applications
• Users
• Operating systems
• Locations

Once you have decided on which tool to assist reporting on identities that are and or not configured to use MFA, you can begin planning your remediation tasks.

What about break glass accounts?

If you’re not prepared, the biggest impact could be to your break glass accounts.

Break glass accounts require special consideration.  These accounts are required during an emergency to access your tenant, and this may be due to several reasons, for example, lost access to global administrator account, or it may be due to a service outage or issue affecting conditional access or an MFA authentication method. Because of this, beak glass accounts need to be treated differently to other accounts to ensure they have access when needed.

If you don’t have break glass accounts or they may be set-up incorrectly, now is the time to get it right before Microsoft enforces MFA and you find yourself locked out of your tenant during an emergency.

There are several steps to making sure your break glass is setup correctly. Our view is that you must have multiple break glass accounts, typically a minimum of 2, with the following characteristics:

• Configured with the default onmicrosoft.com domain to avoid issues with DNS and vanity domains.
• Are not associated with an individual. During an emergency, it may be 1 of several admins required to use a break glass account.
• Use a cloud-based password vault to store break glass account OTP tokens and have a method to access the password vault that isn’t tied to Entra ID SSO.
• Have a well define approval process for accessing break glass credentials, including who can request access, how to validate a requestors identity, and who can approve access.
• Have Physical FIDO2 keys as fall back in the extreme event where your cloud vault is offline, or the OTP MFA capabilities are also impacted in an outage.
• Only use during an emergency, rotate passwords on a yearly basis, or after they’ve been used to access your tenant during an emergency. And test your break glass processes yearly.
• Proactively alert and notify administrators when a successful and failed sign-in attempts are detected.

Time is of the essence

Microsoft has made the right choice to enforce MFA when accessing Azure. Doing so provides a robust security control against identity-based attacks. Hopefully, for many organisations, most identities already have a valid MFA registration and will not be impacted, however, no doubt will be identities that are at risk that require remediation.

Start planning today to ensure you minimise the impact to your environment.

If you need assistance, Arinco can help. With our Security Done Right offering, we work closely with our customers to assess your environment and to implement controls that improve the security of your cloud environment. Reach out to us if you’re interested to hear more.