Introduction

In case you missed the update about the new announcement Microsoft is tightening security around Azure and Microsoft admin portals, by enforcing multifactor authentication (MFA) for all interactive sign-ins. This change has sparked a lot of questions across social medias, and in this post, I aim to address these questions to the best of my ability 😉

Please mark your calendars and make the necessary reminders – as of 15 Oct 2024 this is the start date when the changes will start rollout worldwide – so in less than two weeks, all Azure administrators must use two-factor login!

Many enterprises globally, including our clients, need to review their security configurations in light of the recent mandated MFA enforcement on many Microsoft portals. It’s likely that this announcement has made you take a closer look at how to successfully secure your tenant.

We will outline our own security enhancement efforts for my renter in this piece. These are doable actions you can take to remain ahead of potential risks in light of the new enforcement, from setting up break glass accounts to enrolling a FIDO2 key. (And yes, it is strongly advised that you open two break glass accounts for your tenant—at the very least!)

Please check out my post about to be notified when someone login with your break the glass account(s):

Break Glass account – and how to get notified when a Break Glass account is used

Mandatory MFA enforcements – why?

Back in November 2023, Microsoft launched there Microsoft’s Secure Future Initiative (SFI) – One of the key actions in this is to ensure that Azure accounts are protected with securely managed, phishing-resistant multifactor authentication (MFA). Unfortunately, way too many accounts remain unprotected even today, making them prime targets for hackers. MFA is, among other things, an improvement of security because a large number of the cyber attacks that are currently taking place all over the world are due to reused passwords, where the hackers find leaked passwords on the web and use them to log in. Two-factor or multi-factor would stop these attacks. Implementing MFA can prevent or significantly slow down about 99,2% or more of attacks.

Mandatory MFA enforcements – now what?

In line with this, Microsoft´s recommendations around these accounts has been updated with the following note at there website:

Starting July 2024, Azure teams will begin rolling out additional tenant-level security measures to require multi-factor authentication (MFA) for all Users. As already documented use strong authentication for your emergency access accounts. We recommend updating these accounts to use FIDO2 or certificate-based authentication (when configured as MFA) instead of relying only on a long password. Both methods will satisfy the MFA requirements. – Microsoft Learn

Based on the updated guidance, all tenants should consider enabling FIDO2 or certificate-based authentication (CBA) for emergency access accounts. I personally prefer using a FIDO2 hardware token, as it can be physically secured in a safe location.👌😎

What type of accounts and actions will be affected and how?

Microsoft will enforce multifactor authentication (MFA) for all sign-in attempts. This specifically applies to all management tools used to manage Azure resources, Microsoft 365, and the Graph API.

• Your emergency-access account(s) (aka “Break-glass”)
  • If you don’t have this account in your tenant, stop now and set it up with monitoring and alerts! This account, your backup in emergencies, will require MFA starting October 15th. Be sure to test it regularly (every 90 days is recommended by Microsoft). I highly suggest securing it with physical FIDO2 keys.
• All users, regardless of their RBAC role, who log in to the applications listed below and perform any Create, Read, Update, or Delete (CRUD) operations.
• User identities that sign in as “service accounts” to run automation (username/password), including scripts or other automated tasks, as well as break glass or emergency access accounts.
  • MFA will be required here as well
  • Use service principals and managed identities as workload identities, as they won’t be impacted by this enforcement.
• Privileged Identity Management (PIM) to delegate roles?
  • MFA will now be required to log into entra.microsoft.com and activate roles. Hopefully, you’re already using MFA for role activation, so this won’t be an issue. If not, this is critical—these roles MUST be protected with MFA!

Here’s the entire list with resources that are impacted:

Application name	App ID	Enforcement phase
Azure portal	c44b4083-3bb0-49c1-b47d-974e53cbdf3c	Second half of 2024
Microsoft Entra admin center	c44b4083-3bb0-49c1-b47d-974e53cbdf3c	Second half of 2024
Microsoft Intune admin center	c44b4083-3bb0-49c1-b47d-974e53cbdf3c	Second half of 2024
Azure command-line interface (Azure CLI)	04b07795-8ddb-461a-bbee-02f9e1bf7b46	Early 2025
Azure PowerShell	1950a258-227b-4e31-a9cf-717495945fc2	Early 2025
Azure mobile app	0c1307d4-29d6-4389-a11c-5cbe7f65d7fa	Early 2025
Infrastructure as Code (IaC) tools	Use Azure CLI or Azure PowerShell IDs	Early 2025

What type of accounts will not be affected with MFA enforcement?

End users who access applications, websites, or services hosted on Azure but do not sign into the specified applications are not required to use MFA. In these cases, access will be managed by the website or application itself.

Additionally, workload identities, such as managed identities and service principals, are not impacted by MFA enforcement.

The sections that follow are taken straight from the Microsoft documentation:

A workload identity is an identity you assign to a software workload (such as an application, service, script, or container) to authenticate and access other services and resources. The terminology is inconsistent across the industry, but generally a workload identity is something you need for your software entity to authenticate with some system. For example, in order for GitHub Actions to access Azure subscriptions the action needs a workload identity which has access to those subscriptions. A workload identity could also be an AWS service role attached to an EC2 instance with read-only access to an Amazon S3 bucket.

A Workload Identity is an identity that allows an application or service principal access to resources, sometimes in the context of a user. These workload identities differ from traditional user accounts as they:

• The multifactor authentication cannot be completed.
• have explicit lifecycle processes infrequently.
• need to store passwords or secrets in a secure location.

Using Workload Identities for Service Accounts is advised since they are a more up-to-date method of correctly handling identities and won’t be impacted by enforcement.

But it takes time to complete this process. Prior to doing anything else, ascertain which automation, services, and apps depend on Service Accounts and whether they are exempt from the MFA policy.

See out upcoming blog about this topic 👌

How do we know – notifications

Microsoft will notify all Global Administrators through various channels, but it never hurts to spread the word yourself. I recommend forwarding this post to your IT manager and co-admins, as the official notifications might not fully capture the attention of your (often busy) IT colleagues with Global Administrator roles assigned.

The first notifications are already starting to roll out and you can see them in Microsoft 365 message center.

A message appears in the Microsoft 365 Message Center, providing the same information as the email and service health notification.

It´s send out around 15 August 2024 from o365mc@microsoft.com and looks like this if notifications is setup:

A good friend at Microsoft, Merill Fernando (Principal Product Manager @ Microsoft Entra), has a great website with an archive of all messages from the Microsoft 365 Message Center. You can find it here:

Microsoft 365 Message Center Archive (merill.net)

Azure/Entra Portal notification

When users sign in, a notification appears in the Azure portal, Microsoft Entra admin center, and Microsoft Intune admin center. This notification includes a link to more information about the mandatory MFA enforcement.

How to prepare for this major change

In short, make sure to do your due diligence, inform your stakeholders, and ensure your organization is prepared for the upcoming changes. Identifying your current MFA usage is crucial in this process! 🗝️🔒🔓

Conditional Access policy

Have you deployed a Conditional Access policy for the App Microsoft Admin Portals? If yes, you’re in luck! This policy covers the impacted admin portals. If it’s set with MFA requirements, you can review any exclusions from this policy and address them first.

If you don’t have a policy like this deployed: we suggest you create one now. Just do the 4 settings here and you are covered for this part:

• Users: All users
• Target resources: Select Cloud apps and Select Apps and select Microsoft Admin Portals
• Grant: Require MFA
• Enable policy: Leave it at Report-only

Entra ID reports

This is a great starting point to analyze and understand the sign-in patterns of your accounts in your organization 👌

To get started, navigate to the Entra portal and follow these steps:

• Go to Users > All users > Sign-in logs.
• Apply filters for Application and Authentication requirements.

(Here is a direct link: Users – Microsoft Entra admin center)

Refer to the example below for guidance on setting these filters.

Entra ID Diagnostic Settings

If your Diagnostic Settings are set to send SigninLogs (NonInteractiveUserSigninLogs is not needed to check this) to your Log Analytics workspace, you can easily view the results using Conditional Access – Insights and Reporting, the Multi-Factor Authentication (MFA) Gaps Analyzer Workbook can be a valuable tool for your investigation process – and it´s just works!

You can access the workbook here: Multi-Factor Authentication Gaps Analyzer Workbook.

To run your queries effectively, use the following application IDs to filter for the right data you need:

Application name	App ID
Azure portal	c44b4083-3bb0-49c1-b47d-974e53cbdf3c
Azure CLI	04b07795-8ddb-461a-bbee-02f9e1bf7b46
Azure PowerShell	1950a258-227b-4e31-a9cf-717495945fc2
Azure mobile app	0c1307d4-29d6-4389-a11c-5cbe7f65d7f
Microsoft Entra admin center	c44b4083-3bb0-49c1-b47d-974e53cbdf3c
Microsoft Intune admin center	c44b4083-3bb0-49c1-b47d-974e53cbdf3c

These IDs will help you filter and analyze the data specific to each application, aiding in your overall assessment and response.

Entra ID Insights and reporting

In the Conditional Access window, go to Insights and reporting on the left side. Select your Conditional Access policy and choose a time frame. As shown below, I have one user who would have needed to take action (in this case, register MFA) if the Conditional Access policy had been enabled.

Scroll down the page to view more details. Sample account here accessed the admin portal, showing a reportonlyinterrupted status, as shown in the screenshot below. If MFA had been used, the status would have been reportOnlySuccess Therefore, I need to check if your account support MFA.

If you don’t have access to Log Analytics or a similar service, this method may not be very efficient. However, you can still use the What If button in Conditional Access to manually check if this rule affects users’ logins. Additionally, you can review the user’s sign-in log in Entra ID, where the “report-only” list will provide an estimated result.

Microsoft have a small PowerShell Module to give a kind of the same overview too here: AzureAD/MSIdentityTools (github.com)

Install-Module MsIdentityTools -Scope CurrentUser

Connect-MgGraph -Scopes AuditLog.Read.All, Directory.Read.All, UserAuthenticationMethod.Read.All

Export-MsIdAzureMfaReport .\MFAreport.xlsx

Requires PowerShell 7.0

PowerShell script for reporting and email reports

There is a PowerShell script provided here, to help identify users affected by MFA enforcement, and it´s support automation and email reporting (and Managed Identity support for etc. Azure Automation Runbooks), so you can setup a task to run it every day or so if you need to get reports on this along the way👌

Script requirements

The script needs the following Microsoft Graph permissions as this blog is created:

•  AuditLog.Read.All
•  Directory.Read.All
•  UserAuthenticationMethod.Read.All
•  Mail.Send

The script also requires the following PowerShell modules to be installed (tested with v. 2.19):

• Microsoft.Graph.Authentication
• Microsoft.Graph.Beta.Users
• Microsoft.Graph.Beta.Reports
• Microsoft.Graph.Reports

Arguments supported in script

• useManagedIdentity: Use managed identity to connect to Microsoft Graph.
• attatchExportedCSV: If set to add attachment to the email, send it also.
• debugOutput: If set to true, the script will output additional debug/output information.
• daysToCheckLogs: Number of days to check for sign-in logs (default is 90 days).
• enforceYears: Years when MFA enforcement is planned. The default values are “2024” and “2025”.
• emailTo: Email address to send the report to.
• emailFrom: Email address to send the report from.
• emailSubject: Subject of the email. The default value is “MFA Enforcement Report”
• emailBody: Body of the email. The default value is “Please find the attached MFA Enforcement Report.”

You find the script here: public/EntraID/MFA/Get-MFAEnforcementReport/Get-MFAEnforcementReport.ps1 at main · mindcore-tech/public (github.com)

Sample reporting

Output looks like this from demo tenant data:

The email report there is send if any hits, provides the current status of Multi-Factor Authentication (MFA) enforcement across Microsoft enforced portals for your tenant (with an option to get the raw data in .csv files attached too! 😉).

The report highlights users who are either missing MFA setup or whose devices are not capable of setting up MFA and the last sign-in time and non-interactive login.

If needed, you can run this as a scheduled task in etc. an Azure Automation Runbook and get the last report right into your mailbox!

Recommended action and next step

Now that we’ve identified the accounts likely to be affected, let’s address the necessary changes – as that is a need to stay secure and you are able to sign-in.

Enable the Passkeys feature in Entra ID

If you are unsure if Passkey is enabled or not for you tenant, visit the Entra ID Portal under Entra Portal > Protection > Authentication Methods > Policies > Here set the enablement to Yes. Here select a test group or all uses.

Now we can go to the Configure tab, as we here have an option to setup and set what types of Passkeys is valid to use and setup. This should be set to Yes if your organization wants to ensure that the FIDO2 security key model or passkey provider is authentic and sourced from a legitimate vendor

Set this to Yes if your organization needs to control which security key models or passkey providers are allowed, based on their Authenticator Attestation GUID (AAGUID). To configure specific vendors or models for Passkeys, you can work with your security key vendor to obtain the AAGUID. If the passkey is already registered, the AAGUID can be found in the authentication method details for the user.

Now when you have added your AAGUID’s as shown here press Save.

Enable MFA for your tenant

Microsoft Entra ID P1 or P2 licenses can easily enable multifactor authentication through Conditional Access. Microsoft has simplified the process by offering a template that can be activated with just a few clicks.

I love the available templates because they are very useful for many organizations in establishing a baseline to secure their environment!

I highly recommend securing Azure management with MFA and enforcing strong, phishing-resistant authentication for all administrators.

Require MFA for Azure management with Conditional Access – Microsoft Entra ID | Microsoft Learn
Require phishing-resistant multifactor authentication for Microsoft Entra administrator roles – Microsoft Entra ID | Microsoft Learn

Organizations with Entra ID Free can easily enable Security Defaults to protect all users in their tenant.

Enable MFA for your identified accounts

In the Entra ID portal, you can quickly check a user’s MFA capabilities by selecting the user account and clicking “Authentication methods” on the left. You may see a banner suggesting the “new user authentication method experience” (if you haven’t used it before). We highly recommend using it, as it offer a much better experience and support the new types of MFA (still not know why it´s there – but it is 😂)

You can still switch between the old and new experiences at any time with a single click if needed 👌

In the new experience (see picture below), it’s clear that this user account has no MFA methods available and will be unable to log in after October 15 until an MFA method is registered!

Entra ID Portal – Authentication methods

In Entra ID, go to Authentication methods > Activity to see summaries, with the first one showing the number of users without MFA capabilities

Click on XX% of your organization isn’t capable, and this to open a window listing non-MFA capable users.

Overview of the types of reports:

• Users capable of Azure multifactor authentication: Users registered and enabled for a strong authentication method in Microsoft Entra ID. Either a user or an admin may register an authentication method on behalf of a user. Authentication methods are enabled by authentication method policy or multifactor authentication service settings.
• Users capable of passwordless authentication: Users capable of passwordless authentication: Users registered and enabled for at least one of the following passwordless authentication methods: FIDO, Windows Hello for Business, or Passwordless Phone Sign-in.

Plan and test your changes for your break the glass accounts

Finally, I’ll show you how to quickly set up MFA for your break the glass account(s). This account is crucial as it provides emergency access to your system if you’re unable to access your tenant through your regular methods. Lockouts may happen due to misconfigured Conditional Access policies or technical issues within the tenant’s environment.

Break Glass accounts are managed differently from standard admin or user accounts. Traditionally, the goal was before to keep MFA disabled for these accounts to ensure that the right people could access them during an emergency and the information was kept in etc. a safe at the office – My preference is a FIDO2 hardware token as they can be physically secured in a safe location.

However, with the new changes here, break the glass accounts will also be subject to MFA policies, so it’s time to update their configurations 🔐

Microsoft and we recommends two methods for securing break the glass accounts: Certificate-Based Authentication (CBA) or Passkeys using FIDO2. I will focus on setting up a FIDO2 physical key, as it is generally easier to configure and I have a few of them!

Why the use of FIDO2?

FIDO2 is a strong, phishing-resistant authentication method that offers enhanced security. A key point often overlooked is the strength of MFA methods and their dependence on specific services. The illustration from Build resilience with credential management in Microsoft Entra ID – Microsoft Entra | Microsoft Learn shows that a FIDO2 key is a robust choice for securing your critical break the glass accounts, even though it doesn’t show the user’s device.

Here’s how it works

When you register with an online service, your client device generates a new cryptographic key pair. This key pair is unique to the service’s domain. The private key remains securely stored on your device, while the public key is registered with the online service. These cryptographic key pairs, known as passkeys, ensure that each service you use has its own distinct set of keys, making it much harder for attackers to compromise your accounts through phishing.

Break the glass account guide offers two approaches to securing these critical accounts. One option is to create a long, complex password, split it into two or three parts, and store each part in separate, secure locations like fireproof safes. The alternative, and what I recommend, is to use a FIDO2 security key, which I will demonstrate below. If FIDO2 is not enabled, the account will eventually be captured by MFA enforcement, so it’s crucial to implement this method promptly to maintain secure and uninterrupted access

How to setup your FIDO2 key on your break the glass account

Register FIDO2 key

Now for the important part—it’s time to test your break the glass account. Make sure it works before you find yourself in a critical situation. While you can always reset it if needed, it’s better to verify now to ensure you can log in when things really matter! 🤣

But the easiest way to manage a non-personal account like this is to use a Temporary Access Pass (TAP). TAP is an MFA method designed specifically for setting up other MFA methods and is often referred to as a bootstrap method.

Now go to the user´s page for your break the glass account and select Authentication methods, then Add authentication method choose Temporary Access Pass and click Add on the following screen.

You’ll now see the Temporary Access Pass (TAP). Be sure to copy it, as it won’t be retrievable later. You’ll also receive a direct link for registering MFA. Note that this TAP is for one-time use only!

To register your key, we need to sign in to your break the glass account at https://mysignins.microsoft.com/security-info or via https://aka.ms/mysecurityinfo. Use the username like normal and then the TAP – please note that the TAP can´t be used like a normal password as shown here – you need to use the Use your Temporary Access Pass instead.

On this following page, select the option to “Add sign-in method” and then choose “Security key,” as shown here:

Click then on Add. On the next page, select the security key type as shown here – for this test, we select USB device:

In the pop-up window, select Security key to begin setting up your key. Ensure that the key is inserted into your computer before proceeding.

The security key will guide you through the setup process on your computer (yes, its suuuper easy .😉), including steps like setting a PIN for the key and touching the key to confirm your physical presence.

Finally, assign a name to the key and click Next to complete the setup! 👌

Now your done! 🗝️

Signing in with a FIDO2 key

When logging into a portal, select Sign-in options and you are directed to the screen shown as here – no need to enter your username!

Select Face, fingerprint, PIN, or security key.

Now select which device to log in with, a Security key in this instance. Click Next and enter your PIN.

Now you see a list of accounts/users stored on your FIDO2 key is displayed here, and we can choose which one to sign in as and press “OK” in the bottom.

And after this, you’ll be logged in, ready to perform tasks with your account/break the glass account(s) – remember that break the glass account(s) should only be used in an emergency! 😉

Request more time to prepare for enforcement in your tenant (but not recommended)

Microsoft recognize that some customers might need more time to prepare for MFA requirements. Microsoft offers a grace period for those with complex environments or technical challenges.

From 8/15/2024 to 10/15/2024, Global Administrators can extend the MFA enforcement start date to 3/15/2025 via the Azure portal. Elevated access is required to make this request.

Global Administrators need to adjust the enforcement start date for each tenant individually.

Conclusion

As we’ve explored, the recent MFA enforcement changes from Microsoft are a significant step towards securing your Azure and Microsoft 365 environments. Understanding which accounts are affected and taking proactive steps to secure them, particularly your break the glass accounts, is crucial. By leveraging tools like FIDO2 security keys and the Microsoft Identity Tools PowerShell module, you can ensure that your organization is well-prepared for these changes.

Remember, these measures are not just about compliance – they’re about protecting your organization from increasingly sophisticated threats. Taking the time now to secure your accounts will pay off in the long run, especially in critical moments when security is paramount.

Stay proactive, keep your stakeholders informed, and make sure your security measures are up to date. With the right preparation, you can navigate these changes smoothly and maintain a secure environment for your organization.

Keep users and data safe by setting up MFA with etc. the MFA wizard for Microsoft Entra and learn more from the MFA deployment guide. If you’re using user identities for automation, start the process of migrating to managed identities or service principals.

References

Update on MFA requirements for Azure sign-in – Microsoft Community Hub

Announcing mandatory multi-factor authentication for Azure sign-in | Microsoft Azure Blog