Update your emergency accounts before October 15th.

Even if you have been out of office for the last couple of months, you should be aware that starting October 15^th you will need to provide Multi Factor Authentication (MFA) to logon to Azure portal, Entra admin center and Intune admin center. This will be enforced to all users accessing these resources regardless of their role or permission level.

Microsoft article: Mandatory MFA for Azure and other administration portals.

Two types of accounts are notably affected by this enforcement:

• Emergency “Break the Glass” accounts.
• Non-personal accounts (NPA). Meaning regular user accounts used by services or applications.

The latter will most likely be affected beginning of 2025. That is why this article will focus on Emergency accounts.

What are emergency accounts?

Microsoft recommends that you set up one or two directly assigned emergency accounts in case you lose access to your tenant for whatever reason. In general, these are the characteristics of emergency accounts:

• Cloud-only accounts which do not have dependencies on on-premises services. It is customary to use the *.onmicrosoft.com domain for these accounts.
• Directly assigned to the Global Administrator role.
• Excluded from almost all conditional access policies.*
• Not assigned to one individual.
• With minimal number of dependencies, including MFA service.

In practice, this was most times achieved by creating an account with a long password which was then split into pieces and given to different people in the organisation and no MFA was configured or required for these accounts.

With Microsoft’s new MFA enforcement, you need a different approach for emergency accounts.

* We recommend creating specific conditional access policies for emergency accounts to compensate for the exclusions.

You need to enable MFA for emergency accounts by October 15^th

In practice, you can choose any MFA method supported by Entra ID for your emergency accounts. But now that you are forced to do it, why not pick a long-term solution?

Phishing-resistant MFA methods are the best solution for securing your emergency accounts and still being able to use them in case of an (ahem) emergency. Other than eliminating MFA methods one by one, I will appeal to the risk-based approach: if you will have an account with direct Global Administrator access, you should protect it accordingly.

From the three phishing-resistant methods currently supported by Entra ID we recommend FIDO2 compliant keys. The reasons of this recommendation:

• Microsoft Authenticator (as sign-in method) and Windows Hello for Business are linked to a specific device which will need to be maintained, updated, and (even if they fit in a safe) how will they remain charged?
• Certificate authentication needs an infrastructure for the trust chain which represents an additional dependency.
• FIDO2 hardware keys are the most cost-efficient solution to protect your emergency accounts.

While you are at it, why not deploy FIDO2 keys for all your administrators? 😊

There are plenty of supported FIDO2 compliant keys available that you can use with Entra ID. Some of them require a PIN or passphrase to activate the cryptographic functions, some are unlocked by Biometrics. This is referred to as “a gesture” that activates the key, and it varies from one vendor to another.

You must be aware that, even if Entra ID now supports device-bound FIDO2 passkeys, this approach is similar to using a smartphone or Windows device which you will need to maintain and keep updated to be used for emergency access when required and, thus, not recommended.

Suggested approach

In the times when a long shared password was used, there was a group of people within the organization, the Quorum, who held the pieces of the password. This Quorum was normally composed by members of the C-Suite, IT and security management. A sub-group of these members was required to get access to the emergency accounts to mitigate the possibility of misuse.

Today, we would leverage the possibility to register multiple FIDO2 keys for one emergency account. These keys should be kept securely (in a safe, for example) and in such a way that prevents one individual from accessing them alone.

There are two viable options:

• Two individuals split the combination to one physical safe that holds one FIDO2 key. Both (or even a third person) hold the “gesture” to activate the key.
• One individual knows the combination of the physical safe and another knows the PIN for the FIDO2 key or has the fingerprint to activate it.

Either option will provide separation of duties. There are many possible deviations from those options, but keep in mind not to place all the responsibility in one person only.

Replicating the setup in another geography or region, will also provide redundancy in case of localized emergency. (i.e. physical safe being inaccessible, faulty FIDO2 key, etc.)

You can decide if you prefer to create only one emergency account with several FIDO2 keys assigned to it, or creating separate accounts for each location.

Ensure you register more than one FIDO2 key to each emergency account you create. It is even better to use different hardware providers to be prepared in situations like the one related to Yubikey’s recently discovered vulnerability.

Pros and Cons

The most obvious inconvenience for the suggested approach is the dependence on a physical key for emergency access. But you should register more than one key for each account, preferably, from two different vendors.

One of the advantages is the number of required emergency accounts. In the past, depending on the type of Quorum, you would need two or more accounts to be set up.

With this new approach, you can easily have only one emergency account with different keys spread in several places. Furthermore, this can be a passwordless account. In fact, it should be!

The reason to create more accounts will be related to administrative and monitoring purposes. Would you prefer to use one account per region, or only one account and monitor the IP originating the login event?

Normally, Microsoft recommends excluding at least one emergency account from conditional access policies. However, since we now know from what specific location these will be used, we can add that information to the conditional access policies aimed for emergency accounts to prevent misuse.

Creating or updating the accounts

These accounts were regularly created during “Quorum” ceremonies where the password was created jointly to ensure no one knew the whole password.

A similar approach can be used today to update them and register the FIDO2 key or keys that will be used to protect the digital identity. Bring in the members of your Quorum and follow how these keys are being registered. As part of the registration process, members should provide the “gestures” to activate the keys: PINs, biometrics or others. In this way, enough transparency will be built into the process.

Make sure you test your accounts in this setting before storing the FIDO2 keys in their safes. This is also the opportunity to test your monitoring and alerting capabilities as described below.

In fact, you should regularly test the whole procedure as part of your incident readiness exercises. And, if any of the persons who hold PINs, safe combinations, or any information related to the emergency accounts leaves the company or switch roles, you should make the necessary adjustments and take the opportunity to test for functioning access. We recommend conducting this review at least twice per year.

Monitoring

The original recommendation included setting up alerts in any login attempt using these accounts. With the recent requirement, you should also add alerts when authentication methods (MFA) are added to the account, or when sensitive activities are conducted by any of the emergency accounts.

You should only expect those alerts to be triggered when you are updating your accounts (i.e. adding new FIDO2 keys), testing them or using them in a real emergency situation.

Bear in mind that these alerts can take some time to arrive. In our experience, there is a gap of five minutes between a successful logon and the alert message.

Conclusion

Clock is ticking! You should update your emergency accounts now, assuming your human administrators are already using (phishing-resistant) MFA.

FIDO2 keys are the most affordable and effective solution to do so. Paired with a sound governance process, you should be able to face the upcoming MFA enforcement without problem.

Don’t forget that Non-personal accounts are next: Azure CLI and Powershell are scheduled to require MFA early 2025. This will potentially be a higher impact since some organizations still use “user” accounts for service or programmatic access to Entra ID and Azure.

Prepare for this upcoming requirement by identifying all of those accounts: you can leverage MFA Insights from Entra ID to identify them. Once identified, you can lay out a plan to migrate them as required (managed identity or service principal).

Related Links

Manage emergency access admin accounts – Microsoft Entra ID