Break-glass accounts in Microsoft 365: when an SME needs emergency admin accounts

What a break-glass account is and is not

An emergency account is not a day-to-day admin account and not “an extra admin for the director”. It is a dedicated account with Global Administrator rights, meant for the rare moment when the normal path into the tenant fails: a Conditional Access mistake, a broken MFA method, an identity-provider outage, or a misconfiguration that locks out every normal admin. Microsoft often calls these emergency access or break-glass accounts.

It is also not a free pass to turn MFA “off” for everyone. The exception is narrow: only these emergency accounts, with compensating controls (offline storage, logging, alerting). See also Microsoft 365 Secure Score — emergency access belongs with a mature identity baseline, not with chasing a score without a procedure.

Why an SME still needs this

Three practical reasons. Lock-out risk: the tighter you set MFA and Conditional Access, the worse the impact if those rules or methods fail — without an emergency path you are outside your own tenant. Continuity: billing, mail, and SharePoint keep running; someone must still be able to intervene. Governance: the director wants to know “who may open the emergency vault?” — not “we hope it never happens”. Break-glass is useful when you attach a short procedure.

Without MFA and tidy admin roles, an emergency account is early. Get the basics right first (MFA, limited admins, legacy authentication off), then break-glass. Floor ICT checks per tenant whether the exclusion fits before we flip switches.

How you usually set emergency accounts up

In many small and medium-sized enterprises (SMEs) this approach is sensible — adapt it to your situation:

• two separate cloud-only Global Admin accounts (not synced on-premises accounts), with long, unique passwords;
• no mailbox for daily use, no unnecessary licence, no single employee’s personal name as the only key;
• exclusion from the normal Conditional Access policy that enforces MFA — only for these accounts, as narrow as possible, with other compensations (monitoring, physical storage);
• passwords offline: sealed envelope in a safe, or a hardware vault — not in the same password manager as day-to-day admins;
• alert on every successful sign-in (for example via Microsoft Entra ID sign-in logs or an alert to Floor ICT and one internal owner);
• link to the joiner/leaver checklist: when someone who knows the procedure leaves, re-check who may open the vault.

Do not use the accounts for routine admin work. Every sign-in is an incident until proven otherwise.

What you write down

Keep it short enough to follow in a real outage:

• how many emergency accounts exist and under which names (without putting the password in the document);
• where the sealed credentials live and who has physical or procedural access;
• when opening is allowed: only on a demonstrated lock-out or critical outage, not for “convenient quick access”;
• whom you notify immediately (internal owner, Floor ICT, optionally leadership);
• what you do after use: rotate the password, briefly log the incident, reaffirm the exception;
• review cadence: at least each quarter or half-year check that the accounts still exist, logging still works, and the vault still matches.

Put those points on one page. That is your break-glass agreement; the tenant follows that text.

What Floor ICT configures — and what you decide

In the Microsoft 365 tenant we typically: create or clean up emergency accounts; keep Conditional Access exclusions as narrow as possible; set monitoring or alerts on sign-in; and give a short hand-back on “how you test the procedure without panic”. We tie this to MFA, admin roles, and Secure Score actions already in scope.

You still decide: who may know the sealed credentials; when opening is allowed; whether you want one or two accounts; and whether you schedule a rehearsal. Technical switches without those choices give false comfort; a procedure without working accounts does not help either.