{"id":1007793,"date":"2026-06-01T12:11:37","date_gmt":"2026-06-01T10:11:37","guid":{"rendered":"https:\/\/www.teal-consulting.de\/2026\/06\/01\/microsoft-entra-break-glass-best-practices\/"},"modified":"2026-06-01T14:59:17","modified_gmt":"2026-06-01T12:59:17","slug":"microsoft-entra-break-glass-best-practices","status":"publish","type":"post","link":"https:\/\/www.teal-consulting.de\/en\/2026\/06\/01\/microsoft-entra-break-glass-best-practices\/","title":{"rendered":"Emergency Access in Microsoft Entra: Best Practices for Your Break-Glass Accounts"},"content":{"rendered":"
[vc_row css_animation=”” row_type=”row” use_row_as_full_screen_section=”no” type=”full_width” angled_section=”no” text_align=”left” background_image_as_pattern=”without_pattern”][vc_column][vc_empty_space height=”30″][vc_row_inner row_type=”row” type=”full_width” text_align=”left” css_animation=””][vc_column_inner][vc_column_text][\/vc_column_text][\/vc_column_inner][\/vc_row_inner][\/vc_column][\/vc_row][vc_row css_animation=”” row_type=”row” use_row_as_full_screen_section=”no” type=”full_width” angled_section=”no” text_align=”left” background_image_as_pattern=”without_pattern”][vc_column][vc_empty_space height=”50″][vc_row_inner row_type=”row” type=”full_width” text_align=”left” css_animation=””][vc_column_inner][vc_column_text css=””]Imagine it\u2019s 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.<\/p>\n

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?<\/p>\n

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\u2019s understandable\u2026 until a misconfiguration, a global system failure, or a targeted cyberattack turns that theoretical problem into a very real reality.<\/p>\n

This is exactly where emergency accounts\u2014so-called \u201cbreak-glass accounts\u201d\u2014come into play. In this article, we\u2019ll show you how to securely set up, harden, and monitor this last line of defense in Microsoft Entra according to current best practices.[\/vc_column_text][\/vc_column_inner][\/vc_row_inner][\/vc_column][\/vc_row][vc_row css_animation=”” row_type=”row” use_row_as_full_screen_section=”no” type=”full_width” angled_section=”no” text_align=”left” background_image_as_pattern=”without_pattern”][vc_column][vc_empty_space height=”50″][vc_row_inner row_type=”row” type=”full_width” text_align=”left” css_animation=””][vc_column_inner][vc_column_text css=””]\n

The harsh reality in many server rooms<\/h2>\n[\/vc_column_text][vc_empty_space height=”20″][vc_column_text css=””]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:<\/p>\n
    \n
  1. \n
      \n
    1. \n
        \n
      1. There are simply no break-glass accounts at all<\/strong><\/li>\n
      2. There is an emergency account,<\/strong> but it was created years ago by a former employee, the password is nowhere to be found, and a login has never been tested<\/li>\n
      3. Accounts exist,<\/strong> but there is no documentation and no emergency manual<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n[\/vc_column_text][vc_empty_space height=”20″][vc_column_text css=””]To make matters worse, the technical landscape is changing rapidly. Microsoft\u2019s 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\u2019t be a static document sitting in a drawer; it needs to be dynamic.[\/vc_column_text][\/vc_column_inner][\/vc_row_inner][\/vc_column][\/vc_row][vc_row css_animation=”” row_type=”row” use_row_as_full_screen_section=”no” type=”full_width” angled_section=”no” text_align=”left” background_image_as_pattern=”without_pattern”][vc_column][vc_empty_space height=”50″][vc_row_inner row_type=”row” type=”full_width” text_align=”left” css_animation=””][vc_column_inner][vc_column_text css=””]\n

        Break-Glass Accounts \u201eDone Right\u201c<\/h2>\n[\/vc_column_text][vc_empty_space height=”20″][vc_column_text css=””]A \u201cbreak-glass\u201d 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.<\/p>\n

        To protect these accounts as critical infrastructure, we recommend the following procedure:<\/p>\n

        1. Title: Put an End to \u201cSecurity by Obscurity\u201d<\/h3>\n

        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\u2019t looking for names; they\u2019re looking for permissions.<\/p>\n

        Our recommendation:<\/strong> \u201cUse 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,\u201d<\/em><\/span> says our Security Architect Fabian B\u00f6hm.<\/p>\n

         <\/p>\n

        2. Permissions: Permanent and active<\/h3>\n

        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.<\/p>\n

         <\/p>\n

        3. Group-based approach vs. individual accounts<\/h3>\n

        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:<\/p>\n