In every well-architected identity security strategy, Break glass accounts play a critical role in identity resilience, providing emergency access when normal authentication mechanisms fail as a result of policy misconfiguration, service disruptions, or enforcement errors. These accounts are intentionally excluded from Conditional Access and other controls so they remain accessible during emergencies; however, these exceptions make them high-risk and demand strong governance and monitoring.

This article covers industry-aligned best practices for emergency access accounts in Microsoft Entra ID and explains how to implement real-time monitoring and alerting with Azure Log Analytics, ensuring break glass accounts are both accessible during emergencies and visible when used.

What Are Break Glass Accounts and Why They Matter

A break glass account is a cloud-only Global Administrator account reserved strictly for emergency recovery scenarios. These scenarios include being accidentally locked out due to overly restrictive Conditional Access policies, authentication outages, or mistakes in MFA configurations.

Because break glass accounts are excluded from usual protections, they:

• Must use strong, unique passwords
• Should not be tied to individuals’ daily tasks
• Should be audited continuously
• Must be monitored for any usage or changes

Failing to treat these accounts as critical security events can leave your organization vulnerable to misuse or undetected compromise.

Best Practices for Break Glass Accounts

Here are the foundational practices worth adopting before you even consider monitoring:

1. Maintain Redundant Access

Always have at least two emergency access accounts. Redundancy ensures that if one account becomes inaccessible (e.g., forgotten password, lost MFA device), you still retain access to the tenant.

2. Use Cloud-Only Identities

Break glass accounts should be cloud-only. Avoid syncing these accounts from on-premises directories because local failures or sync issues could also impact availability.

3. Choose Strategic Names

Avoid predictable names (e.g., admin1@). Instead, use names that do not clearly indicate administrative purpose, making them harder to target during reconnaissance or brute-force attacks.

4. Store Credentials Securely

Credentials should be stored in a physical secure vault or password manager that only designated responders can access. Avoid storing them in accessible documents or personal notes.

5. Use Strong Passwords and Secure MFA

Passwords should be long, complex, and not reused elsewhere. While break glass accounts are often excluded from MFA enforcement via Conditional Access, it’s still best to couple them with highly secure authentication methods (e.g., Fido2 Security keys) that are not tied to personal devices.

6. Exclude from Conditional Access Deliberately

Conditional Access exclusions should be deliberately scoped and clearly documented, with periodic reviews to confirm they remain appropriate and do not unintentionally broaden access.

7. Regularly Validate and Document Use Cases

Break glass accounts should be reserved strictly for emergency scenarios. Emergency access events, including planned drills or actual usage, should be periodically reviewed and documented to validate readiness and ensure continued adherence to established procedures.

The importance of Monitoring

Best practices form a critical foundation, but without proper monitoring, organizations lack visibility into access or changes involving break glass accounts, allowing potentially unauthorized activity to go undetected.

Monitoring should offer:

• Immediate visibility of any sign-in
• Detailed context on the method and source of access
• Real-time alerts so teams can investigate promptly

Monitoring Break Glass Access Using Log Analytics Alerts

Azure Log Analytics, and Kusto Query Language (KQL), provides a flexible way to analyze identity signals and monitor high-risk activity in Microsoft Entra ID. By centralizing sign-in and audit logs in a Log Analytics workspace, organizations can build targeted queries and alerts that detect break glass account usage in near real time.

Prerequisite: Export Logs to Log Analytics

Ensure both SignInLogs and AuditLogs from Microsoft Entra ID are exported to a Log Analytics Workspace via diagnostic settings. This enables you to run queries and configure alerts on entries related to break glass accounts.

Create Log Analytics Alert to Detect Break Glass Sign-Ins

Configure an alert in Log Analytics that triggers whenever a break glass account signs in.

• Alert type: Custom log search condition
  Use a custom KQL-based condition to evaluate sign-in activity captured in the SignInLogs table.
• KQL search query: Detect break glass sign-ins
  The query should filter for successful sign-in events associated with designated break glass accounts and project relevant context such as time, application, location, and authentication details.

Use the following query to capture any sign-ins events by your break glass accounts:

SigninLogs
| where UserPrincipalName in (
"[email protected]",
"[email protected]"
)
| project
TimeGenerated,
UserPrincipalName,
AppDisplayName,
IPAddress,
Location,
ClientAppUsed,
AuthenticationRequirement,
ConditionalAccessStatus

This query looks for any sign-ins attempt by accounts that are designated as break glass, and projects additional context such as the client application, location, and conditional access status.

Alert Rule Configuration

When you create your alert under your Log Analytics Workspace:

• Condition: Trigger when result count > 0 for the query
• Evaluation frequency: Every 5 minutes
• Alert severity: Critical (Sev 0 or Sev 1)

• Notification target: IAM/security team distribution list, on-call responders, or even automated Teams/PagerDuty integrations

Why Automated Remediation Is Not Recommended

For break glass alerts, automated remediation such as disabling the account or resetting credentials is not recommended. The primary purpose of these accounts is to function when standard protections fail. Triggering automated actions in response to break glass usage can escalate an incident, delay recovery efforts, or inadvertently lock responders out of the tenant entirely.
Instead, alerts should trigger prompt immediate review and action by designated Cyber team.

Operational Lessons

• Include break glass alert behavior in your incident playbooks.
• Test alerts and logging as part of quarterly review cycles.
• Ensure alerts are not filtered out by noise suppression rules.
• Train your response teams on what to do when a break glass alert fires.

Final Thoughts

Break glass accounts are an essential safety mechanism, but without proper governance they can quickly become a source of risk. By applying clear best practices and proactive monitoring through Azure Log Analytics and alerting, organizations can detect critical events promptly and respond effectively.

Reference:

Tutorial — Create a log search alert for an Azure resource — Azure Monitor | Microsoft Learn