This chapter covers emergency access or 'break-glass' accounts in Azure Active Directory, a critical identity governance mechanism for maintaining administrative access during emergencies. For the AZ-104 exam, this topic appears in the 'Manage Identities and Governance' domain (15-20% of the exam) and is typically tested with scenario-based questions asking when and how to configure break-glass accounts. Understanding break-glass accounts is essential because they prevent tenant-wide lockout due to misconfigured policies, expired credentials, or compromised MFA devices – a scenario that can bring an entire organization to a halt.
Jump to a section
Imagine a high-security office building with electronic locks on every door. Most employees have keycards that grant access based on their role: IT has server room access, finance has the accounting floor, and so on. But what happens if the electronic access control system fails? Employees can't get in, and more critically, the security team can't access the system to fix it. To handle this, the building has a fireproof key box bolted to the wall near the main entrance. This box contains a master key that opens every door in the building, including the server room and security office. The box itself has a combination lock known only to the most senior security officers. There are strict procedures: the combination is stored in a sealed envelope in a safe deposit box at a bank, and using the master key requires two people to be present. Every use is logged with a timestamp and the names of the individuals. After the emergency is resolved, the master key is returned and the combination is changed. This is exactly how break-glass accounts work in Azure AD. The break-glass account is the master key – it has full, unrestricted access to the entire Azure AD tenant. Its credentials (the combination) are kept extremely secure, not used for daily operations, and only accessed in an emergency when normal administrative access is lost. Just like the fireproof key box, the account is monitored and its usage triggers alerts. And after use, the credentials are rotated to prevent future unauthorized access. The analogy breaks down only in that Azure AD break-glass accounts are cloud-based and can be accessed from anywhere, but the security principles are identical.
What Are Break-Glass Accounts and Why Do They Exist?
Break-glass accounts are emergency access accounts in Azure Active Directory that are assigned the Global Administrator role and are exempt from all conditional access policies, multi-factor authentication requirements, and other security controls. Their sole purpose is to provide a backdoor into the Azure AD tenant when normal administrative access is lost. The term 'break-glass' comes from the physical security concept of breaking a glass panel to access an emergency key or alarm.
In any Azure AD tenant, there are several scenarios where administrators can lose access:
A conditional access policy that requires MFA from a specific location (e.g., corporate network) is misconfigured, locking out all admins.
All users, including admins, are required to use MFA, but the MFA provider (e.g., phone, authenticator app) is unavailable for all admins.
The last Global Administrator leaves the company and their account is deleted.
A malicious insider or external attacker changes the credentials of all admin accounts.
Break-glass accounts are designed to survive these scenarios. They are not subject to any conditional access policies, MFA requirements, or sign-in frequency controls. They can sign in from any location, any device, and at any time. However, because they are so powerful, they must be secured with extreme care.
How Break-Glass Accounts Work Internally
Break-glass accounts are simply Azure AD user accounts that are assigned the Global Administrator role. What makes them 'break-glass' is not a special account type, but the way they are configured and managed. The key characteristics are:
Exemption from Conditional Access: Break-glass accounts are explicitly excluded from all conditional access policies. This is done by adding the account to an exclusion group or by creating a conditional access policy that applies to all users except the break-glass accounts.
No MFA Requirement: The accounts use a long, complex password (at least 16 characters, ideally 20+) that is stored securely, often in a physical safe or a password manager with break-glass access procedures. Because they are exempt from MFA, they rely solely on password strength and procedural controls.
Monitoring and Alerting: Azure AD logs all sign-in activity. A monitoring rule (e.g., Azure Monitor alert) is configured to trigger when a break-glass account signs in. This alert goes to security operations teams immediately.
Credential Rotation: After each use, the password is changed. This prevents the account from being used again without proper authorization.
From a protocol perspective, when a break-glass account signs in, Azure AD checks the user's authentication method. Since the account is exempt from MFA, Azure AD skips the MFA step. The token issued includes the Global Administrator role, granting full access to Azure AD, Azure subscriptions, and any management groups where the account has been assigned. The token's lifetime is governed by the default token lifetime policies (typically 1 hour for access tokens, 24 hours for refresh tokens).
Key Components, Values, Defaults, and Timers
Account Name: Break-glass accounts should be clearly identifiable, e.g., 'break-glass-admin' or 'emergency-access'. Avoid generic names like 'admin' or 'backup'.
Password Length: Minimum 16 characters, recommended 20+ characters. Must include uppercase, lowercase, numbers, and special characters.
Password Storage: The password should be stored in a secure location, such as a physical safe, a password manager with break-glass workflows (e.g., CyberArk, HashiCorp Vault), or split into parts held by different individuals.
Exclusion from Conditional Access: The account must be added to a conditional access policy exclusion. For example, create a policy that applies to 'All users' but excludes the break-glass account.
Monitoring: An Azure Monitor alert rule should be created with a condition like 'Sign-ins from users not in allowed users' or a custom log search for the break-glass account's sign-in events. The alert should have a severity of 'Sev 0' or 'Critical' and notify the security team via email, SMS, or webhook.
Audit Logs: Azure AD Audit Logs record all sign-in and role assignment changes. These logs have a retention period of 30 days for Azure AD Premium P1, 30 days for P2, and 7 days for Free. For long-term retention, export logs to Azure Monitor Logs or Azure Storage.
Number of Accounts: Microsoft recommends at least two break-glass accounts to avoid a single point of failure. One account might be locked out or its password lost.
Configuration and Verification Commands
To configure break-glass accounts, you can use the Azure portal, PowerShell, or Azure CLI.
Creating a Break-Glass Account via Azure Portal: 1. Navigate to Azure Active Directory > Users > New user. 2. Create a user with a clear name like 'Emergency Access Admin'. 3. Assign the Global Administrator role. 4. Set a strong password and note it down. 5. Exclude this user from all conditional access policies.
Using PowerShell (AzureAD module):
Connect-AzureAD
$passwordProfile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
$passwordProfile.Password = "YourStrongPassword!2023"
New-AzureADUser -DisplayName "Emergency Access Admin" -UserPrincipalName "break-glass@yourtenant.onmicrosoft.com" -PasswordProfile $passwordProfile -AccountEnabled $true -MailNickName "breakglass"
Add-AzureADDirectoryRoleMember -ObjectId (Get-AzureADDirectoryRole -Filter "DisplayName eq 'Global Administrator'").ObjectId -RefObjectId (Get-AzureADUser -Filter "UserPrincipalName eq 'break-glass@yourtenant.onmicrosoft.com'").ObjectIdUsing Azure CLI:
az ad user create --display-name "Emergency Access Admin" --user-principal-name break-glass@yourtenant.onmicrosoft.com --password "YourStrongPassword!2023" --force-change-password-next-sign-in false
az ad role assignment create --assignee break-glass@yourtenant.onmicrosoft.com --role "Global Administrator"Verification: To verify that the account is exempt from conditional access, you can test sign-in from a non-corporate network. The account should be able to sign in without MFA. You can also use the 'What If' tool in conditional access to check if the account is affected by any policy.
Interaction with Related Technologies
Break-glass accounts interact with several Azure AD features:
Conditional Access: Break-glass accounts must be excluded from all policies. If not, they are subject to the same restrictions as other users, defeating their purpose.
Identity Protection: Break-glass accounts should be excluded from Identity Protection policies (e.g., risky sign-in policies) to avoid being blocked.
Privileged Identity Management (PIM): Break-glass accounts should NOT be managed via PIM. PIM requires activation with MFA, which defeats the purpose. Break-glass accounts should be permanently and directly assigned the Global Administrator role.
Azure AD Connect: If using hybrid identity, break-glass accounts should be cloud-only (not synchronized from on-premises). This ensures they are not affected by on-premises AD issues.
Microsoft 365 Defender: Break-glass account sign-ins should trigger high-severity alerts in Microsoft 365 Defender for Cloud Apps (formerly MCAS).
Identify the Need for Break-Glass Accounts
The first step is to recognize the scenarios where break-glass accounts are necessary. In any Azure AD tenant, there is a risk of losing administrative access due to misconfigured conditional access policies, MFA provider outages, or credential compromise. Organizations with strict security policies (e.g., requiring MFA for all admins) are particularly vulnerable. The AZ-104 exam expects you to identify that break-glass accounts are needed when there is a risk of tenant-wide lockout. For example, if a conditional access policy requires MFA from a trusted IP range but all admins are outside that range, they cannot sign in. Break-glass accounts provide a bypass. At the protocol level, when an admin tries to sign in, Azure AD evaluates conditional access policies. If the policy requires MFA and the admin cannot satisfy it, the sign-in is blocked. A break-glass account, being excluded from the policy, skips this evaluation and is allowed to sign in with just a password.
Create Dedicated Break-Glass Accounts
Create at least two cloud-only user accounts in Azure AD. These accounts should have a clear naming convention (e.g., 'break-glass-1', 'break-glass-2') and be assigned the Global Administrator role permanently. Do not use PIM for these accounts because PIM requires MFA for activation. The accounts must be cloud-only, not synchronized from on-premises, to avoid being affected by on-premises AD issues. From a directory perspective, these accounts are regular user objects but with the 'Global Administrator' role assignment. The role assignment is stored in the directory as a role assignment object. When the account signs in, Azure AD includes the role in the token's 'roles' claim. The token is issued by the Azure AD STS (Security Token Service) after successful authentication.
Assign Strong, Long Passwords
Generate passwords that are at least 16 characters long, ideally 20-30 characters, containing a mix of uppercase, lowercase, numbers, and special characters. Do not use phrases or patterns that can be guessed. The password should be generated using a cryptographically secure random generator. Store the password securely: either in a physical safe, a password manager with break-glass workflows, or split into two parts held by different individuals. The password is the single factor of authentication since MFA is not used. The password hash is stored in Azure AD using password hash synchronization (if enabled) or cloud-only storage. When the user signs in, Azure AD verifies the password against the stored hash using the PAuth protocol.
Exclude from Conditional Access Policies
Configure all conditional access policies to explicitly exclude the break-glass accounts. This can be done by adding the accounts to a group and excluding that group from every policy, or by adding the accounts individually in each policy's 'Exclude' section. The most reliable approach is to create a dedicated group (e.g., 'Break-Glass Accounts') and exclude that group from all policies. This ensures that no policy can inadvertently block the break-glass accounts. From a conditional access engine perspective, when a sign-in occurs, the engine evaluates all policies that apply to the user. If the user is in the exclusion list, the policy is not evaluated. The break-glass accounts are effectively invisible to conditional access.
Monitor and Alert on Usage
Set up monitoring and alerting for any sign-in activity from the break-glass accounts. In the Azure portal, create an Azure Monitor alert rule that triggers when the break-glass account signs in. Use a log search query like: 'SigninLogs | where UserPrincipalName == "break-glass@yourtenant.onmicrosoft.com"'. Set the alert severity to 'Critical' and configure action groups to notify the security team via email, SMS, or webhook. Additionally, enable Azure AD Identity Protection to detect risky sign-ins, but exclude break-glass accounts from any policies that might block them. The alert should be immediate, as any use of a break-glass account is potentially an emergency or a security incident.
Rotate Credentials After Use
After any use of a break-glass account, immediately change the password. This ensures that if the password was compromised during the emergency, it cannot be used again. The new password should be generated with the same strength requirements and stored securely. The rotation process should be documented and practiced regularly. In addition to password rotation, consider rotating the account name (e.g., create a new break-glass account and delete the old one) for maximum security. From an audit perspective, the password change event will be logged in Azure AD Audit Logs. The old password hash is invalidated, and any tokens issued with the old password will become invalid once the token lifetime expires.
Enterprise Scenario 1: MFA Provider Outage
A large financial institution uses Azure AD with Conditional Access policies that require MFA for all administrators. The MFA provider (e.g., phone calls, SMS) experiences a regional outage, and administrators cannot receive MFA prompts. As a result, all Global Administrators are locked out of the Azure portal and Microsoft 365 admin center. The organization has two break-glass accounts configured with long, complex passwords stored in a physical safe in the CEO's office. The security officer retrieves the password, signs in with the break-glass account, and temporarily disables the MFA requirement for the affected policies. Once the MFA provider is restored, the break-glass account password is rotated, and the policies are re-enabled. Without break-glass accounts, the organization would have to contact Microsoft Support to regain access, which could take hours or days.
Enterprise Scenario 2: Misconfigured Conditional Access Policy
A mid-sized company implements a new Conditional Access policy that requires all users, including admins, to sign in from a trusted IP range (the corporate office). However, the policy is accidentally applied to 'All users' without excluding the break-glass accounts. The administrators are working remotely and cannot sign in because their IP addresses are not in the trusted range. They are locked out. If break-glass accounts were properly excluded, they could sign in from any location and fix the policy. In this case, the company had not created break-glass accounts, so they had to call Microsoft Support to disable the policy. This took 4 hours, during which no administrative changes could be made. The lesson: always exclude break-glass accounts from all Conditional Access policies.
Enterprise Scenario 3: Loss of the Last Global Administrator
A startup has only one Global Administrator who leaves the company. The administrator's account is deleted by HR before IT can transfer the role. With no other Global Administrators, the tenant is effectively orphaned. However, the company had created two break-glass accounts with passwords stored in a password manager. The new IT manager accesses the password manager, signs in with a break-glass account, and assigns the Global Administrator role to other users. The break-glass accounts save the company from having to recreate the entire tenant. Microsoft Support can also assist in such scenarios, but this requires proof of ownership and can take days. Break-glass accounts provide immediate access.
What AZ-104 Tests on This Topic
The AZ-104 exam objective 'Manage identities and governance in Azure' (15-20%) includes the subtopic 'Manage Azure AD users and groups' which covers break-glass accounts. Specifically, the exam expects you to:
Understand the purpose and use cases for break-glass accounts.
Know how to create and configure break-glass accounts.
Know how to exclude break-glass accounts from Conditional Access policies.
Understand the importance of monitoring and alerting.
Know the difference between break-glass accounts and emergency access accounts managed via PIM.
Common Wrong Answers and Why Candidates Choose Them
'Break-glass accounts should use MFA.' – Candidates often think that MFA is always required for admin accounts. But break-glass accounts are specifically designed to work when MFA is unavailable. The correct answer is that break-glass accounts should NOT use MFA.
'Break-glass accounts should be managed via Privileged Identity Management (PIM).' – PIM requires activation with MFA, which defeats the purpose. Break-glass accounts must have permanent, direct role assignments.
'Break-glass accounts should be synchronized from on-premises AD.' – This is wrong because if on-premises AD is compromised or unreachable, the accounts become inaccessible. Cloud-only accounts are independent.
'One break-glass account is sufficient.' – Microsoft recommends at least two to avoid a single point of failure.
Specific Numbers, Values, and Terms
Password length: At least 16 characters.
Number of accounts: At least two.
Account type: Cloud-only.
Role: Global Administrator (permanent assignment).
Exclusion: Must be excluded from all Conditional Access policies.
Monitoring: Azure Monitor alert on sign-in.
Rotation: After each use.
Edge Cases and Exceptions
Azure AD Free tier: Audit logs are retained for only 7 days. For long-term monitoring, you need Azure AD Premium P1 or P2.
Azure AD B2B guest accounts: Break-glass accounts should not be guest accounts; they must be members of the tenant.
Service accounts: Break-glass accounts are not service accounts; they are for human administrators.
Microsoft 365 admin center: Break-glass accounts can also access the M365 admin center because they are Global Administrators.
How to Eliminate Wrong Answers
When you see a question about break-glass accounts, look for keywords:
If the question mentions MFA, the answer should state that break-glass accounts are exempt from MFA.
If the question mentions PIM, the answer should state that break-glass accounts should not use PIM.
If the question mentions synchronization, the answer should state break-glass accounts are cloud-only.
If the question mentions a single account, the answer should state that at least two are needed.
Use the underlying mechanism: break-glass accounts are a 'break glass in case of emergency' tool. They must work when everything else fails. Therefore, any option that adds a dependency (MFA, PIM, on-premises, single account) is wrong.
Break-glass accounts are emergency access accounts that bypass MFA and Conditional Access.
Create at least two cloud-only break-glass accounts with permanent Global Administrator role.
Use passwords at least 16 characters long, stored securely (e.g., physical safe).
Exclude break-glass accounts from all Conditional Access policies.
Monitor break-glass account sign-ins with Azure Monitor alerts.
Rotate break-glass account passwords immediately after any use.
Do not manage break-glass accounts with PIM; they must have direct role assignment.
Break-glass accounts are a safety net against tenant-wide lockout.
These come up on the exam all the time. Here's how to tell them apart.
Break-Glass Account (Direct Assignment)
Permanent role assignment; no activation required.
No MFA requirement; password-only sign-in.
Excluded from Conditional Access policies.
Not suitable for daily use; only for emergencies.
Requires manual password rotation after use.
Privileged Identity Management (PIM) Role Activation
Temporary role assignment; requires activation for a limited time.
Requires MFA for activation.
Respects Conditional Access policies.
Suitable for just-in-time privileged access for daily tasks.
Automatic deactivation after the activation duration expires.
Mistake
Break-glass accounts must have MFA enabled for security.
Correct
Break-glass accounts must NOT have MFA enabled. They are designed to be used when MFA is unavailable, so they rely solely on a strong password and procedural controls.
Mistake
Break-glass accounts should be managed via Privileged Identity Management (PIM).
Correct
PIM requires activation with MFA, which defeats the purpose. Break-glass accounts must have a permanent, direct role assignment.
Mistake
One break-glass account is enough.
Correct
Microsoft recommends at least two break-glass accounts to avoid a single point of failure (e.g., password lost or account locked).
Mistake
Break-glass accounts can be synchronized from on-premises Active Directory.
Correct
Break-glass accounts must be cloud-only to ensure they are not affected by on-premises AD issues (e.g., server outage, compromise).
Mistake
Break-glass accounts are a special account type in Azure AD.
Correct
Break-glass accounts are regular user accounts with the Global Administrator role. What makes them break-glass is the configuration: no MFA, excluded from Conditional Access, and monitored.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Microsoft recommends creating at least two break-glass accounts. This ensures that if one account's password is lost or the account is accidentally disabled, you still have a backup. In an emergency, you need a reliable way to regain access. Having two accounts also allows you to rotate one while keeping the other available.
No, you should not use PIM for break-glass accounts. PIM requires MFA for activation, which defeats the purpose of a break-glass account that must work when MFA is unavailable. Break-glass accounts should have a permanent, direct assignment of the Global Administrator role.
No, break-glass accounts must be cloud-only. If they are synchronized, they depend on the on-premises AD, which could be compromised or unavailable. Cloud-only accounts are independent and can be accessed even if the on-premises environment is down.
Use a password that is at least 16 characters long, ideally 20-30 characters. It should contain a mix of uppercase, lowercase, numbers, and special characters. Generate the password using a cryptographically secure random generator. Store the password securely, such as in a physical safe or a password manager with break-glass workflows.
Create a security group (e.g., 'Break-Glass Accounts') and add the break-glass accounts to it. Then, in each Conditional Access policy, configure the 'Exclude' section to exclude that group. This ensures that all break-glass accounts are exempt from all policies. Alternatively, you can exclude individual accounts, but using a group is easier to manage.
Set up an Azure Monitor alert rule that triggers when a break-glass account signs in. Use a log search query like: 'SigninLogs | where UserPrincipalName == "break-glass@yourtenant.onmicrosoft.com"'. Configure the alert to notify the security team via email, SMS, or webhook. Also, enable Azure AD Identity Protection but exclude break-glass accounts from any blocking policies.
No, break-glass accounts should only be used in emergencies. Their use should be rare, monitored, and audited. For daily administration, use regular admin accounts with PIM for just-in-time access.
You've just covered Emergency Access Break-Glass Accounts — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?