In our projects, Conditional Access is almost always the first step in hardening Microsoft 365. And when we start enforcing policies, blocking unknown platforms, requiring compliant devices or phishing-resistant MFA for admins, we hold a dedicated session with the customer about lockout risk. This article covers what to set up before you start, how to monitor your emergency accounts, and how to roll out Conditional Access in stages without stopping work.
What a break glass account is, and why you need one
A break glass account, officially an emergency access account, is a fully privileged admin account that doesn’t belong to any employee and isn’t used for day-to-day work. It exists for one moment only: when no other admin can sign in. That happens more often than you’d think:
- A Conditional Access mistake: for example a policy that blocks all users, admins included, or requires an authentication method nobody has registered yet.
- An authentication outage: a problem with Microsoft’s MFA service or a mobile carrier that stops admins from getting a code or approval.
- Federation down: an organization that signs in through ADFS or an external identity provider, and the federation server is unavailable.
- A departure or a compromised account: the last admin left, or their account was locked after a security incident.
Without an emergency account, the way out goes through Microsoft support: a long process that’s out of your control, while you can’t manage your own environment.
How to set them up properly
Microsoft’s guidance for emergency accounts has changed in recent years. It used to be a long password, no MFA and excluded from every policy. Today MFA is mandatory for every account signing in to the admin portals (Azure, Entra, Intune and the Microsoft 365 admin center), emergency accounts included, and a Conditional Access exclusion doesn’t bypass it. So the guidance is different:
| Principle | Recommendation |
|---|---|
| How many | At least two emergency accounts, so there’s no single point of failure |
| Account type | Cloud-only in the onmicrosoft.com domain, not synced from AD and not dependent on federation |
| Authentication | Passwordless and phishing-resistant: a physical FIDO2 key (recommended) or certificate-based authentication. A different method from your regular admins, and not tied to anyone’s phone |
| Storage | FIDO2 keys in safes at two separate locations, with a clear procedure for who can access them and when |
| Conditional Access | Both accounts in a dedicated group, excluded from every policy that blocks or restricts sign-in, so a policy mistake can’t lock them out too |
| Roles | Global Administrator as a permanent active assignment in PIM, not eligible, with no expiry or automated cleanup |
| Use | Emergencies only. Not for daily work, testing or as a service account |
| Regular testing | Sign in at least every 90 days, and after any change in the IT team, to make sure the account and key work |
One principle sits behind every row: the emergency account has to work when nothing else does. So it can’t depend on the same phone, the same authentication method or the same policy that might fail.
Monitoring and automation for emergency accounts
A fully privileged account excluded from policy is also a perfect target for an attacker. So you need to know immediately whenever it’s used, and make sure it actually stays excluded.
The second problem is less well known: every admin who creates a new Conditional Access policy has to remember to exclude the emergency account group. One policy without the exclusion, and the emergency account won’t save anyone. So we offer customers a small automation that runs in the cloud:
- Exclusion check every 30 minutes: the automation goes through every Conditional Access policy that blocks or restricts sign-in and confirms the emergency account group is excluded from all of them. If a policy was created without the exclusion, it sends an alert.
- An alert on every sign-in: every sign-in attempt to an emergency account, successful or not, triggers an email alert. Normally there shouldn’t be any.
- Keepalive: every 45 minutes the automation reports that it ran, and any failed run triggers an alert, so you don’t find out on the day that the monitoring itself had stopped.
The cost is modest. From our experience: 8–10 hours to set up and $5–15 a month in cloud costs, depending on use. Organizations with Microsoft Sentinel can build the alerting part there too, but the exclusion check needs its own logic.
Rolling out Conditional Access without stopping the business
The emergency account is the safety net. The right approach is never to need it, so every policy goes through three stages with us:
- Report-only. The policy runs and is logged in the sign-in logs, but isn’t enforced. You see exactly who it would have blocked and fix the gaps before anyone is actually blocked.
- Enforce on a small group. Turn it on for a pilot group of users or devices that are already ready, and widen it gradually.
- Full enforcement. Only after the gaps are fixed, with documented exclusions and a follow-up task for each one.
Here’s what it looks like mid-way at one of our customers, an industrial company:
| Policy | Status | What’s needed before moving on |
|---|---|---|
| Block unknown device platforms | On, with one exclusion | The excluded account uses legacy authentication; fix its sign-in and remove the exclusion |
| MFA to register security info | On | New users register with a Temporary Access Pass, after training the IT team |
| Phishing-resistant MFA for admins | Report-only | Every admin needs to set up a passkey in Microsoft Authenticator and test sign-in |
| Block by user risk | On for a pilot group | Widen the group together with a self-service password reset (SSPR) pilot |
| Require a compliant device | Report-only | Many PCs aren’t compliant yet; fix the gaps from the report and turn it on gradually |
| App protection (MAM) | On | Collecting feedback on the user experience |
| Phishing-resistant MFA for all users | Report-only | Move users from SMS to app-based sign-in, then to passkeys |
Two things stand out. First, the most sensitive policies, the ones that could lock admins out, stay in report-only until every admin is registered for the new method. Second, every exclusion gets an owner and a follow-up task, so it doesn’t become a permanent hole in the policy. We wrote more about moving from SMS to passkeys in our guide to the SMS and voice retirement in Entra.
The bottom line
Before you turn on a single Conditional Access policy, your tenant needs two emergency accounts: cloud-only, with FIDO2 keys in separate safes, excluded from every policy that blocks sign-in, and with an alert on every sign-in. Once they exist, every new policy starts in report-only, moves to a pilot group, and only then is enforced for everyone.
Want to know whether your emergency accounts will really work on the day? Book a call with the OnCloud team and we’ll review your emergency accounts and access policies.
Book a call