Emergency access accounts ensure that you are not accidentally locked out of your tenant, by allowing you to sign in as a global administrator and reset the password for another administrator, if that administrator (and every other) is locked out. Creating, configuring and securing your emergency access accounts is a critical preventative step to ensure you are not left in a bad situation where you cannot log in to your environment as an administrator.
Many well-known organisations that provide security benchmarks for Microsoft Entra recommend implementing at least two emergency access accounts, using long passwords and ensuring that the password is securely stored. These organisations include:
- CIS (Center for Information Security)
- NCSC (National Cyber Security Centre)
- Cyber Essentials (UK Gov scheme)
- Microsoft
In this article, I extend these recommendations by taking you through practical recommendations to help protect your environment with emergency access accounts and secure access to each account.
Emergency access recommendations
Each recommendation below may not fit exactly into your organisation, but you should use these as guidelines for what works best for you. Click on any of the links below.
- Create two emergency access accounts
- Naming conventions and password complexity
- Identity sync and domain name
- Setup strong and practical multi-factor authentication
- Limit access to passwords and MFA tokens
- Configure unique Conditional Access policies
- Limit administrative mistakes with Admin Units
- Monitor with Log Analytics or Microsoft Graph
Create two emergency access accounts
I recommend that you create two emergency access accounts in your tenant, this way if one of your emergency access accounts gets lost or compromised, then you limit the risk of losing access to the other (more to follow on that…) and hence access to your tenant. Although these accounts do not need to be licensed, and Microsoft Entra ID (including MFA from an Idp perspective) in this scenario is free, you need to factor in other potential costs, such as physical hardware MFA tokens or added maintenance costs. Here are some scenarios which could necessitate needing multiple emergency access accounts:
- A compromised password
- A lost hardware token
- A destroyed hardware token
- Loss of access to a software OTP token
- Wrongly configured account changes
- Wrongly configured policy changes
- A formal and safe change testing process
Some recommendations in this article do require your emergency access accounts to have a premium Microsoft Entra ID license assigned.
Naming conventions and password complexity
I have bundled the naming convention of the account and also the password complexity into the same recommendation, as ‘security by obscurity’ comes to mind.
Naming conventions can be useful as they can help your team easily identify the purpose of an identity in your tenant. However, naming your emergency access accounts ‘breakglass1@’ and ‘breakglass2@’ will enable anyone to enumerate your emergency access accounts instantly. At the same time, using names such as Greek gods, tv characters or random complex strings will also enable a mediocre attacker to quickly assume and identify the account’s purpose. I recommend generating a random human name and using that for your emergency access accounts.
Passwords for accounts in Microsoft Entra can be up to 256 characters, utilising lowercase, uppercase, number and symbol characters. I recommend you use all the available character types as well as the maximum amount of characters minus a few! This may seem excessive, as at what point can the human brain remember a string and will need to resort to copy and paste… on an alternative note, someone may see a 256-character string and assume it is the password for an emergency access account based on this logic. Reducing the password length by a small but random amount may delay the inevitable, hence security by obscurity, but good practice nonetheless.
Identity sync and domain name
Emergency access accounts should be cloud-only and should NOT be synchronised from your on-premise directory, or any other directory. This is not only true for emergency access accounts but also any account assigned a privileged role in Microsoft Entra. There are many scenarios whereby a compromised Active Directory or AD connect server could lead to the takeover of a synchronised user account in Microsoft Entra. Thomas Nuanheim published a useful GitHub page titled Abuse of Azure AD Connect Sync Service Account which I often refer back to.
As well as ensuring the account is only stored in the cloud, it is just as important to ensure the built-in fallback domain is used in favour of a custom domain for the emergency access accounts. In most cases, the default domain name for your tenant will be a custom domain, this is what will be selected by default when you create your emergency access account. One scenario where you may even need to rely on your emergency access account is if your custom domain expires or gets taken over and you cannot log in to your tenant as an administrator any more. In this case, ensuring your emergency access accounts are configured with the fall-back domain, ensures you can always sign in when needed.
Setup strong and practical multi-factor authentication
Using a strong multi-factor authentication method is imperative to ensuring your emergency access accounts stay protected even if the password is compromised. Microsoft publishes recommendations on which MFA methods are deemed the most secure. Check out the image below!
By taking a pragmatic approach to deciding the right MFA approach, we can rule out some options:
- Windows Hello – This method helps to provide a secure and seamless experience when a Windows device is authenticated by a user. This will not work for emergency access accounts.
- Microsoft Authenticator – This is a mobile app-based mechanism which ties directly to a user’s mobile phone. While an emergency access account could be licensed and signed in to a single managed mobile phone, it is not practical or recommended.
- Certificates – CBA or Certificate-Based Authentication enables users to authenticate with X.509 certificates to Microsoft Entra ID. This requires PKI infrastructure, such as Cloud PKI and a method of deploying the certificate to a device, hence this method is not recommended for emergency access.
Recommended MFA methods for emergency access accounts are:
- FIDO2 security key – A Fido2 security key is a physical device which handles authentication and increases security as no password is exposed or accessed. They are classed as an un-phishable, passwordless authentication device which can come in any form factor. While most commonly being USB keys, they can also use Bluetooth or NFC devices. FIDO2 keys are perfect for emergency access accounts as they are not tied to any person’s personal device and can be physically secured.
- Hardware OTP – hardware OTP tokens are next best as they do not need to be tied to any person’s personal device and can be physically secured like the FIDO2 key. This makes them practical, however, they do require the accounts to be assigned at least a Microsoft Entra ID P1 license. Hardware OTP tokens are less secure than FIDO2 keys as they have a secret key (or ‘seed’) pre-programmed into the device. This secret key must be manually transported and uploaded into the Microsoft Entra portal.
- Software OTP – The most convenient solution for emergency access accounts is to use a Software-based OTP token where the secret key is programmed into a password management tool. This way, the OTP key can be obtained from anywhere, which is the fastest solution if emergency access is needed.
For each emergency access account, you should configure both a FIDO2 key and a Hardware (or software) OTP key for each.
Limit access to passwords and MFA tokens
It is important that after you create your emergency access accounts, you secure the environment where you save the password and/or security keys. For example, if you use a corporate password manager to store this information, you should consider who can access the information within the password manager. As well as this, if you are physically securing hardware tokens, consider who has authorisation to access where they are stored and whether that physical access is correctly audited and monitored.
Overall, if someone were to gain access to a FIDO2 key, which is password-less in design, they may instantly have access to the emergency access account without further challenge. Additional protection in this scenario can be implemented by using location or IP-based Conditional Access policies.
Configure unique Conditional Access policies
Conditional Access policies need to be used to enforce strict control over how your emergency access accounts can be used. In summary, as standard, you should have an individual Conditional Access policy for each emergency access account, each configured to the following standard:
- Membership of each policy targeting a single group, containing a single emergency access account.
- Each policy targeting ‘All cloud apps’
- Each policy requires a specific Authentication strength for your Emergency access accounts.
- Each policy enforces a short sign-in frequency session control.
Further controls can be enforced if necessary, such as:
- Limiting device platforms to Windows only.
- Limiting locations to trusted locations only.
- Limiting client apps to the browser only.
- Blocking authentication flows.
This approach is recommended as it helps reduce the likelihood of an incorrect configuration change completely locking you out of your emergency access accounts. Whereby, if you lock yourself out of one account, you can simply log into the other to resolve the problem.
In the below example I have two Conditional Access policies, one for each account:
Each policy specifically targets a cloud-only security group which contains only that emergency access account.
Limit enumeration of Emergency Access accounts
Early in this article, I talked about reducing the attacker’s ability to identify your emergency access account, by using the name of a standard user instead of a name which can help deduce the account’s purpose. However, in the above step, I added the emergency access user to a security group with a name that identifies its purpose.
Now, as the group is only a security group, it will not be picked up through Exchange and as a standard user, I cannot enumerate the membership through other services like SharePoint online.
However, by default, a standard user could enumerate the membership of the group (or any group) via the Entra Portal, Azure AD legacy PowerShell modules, or the Microsoft Graph API. You should limit the ability of a standard user to enumerate group membership by these methods.
Prevent standard user access to the Entra Portal
From the Microsoft Entra admin center:
- Expand Identity > Users and select User settings
- Set Restrict access to the Microsoft Entra admin center to Yes
Prevent standard user access to Azure AD PowerShell
Using Microsoft Graph PowerShell, first connect to Microsoft Entra and sign-in with a Global Administrator account.
Connect-MgGraph -Scope Policy.ReadWrite.AuthorizationThen run the following command to block the standard user from accessing the legacy PowerShell modules:
Update-MgBetaPolicyAuthorizationPolicy `
-AuthorizationPolicyId authorizationPolicy -BlockMsolPowerShell:$truePrevent standard user access to Microsoft Graph PowerShell
From the Microsoft Entra admin center:
- Expand Identity > Applications and select Enterprise applications
- Search for Microsoft Graph Command Line Tools and click on it
- Select Properties and set Assignment required to Yes
- Select Users and groups and ensure no standard users are assigned
Protect emergency access groups with Restricted management admin units
Restricted management administrative units will allow you to protect your emergency access accounts and related groups from being modified by anyone other than the specific administrator you designate. In this case, you want to ensure that emergency access accounts can not be modified by anyone unless they are explicitly removed from the admin unit.
While a Global Administrator could remove the admin unit that protects the emergency access resources (as mentioned) setting this up will prevent accidental changes from being made by a Global administrator and remove the risk of changes by a User or Group administrator.
Restricted management administrative units require a Microsoft Entra ID P1 license for each administrative unit administrator. This means, that to set this up, you should have a Microsoft Entra ID P1 license assigned to each admin account which you may want to delegate as an administrator for the admin unit (but ideally none). Follow the below steps to setup Restricted management administrative units:
- Log in to the Microsoft Entra admin center
- Expand Identity > Roles & admins and select Admin units
- Click Add
- Define a name and set Restricted management administrative unit to Yes.
- Click Create.
- Open the new admin unit , then on the users tab, add both emergency access users.
- On the groups tab, add both emergency access groups.
Once this is done, any administrator (including global administrators) will not be able to modify properties for emergency access users or groups. I recommend not assigning any administrative roles to this at the admin unit level, that way, the only method for modifying the users or groups would be for a Global admin to first un-assign the objects from the admin unit.
Monitor with Log Analytics or Microsoft Graph
You should monitor for any activity on your emergency access accounts, then in the event activity is detected, send an alert to other administrators to investigate. By monitoring for activity, you can ensure that these accounts are:
- Only used for emergencies
- Not modified in any way
There are two options you can use to monitor for any changes. You can ship all sign-in and activity logs to a Log Analytics Workspace, and then create alerting rules. Or you can deploy a PowerShell script to extract this information using the Microsoft Graph API and have the script run on a schedule.
Monitor with Log Analytics
For this step, you will need an active Azure Subscription as well as a Log Analytics Workspace resource. Follow the below steps to monitor for activity on emergency access accounts using Log Analytics.
- Log in to entra.microsoft.com
- Expand Identity > Monitoring & health and click Diagnostic settings
- Click Add diagnostic setting
- Select AuditLogs and SignInLogs, then set the destination to Send to Log Analytics Workspace and select your workspace
- Now log in to portal.azure.com and navigate to your Log Analytics Workspace
- Expand Monitoring and click Alerts
- Click Create, then from the drop-down list, select Alert rule
- On the Condition tab, next to Signal name select Custom log search and use the following search query: (Enter the object IDs of both emergency access accounts)
SigninLogs
| project UserId
| where UserId == "fa9c0bfd-bfe8-4b2a-a865-54cb0e930b4c" or UserId == "a93d95d8-77c4-4632-805c-0acd7aed5608"9. Leave the Measurement settings as default and set the Alert logs to:
- Operator: Greater than
- Threshold value: 0
- Frequency of evaluation: 5 minutes
10. Click Next to define an action group and select Use quick actions, then define the following settings:
- Action group name: NotifyAllGlobalAdmins
- Display name: NotifyGA
- Actions:
- Email: GA distribution list
NOTE
I do not recommend licensing your Global admin users. Instead, create a distribution list that contains the standard user accounts of the relevant users who can obtain Global administration rights via a separate controlled account.
10. On the Details page, select the Subscription and Resource group for the LAW, then define the Alert rule name and advanced settings as required
11. Click Review + create
Monitor with Microsoft Graph PowerShell
Microsoft Graph PowerShell is a free alternative solution for monitoring account usage. If you haven’t yet installed the Microsoft Graph PowerShell SDK, check my article here.
Start by connecting to Microsoft Graph, with the following command, ensuring that when prompted, you sign in with a Global Administrator account and consent to the requested permissions.
Connect-MgGraph -Scopes AuditLog.Read.AllThe below example code will get all sign-in logs from a specific emergency access account within the last day. You will need to run this twice for both emergency access accounts:
$startdate = $(get-date).AddDays(-1).ToString("yyyy-MM-dd") #yesterdays date
$enddate = $(get-date).ToString("yyyy-MM-dd") #todays date
$Username = "[email protected]" #UPN of emergency access account
Get-MgBetaAuditLogSignIn `
-Filter "UserPrincipalName eq '$username' and `
createdDateTime gt $startdate and createdDateTime lt $enddate"Now that you have defined the variables containing the username of your target account and date range of the search, you can apply this to your directory audit logs too:
Get-MgBetaAuditLogDirectoryAudit `
-Filter "targetResources/any (x:x/userPrincipalName eq '$username') `
and activityDateTime gt $startdate and activityDateTime lt $enddate"Once you have created your script built on the examples above, you can run them on a schedule and have them email your GA distribution group when results are found. Check these articles to automate your script:
Hi Daniel,
Thanks for your awesome article. I’m not sure to understand this statement :
“Each policy requires a specific Authentication strength for your Emergency access accounts.” You mean, for one policy to set fido2 authentication strengh and for 2nd policy CBA auth strengh for exemple ?
Hey! What I mean is, create a single Authentication Strength policy which contains only the methods you allow for your emergency access accounts and apply that policy in your Conditional Access policies.