Investigating Microsoft Entra Sign-ins and Conditional Access Results

Purpose

Investigation, not remediation

Preserve one evaluated event before considering any user-impacting or policy change.

Audience

Working Microsoft 365 administrators

Use the guide when authentication, access policy, device, network, or application evidence overlaps.

Examples

Synthetic only

alex.taylor@example.com, LAB-WIN11-01, and 192.0.2.44 are documentation-safe placeholders.

Method

Match, record, correlate

Treat the exact time, identity, application, resource, and correlation information as the event boundary.

1 · Investigation question

What is this investigation designed to answer?

Determine what Microsoft Entra recorded for one sign-in attempt and whether authentication, Conditional Access, device, network, client, application, resource, risk, or licensing evidence helps explain the reported symptom.

Which event represents the symptom?

Find the row that matches the reported UTC time, identity, application, resource, sign-in type, and available request or correlation ID.

Where did the attempt stop?

Separate primary authentication, additional authentication, policy evaluation, token issuance, and downstream application access.

What was actually evaluated?

Record the event's user, device, client, location, application, resource, risk, and policy context without generalizing to another session.

What remains unknown?

A sign-in log can narrow the problem without proving the final application, network, device-management, or security root cause.

2 · Boundaries and access

Use read access and keep discovery separate from change.

In the Microsoft Entra admin center, sign-in logs are under Entra ID → Monitoring & health → Sign-in logs. Microsoft documents Reports Reader as the least-privileged role for activity logs. Seeing Conditional Access policy details can require a role that can read both the sign-in logs and the policies.

Licenses and views affect available evidence

Sign-in logs are available across Microsoft Entra editions, but features, risk fields, Conditional Access, programmatic access, retention, and portal views vary by license and role. Conditional Access requires Microsoft Entra ID P1 or an eligible suite. Some properties can be hidden when the required license is absent.

Default sign-in retention is currently seven days for Microsoft Entra ID Free and 30 days for P1 or P2. Retention upgrades are not retroactive. If the event is missing, record the searched window, category, filters, current license boundary, and whether logs were previously routed elsewhere; do not infer that the sign-in never happened.

3 · Evidence before troubleshooting

Build a minimum event record before interpreting it.

Event identity

Time, user, application, resource

Record the exact UTC timestamp, synthetic UPN such as alex.taylor@example.com, application, target resource, sign-in type, status, failure reason, and error code.

Trace identifiers

Request and correlation IDs

Preserve the request ID and correlation ID exactly. Synthetic examples in this guide use 11111111-1111-4111-8111-111111111111 and 22222222-2222-4222-8222-222222222222.

Connection context

IP, location, client, browser, OS

Record the source IP, displayed location indicators, client application, browser, and operating system as event evidence—not as verified physical attribution.

Device context

ID, join, managed, compliant

Record the device ID, join type, managed indicator, and compliant indicator exactly as displayed, including blank or unavailable values.

Authentication

Requirement, methods, steps

Record the authentication requirement, methods used, sequence, step results, MFA satisfaction details, and any interrupted or failed step.

Access policy

Policies and controls

Record each policy evaluated, its result, relevant conditions, grant controls, session controls, and report-only result where available.

4 · Select the event

Match the reported attempt before opening conclusions.

Filter by a narrow UTC time range, user, application, resource, status, and sign-in category. Then compare request and correlation information from the user-visible error or support record when available.

Synthetic event: 2026-08-21T14:32:18Z · alex.taylor@example.com · Finance Portal Sandbox · Microsoft Graph · Interactive user sign-in · correlation ID 22222222-2222-4222-8222-222222222222.

Similar rows near the same time are not interchangeable. Select the event matching the correct timestamp, user, application, resource, and correlation information.

5 · Sign-in categories

Start in the category that represents the actor and flow.

The current sign-in logs experience distinguishes four categories. The legacy experience only includes interactive user sign-ins, and category visibility, fields, grouping, downloads, and related reports can vary by portal experience and license.

User

Interactive user sign-ins

A user supplies an authentication factor to Microsoft Entra ID or a helper application, such as a password, MFA response, biometric gesture, or federated assertion.

User

Non-interactive user sign-ins

A client or operating-system component acts on behalf of a user without a new interactive factor, such as using a refresh token. Identical events can be grouped; expand grouped rows to inspect their individual timestamps.

Workload

Service principal sign-ins

An application or service principal authenticates without a user, commonly with its own certificate or client secret. Similar events can be aggregated.

Workload

Managed identity sign-ins

An Azure resource uses an identity whose credentials Azure manages. These entries are separate from service principal sign-in logs and can also be grouped.

Interactive success and non-interactive failure can coexist because they represent different requests, times, resources, clients, token state, and policy context. For non-interactive confidential-client events, Microsoft notes that the displayed IP can reflect the original token issuance rather than the current refresh-token source.

6 · Authentication details

Read the requirement and every recorded step.

Open Authentication Details for the selected event. Record the authentication requirement, method sequence, success or failure of each step, result detail, and whether Microsoft reports that a requirement was satisfied by an existing claim.

Requirement

Distinguish single-factor, multifactor, passwordless, or other displayed requirements from the individual methods that happened to appear.

Methods and sequence

Preserve each method, timestamp, success indicator, and detail. One successful step can precede a later interruption or failure.

Previously satisfied claims

Microsoft can report that MFA or another requirement was satisfied by a claim already present in the token. That is evidence about this evaluation, not proof that a new prompt occurred.

Outcome boundary

A successful MFA event does not automatically prove the entire sign-in succeeded, a token reached the intended application, or the application granted access.

7 · Conditional Access

Interpret every policy in the selected event's context.

The Conditional Access details list policies that could be evaluated for the event, including policies that did not apply. Multiple policies can evaluate the same sign-in, and one policy's success does not override another policy's failure.

Scope

Applied or not applied

An applied policy matched the relevant assignments and conditions for evaluation. Not applied means the sign-in did not meet that policy's criteria, such as an exclusion or a nonmatching application, platform, client, risk, or location; it is not automatically malfunctioning.

Enforced result

Success or failure

Success means the applied policy's requirements were met and that policy would allow the sign-in to proceed. Failure means its requirements were not met and it would block the sign-in. Another policy or another stage can still determine the overall outcome.

Simulation

Report-only results

Report-only records potential impact without enforcing access. Results can include success, failure, user action required, or not applied; interactive controls are not prompted by a report-only policy.

Controls

Conditions, grants, sessions

Record the matched user or workload, target resource, location, device platform, client app, risk and other conditions, then record grant controls and session controls separately.

Correlate before concluding

Conditional Access results must be interpreted with authentication, device, application, user, risk, location, and client details. Sign-in-log evidence describes the evaluated event and should not be generalized to unrelated sessions.

8 · Device evidence

Treat device fields as event signals, not a complete inventory.

Device ID and join type

The device ID can associate the event with a directory device record; join type describes the relationship Microsoft recorded. Confirm the value against the intended device before correlating other records.

Managed and compliant

These indicators reflect what the sign-in record received for that evaluation. A successful sign-in does not prove the device is correctly managed or compliant outside that event.

Operating system and browser

These values describe reported client context and can help compare flows. They are not a complete device-security assessment.

Blank fields

Missing device information can result from the flow, client, token, category, privacy behavior, or unavailable signal. A blank field does not automatically prove the device is unknown, unmanaged, or malicious.

9 · Network, location, and client

Preserve the displayed context without overstating attribution.

Record the source IP, displayed city, region, country, named-location result, client application, browser, operating system, and original transfer method when available. A synthetic source such as 192.0.2.44 is documentation-only.

IP geolocation is an indicator, not proof of a person's physical location. VPNs, proxies, carrier networks, secure access services, egress architecture, token flows, and grouped non-interactive events can affect what appears. Compare the event with approved network architecture and adjacent events before escalating or dismissing it.

10 · Application and resource

Separate the requesting client from the target resource.

Record both the application and resource display names and IDs where available, plus the home and resource tenant context for cross-tenant activity. The client asking for a token and the API or service receiving it can be different.

An application or resource mismatch can explain why a policy appears outside the administrator's first expectation. It does not by itself prove incorrect consent, permissions, ownership, or compromise. Correlate the IDs with the approved enterprise application and resource records before drawing that conclusion.

11 · Errors and identifiers

Preserve exact values for the next investigation layer.

Error code and failure reason

Use the event's numeric error code, failure reason, and additional details together. Similar user-facing symptoms can produce different codes and investigation paths.

Request ID

Preserve the request ID shown for the attempt. Microsoft support and diagnostics can use it with the time and tenant context to identify the request.

Correlation ID

Use the correlation ID to match the reported attempt and related activity. Microsoft cautions that the same value appearing in multiple logs does not automatically make those logs joinable across services.

Similar events

Two rows with different correlation IDs are distinct events even when their user, application, and minute appear similar. Compare them; do not silently substitute one for the other.

12 · Evidence correlation

Separate observations from conclusions.

Observation	What it may indicate	What it does not prove	Safest next investigation step
Invalid username or password.	The submitted credential or identifier was not accepted for this attempt.	Account compromise, a directory outage, or the user's intent.	Match the exact event and compare its error code, identifier, client, and adjacent authorized activity.
MFA requirement not completed.	The recorded multifactor step was interrupted, timed out, denied, or otherwise incomplete.	Why the user did not complete it or that every authentication method is broken.	Review the authentication step details, requirement, method, timing, and user-reported experience.
Conditional Access failure.	At least one applied policy requirement was not met or a block control applied.	That the policy is misconfigured.	Identify the failing policy, matched conditions, controls, and the event's user, device, location, client, risk, app, and resource.
Policy not applied.	The event did not match that policy's assignments or conditions.	That Conditional Access malfunctioned or no other policy applied.	Review that policy's inclusion, exclusion, resource, platform, client, location, risk, and state for this event.
Device not marked compliant.	A compliant-device signal was false or unavailable for the evaluated request.	That the device is malicious, unenrolled, or currently noncompliant in every system.	Match the device ID and flow, then compare authorized device-management evidence at the event time.
Device information missing.	The flow or client might not have supplied device claims.	That the device is unknown, unmanaged, or malicious.	Confirm the sign-in category, client, browser, token flow, and whether a working comparison event contains device data.
Unexpected source location.	The displayed IP or geolocation differs from the expected network path.	The user's physical location or account compromise.	Preserve the event and compare approved VPN, proxy, egress, carrier, risk, and adjacent sign-in evidence.
Legacy or unsupported client appears.	The request used a client category or protocol different from the expected modern flow.	Which application component generated it or that changing policy is safe.	Correlate client, application, resource, sign-in type, user report, and supported authentication path.
User sign-in succeeds but application access still fails.	Microsoft Entra authentication completed while a downstream authorization, consent, resource, session, network, or application dependency did not.	End-to-end application health or correct permissions.	Trace the same application and resource IDs into the narrowest authorized downstream evidence.
Interactive sign-in succeeds while non-interactive activity fails.	The background token request had different time, resource, client, token, or policy context.	That the successful interactive event should make every later request succeed.	Expand grouped non-interactive rows and compare exact timestamps, IDs, resources, clients, and error details.
Application or resource mismatch.	The token request targeted a different client or resource than first reported.	Incorrect consent, malicious use, or wrong ownership.	Verify display names and IDs against approved enterprise application and resource records.
Similar events have different correlation IDs.	They are separate requests with potentially different evaluation context.	That either row represents the user's reported attempt.	Use the exact UTC time, request ID, correlation ID, application, and resource to select the correct event.

13 · Interpretation mistakes

Avoid conclusions that the event cannot support.

“MFA succeeded, so access succeeded.”

MFA can be one successful step before another policy, token, resource, or application failure.

“The sign-in succeeded, so the device is healthy.”

A successful sign-in does not prove correct management, compliance, configuration, or security posture.

“Not applied means broken.”

A policy can correctly remain outside the event because an assignment or condition did not match.

“Report-only blocked the user.”

Report-only evaluates potential impact and does not enforce access.

“One row proves the root cause.”

The row records one evaluated event; downstream access and adjacent requests can have different evidence.

“Blank device data proves danger.”

Missing claims have several routine technical explanations and require correlation.

14 · Escalation

Stop when evidence, risk, or authority exceeds routine investigation.

Preserve the event record and escalate through the approved security, identity, application, or service-support path when any of the following applies:

Security concern

Suspected compromise, impossible or unexplained activity, high-risk detections, or authentication-method registration anomalies appear.

Protected identities

A break-glass or emergency-access account, privileged identity, or evidence-integrity concern is involved.

Broad policy impact

Conditional Access failures are widespread, a policy changed without known ownership, or verified emergency access is uncertain.

Workload identity

A service-principal or managed-identity failure requires credential, permission, consent, ownership, or production application review.

Evidence limitation

Required audit evidence is missing, outside retention, hidden by licensing, or unavailable in the current portal or export.

Change required

Any next step would modify policy, identity, authentication, device, application, consent, session, or user access.

15 · Intentionally excluded

This guide does not provide user-impacting or tenant-changing procedures.

Excluded actions include disabling users; resetting passwords; changing authentication methods; revoking sessions; changing Conditional Access policies; excluding users from policies; modifying named locations; changing device compliance; deleting devices; granting administrative roles; changing application permissions or consent; disabling security defaults; bypassing MFA; or otherwise weakening tenant security.

Those actions require separate authorization, change control, verified emergency access, rollback planning, and environment-specific review by accountable identity and security owners.

16 · Related resources

Continue through the appropriate KrippyTech path.

Learning method

MSP University

Use the understand, investigate, resolve, and verify sequence while keeping this guide in the investigation phase.

Review the learning path

Topic hub

Microsoft 365 & Identity

Place sign-in evidence alongside Exchange Online, permissions, applications, and other Microsoft 365 dependencies.

Open the Microsoft 365 hub

Related procedure

Shared mailbox not showing

Use the Exchange procedure when authentication succeeds but the reported symptom concerns mailbox permission propagation or Outlook behavior.

Open the shared-mailbox tutorial