Break-glass account testing: a quarterly checklist

What a break-glass account is for

A break-glass (emergency access) account is the admin sign-in you keep for the day normal admin access fails: a federation or MFA outage, a Conditional Access policy that locks every administrator out, or the only Global Administrator leaving. Microsoft's guidance for Entra ID is specific (Microsoft Learn: Manage emergency access accounts):

• Two or more accounts, cloud-only, on the *.onmicrosoft.com domain, not federated or synchronized from on-premises.
• A passwordless sign-in method: a passkey (FIDO2) is the recommended one, or certificate-based authentication if you already run a PKI.
• Excluded from any Conditional Access policy that blocks or restricts sign-in, because an enforced policy could stop the account during the very emergency it is for.
• An alert on every sign-in, sent to other administrators through Azure Monitor, Microsoft Sentinel or a similar tool.

Other identity providers have their own version of the same idea. The checklist below is written for Entra ID; the steps carry over.

How often to test

Microsoft asks for regular drills that check both that the accounts work and that the monitoring and alerting rules fire. It names the floor: at least every 90 days, again when IT staff change (after a termination or a position change), and again when the organization's Microsoft Entra subscriptions change. So the schedule is quarterly, with an extra run whenever someone who held admin rights or knew where the credentials live moves on.

The alerting half is the one that gets skipped. A sign-in that works while the alert stays silent means the next unauthorized use of that account will be silent too.

The quarterly checklist

Run it for every emergency account in the tenant, in one sitting, and write the record before you close the window.

1. Tell the people who watch the alerts. Agree a test window with whoever receives the sign-in alerts, so the drill is not mistaken for an attack and a real attack is not waved off as the drill. Do not switch the alert off for the test; the alert is half of what you are testing.

2. Fetch the credential the way you would in an emergency. Go to the safe, the vault entry or the drawer with the security key, exactly as the written procedure says. Note how long it took. While you are there, review the list of people authorized to use the accounts and remove anyone who has left or changed role.

3. Sign in with each account. Every emergency account, not just the first one. Use the documented path and the registered passkey or certificate. If a Conditional Access policy blocks the sign-in, the test has found the problem it exists to find.

4. Do one read-only admin task. Microsoft's list asks you to confirm the accounts can sign in and perform administrative tasks. Open Roles and administrators in the Entra admin center and view who holds Global Administrator, for example, and change nothing.

5. Confirm the alert arrived. Check that the email, text or ticket reached the people it should, and note the time it arrived. A sign-in that works with no alert is a failed test.

6. Check that the account has not drifted. No MFA or self-service password reset registered to one person's phone or personal details; still excluded from the Conditional Access policies that block or restrict sign-in; the role assignment unchanged; no sign-ins since the last test that nobody can explain.

7. Put the credential back. Confirm the security key or certificate is where the procedure says it is, and that the certificate is not close to expiry. If your procedure keeps a password for the account, follow its rotation rule and re-seal it. Change safe combinations after anyone with access leaves.

8. Close the window and write the record while the sign-in log entry and the alert are still on screen.

The record to keep

One row per account per test, and every past row kept. The record proves the test happened; it must never contain the credential itself.

Attach two screenshots to each row: the sign-in log entry for the test, with its timestamp, and the alert as it arrived. Name the person who received the alert as well as the person who signed in; a test with two names on it is harder to write up after the fact than a test with one. Never attach the password, a photo of what is inside the sealed envelope, or a security key's PIN.

When the test fails

A failed test is the control working. Record what failed (the alert never arrived, a new policy blocked the account, the key was not where the procedure said), what was done about it, and the date of the re-test. A year of clean passes with no exception ever recorded reads, to a careful reviewer, like a log filled in afterwards. The parenthesis in the quote above is what that looks like from the inside.

The question this record answers

Auditors and cyber-insurance applications both ask how privileged accounts are protected and who holds them. Break-glass accounts are the most privileged accounts in the tenant and, by design, the ones that sit outside your normal sign-in policies. A dated record for each quarter, showing a sign-in, an alert and two named people, is the evidence that this exception is controlled rather than forgotten. For the rest of the list, see what carriers ask for at renewal.

For MSPs: one test per client tenant

Every client tenant has its own emergency accounts, its own alert recipients and its own drift. Put the test on each client's schedule rather than one calendar entry for the whole book, assign it to a named technician, and keep the record with that client's other evidence, next to the restore test log. The answer for one client should never depend on finding another client's folder.

Questions

How often should break-glass accounts be tested?

At least every 90 days under Microsoft's guidance, plus after a change in IT staff and when the organization's Entra subscriptions change.

Does every emergency account need testing each time?

Yes. There are two or more so that one can fail without locking you out, and that only holds if each one has been tried.

Should the accounts be excluded from Conditional Access?

From policies that block or restrict sign-in, yes, according to Microsoft. Report-only policies do not block access and need no exclusion. The passkey or certificate protects the account instead.

Should the alert be paused during the test?

No. Warn the people who receive it, then check that it arrived. An alert that was silenced for the drill has not been tested.

Next step

ControlLedger's control library includes a break-glass check. Schedule it per client every quarter; the assigned technician logs pass, fail, exception or not applicable and attaches the sign-in and alert screenshots, which are hashed with SHA-256 on upload; every run, passed or failed, goes into that client's Evidence Pack. ControlLedger records who attested to what, and when. It does not sign in to the tenant, and it does not verify that the test was performed. The help page goes from signup to the first pack. Free for one client, no credit card.