Emergency access setup in Microsoft Entra – 2024 edition

As there are upcoming changes facing organizations starting July 1^st 2024 when Microsoft starts the MFA enforcement rollout for user accounts (including guest users) that use Azure management logins, I thought it would be beneficial to go through the principals for emergency access and also look at how to construct it in the year 2024 aligning with all the latest recommendations. Let’s start!

Setting the goal

In this blog post we will soar through the reasoning of having emergency access. We’ll look at it from different perspectives to make sure everyone understands why it is essential. We will also make sure that even if you already have emergency access setup, you should read this post all the way through to make sure you have everything setup according to the latest recommendations. Then we’ll check how to implement all of this before ending the post in a summary.

Why do we need emergency access?

The main reason for implementing emergency access is that there needs to be a backup plan if administrative access for personal accounts is locked out, for whatever the reason. Companies should have a business continuity plan that prepares for a loss of administrative access for any of their digital environments. There are known scenarios when loss of access could happen and they span from internal mistakes to hostile tenant takeover attempts.

My suggestion is to implement emergency access with love and care and put some thought behind the access recovery processes and documentation. Doing bare minimum to implement might be enough if the loss of access is caused internally. Unfortunately, if there is a hostile takeover and you only have one account that is easily spotted as emergency account and it is not protected with MFA, then you might run out of luck.

• If there’s a misconfiguration in organization’s conditional access policies that locks out administrator access, then more often than not, the impact typically affects a whole lot a other users too. Every hour of work stoppage is of course expensive. If you don’t have emergency accounts to regain access to the tenant, those hours turn to weeks or a month really quickly. Setting up emergency access is “low effort, high reward” in this situation. The risks here are far more severe than the cost of implementing the emergency access.

• If the multifactor authentication method for (Global) administrators has an outage (if it’s reliant on mobile network or software authenticator) and there are no other admins that could assign Temporary Access Passes to you. Of course, the emergency account could have the same broken MFA method, but that’s why it’s recommended to make two or more accounts, all with different MFA methods.

• There might be a situation, especially in the smaller companies, where there are not many administrators. Say, company’s only Global Administrator decides to part ways with the company and there’s bad blood between him and the company or he gets into an accident and is hospitalized and there’s no one else that could suddenly elevate into a global administrator role.

• Hostile takeover example: Your company has decided to use synced accounts for administrative access including your emergency accounts. An adversary randomly, but successfully phishes on of your employees, performs an account takeover and hacks his way into your network, where he moves laterally and does credential dumping after which he completes privilege escalation to domain admin to ultimately gain domain dominance. He decides to disable or hard delete some administrative accounts in Active Directory. Those changes will be reflected in Entra ID either disabling or placing the user account to Entra recycle bin. He changes the emergency account password in AD which is synced to cloud. Your emergency account did not have MFA, so adversary logs in with it to find out that the emergency account has a permanent Global Administrator role. He does not see any other emergency accounts which makes him excited. It is his tenant now, and you don’t have access to the emergency account anymore. You try to reset the password for the emergency account, but the adversary has already enrolled his own MFA method to it and turned off SSPR tenant-wide…Checkmate!

Point being, there are rare events when the emergency access is more valuable than gold. We cannot predict all those rare event beforehand. But we can do our best to protect the emergency account.

Roadmap to secure privileged access

As a reference, Microsoft recommends creating a roadmap to securing privileged access. The reference roadmap has four stages based on their urgency from Stage 1 to Stage 4.

Well guess what? Stage 1 tasks are categorized as critical and should be completed immediately. And as it happens, defining and establishing at least two emergency access accounts belong to the Stage 1!

“But I already have it set up. Why should I reconfigure it?”

If you read the hostile takeover example you might have noticed that one could have emergency access configured and set up, but not all configurations are created equal. Some have more resiliency against attacks than the other. The other justification to reconfiguration is, that if you set it up years ago, recommendations have changed and there is an upcoming change from Microsoft on July 2024, requiring MFA for all user accounts that are about to login to Azure management.

If you’re absolutely 100% sure that your setup is golden, it might be at least good to review the documented process you’ve created for emergency access usage and who has access to the accounts, the process documentation and how is that access assigned and does it have an audit trail? I know that it feels funny to put an intense effort for something that might never happen, but that one time it does happen, you’re going to be so proud of yourself that you have done this the proper way.

How should we design and build it?

Here’s some tips from the official documentation and my personal observations and experiences. There isn’t one exact model that fits all, but there are some guidelines I’d say are critical and should be included.

The implementation workflow:

1. Create a group and assign role to it
2. Create accounts
3. Register authentication methods to the accounts (hardware passkey)
4. Exclude the group from ALL conditional access policies
5. Create custom authentication strength
6. Create special conditional access policy for these accounts
7. Associate custom authentication strength with special policy
8. Add accounts as members of the group
9. Create sign-in alert rules
10. Test your technical setup
11. Document the emergency plan process
12. Authorize and train relevant employees to act upon emergency

Emergency Accounts

How many? You should have at least two emergency accounts. If the company is very large and has operation globally around the world it might be justified to have more emergency accounts to provide emergency access possibility that follows sunlight. Just don’t over do it!

Naming? You can choose account naming according to your company policies, but consider if you want the account name to give away the true purpose of the account or not? If you choose to use arbitrary names for accounts, then also name the security group arbitrary as well.

Domain? Cloud-only? Accounts must be cloud-only and use *.onmicrosoft.com domain, don’t use your custom federated or on-premises synchronized domains. There is no point of having these account in Active Directory, keep them cloud-only.

Password? Generate long passwords at least 40 characters or longer. Store it securely on a paper and put it in the safe. More rigorous version is to split the password in half and store both halves in a different place. Alternatively, don’t store it at all! Later on, you’re going to require FIDO passkey authentication which replaces password. If you need the password, you can reset it. Make sure the password does not expire. If you decide to keep passwords, change them after each use. Also change the password regularly at least once a year.

Security group? Sure, create role-enabled security group which is better secured from membership changes, than regular security group. Assign the Global Administrator role to the group.

Strong Authentication? Enable and configure FIDO2 hardware passkey authentication. It is ideal as it does not need network access and there is no software that could have downtime or be broken. During first sign-in you must setup Microsoft Authenticator and change the initial password before you can register your passkey.

Note! Microsoft recommends to register two different strong authentication methods. There’s nothing wrong with that, but I really don’t see that to be necessary if you use FIDO2 hardware passkey per emergency account.

Monitoring

There are plenty of step-by-step guides to set up the sign-in log monitoring so I will not repeat them here. Here’s a link to Microsoft guide. There are many community guides for doing this as well. I recommend you forward Entra ID sign-in logs to Azure Log Analytics to gain longer log retention.

What else I think should be monitored?

• Membership changes for “Emergency Access” security group
• Emergency Access exclude existence in all other policies, but the Emergency Access policy
• If you have other security tooling where you can tag VIP accounts, emergency accounts should probably be flagged as VIP

These monitoring items might be a topic for another blog…

Conditional Access

Emergency access group should be excluded from all conditional access policies, except the one that is specifically created for them.

Start by creating a custom authentication strength that you’ll associate with the policy. Only check the Passkeys option. Why I recommend to create a separate custom authentication strength and name it “Emergency Access” is that it should make sure that no other admin edits it or associates it to any other policies. Less room for hassle.

Then move on to create a special grant policy where you include only your emergency access group, to require your newly created custom authentication strength and configure session controls:

• Name: “Grant – Emergency Access”
• Users include: “Emergency Access” group
• Users exclude: –
• Target resources: All cloud apps
• Grant: Require authentication strength: “Emergency Access”
• Session: Sign-in frequency: every time
• Session: Persistent browser session: Never persistent
• Enable policy: On

Optionally: You can configure network conditions and device filters, but they are not be necessary as we enforce FIDO2 passkey use which cannot be phished. If you cannot enforce FIDO2 passkey usage, then consider restricting access to known countries or trusted networks. If you have Privileged Access Workstation concept implemented, you might be able to use device filtering to target your PAWs. If you currently require device compliance from admins during sign-in and it is working fine, you can require that also, but I would recommend not to add too many conditions or conditions at all. Be aware that devices can fall out of compliance depending on your compliance requirements and network ranges might change over time and PAW devices have their lifecycle too and all this extra stuff might just end up blocking the access for emergency account.

Process

There should be at least two employees at all times (including seasonal vacations, summertime etc.) that have access to the FIDO2 keys. If you want to rigorously protect the emergency access you might want to keep security key PINs accessible to separate employees, to ensure that no one employee can use the emergency access alone. If you opt for splitting the security key and PIN access to separate employees, you should have two employees having access to the keys and other two having access to the PINs, again, at all times. It goes without saying, but security keys and their PINs should be stored in separate restricted places. A fire should not be able to destroy both keys at the same time, or a thief should not be able to steal the both keys at the same time, you get the point. Same goes with the PINs.

The process of obtaining the access and using emergency accounts should be documented, trained to authorized employees and tested to see if the process works. The access to this documentation should be restricted.

You’re not expressing distrust into your admins, you’re making sure there is a high cost of breach when trying to takeover these emergency accounts. You’re also making sure that any one leaving administrator alone cannot have all the information needed to use emergency account.

Review the process every time when:

• Any of the authorized employees leave the company
• Company moves to a different location
• There is a new authorized employee that also needs to be trained on the process

Optionally, after using a password to login:

• Change the password
• Store password securely and similarly as you did before

Testing

During the setup process test the following:

• Emergency account access to tenant (just to know that it works)
• Sign-in alert and consequent incident handling process specific to your organization and specifications
• Authorized employees access to FIDO2 hardware passkeys and their PINs
• Authorized employees access to the emergency process documentation

Self-Service Password Reset

When emergency accounts are assigned permanent Global Administrator role, they obey a different SSPR rules than regular user accounts. Administrators have a different reset policy which I will link here: Administrator reset policy differences. The following is two excerpts from that documentation:

“The SSPR administrator policy doesn’t depend upon the Authentications method policy. For example, if you disable third party software tokens in the Authentication methods policy, administrator accounts can still register third party software token applications and use them, but only for SSPR.“

“By default, administrator accounts are enabled for self-service password reset, and a strong default two-gate password reset policy is enforced.“

This means that…

• By default SSPR is enabled for emergency accounts (that have permanent GA role)
• By default strong “two-gate” policy is enforced for administrators requiring two pieces of information
• They can register methods for SSPR, even if they are not enabled in Authentication method policies
• Security questions for administrators are not allowed for SSPR
• A tenant administrator (e.g. Global Administrator) cannot change the Administrator Reset policy requirements

However, when I was playing around with Global Administrator account and tested this SSPR, I was repeatedly able to reset the password using only one method!!

EDIT: This seems to affect only Developer Tenants at the moment. 6.6.2024

Even if the administrator reset policy cannot be changed, you are, however, able to disable SSPR for administrators using Update-MgPolicyAuthorizationPolicy Graph cmdlet. Just know that it can take up to 60 minutes to reflect to the user account.

So, should the emergency account have SSPR enabled or disabled

I tried to figure out the pros and cons of each option

SSPR enabled

• Both legit administrators and the attacker can (technically) perform password reset using the emergency account
• If the emergency account does not have any SSPR methods enabled
  • In this situation, SSPR will fail as there are no SSPR methods available
• If the emergency account does have two SSPR methods enabled
  • In this situation, SSPR should work as there are required amount SSPR methods available
  • It is still highly unlikely that the attacker would have access to both methods. Possible sure, but unlikely.
• Is there a use case for the legit admins to enable SSPR and register two methods for emergency accounts?
  • Only, if there is a loss of administrative access AND the account does not have MFA enabled AND there is no CA policy requiring MFA AND the current password is either…
    • Lost
    • Cannot be retrieved, for whatever reason e.g. there are two employees required but the other one is not available
• The above scenario is pretty fu**ed up and hopefully very marginal
• If SSPR is enabled, then I recommend to turn on Notify all admins when other admins reset their passwords to detect if someone is able to reset the password for emergency account

SSPR disabled

• No one can reset emergency account password without administrative access to Entra
• In a lockout situation this should not be a problem for company administrators if they have configured the account to use FIDO2 hardware passkey

Bottom line

• You should always enable and configure FIDO2 hardware passkeys for emergency accounts and require them to be used during authentication. If you do this, and don’t configure any SSPR methods (FIDO2 passkey is not valid SSPR method), it should not matter if the SSPR is enabled or not for emergency accounts.

Password expiration

You should set the password to never expire for emergency accounts. Check the status with Get-MgUser -UserId $uid | Select-Object @{N=”PasswordNeverExpires”;E={$_.PasswordPolicies -contains “DisablePasswordExpiration”}}

To disable expiration: Update-MgUser -UserId -PasswordPolicies DisablePasswordExpiration

Other considerations

It is not recommended to use Privileged Identity Management to make emergency account eligible for Global Administrator role. By removing variables we make the emergency access more assured. By adding more components we add more complexity that might fail or those components’ (like PIM) features and configuration might change over the years requiring you to review your emergency access configuration more often.

There is no need and you should not assign any licenses to emergency accounts.

If you haven’t migrated to converged authentication method policies yet, check that the per-user MFA policy is disabled for all emergency accounts. We only want to control their methods using the converged authentication method policies.

Summary

Emergency access is a vital part of any cloud environment. Think of it like an insurance: if everything goes unexpectedly wrong, you’ll have some access to fix it and save the day. Just remember to calm down, take some deep breaths so that you don’t panic and do anything stupid. It’s good to understand that emergency accounts are one of the most powerful accounts in your tenant, so take good care of monitoring them and making sure the access to these accounts is properly restricted. Don’t forget to create and rehearse the emergency access process!

Stay secure!