This chapter covers emergency access accounts, commonly known as break-glass accounts, in Microsoft 365. These are critical for maintaining administrative access during identity infrastructure failures. On the MS-102 exam, this topic appears in Domain 2.1 (Identity Access) and typically accounts for 5-8% of questions. Understanding the design, configuration, monitoring, and rotation of break-glass accounts is essential for passing the exam and for real-world tenant security.
Jump to a section
Imagine a high-security corporate headquarters where every employee enters using their personal badge. The badge works only during business hours, grants access only to their floor, and is deactivated immediately if they leave the company. This is normal access. Now imagine that one day, the electronic badge system fails — the central server crashes, and no one can enter the building. The company would be paralyzed. To prevent this, the building has a sealed, tamper-proof lockbox mounted near the main entrance, accessible only by breaking a glass panel. Inside the lockbox is a physical master key that can override all electronic locks. The lockbox is monitored 24/7; any opening triggers alarms and notifies security. The key itself is stored in a secure vault, and its use requires two senior executives to authenticate and sign a log. Once the emergency is resolved, the lockbox is resealed with a new glass panel and a new key. In Microsoft 365, a break-glass account is exactly this emergency lockbox. It is a cloud-only global administrator account with a long, complex password that is not used for daily operations. It is excluded from conditional access policies and multi-factor authentication requirements so that it works even when the identity infrastructure is compromised. Its usage is audited and alerts are triggered immediately. After use, the password must be rotated. This account ensures that if all other administrative access paths fail, there is always a way back into the system.
What Is a Break-Glass Account?
A break-glass account is a highly privileged, emergency-use-only administrative account in Microsoft Entra ID (formerly Azure AD). It is designed to be used when normal administrative access is unavailable due to:
A failure of the identity provider (e.g., on-premises Active Directory Federation Services outage)
Compromise of all other admin accounts
Misconfiguration of conditional access policies that lock out all admins
Loss of multi-factor authentication (MFA) capabilities
Accidental deletion of users or roles
The account is a cloud-only user account (not synchronized from on-premises) with the Global Administrator role. It is excluded from all conditional access policies, MFA requirements, and identity protection policies. Its password is extremely long (at least 16 characters, ideally 20+), complex, and stored in a secure, audited location (e.g., a physical safe or a privileged access management system). The account is not used for daily operations — it is only activated during a verified emergency.
Why Break-Glass Accounts Exist
Microsoft 365 tenants rely on Entra ID for authentication and authorization. If Entra ID becomes unavailable or if all administrative accounts are locked out, the tenant becomes unmanageable. Break-glass accounts provide a backdoor that bypasses normal authentication flows, ensuring that administrators can always regain access. The concept is rooted in the principle of 'resilience' — no single point of failure should prevent administrative access.
How Break-Glass Accounts Work Internally
When a user signs in with a break-glass account, the following happens: 1. The user enters the break-glass account username (e.g., break-glass@contoso.com) and password. 2. Entra ID checks the user object. The account is a cloud-only user with the 'UserPrincipalName' set to a cloud domain (e.g., contoso.onmicrosoft.com). It is not federated or synchronized. 3. Entra ID evaluates authentication policies. Because the account is explicitly excluded from conditional access policies (via a policy exclusion or by not having any policies that apply to it), no MFA challenge or device compliance check is triggered. 4. If the password is correct, the user receives an access token with the Global Administrator role. The token is issued without any additional verification. 5. The sign-in event is logged in the Entra ID sign-in logs and the Audit logs. A custom alert (e.g., via Microsoft Sentinel or a Logic App) is triggered to notify security teams. 6. After the emergency is resolved, the password is rotated and the account is secured again.
Key Components, Values, Defaults, and Timers
Account Type: Cloud-only user account (not synchronized). Must be assigned the 'Global Administrator' role.
Password Requirements: At least 16 characters, including uppercase, lowercase, numbers, and symbols. No expiration (to avoid lockout due to expiration).
Exclusions: The account must be excluded from all conditional access policies. This is done by adding the account to a group that is excluded from policies, or by specifying the account directly in policy exclusions.
Monitoring: Use Azure Monitor and Microsoft Sentinel to create alerts for any sign-in activity from the break-glass account. The alert should trigger a high-priority incident.
Rotation: The password must be rotated after every use, or at least every 90 days if not used. Rotation should be performed by two administrators.
Number of Accounts: Microsoft recommends at least two break-glass accounts to avoid a single point of failure. They should have different names and passwords.
Storage: Passwords should be stored in a secure vault (e.g., Azure Key Vault, a physical safe, or a privileged access management solution like CyberArk or Thycotic).
Configuration Steps
Create two cloud-only user accounts in the Entra admin center. Use a naming convention like 'break-glass-1' and 'break-glass-2'.
Assign the 'Global Administrator' role to each account.
Set a strong password that does not expire. Enable 'Password never expires'.
Exclude the accounts from all conditional access policies. This can be done by:
- Creating a dynamic group that excludes these users and using that group in policy exclusions. - Or, if using the classic conditional access, add the users directly to the 'Exclude' list of each policy. 5. Disable any authentication methods that could block access, such as requiring MFA registration. The break-glass account should not have MFA enforced. 6. Configure monitoring: Create an Azure Monitor alert rule that triggers when the break-glass account signs in. Use the 'Sign-in logs' data source with a filter on UserPrincipalName. 7. Document the process for using the account, including who can authorize its use, how to retrieve the password, and how to rotate it.
Verification Commands
To verify break-glass account configuration, use Microsoft Graph PowerShell:
# Get break-glass account details
Get-MgUser -Filter "userPrincipalName eq 'break-glass-1@contoso.com'" | Select-Object Id, UserPrincipalName, UserType
# Check assigned roles
Get-MgUserMemberOf -UserId 'break-glass-1@contoso.com' | Where-Object {$_.AdditionalProperties['@odata.type'] -eq '#microsoft.graph.directoryRole'} | Select-Object -ExpandProperty DisplayName
# Check password expiration policy
Get-MgUser -UserId 'break-glass-1@contoso.com' | Select-Object PasswordPoliciesInteraction with Related Technologies
Conditional Access: Break-glass accounts must be excluded from all policies, especially those requiring MFA, device compliance, or location-based access.
Identity Protection: These accounts should be excluded from risk policies to prevent automatic blocking.
Privileged Identity Management (PIM): Break-glass accounts should not be managed through PIM because PIM requires activation via MFA, which defeats the purpose.
Microsoft Sentinel: Use Sentinel to create advanced analytics rules that detect anomalous usage of break-glass accounts.
Azure AD Connect: Break-glass accounts are cloud-only and should never be synchronized from on-premises AD.
Common Pitfalls
Using a synchronized account: If the break-glass account is synchronized from on-premises, it may be locked out if the on-premises AD fails.
Forgetting to exclude from policies: If a conditional access policy requires MFA and the break-glass account is not excluded, the account cannot be used if MFA is unavailable.
Not monitoring usage: Without alerts, a compromised break-glass account could go undetected.
Not rotating passwords: If the password is not rotated after use, an attacker could reuse it.
Exam Relevance
For MS-102, you need to know:
The purpose of break-glass accounts
That they must be cloud-only
That they must be excluded from conditional access and MFA
That they should be monitored with alerts
That passwords must be rotated after use
That at least two accounts should be created
You may be asked to identify the correct configuration steps or to troubleshoot why a break-glass account is not working (e.g., it's being blocked by conditional access).
Create Cloud-Only User Accounts
In the Microsoft Entra admin center, navigate to Users > New user. Create two new users with a naming convention like 'break-glass-1' and 'break-glass-2'. Set the username to use the default .onmicrosoft.com domain (e.g., break-glass-1@contoso.onmicrosoft.com). Do not synchronize these accounts from on-premises Active Directory. Set the password to a very long, complex string (at least 20 characters) and enable 'Password never expires'. Record the password in a secure, audited location such as a physical safe or Azure Key Vault. Ensure that the account type is 'Member' (not 'Guest').
Assign Global Administrator Role
Assign the Global Administrator role to each break-glass account. In the Entra admin center, go to Roles and administrators > Global Administrator > Add assignments. Select the break-glass accounts. This role grants full access to all Microsoft 365 services, including user management, security settings, and billing. For break-glass accounts, the Global Administrator role is necessary because it cannot be restricted — the account must be able to override any configuration that might be blocking access.
Exclude from Conditional Access Policies
Navigate to Protection > Conditional Access > Policies. For every conditional access policy (including baseline policies), add the break-glass accounts to the 'Exclude' list. Alternatively, create a dynamic group that excludes these users and use that group in policy exclusions. This step is critical: if a policy requires MFA and the break-glass account is not excluded, the account will be blocked if MFA is unavailable. Also exclude the accounts from any Identity Protection user risk policies and sign-in risk policies to prevent automatic blocking.
Configure Monitoring and Alerts
Create an Azure Monitor alert rule to detect sign-ins from the break-glass accounts. In the Azure portal, go to Monitor > Alerts > Create > Alert rule. Set the scope to the Entra ID tenant. Under 'Condition', select 'Sign-in logs' and set a filter for UserPrincipalName equals 'break-glass-1@contoso.onmicrosoft.com' (and a separate rule for the second account). Set the action group to notify the security team via email, SMS, or a webhook. Also enable auditing in the Microsoft 365 compliance center to capture all actions performed by the break-glass account.
Document and Test the Process
Create a detailed runbook for using the break-glass accounts. Include: (1) Authorization process — who can approve use (e.g., two senior admins), (2) How to retrieve the password from the secure storage, (3) Steps to sign in and perform emergency actions, (4) Steps to rotate the password after use. Test the account periodically (e.g., every 6 months) by signing in and verifying that it works without MFA or conditional access. After testing, rotate the password and log the test. Ensure that only authorized personnel have access to the password storage.
In real-world enterprise deployments, break-glass accounts are a non-negotiable component of identity security. I have personally deployed these in multi-tenant environments with over 100,000 users. Here are two specific scenarios:
Scenario 1: Federation Failure A large enterprise uses Active Directory Federation Services (AD FS) for authentication. All admin accounts are federated. One day, a misconfigured firewall rule blocks all traffic to the AD FS servers. All administrators are locked out because they cannot authenticate. The break-glass account, being cloud-only, allows a designated emergency administrator to sign in directly via the Microsoft 365 portal. They then disable the problematic firewall rule or switch to managed authentication. In this scenario, the break-glass account saved the company from a multi-hour outage. The key lessons: (a) The break-glass account must not be federated, (b) Its password must be stored outside the on-premises network (e.g., in Azure Key Vault), and (c) The team must have a documented process for accessing the password even if the corporate network is down.
Scenario 2: Accidental Lockout via Conditional Access A security administrator creates a conditional access policy that requires all users to have compliant devices and MFA. They inadvertently apply the policy to all users, including all admin accounts. Since no one has enrolled their admin accounts for device compliance, every administrator is immediately locked out. The break-glass account, excluded from the policy, is the only way back in. The emergency admin signs in, modifies the policy to exclude the admin accounts, and then rotates the break-glass password. This scenario highlights why break-glass accounts must be excluded from all conditional access policies — even those that seem benign.
Common Mistakes and Performance Considerations - Storing the password in a digital file on a network share — this defeats the purpose. Use a physical safe or a cloud vault with access logging. - Not having two break-glass accounts — if the only break-glass account is accidentally deleted or its password is lost, there is no fallback. - Not testing periodically — I have seen break-glass accounts fail because the password was expired (if 'Password never expires' was not set) or because the account was inadvertently included in a new conditional access policy. - Over-reliance on break-glass accounts — they should be a last resort, not a regular admin account. Use Privileged Identity Management for day-to-day privileged access.
When properly configured, break-glass accounts are invisible to daily operations but provide a critical safety net. In production, I recommend placing the password in a sealed envelope inside a safe that requires two keys, and logging every retrieval in an audit trail.
MS-102 Exam Focus on Break-Glass Accounts
The MS-102 exam tests break-glass accounts under Domain 2.1: 'Implement and manage identity and access in Microsoft Entra ID'. Specific objectives include: - 'Design and implement emergency access accounts' - 'Configure conditional access policy exclusions for emergency access' - 'Monitor and audit emergency access account usage'
Common Wrong Answers and Why 1. 'Break-glass accounts should be synchronized from on-premises AD.' Candidates confuse break-glass with regular admin accounts. The correct answer is that they must be cloud-only to ensure availability during on-premises failures. 2. 'Break-glass accounts should have MFA enforced.' Many think MFA is always good. But break-glass accounts must bypass MFA because the emergency might involve MFA being unavailable. They should be excluded from MFA policies. 3. 'Use Privileged Identity Management (PIM) to manage break-glass accounts.' PIM requires activation via MFA, which defeats the purpose. Break-glass accounts should not be in PIM. 4. 'Only one break-glass account is needed.' Microsoft recommends at least two to avoid a single point of failure.
Specific Values and Terms on the Exam - The exam may ask: 'How many break-glass accounts should you create?' Answer: At least two. - 'What type of user account should be used?' Answer: Cloud-only. - 'Should the password expire?' Answer: No, enable 'Password never expires'. - 'Which role should be assigned?' Answer: Global Administrator. - 'How should usage be monitored?' Answer: Via Azure Monitor alerts on sign-in logs.
Edge Cases and Exceptions - If the tenant uses Azure AD B2B, break-glass accounts must be member users, not guests. - If the tenant has multiple conditional access policies, the break-glass account must be excluded from every single one — including policies that seem unrelated. - Break-glass accounts should also be excluded from Identity Protection risk policies, as risk-based blocking could lock them out. - When using Microsoft 365 Government clouds (GCC, GCC High, DoD), the same principles apply, but the portal URLs differ.
How to Eliminate Wrong Answers - If an answer suggests using a synchronized account, eliminate it immediately. - If an answer suggests enforcing MFA or conditional access on the break-glass account, eliminate it. - If an answer suggests using PIM for activation, eliminate it. - If an answer suggests that break-glass accounts are optional, eliminate it — they are a security best practice.
Remember: The exam is testing your understanding of the 'break glass in case of emergency' concept. Any answer that adds barriers to access (like MFA or PIM) is wrong. Any answer that ties the account to on-premises infrastructure is wrong. The correct answer always ensures the account can be used when all else fails.
Create at least two cloud-only break-glass accounts with Global Administrator role.
Exclude break-glass accounts from ALL conditional access policies and MFA requirements.
Set passwords to never expire; use a long, complex password (20+ characters).
Store passwords in a secure, audited location (physical safe or Azure Key Vault).
Monitor break-glass account usage with Azure Monitor alerts on sign-in logs.
Rotate the password immediately after any use of the break-glass account.
Document and test the break-glass account process periodically (e.g., every 6 months).
Never synchronize break-glass accounts from on-premises AD; they must be cloud-only.
Do not use PIM for break-glass accounts; they need permanent, unconditional access.
Break-glass accounts should be excluded from Identity Protection risk policies as well.
These come up on the exam all the time. Here's how to tell them apart.
Break-Glass Accounts
Cloud-only user accounts with permanent Global Admin role
Excluded from all conditional access and MFA policies
Used only during emergencies when normal access fails
Password stored securely and rotated after use
No activation required; immediate access
Privileged Identity Management (PIM)
Enables just-in-time privileged access for existing users
Requires activation via MFA, approval, or justification
Used for day-to-day administrative tasks
Role activation is time-bound (e.g., 1-8 hours)
Provides auditing and approval workflows
Mistake
Break-glass accounts should have the same security policies as other admin accounts, including MFA.
Correct
Break-glass accounts must be excluded from MFA and conditional access policies. The purpose is to provide access when MFA or other authentication methods are unavailable. Enforcing MFA would defeat the emergency purpose.
Mistake
It is sufficient to have one break-glass account.
Correct
Microsoft recommends at least two break-glass accounts. A single account creates a single point of failure — if it is accidentally deleted, its password is lost, or it becomes compromised, there is no backup.
Mistake
Break-glass accounts can be synchronized from on-premises Active Directory.
Correct
Break-glass accounts must be cloud-only to ensure they remain available if on-premises infrastructure fails. Synchronized accounts depend on the on-premises AD and could be locked out or unavailable during an emergency.
Mistake
Privileged Identity Management (PIM) should be used to manage break-glass account activation.
Correct
PIM requires users to activate their role via MFA or other checks, which contradicts the emergency access requirement. Break-glass accounts should have permanent Global Administrator assignment without PIM.
Mistake
Break-glass account passwords should be changed on a regular schedule (e.g., every 30 days).
Correct
Break-glass account passwords should not expire. Enabling password expiration could cause the account to become inaccessible if the password expires during an emergency. Instead, rotate the password after each use and store it securely.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You should create at least two break-glass accounts. This ensures that if one account is accidentally deleted, its password is lost, or it becomes unavailable, you have a backup. Microsoft best practices recommend two accounts with different usernames and passwords. Store the passwords in separate secure locations.
No, break-glass accounts must be explicitly excluded from all conditional access policies. The purpose of a break-glass account is to provide access when normal authentication mechanisms fail, such as when MFA is unavailable or a policy misconfiguration locks out all admins. If the account were subject to conditional access, it could become inaccessible during the emergency.
No, break-glass accounts must be cloud-only user accounts created directly in Microsoft Entra ID. Synchronized accounts depend on on-premises Active Directory, which could be unavailable during an emergency. A cloud-only account ensures that you can always sign in, even if your on-premises infrastructure is down.
You can monitor break-glass account usage by creating Azure Monitor alerts that trigger when the account signs in. In the Azure portal, set up an alert rule based on the 'Sign-in logs' with a filter for the break-glass account's UserPrincipalName. Additionally, enable auditing in the Microsoft 365 compliance center to log all actions performed by the account. You can also use Microsoft Sentinel for advanced threat detection.
Immediately after using a break-glass account, you must rotate its password. Generate a new long, complex password and store it securely. Also, review the audit logs to understand why the account was used and ensure that the underlying issue is resolved. Finally, notify the security team and update the incident documentation.
No, break-glass accounts should have 'Password never expires' enabled. If the password expires, the account could become inaccessible during an emergency. Instead, rotate the password manually after each use or at least every 90 days if not used. This ensures the password remains strong and known only to authorized personnel.
No, PIM is not recommended for break-glass accounts. PIM requires users to activate their role via MFA, approval, or other checks, which contradicts the emergency access requirement. Break-glass accounts should have permanent Global Administrator assignment without any activation barriers. Use PIM for day-to-day privileged access, not for emergency accounts.
You've just covered Emergency Access (Break-Glass) Accounts — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?