ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Microsoft Entra ID • Emergency Access • SigninLogs • AuditLogs • KQL

Someone Used the Break-Glass Account — It Wasn't an Emergency

The emergency access account signed in.

That should have been unusual by design.

There was no tenant lockout.
No outage requiring emergency administration.
No scheduled validation exercise.

So why had the break-glass account been used?

Agent Foskett treated the sign-in as the beginning of the investigation — not the explanation.

Discuss Microsoft SecurityBack to investigations
Agent Foskett investigating unexpected use of a Microsoft Entra emergency access account
Emergency Access Should Be Exceptional.

Microsoft recommends monitoring emergency access accounts and triggering notifications whenever they are used. Unexpected use deserves immediate review.

✓ Confirm the sign-in
✓ Reconstruct the source and authentication
✓ Follow the administrative activity

A successful sign-in was enough to start asking questions

Emergency access accounts exist for situations where normal administrative access cannot be used.

That makes ordinary use unusual by definition.

Agent Foskett first checked whether the organisation was performing an approved validation exercise or responding to a genuine emergency.

Neither explanation applied.

The account had been used outside its expected operating pattern.

Start with the emergency account's Object ID

Usernames can change. The Microsoft Entra user object ID provides a stronger pivot for the known emergency account. Agent Foskett searched SigninLogs for every observed interactive sign-in involving that identity.
break-glass-signins.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let EmergencyAccountId =
"00aa00aa-bb11-cc22-dd33-44ee44ee44ee";
SigninLogs
| where TimeGenerated > ago(30d)
| where UserId =~ EmergencyAccountId
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          AppDisplayName,
          ResourceDisplayName,
          ResultType,
          ResultDescription,
          ConditionalAccessStatus,
          CorrelationId
| order by TimeGenerated asc

The first question was simple: did the authentication succeed?

A failed attempt and a successful emergency-account sign-in represent very different situations.

Agent Foskett preserved both, but focused immediately on successful authentication.

He recorded the timestamp, source IP, application, target resource and Conditional Access result.

The account was highly privileged. Success changed the urgency of the case.

One sign-in can contain much more than an IP address

Agent Foskett expanded the sign-in context to examine device, location, authentication and risk information available in the record.
break-glass-context.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
let EmergencyAccountId =
"00aa00aa-bb11-cc22-dd33-44ee44ee44ee";
SigninLogs
| where TimeGenerated > ago(30d)
| where UserId =~ EmergencyAccountId
| extend DeviceId = tostring(DeviceDetail.deviceId),
         Browser = tostring(DeviceDetail.browser),
         OperatingSystem = tostring(DeviceDetail.operatingSystem)
| project TimeGenerated,
          IPAddress,
          Location,
          AppDisplayName,
          ResourceDisplayName,
          DeviceId,
          Browser,
          OperatingSystem,
          AuthenticationRequirement,
          RiskLevelDuringSignIn,
          RiskState,
          ConditionalAccessStatus
| order by TimeGenerated asc

A familiar IP address would not automatically make it legitimate

The source IP could belong to a corporate office, VPN exit point or administrator network.

That would be useful context — but it would not explain why the emergency account was used.

Agent Foskett separated two questions:

Where did the sign-in come from?

and

Was anyone authorised to use the account at that time?

A familiar network answers only the first.

Was this really the first use?

Agent Foskett widened the time window to understand the account's historical sign-in pattern. An emergency account should normally have very little activity outside controlled testing or actual emergency use.
emergency-account-history.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
let EmergencyAccountId =
"00aa00aa-bb11-cc22-dd33-44ee44ee44ee";
SigninLogs
| where TimeGenerated > ago(180d)
| where UserId =~ EmergencyAccountId
| summarize Attempts = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            SourceIPs = make_set(IPAddress, 20)
            by ResultType
| order by LastSeen desc

No previous record is not the same as never used

Log retention matters.

If the workspace only retained a shorter period, the absence of older sign-ins could not prove the account had never been used before.

Agent Foskett documented the available evidence window before describing the account as dormant.

Absence of telemetry outside your retention period is not evidence of absence.

What happened after the sign-in?

Authentication was only the entry point. The more important question was what changed after the privileged identity became active.

Agent Foskett pivoted into AuditLogs and searched the surrounding time window for directory changes.
post-signin-audit-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let EmergencyUPN =
"breakglass-admin@contoso.com";
let SignInTime = datetime(2026-10-02 02:17:00);
AuditLogs
| where TimeGenerated between
    (SignInTime - 10m .. SignInTime + 2h)
| where tostring(InitiatedBy) has EmergencyUPN
| project TimeGenerated,
          OperationName,
          Category,
          Result,
          TargetResources,
          AdditionalDetails,
          CorrelationId
| order by TimeGenerated asc

The account could be used without changing Microsoft Entra

An empty AuditLogs result would not prove that nothing happened.

The account could have accessed Azure resources, Microsoft 365 services or other administrative surfaces whose activity is recorded elsewhere.

Agent Foskett used the sign-in's application and resource context to decide which additional telemetry needed to be examined.

Follow the resource that was accessed — not just the identity provider that authenticated it.

Was the account itself changed before it was used?

Microsoft recommends monitoring emergency accounts not only for sign-ins, but also for changes to their credentials, authentication methods, permissions and roles.

Agent Foskett searched for audit events targeting the emergency account itself.
emergency-account-changes.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let EmergencyAccountId =
"00aa00aa-bb11-cc22-dd33-44ee44ee44ee";
AuditLogs
| where TimeGenerated > ago(30d)
| where tostring(TargetResources) has EmergencyAccountId
| project TimeGenerated,
          OperationName,
          Category,
          Result,
          InitiatedBy,
          TargetResources,
          CorrelationId
| order by TimeGenerated asc

A password or authentication-method change would alter the investigation

If the emergency account's credentials or authentication methods had changed shortly before the unexpected sign-in, Agent Foskett would treat that as a separate but potentially related event.

Who made the change?
Was it part of an approved credential rotation?
Did the sign-in occur immediately afterward?

The login tells you the account was used. The account-change history can help explain how that became possible.

Emergency access accounts need their own baseline

Normal users can generate hundreds of expected sign-ins.

A break-glass account should not.

That means its baseline is fundamentally different: expected activity may be limited to controlled validation exercises and genuine emergencies.

For an emergency account, a single successful sign-in can be the anomaly.

Build the emergency-access timeline

Agent Foskett organised the evidence chronologically.
Expected stateThe emergency account should be unused outside controlled testing or genuine emergency access.
Sign-in detectedPreserve the timestamp, result, source IP, application and resource.
Context checkedReview device, location, authentication, risk and Conditional Access details.
Authorization checkedDetermine whether an approved test or actual emergency explains the use.
Account changes reviewedLook for credential, authentication-method, permission or role changes involving the account.
Post-sign-in activity scopedFollow the account into AuditLogs and resource-specific telemetry.

What Agent Foskett checked

Sign-in resultDid the emergency access attempt actually succeed?
Source contextWhat IP address, location, device and application were recorded?
Expected useWas there a documented emergency or scheduled validation exercise?
Historical activityHow often had the account appeared within the available retention window?
Account changesWere credentials, authentication methods, permissions or roles changed nearby?
Administrative activityWhat did the privileged identity do after authentication?

What the evidence can and cannot prove

SigninLogs can establish that Microsoft Entra recorded an interactive sign-in attempt and provide authentication, source, application and resource context available in that event.

AuditLogs can help establish directory changes involving or initiated by the account.

Neither table alone proves who was physically behind the keyboard or whether an action was malicious.

And a lack of historical records cannot establish that the account was never previously used if telemetry collection or retention was incomplete.

Prove the authentication. Verify the authorization. Then follow the privileged activity.

The lesson

The emergency account existed for the day normal administration failed.

But normal administration had not failed.

There was no emergency.
There was no scheduled test.

So Agent Foskett followed the sign-in, checked the account's history, reviewed changes to the identity and investigated what happened after authentication.

Emergency access should be exceptional. When it isn't, investigate immediately.
Investigation principle: A successful break-glass sign-in outside an approved test or genuine emergency should be treated as a high-priority identity event.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingExplore practical investigation techniques across Microsoft Defender XDR, Microsoft Sentinel and Microsoft Entra ID.SOC Analyst AcademyBuild practical investigation and triage skills across identity, endpoint, email and cloud security.
The account was reserved for emergencies. This wasn't one.
Confirm the sign-in. Verify the reason. Follow the privileged activity.
Continue the Investigation

Final thought

Emergency access accounts are designed to be available when almost everything else has gone wrong.

That is exactly why ordinary use should stand out.

When a break-glass account signs in unexpectedly, do not stop at the successful authentication.

Find the source. Check the authentication context. Verify whether anyone authorised the use. Review changes to the account. Then follow every privileged action that came afterward.

Someone used the break-glass account.

There was no emergency.

The sign-in log knew it happened.

Follow the evidence. Build the timeline.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

Someone Used the Break-Glass Account — It Wasn't an Emergency

This Agent Foskett investigation examines unexpected use of a Microsoft Entra emergency access or break-glass account using SigninLogs, AuditLogs and KQL.

Investigating Emergency Access Account Sign-Ins in Microsoft Entra ID

Use Microsoft Entra sign-in telemetry to investigate the account, source IP, application, target resource, authentication context, risk and Conditional Access status surrounding unexpected emergency-account use.

Following Privileged Activity After a Break-Glass Sign-In

Pivot from SigninLogs into AuditLogs and resource-specific telemetry to determine whether the account changed directory objects, accessed administrative resources or had its own credentials, authentication methods, permissions or roles modified.