CMMC Level 2 Break Glass Accounts Setup in Microsoft Entra ID

If you’re pursuing CMMC Level 2, getting locked out of Entra ID during a security change is the kind of “one bad click” story you don’t want to tell an auditor (or your CEO). I treat Entra break glass accounts like the spare key to a building, you hope you never use it, but you can’t afford to find out it doesn’t work.

In this guide, I’ll lay out a practical setup that fits small DoD contractors. You’ll get prescriptive steps, Conditional Access examples, monitoring tips, and an evidence checklist you can save for your assessment.

Why CMMC Level 2 forces you to take emergency access seriously

CMMC Level 2 maps to NIST SP 800-171 and expects consistent account controls across Access Control, Identification and Authentication, and Audit and Accountability. That means your “emergency admin” can’t be a mystery account that nobody owns, nobody monitors, and everybody can access.

Even though CMMC doesn’t call out break glass accounts by name, the intent is clear: privileged access must be controlled, logged, and reviewed. So I document emergency access in the SSP, restrict it with strong authentication, and prove it’s monitored.

If you’re aligning Microsoft 365 scope and configuration for CMMC, this background helps frame the decisions in Entra ID. I like having teams read a concise scoping write-up such as Microsoft 365 CMMC alignment scoping and configuration before we change policies.

As a Business Technology Partner, I often start with Small Business IT basics like Cloud Infrastructure hygiene and an Office 365 Migration plan. When Data Center Technology and Restaurant POS Support sit beside Kitchen Technology Solutions, I pair Cybersecurity Services with Endpoint Security and Device Hardening so operations don’t become the weak link. That mix supports Innovative IT Solutions through Tailored Technology Services, strong Cloud Management, and practical Technology Consulting. From Infrastructure Optimization to Digital Transformation, my IT Strategy for SMBs centers on Secure Cloud Architecture, Managed IT for Small Business, and Business Continuity & Security.

My baseline design for break glass in Entra ID (what I use for SMBs)

I set up two emergency access accounts, not one. Two accounts reduce single points of failure (lost key, locked method, bad policy). Both are cloud-only identities, not synced from on-prem AD, because directory sync issues are common during outages.

Here’s the pattern I recommend:

Item	Break glass 1	Break glass 2
Account type	Cloud-only user	Cloud-only user
Admin role	Global Administrator (direct assignment)	Global Administrator (direct assignment)
MFA	Passkey or FIDO2 security key (phishing-resistant)	Different passkey or different FIDO2 key
Conditional Access	Very limited scope exclusions, plus a dedicated emergency policy	Same, tested separately
Monitoring	Alert on any sign-in, role change, or auth method change	Same

Two hard rules keep me out of trouble later:

• Each account has a real owner (named custodian) and a real process (dual control).
• I don’t use shared mailboxes or “generic admin” mailboxes for break glass. That wrecks accountability.

For phishing-resistant setup ideas, these two walkthroughs align well with what I see working in the field: break glass with phishing-resistant MFA in Entra ID and configure an Entra emergency access account.

Step-by-step: creating Entra break glass accounts the right way

I build these accounts in the Entra admin center, then I prove they work before I touch broader Conditional Access.

1. Plan names and owners first. I use a naming standard like bg-globaladmin-01 and bg-globaladmin-02, plus a documented custodian for each.
2. Create two cloud-only users. Don’t assign product licenses unless you truly need them. Avoid mailboxes unless your alerting design requires it (most SMBs don’t).
3. Set long, unique passwords. Generate high-entropy passwords and store them offline with tamper evidence. I use sealed envelopes in a fire safe, with a sign-out log.
4. Register phishing-resistant MFA. Add a passkey or FIDO2 key to each account. Use two different keys, stored separately.
5. Assign Global Administrator directly. This is an exception to least privilege, so I document it as “emergency-only” access with strict monitoring. PIM can fail when you need it most.
6. Block legacy authentication tenant-wide. If legacy auth is still possible, the break glass account becomes a soft target.
7. Perform a controlled sign-in test. Validate you can sign in, open Entra, and view Conditional Access. Then sign out and confirm logs are captured.

Gotcha: I never “test” by turning off policies for the whole tenant. I test in a controlled window, with a rollback plan.

Optional admin automation (keep it short and readable): I sometimes export Conditional Access policies via Microsoft Graph for evidence using commands like Connect-MgGraph -Scopes "Policy.Read.All" and Get-MgIdentityConditionalAccessPolicy.

Conditional Access policy settings that won’t lock you out

The biggest mistake I see is overreacting: teams exclude break glass from every Conditional Access policy. That “works” until the account gets phished or guessed, then nothing stands in the attacker’s way.

Instead, I do two things:

1. Exclude break glass from only the policies that could create total lockout, like a policy that blocks all cloud apps or requires a device state you can’t meet in a crisis.

2. Create one dedicated Emergency Access Conditional Access policy that still applies to break glass accounts.

Here’s a practical example you can copy as a starting point:

Setting	Recommendation	Why I do it
Users	Include break glass accounts	Keeps them governed
Cloud apps	Include “All cloud apps”	Prevents weird gaps
Conditions	Limit by Named locations (your offices, VPN egress)	Reduces exposure
Grant	Require authentication strength: phishing-resistant MFA	Stops most credential theft paths
Session	Keep defaults, avoid aggressive sign-in frequency	Aggressive sessions can backfire
Client apps	Block legacy auth (if not blocked elsewhere)	Removes old attack paths

For monitoring, I alert on any sign-in for these accounts. If you don’t have a full SIEM, you can still build practical alerts. Even a basic workflow can route alerts to a small on-call group. For broader Microsoft 365 hardening priorities, I often reference Microsoft 365 security best practices (2026) to help teams focus on what matters first.

Common pitfalls I flag in CMMC Level 2 reviews

I’ve seen these mistakes cost teams days of recovery time:

• Excluding break glass from Conditional Access entirely: you remove safety rails when you need them most.
• Using shared mailboxes or group access: auditors want unique accountability, and so should you.
• Relying on SMS for MFA: it’s too easy to intercept or redirect.
• Storing credentials in a password manager without dual control: if one admin gets compromised, the emergency account goes too.
• Not testing: an untested break glass account is a false sense of security.

Compensating control (label it clearly): if phishing-resistant MFA is not feasible yet, I document a temporary exception, restrict sign-in to Named locations, add extra alerting, and set a short deadline to move to passkeys or FIDO2.

Auditor evidence checklist (save this as you build)

I like to collect evidence as I configure, not weeks later. For CMMC Level 2, these artifacts usually map cleanly to SSP statements and objective evidence.

• Screenshots of both break glass user objects (user details, roles assigned, authentication methods page).
• Export of Conditional Access policies (JSON export or Graph output), including the emergency policy.
• Screenshots of Named locations used by the emergency policy.
• Sign-in log exports showing a successful test sign-in and sign-out (with timestamps).
• Audit log exports for role assignment and authentication method registration.
• A short break glass runbook: who can open the safe, how dual control works, how to rotate credentials.
• Evidence of periodic testing (ticket, change record, or signed test log).

Conclusion

When I set up Entra break glass accounts for CMMC Level 2 clients, I’m not just preventing lockouts. I’m building a defensible control that auditors can follow end to end. Keep the accounts rare, monitored, and tested, then document the “why” in your SSP. If you want, I can review your current Conditional Access design and help you harden it without breaking your day-to-day admin flow.