Lesson 2 — Understanding Sign-in Logs
Microsoft Entra sign-in logs record authentication activity across users, applications, service principals and managed identities.
A single sign-in event can show who attempted access, which application was involved, whether authentication succeeded, which Conditional Access policies applied, what device and location context was available and whether identity risk was detected.
This lesson explains how analysts read sign-in evidence methodically and avoid treating one field—such as location or success status—as the whole investigation.
What you will learn
This lesson shows how to turn Entra sign-in records into an investigation timeline.
Learning objectives
After completing this lesson, you should be able to review a Microsoft Entra sign-in event systematically.
- Recognise the main sign-in log categories.
- Interpret successful, failed and interrupted sign-ins.
- Review authentication, application and device details.
- Explain Conditional Access and risk results.
- Correlate sign-ins with surrounding identity activity.
The problem this solves
A sign-in can fail for many reasons: bad credentials, an unmet MFA requirement, Conditional Access, a disabled account or a blocked authentication flow.
Sign-in logs provide the evidence needed to distinguish normal failure, policy enforcement, technical problems and possible account compromise.
What are Microsoft Entra sign-in logs?
Microsoft Entra records sign-in activity for users and workloads. The logs provide technical and security context for authentication attempts in the tenant.
The main categories include interactive user sign-ins, non-interactive user sign-ins, service principal sign-ins and managed identity sign-ins.
Start by confirming the sign-in type. A background token refresh should not be interpreted the same way as a user entering credentials interactively.
Interactive user sign-ins
Interactive sign-ins involve a user providing an authentication factor or directly participating in the sign-in flow.
Examples include entering a password, approving Microsoft Authenticator or using a passkey.
Non-interactive user sign-ins
Non-interactive sign-ins occur on behalf of a user, often when an application or operating-system component refreshes a token in the background.
They may appear frequently and can be grouped because many events share the same characteristics.
Sign-in types compared
| Type | Identity involved | Typical example |
|---|---|---|
| Interactive user | A person actively authenticates. | User enters credentials and completes MFA. |
| Non-interactive user | An application acts on behalf of a signed-in user. | Outlook refreshes a token without prompting the user. |
| Service principal | An application or service authenticates without a user. | An app uses a certificate or secret to access an API. |
| Managed identity | An Azure resource authenticates using its managed identity. | An Azure function accesses Key Vault. |
Success, failure and interruption
A successful event means the requested authentication and policy requirements were satisfied.
A failed event means access was not completed. An interrupted event can indicate that another action—such as MFA, consent or password change—was required.
Status and error codes
The status area provides the result, failure reason and error code.
Use all three together. A numerical code without the surrounding message and policy context can be misleading.
First fields to review
| Field | Investigation question |
|---|---|
| User | Which identity attempted the sign-in, and is the account expected to be active? |
| Application | Which client or enterprise application initiated the request? |
| Resource | What service or API was the identity trying to access? |
| Status | Was access successful, failed or interrupted? |
| IP address | Which public address was observed, and is it known or suspicious? |
| Date and time | Does the event fit the user's expected activity and surrounding timeline? |
IP address and location
The location shown in the log is derived from the observed IP address and should be treated as context rather than proof of physical location.
VPNs, mobile carriers, proxies and cloud services can make legitimate sign-ins appear elsewhere.
Application and resource
The client application is not always the same as the resource being accessed.
For example, a user might sign in through a browser while requesting access to Microsoft Graph, SharePoint or Exchange Online.
Device information
Device context can include operating system, browser, device ID, join type, compliance state and management status.
Missing device details do not automatically indicate malicious activity. Some sign-in flows and clients provide limited device information.
Authentication requirement
This field indicates the level of authentication required for the sign-in, such as single-factor or multifactor authentication.
It should be reviewed alongside the detailed authentication steps and Conditional Access result.
Authentication details
The authentication details section shows the sequence of methods and steps used during the sign-in.
It can help determine whether MFA was performed during this event, previously satisfied by a claim, or completed through another supported method.
Why “MFA satisfied” needs context
| Observation | Possible interpretation |
|---|---|
| MFA completed during sign-in | The user performed an additional authentication step in the current flow. |
| MFA requirement satisfied by claim | A previous authentication or token claim satisfied the requirement without a new prompt. |
| No MFA requirement | The sign-in may not have matched a policy requiring MFA. |
| MFA failed or interrupted | The user did not complete the required authentication step. |
Conditional Access result
The Conditional Access section shows whether policies applied, did not apply, were excluded or operated in report-only mode.
Review each policy result rather than relying only on the overall status.
Report-only policies
Report-only evaluates what a policy would have done without enforcing the grant or session control.
A report-only success does not mean the policy protected the sign-in.
Identity risk
Microsoft Entra ID Protection can identify suspicious sign-in and user-risk signals.
Risk level, risk state and risk detections should be reviewed with sign-in evidence, user history and surrounding activity. Risk-based Conditional Access can use those signals to require remediation or block access.
Correlation ID and request ID
Correlation and request identifiers help connect technical events and support troubleshooting.
Record them when escalating a failed sign-in, investigating related events or working with Microsoft support.
Client application
The client application or authentication protocol helps explain how the sign-in occurred.
Browser, mobile apps, desktop clients, legacy protocols and device-code flows can carry different security implications.
Investigation workflow
The sign-in record tells you how access was evaluated. The surrounding timeline tells you whether the access was legitimate.
Successful but suspicious
A successful sign-in can still be malicious if an attacker possesses valid credentials, satisfies MFA or reuses a token.
Investigate unfamiliar applications, abnormal locations, new devices, unusual timing and activity that followed.
Failed does not mean harmless
Repeated failures can indicate password spraying, legacy-authentication attempts or an attacker testing a disabled account.
Look for patterns across users, IP addresses, applications and time.
Example investigation
Common mistakes
| Mistake | Why it creates risk | Better practice |
|---|---|---|
| Trusting the displayed location as exact | IP geolocation can be inaccurate or affected by VPNs and proxies. | Use location as one signal among many. |
| Assuming success means legitimate | Attackers can authenticate with stolen credentials or tokens. | Review device, risk, MFA and post-sign-in activity. |
| Ignoring non-interactive sign-ins | Token use and background access may continue after the initial interactive event. | Review both interactive and non-interactive timelines. |
| Reading only the overall Conditional Access result | Individual policies may be excluded, report-only or not applied. | Inspect each policy evaluation. |
Key takeaways
- Microsoft Entra provides separate sign-in logs for users and workloads.
- Interactive and non-interactive sign-ins represent different authentication behaviour.
- Status, error codes, authentication details and Conditional Access must be read together.
- IP location and device data are useful context but not definitive proof.
- A successful sign-in can still represent compromise.
- Always correlate the event with user history and activity that followed.
Related Agent Foskett resources
Continue learning
Microsoft Entra Sign-in Logs
Microsoft Entra sign-in logs record interactive users, non-interactive users, service principals and managed identities, including authentication status, IP address, location, device information, Conditional Access and risk.
Microsoft Entra Academy Lesson 2 — Understanding Sign-in Logs
This Agent Foskett Microsoft Entra Academy lesson explains how analysts interpret sign-in status, error codes, authentication details, Conditional Access results and identity risk.
