Table of Contents
Introduction: Setting the Stage for Microsoft’s Secure Future Initiative
Security above all else. These words from Microsoft's EVP of Security, Charlie Bell, form the foundation of the Microsoft Secure Future Initiative. Microsoft is no stranger to security incidents, with an internal team dedicated to helping clients when the proverbial "shit hits the fan." This team guides clients through detecting further activity, isolating the threat, and even assisting in fully removing it from their environment.
This team is known as Microsoft Incident Response (MIR), formerly DART (Detection and Response Team). Microsoft customers aren't the only ones who have benefited from the team's expertise. When Microsoft was successfully infiltrated by Midnight Blizzard in January, the MIR team undoubtedly had their hands full. The point is, Microsoft is well-positioned to apply the lessons learned from these major security incidents to improve their customers' methods and practices for securing their environments, which brings us to the Microsoft Secure Future Initiative.
With this new initiative, Microsoft aims to implement security controls across every Microsoft 365 tenant by default. This will be achieved by ensuring that new products and services are designed with a security-first approach or by enabling and enforcing certain protections across all tenants worldwide, with no option to "opt-out."
It’s no secret that simply enabling multifactor authentication (MFA) can significantly enhance an organization's security posture. As highlighted (again) in Microsoft's Digital Defence Report 2023, enabling MFA reduces the risk of compromise by 99.2%. Given this substantial percentage, it’s clear that enabling MFA is crucial for enhancing security, making it something no organization should overlook. This leads us to Microsoft's mandatory Azure multifactor authentication (MFA) enforcement.
For those who might have missed it, the new mandatory MFA enforcement was announced by Microsoft in August. It marks a significant shift in Microsoft's capability and overall leverage within the corporate world to enact real, positive security changes at scale, underscoring the urgency of deploying MFA across your environment.
The potential impacts of this change for organizations are both positive and challenging. Some organizations may be better positioned to quickly adapt to the enforcement, while others with more complex environments may face challenges that concern IT admins regarding day-to-day operations.
The purpose of this article is to provide guidance for organizations that might be struggling to navigate these upcoming changes. By highlighting the relevant topics and areas of concern related to the enforcement, this article aims to ensure that you are confident and prepared for the change without disrupting day-to-day operations.
Auditing your environment
To begin this journey of readiness, we must first understand what will be affected by the change. The enforcement will only impact user objects that directly access certain Microsoft admin portals using specific app IDs. I won’t list the full scope of the enforcement in this article, as many community blogs have already covered this, and Microsoft has its own article that highlights these details.
Thankfully, Microsoft and the community have provided tools to help you better understand which objects in your environment will be affected. I will focus on highlighting these tools and how they can be used for preparation.
Auditing tools
The Multifactor Authentication Gaps workbook is a useful tool for identifying user sign-ins and applications that aren’t protected by MFA. As noted in Microsoft’s article, the workbook:
Identifies user sign-ins not protected by MFA requirements.
Provides further drill-down options using various pivots such as applications, operating systems, and locations.
Offers several filters, such as trusted locations and device states, to narrow down the users and applications.
Includes filters to scope the workbook for a subset of users and applications.
This tool can help you gain a broader understanding of which sign-ins are not protected by MFA on a per-application basis. Since it uses data from your Log Analytics Workspace, it can return insights over a longer period of time.
The second, and likely preferred, method is using the MsIdAzureMfaReport included in MsIdentityTools. This tool provides a list of all user objects that have signed into the affected portals, identifies which portals those users have accessed, checks whether they are MFA-capable, and shows which authentication methods have been registered.
This tool only looks back up to 30 days, and even less (7 days) if you're using Microsoft Entra ID Free. Running the tool regularly up to the enforcement dates will likely yield the best results, making it the easiest way to determine which user accounts will be impacted.
Authentication methods policy: Legacy vs New
One important consideration when preparing for mandatory MFA is the authentication methods that end users are allowed to use. Currently, Microsoft is pushing to migrate from legacy MFA methods to the new authentication methods policy in the Entra portal, which also includes Self-Service Password Reset (SSPR) methods.
To ensure the successful enforcement of mandatory MFA, it is advisable to review the configuration settings related to legacy MFA. For example, if you are using Conditional Access (CA), per-user MFA should be disabled. Using per-user MFA in conjunction with CA can result in multiple MFA prompts, which can negatively impact user productivity and cause frustration. Disabling this feature is a crucial step.
Another aspect to consider is the legacy service settings, particularly the verification methods enabled there. These settings can pose a potential security risk if not properly managed before finalizing the migration to the new authentication methods policy. I’ve seen organizations configure the new authentication methods policy under the assumption that only the methods enabled in that policy are available to users. However, if the migration hasn’t been completed and less secure methods, such as SMS and voice, are still enabled in the legacy service settings, end users might register these less secure methods. This misalignment can introduce new risks to your environment.
As illustrated in the previous images, SMS and voice call are just two methods that have been disabled in the new policy. However, because they are still enabled in the legacy service settings and the migration is in the pre-migration phase, these older settings still apply, meaning users can still register and use these less secure methods.
One of the benefits of moving to the new policy is the ability to scope each method to specific user groups. This means that if you must allow less secure methods, such as SMS—perhaps for users who do not have a smartphone—you can limit these methods to just those users, thereby reducing the overall attack surface and limiting that attack vector. My recommendation, however, is to issue Passkeys (security keys) to those users, as these are phish-resistant and allow you to disable methods like SMS altogether.
Transitioning to the new authentication methods policy ensures that all available methods are consolidated in a single location, and you have the option to limit which users can use each authentication method. Here’s how you can migrate and mitigate these risks.
How To - Migrate to the new authentication method policy
Firstly, make sure that all authentication methods you want to allow, are enabled in the new policy and scoped to the correct users.
Only authentication methods specified in the new policy will now be allowed.
Conditional Access considerations
To facilitate a controlled enablement of mandatory MFA, you will need to enforce it yourself through policy, and this can be done using Conditional Access in a variety of ways, which I’ll briefly discuss below.
Templates
You can use the built-in templates provided by Microsoft to get up and running quickly. The two policies highlighted below would be a great starting point, especially since the second one specifically targets the cloud app "Microsoft Azure Management."
You could further extend this protection to all portals within the scope of the mandatory MFA enforcement by using the "Microsoft Admin Portals" cloud app.
Persona-based framework (Zero Trust Conditional Access architecture)
The gold standard of Conditional Access (CA) policy frameworks is based on user personas. These personas group different types of users based on various conditions related to their workstyle. This could involve whether or not they need to use a compliant device, if they are BYOD-only (or perhaps both!), or if they need access to specific apps. By grouping users in this way, you can create dedicated policies for these different personas, leading to a more manageable and scalable architecture that is easier to troubleshoot and maintain. Here’s an example of what that might look like.
With this approach, you will typically end up with more policies, but they are easier to manage since you are only focusing on auditing a small subset of policies when troubleshooting. While this method may take longer to implement compared to using the template method, it will provide additional value long after the mandatory MFA enforcement, making it worthwhile to invest time in understanding this approach. You can read more about this framework here.
Authentication Strengths
When configuring CA policies to require MFA, you can do this in one of two ways: using the built-in "Require multifactor authentication" checkbox or using Authentication Strengths. The former allows any level of registered authentication method to be used for satisfying MFA. For example, if a user has both a FIDO2 security key and SMS registered, either can be used to sign in and satisfy MFA. However, this isn't ideal since one method is more secure than the other, which is where the latter option comes in.
With Authentication Strengths, it is possible to group different authentication methods together to provide a custom set of allowed methods that can then be assigned to your CA policies. For example, you might decide that any level of authentication method is suitable for a normal sign-in to Microsoft 365, but accessing a highly sensitive SharePoint Online site requires a stronger level of authentication, such as a FIDO2 security key. This is where Authentication Strengths shine. There are also other reasons for using Authentication Strengths, including the capability to require stronger MFA methods, such as FIDO2, for guests when combined with cross-tenant settings. You can read more about this in Fabian Bader’s post on raising the MFA bar for guest users.
Yes, you can (and still should) manage which methods are available to users in the authentication methods policy. However, using Authentication Strengths, we can enhance security by enforcing more secure methods, and it adds flexibility to our policy enforcement. This ties in nicely with the persona-based framework; perhaps you want different strengths for different user roles. The point is, Authentication Strengths should be considered as part of your preparation for mandatory MFA, especially if you want to enforce phish-resistant methods.
Named Locations
Using Named Locations allows you to enforce location-based access controls, such as blocking access from certain countries, or only allowing sign-ins from a trusted IP range. These considerations should be part of any Conditional Access deployment. In the context of this article, they are particularly relevant for reducing the attack surface of emergency access accounts and the protections applied to them while preparing for mandatory MFA.
Some best practices and use cases for Named Locations might include maintaining an allow list of countries. When used in conjunction with the "block" grant control, you can limit where users can access your environment. Or, you may want to allow users to access their corporate emails while away on holiday; having a Named Location with all approved holiday destinations can be used with Conditional Access and Access Packages to provide self-serve access while traveling securely. It is also prudent to only enable the "trusted" checkbox for IP ranges/addresses that belong to the organization. This helps the ML and AI detection tools under the hood better understand what is and isn’t part of your network.
Security Defaults
Security Defaults are primarily intended for tenants that do not have Entra ID P1 or P2 available to them. Security Defaults allow Microsoft to manage certain basic security controls on your behalf, including requiring MFA for all users, blocking legacy authentication, and more. It is generally not recommended for environments where more control is required, which includes most SMBs and enterprise organizations. Simply put, only use Security Defaults if you really have to, but it is an option when preparing for mandatory MFA. You can find out more about Security Defaults here.
External authentication methods
Not too long ago, Microsoft announced external authentication methods in Microsoft Entra ID, which allow you to officially integrate and use your preferred MFA solution within Entra ID. I have not yet had the opportunity to delve into this, but as someone who has worked extensively with Duo, I suspect this new solution will mean that when using Duo for MFA, sign-in activity will now be recognized as multifactor authentication rather than single-factor, which used to be the case. Either way, the legacy method for managing this, called Custom Controls, is not supported for mandatory MFA. Therefore, you must migrate to this new solution to be ready for the enforcement if you are using a third-party MFA provider. Failing to do so could result in issues, such as end users having to register MFA twice, causing confusion and increased helpdesk calls.
Security info registration
Enforcement of MFA means one thing: MFA registration will be required. For the security-conscious, you may prefer to limit how and where users can register their MFA methods. This is particularly useful when building mitigations against AiTM (Adversary-in-the-Middle) attacks, as in the case of a user being compromised, the first thing an adversary might do is register an MFA method to gain persistence. By limiting how users can register their security information, you can provide some protection against this. For example, perhaps users can only register MFA methods from the office IP during onboarding or routine account maintenance, or maybe they can only register security information on a compliant device. However you decide to handle it, this is likely something you will need to consider as you prepare for the changes.
Workload Identities: Migrating from user-based service accounts
To understand this consideration, we must first clarify what a workload identity is. A workload identity is a non-human entity in Entra ID that provides authentication and access to resources for certain workloads, such as apps, services, containers, etc. Workload identities help manage access controls for these entities by applying the same identity governance controls that apply to human users, such as role-based access control (RBAC) and Conditional Access. This approach enhances security by ensuring that only authorized workloads can perform specific actions within the Azure environment, without relying on shared credentials or embedded secrets. These workload identities typically come in the form of either a Service Principal or a Managed Identity.
Service Principal
A Service Principal is an object created in Entra ID that allows authentication and access to Azure resources. It is typically used in scenarios where an application or service needs to interact with Azure resources, such as a custom app or a third-party service.
Service Principals require manual management of credentials (such as client secrets or certificates). The application owner is responsible for storing and rotating these credentials. Service Principals are typically created during the app registration process in Entra ID. Additionally, Service Principals can be used across multiple tenants or subscriptions, making them more versatile for multi-tenant applications.
Managed Identity
A Managed Identity is a feature within Entra ID that allows the creation of an identity object used to enable Azure services to authenticate to other Azure resources without managing any credentials. There are two types of Managed Identities:
System-Assigned: Tied to a specific Azure resource (like a VM or an Azure Function) and automatically created and deleted with the resource.
User-Assigned: Created as a standalone resource that can be assigned to multiple Azure resources.
Because credentials are automatically managed, there is no need for manual credential management, which helps reduce the risk of exposure. Managed Identities are ideal for Azure services running in the cloud, where the identity's lifecycle is tied to the service's lifecycle, providing a more seamless and secure way to access Azure resources. They are typically easier to set up and use because Azure handles the entire identity lifecycle, including the management of credentials.
Key differences / recap:
Credential Management: Service Principals require manual management of credentials, whereas Managed Identities are automatically managed by Azure.
Flexibility: Service Principals are more flexible for multi-tenant scenarios, while Managed Identities are typically used within a single Azure tenant.
Lifecycle Management: Managed Identities have a lifecycle tied to the Azure resource they are associated with, simplifying their management, while Service Principals need to be managed separately.
Why are they important?
This is arguably one of the most important and impactful considerations for mandatory MFA enforcement because many organizations still use user-based service accounts. These are admin-created user accounts, often with an assigned license, that are used for some form of task automation—almost always excluded from, you guessed it, MFA!
These accounts could be used for sending mail on behalf of the organization, authenticating into an app to run a script, or anything similar. The critical point is that if any of these accounts access the affected portals, they will be required to use MFA, which can pose significant challenges for organizations that rely heavily on automation.
What do you need to do?
To be fully prepared for the upcoming changes, it is recommended to audit your environment, identify any user-based service accounts you are using, and begin the migration toward workload identities. This will move you toward modern cloud-based authentication solutions and improve your security posture by moving away from those unsecured user accounts that have been forgotten by everyone for years.
To find out more about Managed Identities in Azure, take a look here.
Emergency Access accounts
Emergency access accounts are like the back door key—the window you purposely keep unlocked just in case you ever lock yourself out of the house. They are your solution to getting back in when the unexpected happens.
Whether it's due to conditional access misconfiguration, account takeovers, service outages, or any other reason, emergency access accounts (also known as break-glass accounts) provide the admin access you need if you ever find yourself locked out of your account or tenant. The big issue concerning them in the context of mandatory MFA is that the long-standing recommendation has been to exclude these accounts from all forms of MFA to avoid any roadblocks when you need to use them. Although there has been some variation in recommendations over the years, Microsoft's current stance is clear: all emergency access accounts should have MFA enabled, period. Consequently, these accounts will be within the scope of this new security feature.
Best practices
I’m not going to go over every best practice for emergency access accounts—others like Daniel Bradley, Jan Bakker, and Merill Fernando have already done an excellent job of that. Instead, I’ll highlight the top recommendations that I consider most important.
The easiest and arguably most secure method is to use a FIDO2 security key for all emergency access accounts. FIDO2 is phish-resistant, easy to manage/store, and more than one key can be assigned to a single user account. However, I've had conversations with clients who face challenges with this guidance. For example, in today’s remote work environment, do you really want to store a security key at every admin’s house? And if a crisis does occur, do you want to spend extra time traveling to the office to retrieve the security key? Probably not. It’s almost akin to the scenario where you split a long password in half and store each half in a separate location or safe—while it looks good on paper, it could cause issues in practice when quick access is needed.
Recommendations
For organizations that share these concerns, I recommend considering all of the above factors and layering them together.
For Emergency Access Account 1: Use authentication strengths that require a specific security key (AAGUID).
For Emergency Access Account 2: Use a password and software OATH token stored either in multiple users’ Microsoft Authenticator accounts or in a password manager, with access only available to those who might need it. Back this up with a named location policy that only allows sign-ins from the corporate IP address or, at the very least, is geo-restricted.
This approach provides the flexibility that may be required within an organization when using these accounts while also ensuring that authentication is secured before the enforcement of mandatory MFA.
Of course, these options are for those who need to consider these scenarios, and whatever solution you decide on should be based on your own risk assessment and specific organizational needs.
Emergency access monitoring
While not directly related to mandatory MFA, an important part of your emergency access strategy is ensuring that you monitor these accounts. They are highly privileged and should only be used in emergency situations; therefore, you should always know when an account has been used. You can set this up with an alert rule in Log Analytics or an activity policy in Microsoft Defender for Cloud Apps.
You can read up more on emergency access accounts here.
Conclusion
I'm just going to say it: preparing for mandatory MFA is not that big of a deal. You should already be working toward enabling MFA for all user objects, and this little push from Microsoft will just help us all get there a bit faster.
The key takeaways from this article should be:
Ensure your authentication methods are correctly configured: Legacy settings can interfere with them.
Use features like authentication strengths and named locations to strengthen the policies targeting your emergency access accounts.
Invest the time before enforcement to review and understand what user-based service accounts you have in your environment, and migrate them to workload identities—this will likely be the most challenging hurdle.
Build your CA policies to match your organizational risk, but keep it practical. If you need to use your emergency access account, consider how long you're comfortable waiting before you can access it. The persona-based framework is your long-term ally.
Audit, audit, audit: You still have time—make the most of it by running reports regularly to ensure all affected user accounts are included.
I decided to jump on the mind map bandwagon, and it really does make it easier to visualize what you may need to consider for this particular task, so I’ve provided one below.
If anyone has experiences to share or any questions to ask, feel free to reach out to me!
Comments