CMMC Level 2 Break-Glass Accounts for Microsoft 365, a 2-account setup, storage rules, and evidence to capture

If you’ve ever locked yourself out of a Microsoft 365 tenant, you already understand the problem. When Conditional Access, MFA, or identity providers misbehave, you need a way back in. For CMMC Level 2, you also need to prove that your emergency access is controlled, logged, and reviewed.

In this post, I lay out how I set up CMMC break glass accounts in Microsoft Entra ID using a simple two-account model (with separate custodians), how I store and handle the credentials, and what evidence I capture so an assessor can validate the control.

I do this work as part of my Small Business IT practice, across Cloud Infrastructure, Office 365 Migration, and Data Center Technology projects, plus Restaurant POS Support and Kitchen Technology Solutions rollouts where uptime matters just as much as Cybersecurity Services.

What CMMC Level 2 is really asking for with emergency admin access

CMMC Level 2 doesn’t contain a control that says “create break-glass accounts.” Instead, it expects you to protect privileged access, limit who can use it, and produce audit trails. In practice, emergency access accounts become part of your story for access control and auditability during a CMMC assessment.

I anchor my approach on two references:

• The DoD’s CMMC Level 2 Assessment Guide (v2.13), because it clarifies what assessors look for in practice and evidence.
• Microsoft’s mapping guidance such as CMMC Level 2 identification and authentication controls in Entra, because most small teams need a practical Microsoft 365 implementation, not theory.

Here is the key mindset shift: a break-glass account is not a convenience account. It’s like a fire extinguisher behind glass. You want it to work under stress, yet you also want proof that nobody “borrowed” it for routine admin tasks.

In my consulting, I tie this back to IT Strategy for SMBs and Business Continuity & Security. If your tenant is your identity plane, a lockout is an outage.

My 2-account Entra ID setup for CMMC break glass accounts (separate custodians)

Microsoft’s baseline guidance is clear: create two emergency access accounts for redundancy. I start with Microsoft’s own page on emergency access admin accounts, then I tailor it to the tenant’s risk and licensing.

Account design rules I use (and why)

I create exactly two accounts, each owned by a different custodian (two different people, two different approval paths). I typically name them something unremarkable (not “breakglass”) and keep them cloud-only.

I also prefer using the tenant’s *.onmicrosoft.com UPN. That way, if DNS or federation breaks, the accounts still authenticate.

For both accounts:

• I assign Global Administrator (yes, it should be rare, but this is your last resort).
• I block sign-in notifications and set strong monitoring and alerting instead.
• I keep them unlicensed unless there’s a strict business need (mailboxes create extra exposure).
• I document exactly what “emergency use” means in policy.

Conditional Access: one account must survive your own mistakes

This is where many teams fail.

I design two different enforcement profiles:

• BG-1 (Survivability account): excluded from Conditional Access policies that could lock out admins. This is the account I expect to work during CA or MFA failures.
• BG-2 (Hardened emergency account): included in strict policies, including phishing-resistant MFA and device controls, so I still have a “secure way in” for most incidents.

If your tenant uses CA session controls, reauthentication rules matter too. Microsoft’s guidance on requiring reauthentication with Conditional Access helps you avoid long-lived sessions that quietly become risk.

Gotcha: If you’re using Security Defaults, you can’t do user exclusions the same way. In that case, I plan a controlled move to Conditional Access so the break-glass model is actually enforceable.

This setup fits well inside Secure Cloud Architecture projects where I also implement Endpoint Security and Device Hardening (often via a dedicated admin workstation or hardened VM).

Storage and handling rules that hold up in a CMMC Level 2 interview

CMMC assessors tend to ask simple questions with sharp edges: “Who can access the credentials?” and “How do you know they didn’t?”

So I use dual custody. Two accounts, two custodians, and no single person can retrieve both sets of credentials without leaving a trail. I also avoid storing break-glass passwords in the same system that depends on Entra ID SSO, unless I have a tested offline recovery path.

Here is example policy language I deploy and customize:

“The organization maintains two emergency access (break-glass) administrator accounts (BG-1 and BG-2) in Microsoft Entra ID. Each account has a separate custodian. Credentials are stored under dual control using (1) sealed, tamper-evident envelopes in a locked safe and (2) an approved password vault with access approvals and view logs. Emergency use requires an incident ticket and documented approval. All uses trigger immediate log review, password rotation, and a post-incident report within 2 business days.”

From a service delivery view, this is part of my Tailored Technology Services and Cloud Management offering. It’s also where a reliable Business Technology Partner adds value, because the process has to work at 2:00 AM when someone is locked out and your ordering system is down.

The SOP I follow, plus the evidence artifacts auditors expect

I keep the operating procedure short enough to follow, but strict enough to defend.

Sample SOP steps (emergency use)

1. Open an incident ticket and label it “Emergency Admin Access.”
2. Record the trigger (lockout, CA failure, compromised admin, outage).
3. Obtain approval (at minimum, custodian plus security lead or executive approver).
4. Retrieve credentials (safe sign-out log and/or vault approval record).
5. Sign in from an approved admin workstation (or hardened VM) and document actions taken.
6. Export logs immediately after the session (sign-in and audit trails).
7. Rotate the password, validate account state, and complete a short post-incident review.

I also run a scheduled test. I usually do quarterly, because teams change and controls drift. Some orgs do annual, but quarterly gives better muscle memory.

Evidence table (what to capture, where it lives, and how long to keep it)

Below is the evidence set I prepare so an assessor can trace the story end-to-end. Retention varies by tenant licensing and policy, so I document the actual configured retention and keep exports with the incident record.

Evidence artifact	Source in Microsoft 365	How I capture/export	Suggested retention
Break-glass account properties and role assignment	Entra admin center (Users, Roles and administrators)	Screenshot key settings plus directory export/report if available	Life of control + 1 year
Conditional Access policy set and exclusions	Entra admin center (Conditional Access)	Screenshot policy, assignments, and exclusions; change record/ticket	Life of policy + 1 year
Sign-in logs for BG-1/BG-2	Entra admin center (Monitoring and health, Sign-in logs)	Filter by user, export CSV, attach to ticket	At least 12 months accessible, then archive per policy
Audit logs (directory changes, role changes)	Entra admin center (Audit logs)	Filter by target user and timeframe, export CSV	Same as sign-in logs
Unified audit log (admin actions across M365)	Microsoft Purview portal (Audit)	Search by user/time, export results, attach to ticket	Align to your audit log retention setting
Vault access approvals and view logs	Your password vault	Export PDF/CSV showing who approved and who viewed	3 years (or contract requirement)
Incident ticket with action notes	Ticketing system	PDF export of ticket, include approvals and timeline	3 years (or contract requirement)
Quarterly test record	Ticketing system + exported logs	Create a “test” ticket, attach exports and review notes	3 years

If you want a practical walkthrough of how break-glass accounts behave in Microsoft 365 tenants, I also like this third-party summary: break-glass account best practices. I don’t treat it as authority, but it matches what I see in the field.

Conclusion: make it work, then make it provable

CMMC Level 2 isn’t impressed by a clever design if you can’t prove it works. I set up two CMMC break glass accounts, store them under dual custody, test them on schedule, and capture the exact exports that show who did what and when. If you want help tightening this up as part of Technology Consulting, Infrastructure Optimization, or broader Digital Transformation work, start by validating your current Conditional Access exclusions and your evidence trail. The question to ask yourself is simple: if an assessor asked for proof tomorrow, could I produce it in one hour?