Break-glass account: exclude it from Conditional Access

A poorly calibrated Conditional Access rule can lock every administrator out of the tenant — including whoever created it. The scenario is classic: a 'require compliant device' or 'block outside country' rule that, as a side effect, also applies to admin accounts. No one can sign in to fix the rule, and the organization must go through Microsoft support, with delays measured in hours or days. The break-glass account is the universal safeguard, explicitly recommended by Microsoft.

This account is your escape hatch: access that stays possible whatever happens to your rules, your MFA provider or your devices. Well designed, it costs nothing and saves you from a crisis. Badly designed or forgotten in an exclusion, it becomes useless at the worst moment. Here is how to set it up correctly, how to protect it despite its special status, and how never to forget to exclude it — because the day you need it, there is no second chance to get it right.

The rules of a good break-glass account

An emergency account is not an ordinary admin account. It follows precise rules that guarantee it will work the day everything else fails, without becoming a weakness itself.

• A dedicated, non-personal cloud account reserved exclusively for emergencies.
• A long, complex password, stored offline in a safe place (physical vault or secrets manager).
• Excluded from all Conditional Access rules, without exception.
• A high-privilege role (Global Administrator), used only when needed.
• Continuously monitored: any sign-in should trigger an immediate alert.

The account-security paradox

A break-glass account is powerful and excluded from protections: it must therefore be compensated by other measures. That's the balance to strike, because emergency access that is too protected becomes unusable in a crisis, while access that is too open becomes a target.

Protect it without making it unusable

Excluding it from MFA eases emergency access but exposes it. Best practice is to use a very long secret stored offline, optionally split the password between two owners, and keep at least two emergency accounts to cover the loss of one. Some organizations keep MFA via a dedicated, robust method, such as a FIDO2 key kept in a safe place, rather than excluding it entirely.

Monitor it as a critical asset

Since it should never be used day to day, any sign-in is an abnormal event. Configure an alert that immediately notifies the security team whenever an authentication occurs on this account. A periodic review of its validity (password, role, exclusions) completes the setup and guarantees it will be operational the day you actually need it.

Step-by-step setup

1. 1Create a dedicated cloud account in Entra ID, unlinked to any individual.
2. 2Give it a long password, stored offline in a safe place.
3. 3Grant it the Global Administrator role, reserved for emergencies.
4. 4Explicitly exclude it from all existing Conditional Access rules.
5. 5Configure an alert on any sign-in from this account.
6. 6Document the emergency-access procedure and test it periodically.

A concrete example: the rule that would have locked everyone out

An SMB decides to require a compliant device to access Microsoft 365. The rule seems harmless, but the administrator's account often signs in from a personal machine not enrolled in Intune. Deployed straight in enforced mode, the rule would have blocked the administrator themselves: no more access to fix it.

Because a break-glass account had been created and excluded beforehand, the crisis never happened. The administrator signs in with the emergency account, sees the rule is too broad, moves it back to report-only, adjusts the exclusions, then re-enables it cleanly. Without that safety net, they would have had to open a Microsoft support ticket and wait, while the whole organization lost access to email and files. The emergency account turned a potential major incident, with real business impact, into a five-minute fix handled quietly from a single browser tab.

Other safety nets so you never lock yourself out

The break-glass account is the ultimate safety net, but not the only one. Good Conditional Access hygiene combines several safeguards, so the emergency account is only ever needed in truly extreme cases.

• Report-only mode: enable each new rule in audit before enforcing it, to see who it would have blocked.
• Excluding the current administrator, so you don't cut your own access during the rollout.
• Gradual targeting: start with a pilot group rather than 'all users' from the outset.
• Reversibility: being able to disable a rule immediately if an unexpected lockout occurs.
• Documenting exclusions, so another administrator understands the choices made.

These nets stack: report-only avoids most surprises, excluding the administrator protects whoever runs the deployment, and the break-glass account covers the residual case where everything else has failed. It is this defense in depth that lets you enable Conditional Access with confidence, even on a production tenant.

The classic mistake, and how AuPoint prevents it

The most common mistake is forgetting to exclude the break-glass account from a new rule. You carefully exclude it from existing rules, then, six months later, you create another rule without thinking about it — and the safety net has a hole. AuPoint remembers your break-glass account and automatically injects it into the exclusions of every Conditional Access rule you deploy. You can't create one that forgets it.

AuPoint goes further: it requires selecting an emergency account before allowing any Conditional Access rule to be enabled. Combined with the impact preview and one-click reversibility, this makes locking the tenant structurally impossible. You deploy your security rules without ever fearing you will shut yourself out, and the exclusion follows every future rule automatically rather than depending on your memory.

FAQ

How many break-glass accounts do I need?

At least two, to cover the unavailability of one (lost password, compromised account, absent owner). Microsoft recommends this redundancy for emergency access, ideally with different access methods for the two accounts.

Should it really be excluded from MFA?

The goal is to keep access even if MFA is unavailable. Some organizations exclude it entirely, others keep a dedicated robust MFA method. Either way, the account must stay reachable during an identity-provider outage, without depending on a single device.

How often should I test the account?

Test the access procedure at least once or twice a year, and after every major configuration change, to make sure the password works and the exclusions are still in place. An emergency account that is never tested is really a gamble, not a safety net.

Set up your emergency account once in AuPoint, then deploy all your Conditional Access rules with peace of mind — the exclusion is automatic on every rule. Connect your tenant and start free today.