Break-Glass Accounts: 9 Proven Wins for Safer MSP Tenants

Almost every managed tenant has a pair of break-glass accounts sitting in it, created during onboarding and untouched ever since. They are the emergency admin logins that exist so that a broken Conditional Access policy, an expired token or a locked-out administrator does not turn into a week without access. The uncomfortable truth is that most break-glass accounts have never been tested since the day they were made — and an emergency credential nobody has exercised is a hope, not a control.

This article is about closing that gap. Not with another policy document, but with a small, repeatable set of checks that someone owns and runs on a schedule. It is unglamorous work, which is precisely why it keeps slipping — and precisely why it suits dedicated, outstaffed capacity rather than the on-call rota.

What break-glass accounts actually are

Break-glass accounts — also called emergency access accounts — are highly privileged identities kept in reserve for the moment normal administrative access stops working. Microsoft’s emergency access guidance for Entra ID sets out the shape most organisations follow: at least two cloud-only accounts on the default onmicrosoft.com domain, holding the Global Administrator role permanently rather than through Privileged Identity Management, and explicitly excluded from the Conditional Access policies that govern everyone else.

Every one of those design choices exists to remove a dependency. Cloud-only, so an on-premises directory failure does not take them with it. Permanent role assignment, so an activation workflow that itself needs sign-in is not in the path. Excluded from Conditional Access, so the policy that just locked everyone out does not lock out the recovery route too. Two of them, so a single lost credential is not the end of the story.

The design is well understood. What is far less consistently done is verifying that break-glass accounts still behave the way the design assumes. Tenants drift. Policies get rewritten by someone who did not know about the exclusion. Licences get reassigned. The person who put the credential in the safe left eighteen months ago. None of that shows up on a dashboard, because break-glass accounts are supposed to be silent.

Why break-glass accounts fail silently

The failure mode that matters is not dramatic. Nobody deletes the emergency admin. Instead, break-glass accounts decay through ordinary, well-intentioned change.

A new Conditional Access policy is written to require compliant devices, and the exclusion list is built from a security group rather than the accounts themselves — then somebody tidies up the group. A tenant-wide policy blocking legacy authentication is rolled out in report-only mode, then enforced months later by a different engineer. A password rotation happens and the new credential is recorded in a password manager the out-of-hours team cannot reach. The second factor is registered to a phone number belonging to someone who has since changed roles.

Each of these is invisible until the day it matters, and the day it matters is by definition the worst possible day to find out. That is the structural problem with break-glass accounts: the control is only ever exercised under pressure, so the feedback loop that would catch the drift never runs. Backup taught the industry this lesson already — an untested restore is not a backup — and break-glass accounts are the same shape of problem wearing different clothes.

There is a second, quieter risk running the other way. Because break-glass accounts are excluded from the controls that protect everything else, they are an attractive target. A permanently privileged, MFA-exempt account with a static password is precisely what an attacker wants. Testing break-glass accounts is therefore not only about availability; it is about confirming that the exemption is still narrow, still monitored, and still justified.

Nine proven checks for break-glass accounts

These are the checks worth running across a managed estate. They are deliberately concrete: each one either passes or fails, and each one produces evidence you can hand to a client or an auditor.

1. Confirm the accounts exist and are cloud-only

Start with an inventory. For every tenant you manage, list the break-glass accounts, confirm there are at least two, and confirm they are cloud-only rather than synchronised from on-premises Active Directory. A synchronised emergency account inherits the failure it is meant to survive.

2. Verify the Conditional Access exclusions directly

Do not trust the group. Enumerate every Conditional Access policy in the tenant and confirm the break-glass accounts are excluded by object, not by membership of a group that somebody could empty. This is the single highest-value check in the list, because it is the one that most often breaks quietly.

3. Actually sign in

The test that counts is a real, completed sign-in from a clean browser session. Not a token refresh, not a check that the object exists — a full authentication that lands in the portal. Everything else is inference. Schedule this so that both break-glass accounts get exercised, not just the first one in the list.

4. Check role assignment is permanent, not eligible

If the Global Administrator role is PIM-eligible rather than permanently assigned, activation becomes a dependency during an outage. Confirm the assignment is active and standing. Where a client’s policy requires PIM everywhere, document the exception explicitly rather than leaving it to be rediscovered.

5. Validate the second factor and its custodian

Current guidance points firmly at phishing-resistant methods — a FIDO2 security key or certificate-based authentication — rather than SMS or an authenticator app tied to one person’s handset. Whatever the method, confirm the physical token is where the runbook says it is, and that a named, current employee can retrieve it. The NCSC’s guidance on multi-factor authentication is a useful reference when justifying the method to a client.

6. Confirm credential escrow is reachable out of hours

Where is the credential, and who can get to it at two in the morning on a Sunday? If the answer is a password vault that requires the same identity provider that just failed, the escrow is circular. Break-glass accounts need an out-of-band path — a physical safe, a sealed envelope with a tamper log, or a vault on separate infrastructure.

7. Check licensing and mailbox state

Emergency accounts are usually left unlicensed on purpose: no mailbox and no file storage means less attack surface and nothing to exfiltrate. Confirm that is still true, and that nobody has quietly assigned a licence to make an alert route somewhere.

8. Verify alerting fires on use

A sign-in by one of the break-glass accounts should raise a high-severity alert that reaches a human quickly. Test it by triggering the alert during your scheduled sign-in and confirming it arrives. An alert rule that exists but does not deliver is worse than none, because it creates false confidence.

9. Record the result as evidence

Every test should leave a dated record: which tenant, which account, who ran it, what passed, what was remediated. This is what turns break-glass accounts from an assumption into a control you can evidence during a client security review or an insurance questionnaire.

Who owns the testing

The reason break-glass accounts go untested is rarely disagreement about whether testing matters. It is that the work has no owner. It is not incident work, so it never reaches the on-call engineer. It is not project work, so it never gets a budget line. It sits in the same category as restore testing, firmware cycles and access recertification: continuous, low-drama, evidence-generating work that everybody agrees with and nobody is scheduled to do.

Naming an owner changes the outcome more than any tooling decision. That owner needs three things: a list of tenants, a fixed cadence, and enough uninterrupted time to work through the estate without being pulled onto tickets. Senior engineers rarely have the third, which is why the task keeps rolling forward quarter after quarter.

A quarterly test you can actually run

Keep the cadence realistic. Quarterly is frequent enough to catch policy drift before it compounds and infrequent enough that it does not get abandoned. For each tenant, the run looks like this.

Pull the current list of break-glass accounts and diff it against last quarter’s record. Enumerate Conditional Access policies and confirm the exclusions by object. Retrieve the credential from escrow, noting whether the retrieval itself worked and how long it took. Sign in with each account from a clean session. Confirm the alert fired and reached someone. Rotate the credential, return it to escrow, and re-seal. Write the result up, including anything that had to be fixed mid-test — those fixes are the return on the whole exercise.

Two details make the difference between a test and a box-tick. First, rotate the credential as part of the test rather than as a separate task, so the rotation is always verified by a sign-in. Second, time the escrow retrieval. A credential you can reach in forty minutes is a very different control from one you can reach in four hours, and the difference only surfaces if somebody measures it. If the test uncovers a broader gap, feed it into your incident management planning rather than closing it as a one-off ticket.

Why South African outstaffing fits this work

Testing break-glass accounts across thirty or forty tenants is exactly the kind of work that suits dedicated outstaffed capacity. It is repeatable, it needs care rather than heroics, and it produces documentation as a by-product. What it does not suit is a senior engineer squeezing it between escalations.

OutsourceZA places skilled South African engineers and security analysts with UK and EU managed service providers at roughly 40–60% of the equivalent local cost. Because South Africa sits in a timezone that overlaps the full UK working day, an outstaffed engineer running break-glass accounts testing is available for a real handover conversation when something fails mid-test — not leaving a note for the following morning. That overlap is what makes the model work for MSP operations rather than only for offshore project work.

Our engineers are MSP-ready: familiar with multi-tenant administration, RMM and PSA tooling, and the evidence expectations that come with client security reviews. Outstaffing also flexes — you can start with one engineer owning identity hygiene across the estate and scale as the client base grows. You can see the full range on our IT outsourcing services page, read more about us, or get in touch to talk through what owning this work would look like for your estate. Engineers looking for this kind of role can browse our current IT jobs.

Frequently asked questions

How many break-glass accounts should a tenant have?

At least two. Two accounts mean a single lost credential, a single failed security key or a single compromised identity does not remove your recovery path. Keep them on separate credentials and, ideally, separate escrow locations so that one physical failure cannot take both.

How often should break-glass accounts be tested?

Quarterly is the cadence most managed service providers can sustain, and it aligns with common validation guidance. Twice a year is a defensible minimum for smaller estates. What matters more than the exact interval is that the date is scheduled, owned and recorded rather than left to whoever remembers.

Should break-glass accounts use MFA?

Yes, but with a method that does not depend on a single person or a mobile network. A FIDO2 hardware security key held in escrow is the current recommendation, because it is phishing-resistant and can be physically handed over. Excluding break-glass accounts from Conditional Access does not mean leaving them with a password alone.

What is the difference between a break-glass account and a normal admin account?

A normal administrative account is used daily, governed by Conditional Access and ideally elevated just-in-time through PIM. Break-glass accounts are the opposite by design: used almost never, exempt from those policies, and permanently privileged — which is why they need compensating controls in the form of escrow, alerting and scheduled testing.

Can this testing be outsourced?

It is a good candidate. The work is procedural and produces its own audit trail, so it transfers cleanly to a dedicated engineer working to a documented runbook. The main requirement is timezone overlap, so that a failure found mid-test can be escalated to your team the same working day rather than the next one.

The control you only get to test in advance

Break-glass accounts are the last thing standing between a bad configuration change and a tenant nobody can administer. They are also the control most likely to have quietly stopped working, because nothing in normal operations ever touches them. Nine checks, run quarterly by someone whose job it is, turns that from an article of faith into something you can evidence. If your estate has never had that owner, that is the gap worth filling first.