09/07/2024 – Update 2

Microsoft enforce since 1st of July 2024 the need for Multifactor Authentication if a account access the Azure Portal. This also affects Break Glass accounts when the will use to access the Azure Portal. To reflect this new requirements classic Breakglass Accounts which only have a password enabled for login will won`t work after the rollout.

Microsoft recommend to use FIDO2 or certificate based authentication for these accounts. I`ve updated the article to enable FIDO2 for Breakglass accounts.

19/01/2022 – Update 1

I´ve updated the article because the actual sign-in query only logs all login attempts of the break glass account (successfully, unsuccessfully, etc.) . I added the different IDs so that you can setup the alert mail based on a indivudal filter. Thank you goes out to Eric Soldierer for this note. I also updated some changed services that had left their preview status.

In the past I do a lot of Azure Governance workshop and one interesting topic is how to handle the Break Glass Account. Before we going deeper, first we take a look was is the Break Glass Account. For each Administrator role in Azure or Office365 is it best practice to use MFA to secure the account and get a better security for the Tenant. To realize this, normally we use Conditional Access and create a rule, that every Admin require MFA for login. But what can we do, when:

• the MFA service is down
• we create a Conditinal Access that with a wrong rule set and lost sign-in access
• we do not regulary update our control list and the admin account goes lost

For this cases we need a Break glass account, an additional account with a high security password, to enter the Tenant in an emergeny case. For this account, there are some recommendations:

• only use a generic account
• create a complex password with more than 16 characters
• use a seperate FIDO2 key for every breakglass account
• up to 256 characters possible – the limit of 16 character is removed
• for compliance reason divide the password into two parts
• save each part in a different location
• create a security group that contains the break glass accounts
• create two break glass accounts with no standard username like breakglass@ or emergency
• use the Tenant name for the account
• do not use a custom domain name
• in futher it will be possible to use FIDO2 security key for break glass (right now is in preview and not recommended for such critical scenario)

Now we can discuss in some ways a security gap – a service account with Global admin rights that do not require MFA for login. The use of a generic name can be a risk and the usage of this account most be transparenet for every tenant admin. Now you see, why it is so important to monitor this accounts and get notified when they will be used for login.