Why SMBs get “bricked” during admin hardening
The real risk: security improvements that remove your last way back in
Tightening Microsoft 365 security often means Conditional Access (CA), MFA enforcement, and admin role cleanup. Those are the right moves—but the most common failure mode is accidentally blocking the only accounts that can fix mistakes.
This is especially likely in SMBs where one or two people make changes quickly, often after hours, without a deployment plan or a validated recovery path.
What this article is (and isn’t)
This is not another “what is an emergency access account” explainer. It’s an SMB-friendly operating system for introducing or modifying Conditional Access while continuously proving your emergency access remains usable.
It’s designed for Business Premium and E3 environments where you want strong controls without creating a single point of failure.
The “Don’t Brick the Tenant” protocol (lightweight operating system)
Principle 1: Separate recovery from day-to-day identity dependencies
Your day-to-day admins can rely on modern controls like device compliance, app-based MFA, and strict sign-in risk rules. Your break-glass accounts should be able to get in during the realistic events that break those dependencies.
Examples include an outage in a specific MFA method, a device compliance issue, or an overly broad CA policy.
Principle 2: Prove, don’t assume
Most lockouts happen because someone *assumed* the exclusions, auth methods, or roles were still correct after changes. This protocol makes proof a recurring control: you test access and keep evidence.
Principle 3: Reduce blast radius with staged rollout and “escape hatches”
You don’t introduce CA like a light switch. You introduce it like a change that can be rolled back quickly, with scoped targeting, reporting first, and a known-good admin entry point.
Build the emergency access baseline (before you touch Conditional Access)
Two accounts, not one
Create two emergency access accounts so one can still work if the other is accidentally disabled, compromised, or misconfigured. Keep them cloud-only and not tied to a single person’s employment status.
Keep them out of normal workflows: no email mailbox use, no Teams sign-in, and no app registrations unless there is a specific recovery requirement.
Minimum roles, maximum usefulness
Emergency accounts need enough privilege to recover the tenant. In many SMBs that means Global Administrator, but restrict where possible and avoid day-to-day use.
Also ensure there are at least two additional non-emergency admins with appropriate roles for routine work, so the break-glass accounts stay untouched.
Conditional Access exclusions that won’t accidentally drift
You want a simple, auditable rule: emergency accounts are excluded from policies that could block sign-in. In practice:
- Exclude emergency accounts from all Conditional Access policies that enforce MFA, device compliance, approved apps, sign-in risk, or location restrictions
- Keep exclusions explicit (select the specific accounts), not based on fragile group logic unless you have strong group governance
Decide the break-glass authentication method (based on outage scenarios)
Choose methods that fail differently
For daily users, app-based MFA is great. For emergency access, diversity matters more than convenience. You’re trying to avoid a single dependency that can fail across the whole tenant.
Aim for at least two methods across the two accounts that don’t share the same failure mode.
Practical decision rules for SMBs
Use these rules to avoid “perfect on paper” setups that fail in real incidents:
- If your org is heavily dependent on phone/SMS, keep at least one emergency account that does not rely on SMS (SIM swap and carrier outages are real)
- If your org is heavily dependent on the Authenticator app, keep at least one emergency path that does not require that app (phone loss, app corruption, or push fatigue attacks)
- If you can support it operationally, consider FIDO2 security keys for one emergency account because they’re resilient to many phishing scenarios; store keys like physical emergency equipment
Document the “why” behind your choice
Write down what each break-glass account depends on (device, phone number, security key location). In an incident, you want clarity, not guesswork.
Credential custody model: who holds what, where, and how access is granted
Treat credentials like a fire extinguisher, not a password
Emergency credentials shouldn’t live in someone’s browser password manager or personal notes. Use controlled custody.
A workable SMB model:
- Store usernames + passwords in an approved password vault with restricted access
- Store any physical factor (like a FIDO2 key) in a labeled, secured location with an access log
- Define two-person access for retrieval when possible (even informally: owner + IT lead)
Make access to custody itself resilient
If your vault is protected by the same MFA methods that might be failing, you may be locked out of the vault when you need it. Have a documented way to access the stored credentials during an MFA outage (for example, offline recovery codes stored securely).
Keep this simple and reviewed—complexity is its own failure mode.
Pre-change checklist (the non-negotiables)
Confirm your recovery path before the change window
Before you create or modify any Conditional Access policy, confirm the emergency access accounts exist, are excluded, and have verified authentication methods.
- Verify two emergency access accounts exist and are enabled
- Confirm both are excluded from every relevant CA policy (MFA, device, location, risk)
- Confirm each has at least one working authentication method, and the two accounts don’t share the same single dependency
- Confirm credential custody is accessible (vault access + any physical factor)
- Identify the rollback plan: who can disable the new policy and how fast
Pick a “safe” change window and a rollback owner
Even in SMBs, assign one person to implement and one to observe and verify. The rollback owner’s job is to be ready to revert quickly if sign-ins fail.
Safe Conditional Access deployment sequence (SMB pattern)
Step 1: Start in report-only and target a pilot
Create the policy in Report-only mode first. Target a small pilot group (not “All users”) so you can see impact without risking tenant-wide disruption.
Keep the pilot group broad enough to include typical devices and roles, but exclude emergency access accounts from the beginning.
Step 2: Expand scope and add one control at a time
Move from pilot to larger groups in stages. When you change scope, keep controls stable; when you change controls, keep scope stable.
Examples of “one control at a time”:
- First enforce MFA
- Then add device compliance requirements
- Then add location/app restrictions
This makes troubleshooting possible when something breaks.
Step 3: Enforce, then verify break-glass still works
After switching a policy from Report-only to On, immediately perform your break-glass verification (see the monthly test section). This is what prevents silent failures.
If the test fails, treat it like a production incident: roll back or remediate before continuing.
Monitoring and alerting expectations (what “good” looks like)
What you should be watching
You don’t need an enterprise SOC to be safe, but you do need basic signals. At minimum, expect to review:
- Sign-in logs for failed admin sign-ins and unusual locations
- Audit logs for changes to Conditional Access and role assignments
- Alerts for risky sign-ins (where available) and unexpected MFA changes
Set a simple “human paging” rule
In SMBs, automated alerting often becomes noise. Instead, define a rule like: “Any Conditional Access change triggers a same-day review of sign-in and audit logs by a second person.”
This one habit catches a surprising number of self-inflicted outages.
The monthly break-glass login test (documented like an audit control)
What you’re testing (and what you’re not)
You are not using the emergency accounts for work. You are proving they can still sign in and have the expected administrative reach.
The test should be quick, repeatable, and safe.
Test procedure (10–15 minutes)
Use a controlled device and network (for example, a known-good laptop on a known-good connection). Then:
- Attempt sign-in to the Microsoft 365 admin center (or Entra admin center)
- Confirm you can reach the admin portal without being blocked by Conditional Access
- Confirm the account’s admin role is present (don’t make changes)
- Record the result and sign out
Repeat for the second emergency account.
Evidence to capture
Create a simple record that stands up to internal review or an MSP governance assessment:
- Date/time and tester name
- Which emergency account was tested (use an internal identifier, not the full username in a shared doc)
- Result (pass/fail) and any prompts observed
- Screenshot of successful portal landing page or sign-in confirmation
- Ticket/link showing whether any CA changes occurred since the last test
What to do if the test fails
Treat a failure as urgent because it means your recovery path is broken.
- Stop further CA changes
- Identify which policy is blocking sign-in (sign-in logs and CA evaluation details)
- Fix exclusions or authentication method configuration
- Re-test both emergency accounts and document the remediation
How this protocol shows governance maturity (for MSPs and internal IT)
The maturity signal isn’t the policies—it’s the control loop
Many environments can claim they “have break-glass accounts.” Fewer can show they have a repeatable method to prevent lockout during change.
If you’re evaluating an MSP, ask to see:
- Their standard CA rollout sequence
- Their break-glass custody model
- The last three break-glass test records (redacted)
A provider who can produce those artifacts usually won’t “wing it” in your tenant.
Key Takeaways
- Treat emergency access as a tested control, not a checkbox: prove it monthly and after CA enforcement changes.
- Use two break-glass accounts with different dependency profiles to survive realistic outages.
- Roll out Conditional Access in stages: Report-only → pilot → expand → enforce → verify break-glass.
- Store emergency credentials in controlled custody that remains accessible during an MFA disruption.
Frequently Asked Questions
How many break-glass accounts does an SMB need?
Two is the practical baseline. One account is too easy to misconfigure, disable, or lose access to during an incident.
Should break-glass accounts be excluded from every Conditional Access policy?
Exclude them from any policy that could block sign-in (MFA requirements, compliant device, location restrictions, risk-based blocks). You can still monitor them aggressively via logs and alerts.
How often should we run the break-glass login test?
Monthly is a good SMB cadence, and you should also test immediately after enforcing or materially changing Conditional Access. If you do frequent changes, consider a quarterly deep test plus a lightweight post-change verification.
Can we use FIDO2 keys for break-glass in a small business?
Yes, if you can store and control them like physical emergency equipment. The key is operational discipline: secure storage, documented access, and a tested retrieval process.
What’s the most common mistake that causes admin lockouts?
Introducing a new CA policy (device, location, or risk-based) and forgetting to exclude the emergency accounts—or relying on an exclusion method that later changes without notice.
Take the Next Step
If you’re about to tighten Conditional Access and want confidence you won’t brick the tenant, adopt this protocol as your default change process. It’s lightweight, auditable, and designed for the way SMBs actually operate.
Want a second set of eyes? Your Expert Tech can review your break-glass design, Conditional Access rollout plan, and monthly test template so you can harden Microsoft 365 without losing your way back in.