This is how to keep your emergency access account in order

Entra ID is, as you know, your identity provider and all logins and access are tied into this. Therefore it is a vital part of our job to keep it secure, but available for our users and resources when needed. But there are several scenarios where we or the users can be locked out from Entra ID and therefore not able to log in and access resources. This can be misconfigurations (we are humans and we make mistakes), technical issues or a bad actor can be the reason.

When (not if) this happens, it is absolutely crucial that you have a way to gain access to Entra ID so you can remedy the situation! This is why I want to write about “emergency access accounts“, also known as “break-glass accounts“.

EDIT: Some feedback I received on LinkedIn and wanted to add here

From Jan Bakker (Jan Bakker | LinkedIn):

Tip on the Urgency of Testing:

Make sure to test during high-demand periods such as summer holidays and Christmas. Disasters don’t wait for convenient times—it’s crucial to ensure your system is resilient when the team may be unavailable, not just when everyone is comfortably sipping coffee in the office on a sunny day.

I 100% agree! “Disasters don’t wait for convenient times” is an excellent statement.

From Kavya A (Kavya A | LinkedIn):

1.The account must be cloud-only account.
2.Must use *.onmicrosoft.com to prevent domain-based access issues.
3.Provide unusual name for break glass accounts.

I absolutely agree on 1. and 2. and that really should be in my original post. Regarding the names I’m not so sure. On one hand, naming them things like “emergencyaccess@…” can draw unwanted attention, but a determined attacker are likely to identify break-glass accounts regardless of their names. While it is a worthy and interesting discussion I think we agree that very long and complex passwords, combined with FIDO2 and proper monitoring (with alerts) will be a much better way to protect them.

However, thank you for your feedback! I really appreciate it ❤️

What is a “break-glass account”?

To make sure we have common understanding: A break-glass account is a special admin account in Entra ID which is reserved for emergencies, like when your regular admin accounts are locked out or an unforeseen issue blocks access. These accounts come with Global Administrator rights and are strictly for “break glass” moments, not everyday use. Keep them secure, with super-strong passwords and no fancy policies (like MFA) that could lock you out of even these accounts (more on that in a moment). Think of these accounts like smoke detectors or life insurance: You don’t want to need it, but when the s**t hits the fan, you’ll be so glad that you have them.

One thing I’ve noticed about break-glass accounts is that the recommendations about their setup have changed a lot over a relative short time. This is not at all surprising since IT and cloud-computing changes very rapidly, but it does mean that your own setup and routines around break-glass account may be obsolete and you should definitely read up on the more updated recommendations and adjust your setup accordingly.

So what are the recommendations for break-glass accounts?

Here’s the short summary:

  • Secure them as much as possible
    • They must be Global Admin, permanently assigned
    • Use very long and complex password – which do NOT expire
      • The maximum password length is 256 characters so you can go really long!
    • Secure each account with at least 2 dedicated FIDO2 keys
    • Monitor for login: If these accounts log in it should trigger a critical alarm
  • Avoid any and all single point of failures!
    • Have at least 2 accounts
    • Have at least 2 dedicated FIDO2 keys for each account
    • If possible: Place the keys (and their PIN codes) in fireproof and tamper-proof safes. Ideally, these safes should be in geographically separate, secure location
      • Keep geography in mind: Is your IT staff distributed over several locations/cities? Make sure you distribute accordingly
  • Have as few dependencies as possible
    • Avoid ALL person-specific dependencies.
      • No fingerprints or other biometrics
      • No mobile phones
      • No single-person dependency to access FIDO2 keys, their PIN codes or similar.
    • Rely on as few solutions and/or infrastructure as possible
      • No Conditional Access rules
      • No PIM
      • No device filter or dependencies on specific devices
      • Don’t depend on mobile network, SMS messages etc
  • Document the process thoroughly
    • Create and maintain clear documentation outlining when and how to use the emergency accounts and who is authorized to access them
    • Ensure this document is securely stored but easily accessible to authorized personnel
  • ‼️Simulate failure scenarios‼️
    • This is where, in my experience, most people go wrong. They assume too often that “it worked once, so it should be ok”.
    • Regularly conduct drills or exercises simulating scenarios where the break-glass account would be needed, to ensure the process works smoothly under pressure. Train all your IT staff for this situation!
    • Use these drills actively to find improvement areas to your current documentation and process, and make changes accordingly
    • Microsoft recommends you do this:
      • At least every 90 days
      • When there has been a recent change in IT staff, such as after termination or position change
        • This applies to third-party suppliers or consultants with administrative access
      • When the Microsoft Entra subscriptions in the organization have changed

Why Testing Every 90 Days is Crucial!

In both my own experience and that of some of my colleagues, one of the most common mistakes is failing to test these break-glass accounts regularly. Testing your emergency access accounts every 90 days is not just a recommendation—it’s a critical safeguard against unforeseen risks. IT environments evolve rapidly, with frequent updates, staff changes, and emerging security threats, all of which can compromise account reliability if left untested. This is why these accounts MUST BE TESTED REGULARLY! When the unexpected happens, it is not the time to troubleshoot why your break-glass account doesn’t work as intended. Don’t fall into the same trap as so many before you, but commit yourself and your team to regular testing. It doesn’t take much time, but it can truly be a lifesaver!

Some nitty gritty details..

Why FIDO2?

As of October 2024, Microsoft started to automatically require MFA on admin portals, so we have to use MFA on these accounts but we still want as few dependencies as possible. Among the options available Physical FIDO2 keys are simply the superior choice and I will now explain why:

⛔Any MFA method involving a mobile phone creates a dependency on the phone (which is normally a personal device), Azure MFA services and phone carrier signal/ internet connection.

⛔Password+ hardware/software token OTP also depends on Azure MFA services.

✅Only Certificate based authentication (CBA), Windows Hello for business (WHfB) and FIDO2 keys depends only on the Entra Auth Service to work.

CBA will need to be set up with self-signed certs to avoid dependencies on external CRL and you will need a smart card with a smart card reader or similar solution to store the certificates.

WHfB requires a device to be enrolled and updated and creates a potentially very large dependency on this. So it is not very suited for this use case.

✅So FIDO2 keys are not only one of the best and phishing resistant MFA methods, but it also is the one with fewest dependencies, which is really important for break-glass accounts.

🚨Keep in mind that FIDO2 keys should be secured using PIN codes, so how should these be handled? These codes are vital in order to use the FIDO2 keys, and must be available yet kept secure. Here you can either write them down and store them in secure safes, or store them in some password manager. I do however think that a password manager will introduce another dependency (and we still want as few of them as possible). But this depends largely on which options you have available.

Striking a balance between security and accessibility is essential

This can become very complicated and it’s difficult to give detailed recommendations since all companies are different with different resources and needs. Also I never think one size fits all, and in order to have good security there must be some adaption to the company, and the company must also adapt some for the security measures.

Let’s imagine your company has two locations, Oslo and Stockholm, and you’ve got two break-glass accounts with two FIDO2 keys each (four keys total). It makes sense to spread the keys out. This way, each location has one key for each break-glass account. That way, no matter where the crisis hits, staff in either location can step in and access the accounts quickly. It’s all about avoiding dependencies.

Thank you copilot for making me this nice ascii drawing to illustrate:

                   Company: Break-Glass Account Setup
---------------------------------------------------------------------
| Break-Glass Account 1 |
|-------------------------------------------|
| Break-Glass Account 2 |
---------------------------------------------------------------------

Oslo (Location 1)
--------------------------------------------------
| FIDO2 Key 1 (Account 1) | FIDO2 Key 2 (Account 2) |
--------------------------------------------------

Stockholm (Location 2)
--------------------------------------------------
| FIDO2 Key 1 (Account 1) | FIDO2 Key 2 (Account 2) |
--------------------------------------------------

A real-life example

From my own personal experience I will never forget the MFA outage in November 2018.

I had just spent a considerable time and effort to convince a customer that while MFA may seem cumbersome for some users, it is an absolutely vital part of keeping your accounts, and access to your data secure. So, a little reluctantly, they were in the process of enforcing MFA to all accounts, also while working from their company network (where they really thought MFA was unnecessary).

Then, about 2 weeks into the implementation, Microsoft had a global MFA outage and in order to let people sign in, admins had to temporarily remove the MFA requirement. 😱 We did not have a dedicated break-glass account at that time, but “fortunately” one of the admins had gone rogue and had previously removed his account from the Cond.Access policies because he thought MFA was just nagging and provided little to no safety. So his account became our substitute for a break-glass account so we could remove MFA requirement from the office network and people could log in again.

😂 Needless to say, I had a hard time convincing them to keep using MFA after this episode, but it was absolutely a valuable experience.

In conclusion

Break-glass accounts play a crucial role in the overall identity security strategy for Entra ID. At their core, they ensure that even during unexpected events (such as account lockouts, misconfigurations, or technical failures) administrators retain the ability to recover and secure the environment.

Break-glass accounts complement other security measures, like Conditional Access policies and Privileged Identity Management (PIM), by acting as a last-resort mechanism. While Conditional Access and PIM are designed to enhance security during regular operations, break-glass accounts ensure that security is maintained even if those systems become inaccessible or compromised.

Beyond their practical benefits, break-glass accounts are often necessary to meet compliance requirements and industry standards. Frameworks like ISO 27001 emphasize the need for robust access control measures and contingency plans to address unforeseen incidents. Having break-glass accounts aligns with these requirements by ensuring that administrative access can be restored quickly in case of emergency.

👉And one more time: Test and verify your break-glass accounts regularly! 👈

Author

  • Per-Torben Sørensen has 25 years experience in IT and Microsoft infrastructure. He is currently an MCT and works as a Technical Architect within M365 at Crayon. His passion is Entra ID and Identity and access management and helps customers become "copilot-ready". He's also a engaged speaker and is always eager to share his knowledge and learn from others.

    View all posts

Discover more from Agder in the cloud

Subscribe to get the latest posts sent to your email.

By Per-Torben Sørensen

Per-Torben Sørensen has 25 years experience in IT and Microsoft infrastructure. He is currently an MCT and works as a Technical Architect within M365 at Crayon. His passion is Entra ID and Identity and access management and helps customers become "copilot-ready". He's also a engaged speaker and is always eager to share his knowledge and learn from others.

Related Post

Leave a Reply