Imagine it’s Tuesday morning at 9:00 a.m. A routine update to your Conditional Access policies in Microsoft Entra goes wrong. A small logical error, a checkbox set incorrectly in the exclusions, and suddenly you and your entire admin team are locked out of the tenant. No access to Microsoft 365, no Azure management, completely unable to act.

Emergencies happen every day. Most of the time, they affect other people. Until the day it happens to your own company. What do you do then?

At TEAL, we know from our daily consulting work: Most IT managers know in theory that things can go wrong. But hardly any company invests enough time in planning for the scenario of losing total control over its own cloud environment. That’s understandable… until a misconfiguration, a global system failure, or a targeted cyberattack turns that theoretical problem into a very real reality.

This is exactly where emergency accounts—so-called “break-glass accounts”—come into play. In this article, we’ll show you how to securely set up, harden, and monitor this last line of defense in Microsoft Entra according to current best practices.

The harsh reality in many server rooms

On paper, the need for emergency access is an absolute no-brainer for any Identity and Access Management (IAM) expert. However, when we look at the reality in companies, from small and medium-sized businesses (SMBs) to large corporations, we usually encounter one of three nightmare scenarios:

1. 1. 1. There are simply no break-glass accounts at all
      2. There is an emergency account, but it was created years ago by a former employee, the password is nowhere to be found, and a login has never been tested
      3. Accounts exist, but there is no documentation and no emergency manual

To make matters worse, the technical landscape is changing rapidly. Microsoft’s Secure Future Initiative now strictly enforces multi-factor authentication (MFA) for admin portals and CLI tools. The outdated approach of simply creating an emergency account with a 30-character password and exempting it from any MFA no longer works technically and is extremely dangerous. Your break-glass setup shouldn’t be a static document sitting in a drawer; it needs to be dynamic.

Break-Glass Accounts „Done Right“

A “break-glass” account in Microsoft Entra ID is a standalone account assigned the Global Administrator role. It is not linked to any specific individual. Why? Because, in an emergency, access must not depend on whether a particular employee is on vacation, sick, or even still employed by the company.

To protect these accounts as critical infrastructure, we recommend the following procedure:

1. Title: Put an End to “Security by Obscurity”

It used to be commonly believed that emergency accounts should have inconspicuous names so as not to attract attention during reconnaissance by attackers. This way of thinking is outdated. Attackers aren’t looking for names; they’re looking for permissions.

Our recommendation: “Use clear, unambiguous names (e.g., BreakGlass01@ihrefirma.onmicrosoft.com) and use only the standard .com domain. In an emergency, your own SOC team and admins need to be able to identify which account is involved immediately and without any guesswork,” says our Security Architect Fabian Böhm.

2. Permissions: Permanent and active

The emergency account must be operational immediately when everything else fails. Therefore, this role must not be requested via Privileged Identity Management (PIM) or be subject to a time limit. It must be a direct, permanent assignment as a Global Administrator. Microsoft recommends a maximum of 4 Global Administrators per tenant. You must already factor in your two break-glass accounts here.

3. Group-based approach vs. individual accounts

Should break-glass accounts be organized into a security group? Opinions on this often differ. Here at TEAL, we have a clear stance on this:

• • The single-account approach
  • Our recommendation (group-based approach): Use a role-assignable security group. While this adds a layer of complexity, it allows you to enforce authentication methods such as passkeys (FIDO2) and device-bound profiles specifically for this group and restrict usage via AAGUIDs to approved hardware tokens (e.g., YubiKeys).

4. Restrict management via RMAU

Since accounts and groups are objects within the tenant, they could theoretically be manipulated or deleted by other privileged administrators. We prevent this by using Restricted Management Administrative Units (RMAU). By placing your break-glass accounts and their security group within an RMAU, you completely block administrative access for standard administrators. Only explicitly defined identities can manage these accounts. A massive security gain.

Monitoring & Procedures: When the emergency account whispers, the SOC must shout

An emergency account must never be used during normal operations. Every single login attempt, whether successful or failed, must immediately trigger a critical alarm with the highest priority.

To achieve this, you must stream Microsoft Entra logs to a Log Analytics workspace (or directly to a SIEM such as Microsoft Sentinel). As soon as any activity is detected on the account, an automated alert must notify IT management and the Security Operations Center (SOC) via phone, SMS, or dedicated channels.

Furthermore, even the best technical safeguards are useless without the appropriate organizational processes:

• • Secure Storage: Passwords and hardware tokens should be stored in physical safes (e.g., at two separate company locations).
  • Regular testing: At least once a quarter, you must simulate an emergency scenario and thoroughly test the login process using the break-glass account.
  • Documentation & training: Your IT staff must know instinctively where the keys are kept, who is authorized to open the safe, and what the technical steps for recovery entail.

Conclusion

A secure Microsoft Entra tenant isn’t just defined by how well it fends off attacks, but above all by how resilient it is in the event of a disaster. A properly configured, group-based break-glass account protected via RMAU ensures that you can take action in an emergency instead of panicking.

Have you already run through an emergency scenario for your tenant? We can help you elevate your IAM architecture to an enterprise level, avoid pitfalls during the Microsoft MFA migration, and make your emergency processes watertight.

Source: Chance of Security