Emergency Access Accounts for M365

This post will provide an introduction into the world of emergency access accounts, what they are, why you need them and how you can manage them, including the recent recommendations with regards to authentication.

What are emergency accounts?

An emergency account, otherwise known as a break-glass account, is an account that should only be used in case of emergencies. It is designed to be able to provide an 'all-access' account that should be utilised in the event you are locked out via your normal admin credentials.

Why use emergency access accounts?

These accounts should be used in the event of a disaster or outage of any kind causing a lockout to your Entra account. Now, this could be for one of many reasons, a few of them could be in the event of:

• Network outages or faulty hardware
• A service issue outside of your control
• A natural disaster impacting trusted IP locations
• Sudden loss of privileged accounts
• Malicious threats to your accounts
• Accidental impact from configuration changes

The above list is not extensive; these are just a few of the reasons that may cause an impact to service prompting a tenant admin or owner to respond.

Best Practices and Secure Configuration

Emergency access accounts are, by design, excluded from the bulk of our policies and are highly privileged. That leaves the question: How do we make sure they remain secure? Thankfully, there are a few recommendations and steps that can be taken to ensure that these accounts remain restricted whilst being available should the need arise.

• Create two emergency access accounts
• Excluded from the main bulk of conditional access policies
• The accounts should have the global admin role permanently assigned
• Limit the availability of the password and MFA devices
• Configure strong, phishing-resistant MFA
• Enable monitoring and appropriate alerting for usage
• Integrate with disaster recovery plans and perform regular testing

Create Two Emergency Access Accounts

Provisioning two emergency accounts is the recommended approach. This allows for alternating dependencies with authentication to be applied to the accounts to provide a level of control. You should aim to use alternate secure methods to your regular admin accounts.

When it comes to naming these accounts, I've seen multiple approaches and recommendations. Honestly, in my book, if you name it breakglass01 or john.smith it doesn't make any difference. Sure, the latter provides some obscurity, but ultimately your accounts aren't going to be enumerated based on their names—it's their roles that matter. So no matter what you name it, the account will still have the Global Admin role associated.

Your emergency access accounts should utilise the default *.onmicrosoft.com domain name for your tenant and should NOT be federated or synced from any on-premises environment.

Excluded from the Bulk of Conditional Access Policies

These accounts should be excluded from all but a few of your conditional access policies. In an emergency, you do not want a misconfigured policy to get in the way. However, that doesn't mean you shouldn't protect these accounts in some way, shape, or form. For example, maybe you'd want to use conditional access to ensure that the accounts are using phishing-resistant MFA, or potentially you would configure one of the two accounts to only be permitted from office IP addresses, limiting the attack surface.

Whatever the decision, the accounts should be excluded from the bulk of your policies and only specific policies applied, alternating the dependencies of authentication where possible.

Permanently Assign the Global Admin Role

When you need to access the accounts, you don't want any delays, as in most circumstances tensions will be high and there will be a lot going on outside of the technical details. As a result, the accounts just need to work; therefore, permanently assigning the global admin role is recommended.

Limit the Availability of the Password and MFA Device

It goes without saying that any passwords should be unique, strong passwords and kept securely. Ideally, the emergency accounts would be passwordless, removing the need to ever know the password. However, if it's a password or a security key, it should be only made accessible to those people that will truly ever need it! Yes, this probably does mean that the majority of your IT team will NOT have access, but it's important to strike the balance and have it accessible in the time of need!

Configure Strong, Phishing-Resistant MFA

With the recent introduction of MFA enforcement to any user who logs in to the Entra/Azure portals, it is no longer the case that you should exclude MFA from these accounts. Instead, the guidance shifts to enforcing phishing-resistant MFA such as FIDO2-based passkeys and passwordless methods. One of the conditional access policies that would be recommended would be one that enforces a strong authentication type such as the methods outlined above.

Enable Monitoring and Appropriate Alerting

Finally, having adequate alerting and monitoring enabled on the account can help notify you or your security team if the account is being used, from which you can determine if this is expected behaviour or not, allowing you to identify and investigate unexpected activity. At the end of the day, the account should only be used during testing of access or in a real emergency.

Integrate with Disaster Recovery Plans and Perform Regular Testing

Incorporating your emergency access accounts into your overall disaster recovery and business continuity plans is essential. These accounts are a critical component of your organization's preparedness for unforeseen events. By integrating them into your disaster recovery plans, you ensure there is a clear, documented process for when and how these accounts should be used.

Regular testing of these accounts is equally important. It's recommended to perform periodic checks—perhaps every 90 days—to confirm that the accounts are functioning as intended. This includes verifying that credentials are up to date, MFA devices are operational, and access procedures are still valid. Regular testing helps to identify any issues before an actual emergency arises, ensuring that you can rely on these accounts when you need them most.

Documenting the procedures for accessing and using the emergency access accounts, and making sure relevant personnel are aware of them, reduces confusion during high-stress situations. Training the appropriate staff on these procedures will help prevent delays and mistakes during an actual crisis.

Summary

In short, hopefully this post provides an insight into why you should have an emergency access account. Whilst there are other tips and tricks around these accounts, this should provide a starting point to protecting your key accounts so you know they can be relied upon if required. If you need any assistance with your emergency accounts or Microsoft 365 tenant, please reach out and see if we can help.