Investigate Microsoft Entra ID Sign-In Alerts

A sign-in alert is a starting point, not a finding by itself. Investigate the identity, client application, target resource, authentication sequence, device state, network context, and related events. Preserve the event identifiers so another analyst can reproduce the review.

Figure 1: The sign-in details pane organizes identity, authentication, device, and Conditional Access evidence.

---

Step 1: Capture the Alert and Define the Time Basis

01

Record Identifiers Before You Pivot

Case Intake

Copy the alert ID, user principal name, application, resource, event status, event time, correlation ID, and request ID where available. Entra admin center displays times according to the signed-in administrator’s time zone; convert the event time to UTC for the case timeline and note the original time zone.

User / UPN:
Application and resource:
Status and result detail:
Event time and time zone:
Correlation ID / Request ID:
Alert source and query window:

❯ View Expected Console Output

Observed: sign-in alert for an unfamiliar client address.
Not established: whether the user or device was compromised.

---

Step 2: Find the Matching Sign-In Record

02

Filter the Entra Sign-In Logs

Event Validation

In the Microsoft Entra admin center, open Entra ID → Monitoring & health → Sign-in logs. Set a narrow time range, then filter by the user and the alert’s correlation ID, request ID, application, or IP address. Select the record that matches the alert; interactive and non-interactive sign-ins are separate views and may both contain related activity.

Confirm: user, tenant, application, resource, client type,
status, error code, correlation ID, request ID, and event time.

❯ View Expected Console Output

Matched record: same user and application, same time window,
correlation ID recorded for subsequent pivots.

---

Step 3: Read the Authentication Sequence

03

Check MFA and Authentication Details

Authentication Review

Open the event’s Authentication Details. Review the authentication requirement, methods and sequence, result of each step, and whether a prior claim satisfied MFA. A single-factor label does not always mean the user bypassed MFA: primary authentication can fail before Conditional Access evaluates the MFA requirement, and an existing claim can affect the prompt shown to the user.

Method and sequence:
Was the method successful?
Was MFA requested, completed, denied, or satisfied by a claim?
Does the event's result detail explain an interruption or failure?

❯ View Expected Console Output

Authentication result recorded from the event details;
no conclusion based on the summary label alone.

---

Step 4: Compare Device, Client, and Network Context

04

Check Whether the Context Fits the User

Context Review

Review device name, operating system, browser or client, managed/compliant state, join type, IP address, and location estimate. Compare them with the user’s expected devices, travel, VPN egress, mobile provider, and approved applications. A geolocation is an estimate and an IP address does not prove a person’s physical location.

Entity: user / device / IP / app
Baseline: expected device, client, and access pattern
Related records: adjacent sign-ins, endpoint alerts, helpdesk or travel context

❯ View Expected Console Output

Document both matching and conflicting context, with source and time.

---

Step 5: Interpret Conditional Access Results

05

Review the Applied Policy Results

Policy Evaluation

Open the Conditional Access tab and record each relevant policy, its result, and the condition or grant control that explains the outcome. Not applied can mean a policy did not match the event; it does not automatically mean the event was suspicious or that MFA was bypassed. Interrupted sign-ins and Windows device sign-ins have additional evaluation details, so read the event’s full context.

Policy name and state:
Result: Success / Failure / Not applied / Report-only
Relevant user, app, location, device, and grant conditions:

❯ View Expected Console Output

If policies are not visible, verify the analyst role can read both
sign-in logs and Conditional Access policy details.

---

Step 6: Correlate, Classify, and Escalate

06

Write a Defensible Disposition

Case Decision

Search the bounded window for adjacent activity by the same user, device, IP, application, and correlation ID. Compare with known-good access and approved changes. State what is observed, what remains uncertain, and why you closed, escalated, or requested user confirmation. Use your identity incident playbook for credential reset, token revocation, or access changes; do not make those changes from this review alone.

Evidence and event IDs:
User / device / application context:
Authentication and Conditional Access outcome:
Confidence and unresolved questions:
Disposition, approving owner, and next action:

❯ View Expected Console Output

The disposition is based on correlated records and an auditable reason.

Check tenant licensing and permissions

Microsoft Entra ID Free includes sign-in logs. Conditional Access requires Microsoft Entra ID P1 or a qualifying subscription such as Microsoft 365 Business Premium. Risk-based Conditional Access and full Identity Protection features require P2 entitlements. To see applied Conditional Access policy details, Microsoft’s least-privileged built-in role is Security Reader; sign-in log viewing alone can use Reports Reader. Confirm current tenant licensing and role assignment before following a workflow that depends on a premium feature.

References

Microsoft: Sign-in log activity details · View applied Conditional Access details · Customize and filter activity logs · Microsoft Entra licensing