You’ve done everything right. You’ve created your breakglass accounts, configured phishing-resistant MFA and set up alerts to notify multiple people the moment either account is touched. You’ve followed the guidance, ticked the boxes and filed it away as done.

But when did you last actually test them?

What Microsoft Recommends

Microsoft is clear on what a properly configured breakglass setup looks like. Their guidance recommends maintaining at least two emergency access Global Administrator accounts to ensure you can always get into Microsoft Entra ID, even when normal authentication or Conditional Access mechanisms fail.

Those accounts should be:

• Excluded from Conditional Access policies
• Protected by strong, phishing-resistant credentials
• Monitored and alerted on for any sign-in activity
• Reserved strictly for genuine emergency scenarios

https://learn.microsoft.com/entra/identity/role-based-access-control/security-emergency-access

The Problem with “Set and Forget”

Most organisations have mature processes around scheduled maintenance, patch cycles, backup jobs, restore tests and maybe even full DR exercises. These are scheduled tested regularly by your IT team or your MSP because everyone understands that an untested backup not a backup until you have done a restore test.

Breakglass accounts deserve the same treatment, but they rarely get it.

As M365 administrators, you are constantly responding to new threats and hardening your tenant. A new Conditional Access policy here, an IP restriction there, a block on legacy authentication, each change makes your environment more secure. But every one of those changes is also an opportunity to accidentally lock out the very accounts you’d rely on in a crisis.

Real-World Scenarios That Can Catch You Out

These aren’t hypothetical edge cases. They’re the kind of thing that happens in real organisations:

• The lost hardware key. Your breakglass account was registered against a YubiKey. That YubiKey is gone, sitting in a drawer nobody can find or walked out the door with someone who left the company. You won’t discover this until you need it.
• The forgotten phone. MFA was set up on someone’s old mobile. That number no longer exists. The account is now effectively inaccessible.
• The IP restriction nobody remembered. A Conditional Access policy was created to restrict access to your corporate IP range. But you have changed your internet provider and now your IP range has changed too, and you forgot to exclude your breakglass accounts. You are now locked out from every location you’d realistically be working from in an emergency.
• Microsoft’s enforced MFA rollout. Microsoft has been progressively enforcing MFA across all accounts, including those that were previously exempt. Did you catch that change? Did you register MFA on your breakglass accounts as part of that rollout and if so, what method did you use? Is it still accessible?

Each of these scenarios has one thing in common: they’re invisible until the moment you need the account to work.

What a Breakglass Test Should Cover

Testing a breakglass account doesn’t need to be complex or time-consuming, but it should be deliberate. Here’s what to validate each time:

1. Can you actually sign in? Attempt a full authentication from outside your normal corporate environment, ideally from a location and device that isn’t covered by your standard Conditional Access policies.
2. Is MFA working? Confirm the registered MFA method is still accessible, whether that’s a hardware key, an authenticator app, or a FIDO2 device. Verify you know where it is and who has access to it.
3. Are your Conditional Access exclusions still in place? Review every CA policy in your tenant and confirm the breakglass accounts are explicitly excluded. Pay particular attention to any policies added since your last test.
4. Do your alerts fire? When you sign in, do the right people get notified? Is the alert going to a distribution list, a monitored mailbox or is it going to one person’s inbox who may have left the organisation?
5. Is the account still assigned Global Administrator? Role assignments can be changed, expired (if using PIM), or accidentally removed during administrative tidying.

How Often Should You Test?

A reasonable baseline is every three to six months, with an additional test triggered any time a key person who could have had access leaves the company.

But if you are doing regular Health checks or Backup tests why not include this and one of the tests?

Closing Thought

A breakglass account that hasn’t been tested is a false sense of security. The whole point of the account is that it exists for the moment everything else has failed. That is precisely the worst time to find out it doesn’t work.

Schedule the test, put it in the calendar, create a scheduled ticket, treat it with the same rigour you’d give a DR exercise because for many organisations, being locked out of your M365 tenant is a DR scenario.

For information on others tests you should be doing in your M365 environment check out my previous articles on Maester or Microsoft Zero trust assessments tool.