Identity and client
User, service principal, managed identity, home/resource tenant, app/client IDs, credential type, browser or client, agent or automation context, and authentication method sequence.
Microsoft Entra identity telemetry operations
Microsoft Entra Sign-In Logs Operations Review Guide
Turn high-volume authentication events into daily triage, defensible investigations, access-control validation, workload-identity oversight, retention, alerting, and evidence that business and technical teams can act on.
Operations objective
Start with who, how, and what—then explain why the access decision occurred
Microsoft frames a sign-in event around three core components: who performed the activity, how the client accessed the service, and what target resource was requested. Operations teams then add authentication steps, Conditional Access, report-only policies, device and network context, risk, token/session behavior, and application dependencies. A failure count alone is not an investigation.
Resource and decision
Target resource and audience, Conditional Access policies, grant/session controls, report-only results, Security Defaults, authentication requirement, and outcome.
Context and evidence
Timestamp, request and correlation IDs, IP and location, device state, risk, error code, failure reason, token details, grouped-event count, related audit change, and ticket.
Evidence boundary: sign-in logs show identity-platform events, not the full application session, endpoint timeline, network packet path, mailbox activity, or every action performed after access. Correlate with audit logs, application logs, endpoint/network telemetry, and Microsoft 365 Unified Audit Log where required.
Sign-in populations
Investigate each log category according to how it is generated
| Log population | What it represents | Operational caveat | Review focus |
|---|---|---|---|
| Interactive user | A user provides or interacts with an authentication factor or sign-in prompt to obtain access. | One user journey can request multiple resources and produce multiple events. A successful authentication can still encounter policy, consent, application, or session problems. | Who/how/what, authentication sequence, MFA claim, Conditional Access, audience, device, location, risk, error, request/correlation IDs, and user report. |
| Non-interactive user | A client or operating-system component acts on behalf of a user, commonly refreshing or exchanging tokens without a prompt. | Identical events can be grouped. For confidential clients, the displayed IP can reflect original token issuance rather than the current refresh request source. | Expand grouped rows, count and timestamps, application/resource, original interactive event, token lifecycle, IP caveat, Conditional Access, revocation, and compromise indicators. |
| Service principal | An application or service authenticates as itself with a certificate, secret, federated credential, or other workload credential. | No user is involved. Events can be grouped by service principal, status, IP, and resource. User-scoped controls do not prove workload protection. | App/service principal IDs, owner, credential, source, resource, permission, success/failure, frequency, new geography/IP, secret/certificate lifecycle, and workload policy. |
| Managed identity | An Azure resource uses a system-assigned or user-assigned managed identity to obtain a token for another resource. | Expected automation can be high volume. A successful token request does not prove least privilege or safe downstream actions. | Identity/resource IDs, Azure resource owner, target resource, subscription, source, frequency, failures, role assignments, recent changes, and workload monitoring. |
| Emerging/tenant-specific categories | Additional activity views can appear as Microsoft adds agent, workload, external-identity, or product-specific telemetry. | Schema, retention, permissions, preview status, and portal grouping can differ. Do not silently exclude a new tab from daily monitoring. | Document available categories, API schema, owner, triage coverage, retention, export destination, alert logic, and change review. |
Event anatomy
Read the evidence in sequence instead of stopping at “success” or “failure”
Basic identifiers
Created time, sign-in ID, request ID, correlation ID, unique token identifier, user/app/resource IDs, tenant IDs, status, error code, failure reason, and processing details.
Authentication details
Policies applied, authentication methods in order, success at each step, MFA requirement, claim satisfaction, passwordless use, federated result, and additional detail.
Conditional Access
Every evaluated policy, result, include/exclude logic, conditions, grant/session controls, report-only outcome, bootstrap exemption, disabled state, and final access effect.
Application and audience
Client application, target resource, resource tenant, service dependency, audience list, authentication protocol, client app type, token issuer, and cross-tenant context.
Device and network
IP, best-effort location, named location, browser/OS, device ID, managed/compliant/hybrid claims, autonomous system, network signal, and Global Secure Access context.
Risk and session
User/sign-in risk, detections, risk state/detail, Continuous Access Evaluation, token protection, session controls, sign-in frequency, original transfer method, and remediation.
Status rule: Conditional Access “Success” can mean policies were evaluated and applicable requirements were satisfied; it does not automatically mean every policy applied or that the business transaction succeeded. Review individual policy results, authentication, target audiences, and application outcome.
Triage matrix
Prioritize business impact, attack likelihood, and evidence quality
| Pattern | Immediate questions | Corroboration | Disposition |
|---|---|---|---|
| Privileged interactive failure or anomaly | Was the attempt expected? Which role, app/resource, method, device, network, risk, and policy were involved? Did any related attempt succeed? | Identity Protection, PIM, audit changes, endpoint/network telemetry, admin work schedule, ticket, other resources/audiences, and emergency-account alerts. | Contain compromised sessions/credentials when warranted, preserve IDs/timestamps, validate policy, contact the authorized owner, and open incident evidence. |
| Repeated user failures | Bad password, lockout, MFA denial, device noncompliance, policy block, expired credential, app misconfiguration, user error, or password spray? | Failure code distribution, IP/ASN, user population, authentication details, risk detections, successful events, endpoint state, help-desk reports, and application health. | Separate attack from usability/service fault; remediate root cause, monitor recurrence, and document user/business impact. |
| Unexpected successful access | Is the identity, application, resource, method, device, source, country, time, and session normal? Was MFA satisfied by an earlier claim? | User confirmation, sign-in history, audit/UAL, endpoint telemetry, mailbox/app activity, token revocation, risk, named location, and related service-principal activity. | Escalate when context cannot be explained; revoke sessions, reset/re-register methods, contain endpoint/app, and preserve evidence as appropriate. |
| Non-interactive spike | Is grouping hiding many attempts? Which original session, client, resource, token family, IP, and status changed? | Expand timestamps, compare interactive issuance, app version, token/session policy, revocations, service health, application logs, and user/device state. | Fix application/token loop or investigate stolen session; avoid treating every grouped row as one request. |
| Service principal anomaly | New IP/resource, credential, permission, owner, frequency, tenant, or failure pattern? Was the app recently changed or deployed? | App registration and enterprise-app audit logs, credential inventory, owners, code/deployment logs, Graph activity, Key Vault, resource logs, and workload policy. | Disable/restrict credential or service principal if malicious, rotate secrets/certificates, reduce permissions, fix automation, and document restoration. |
| Managed identity failure | Which Azure resource and identity requested which target? Was role assignment, resource state, endpoint, subscription, or network path changed? | Azure Activity Log, RBAC, resource configuration, deployment, target service logs, policy, subscription ownership, and recent platform incident. | Restore least-privileged access or contain abused resource; do not replace managed identity with a long-lived secret as a shortcut. |
| Conditional Access mismatch | Why did a policy apply, not apply, fail, or appear only in report-only? Which audience/service dependency was actually requested? | Policy export and ID, What If, report-only, audience list, group/role membership, named locations, device claims, authentication strength, and audit change. | Repair scope or control after pilot validation; preserve before/after policies, sign-ins, exclusions, rollback, and owner acceptance. |
Ten-stage operations runbook
Move from daily health review to incident-ready evidence
Define coverage and authority
Document tenants, log categories, business hours, severity rules, licensed retention, least-privileged roles, on-call owners, privacy boundaries, evidence repository, escalation, support handoff, and incident authority.
Verify data availability
Confirm interactive, non-interactive, service principal, managed identity, risky sign-in, audit, Conditional Access, and routed-log sources. Record ingestion latency, schema, timezone, retention, diagnostic settings, and known gaps.
Run daily health triage
Review privileged failures, high-risk or unfamiliar successes, legacy clients, blocked access, MFA/registration faults, policy failures, service-principal changes, managed-identity failures, impossible volumes, and business-critical resources.
Establish who/how/what
Identify the identity, client/application, and target resource before interpreting context. Capture object IDs, home/resource tenant, credential/method, timestamps, request/correlation IDs, status, error, and grouped-event count.
Reconstruct authentication and policy
Read every authentication step, MFA claim, federation, Conditional Access and report-only result, audience, device, location, risk, session, and service dependency. Compare expected and actual controls.
Correlate outside Entra
Use audit logs, Microsoft 365 UAL, application/resource logs, Azure Activity Log, Defender/endpoint/network telemetry, PIM, HR, CMDB, service health, deployment pipelines, and user/owner confirmation.
Classify and contain
Separate malicious access, policy defect, credential/session fault, application defect, device/network issue, service outage, expected automation, and user error. Apply authorized containment proportional to evidence and business impact.
Repair and validate
Fix identity, method, device, app, resource, credential, permission, policy, named location, or routing root cause. Retest positive and negative paths; confirm no new failure in dependent audiences or background token flows.
Preserve investigation evidence
Export raw and filtered events before retention expires. Preserve query/filter, UTC window, tenant, category, schema, row count, hash, IDs, screenshots, related logs, analyst notes, timeline, decisions, and chain-of-custody handling.
Tune and govern
Update alerts, workbooks, queries, suppression, routing, runbooks, policy tests, application ownership, credential lifecycle, retention, lessons learned, metrics, residual risk, and next review without hiding recurring defects.
Retention, routing, and evidence
Design storage before the event you need has expired
Microsoft’s current native retention for audit and sign-in activity is seven days with Entra ID Free and 30 days with P1 or P2. Risky sign-ins are retained seven days for Free, 30 days for P1, and 90 days for P2. Licensing upgrades are not retroactive, and Entra activity logs are separate from Microsoft 365 Unified Audit Log retention.
Routing design
- Choose Log Analytics, Storage, Event Hubs, or partner destinations based on investigation, alerting, archive, immutability, and cost needs.
- Select every required log category and validate ingestion with known test events.
- Record workspace/storage/event-hub owner, region, access model, retention, lifecycle, encryption, monitoring, and failure alert.
- Protect diagnostic-setting changes and detect stopped ingestion or schema drift.
- Separate hot operational queries from long-term low-cost archive where appropriate.
- Test retrieval, export, hash, legal/privacy handling, and evidence access before an incident.
Evidence package
- UTC start/end, tenant ID, identity/app/resource object IDs, request/correlation/token identifiers, and event category.
- Portal/API/PowerShell query, filters, selected fields, aggregation setting, page/count logic, and export timestamp.
- Raw immutable file plus analyst working copy, row count, hash, timezone, schema, and source.
- Authentication, Conditional Access/report-only, device, location, network, risk, and session details.
- Related audit/UAL/application/endpoint/network records, screenshots, tickets, owner/user statements, and timeline.
- Finding, containment, remediation, validation, residual risk, approvals, retention label, and custody history.
Privacy rule: sign-in logs contain personal and pseudonymous identifiers, IP/location, device, application, and behavior data. Apply least privilege, approved purpose, regional/contractual requirements, retention limits, secure export, and access logging. Do not copy broad datasets into unmanaged tickets or email.
Common analysis failures
Prevent false conclusions from incomplete or misread telemetry
These mistakes can hide compromise, misdiagnose policy, or create unusable evidence. Treat them as blocking quality defects.
Only interactive logs reviewed
Background user tokens, service principals, and managed identities can carry the most important persistence, automation, or workload evidence.
Success means safe
A successful token request can be malicious, overprivileged, incorrectly scoped, or followed by harmful application activity.
Failure equals attack
Bad configuration, device posture, stale credentials, service health, token loops, and user error can resemble hostile activity without correlation.
Grouped row counted once
Non-interactive and workload views aggregate similar events. Expand counts and timestamps before estimating volume or duration.
IP treated as current source
Some non-interactive confidential-client events can display the original token-issuance IP rather than the current refresh request source.
Conditional Access status misread
Overall Success, Not Applied, bootstrap exemptions, report-only, disabled policies, and individual results require separate interpretation.
Application audience ignored
Teams, portals, and clients request dependent resources. Investigating only the user-visible application can miss the policy that actually blocked access.
Retention assumed retroactive
Upgrading a license or enabling routing today cannot recover events that already expired from native retention.
Screenshot-only evidence
A picture without raw rows, IDs, query, UTC window, schema, hash, and related records cannot support repeatable analysis.
Measures and closeout
Measure detection, diagnosis, data quality, and remediation
Minimum closeout: scope, roles, data-source and retention inventory, diagnostic settings, queries, alert/workbook logic, raw exports and hashes, IDs, timeline, related telemetry, finding classification, containment, remediation, validation, privacy/custody record, residual risk, owners, and next review.
Related ecosystem guides
Connect sign-in evidence to access, risk, methods, apps, and response
Conditional Access reviewValidate policy assignments, controls, exclusions, report-only results, and evidence.
Identity Protection reviewInvestigate risky users, sign-ins, detections, remediation, and residual risk.
Authentication methodsReconcile method enablement, registration, use, migration, strengths, and failures.
Named locations governanceValidate public egress, country, proxy/VPN, trusted flags, and policy dependencies.
App registration securityGovern service principals, credentials, permissions, owners, consent, and lifecycle.
Emergency access securityMonitor and test cloud-only recovery accounts and investigate every use.
Microsoft 365 admin toolsetUse related planning, assessment, and evidence-building resources.
Microsoft 365 managed servicesGet ongoing identity, endpoint, email, collaboration, and tenant operations support.
Authoritative Microsoft references
Validate schemas, retention, and investigation behavior
Frequently asked questions
Microsoft Entra sign-in logs FAQ
Why do we need to review non-interactive sign-ins?
They show token acquisition performed on behalf of users without a fresh prompt. They can reveal background application loops, session persistence, revoked or stolen-token behavior, and resource access that interactive logs alone do not explain.
Does a successful sign-in prove the activity was authorized?
No. It proves the identity platform issued or processed access successfully under the observed conditions. Validate the identity, client, resource, method, policy, device, network, risk, session, owner, and downstream application activity.
How long are Entra sign-in logs retained?
Microsoft currently documents seven days for Entra ID Free and 30 days for P1/P2 native sign-in activity. Risky sign-ins are seven, 30, or 90 days for Free, P1, or P2 respectively. Route logs for longer approved retention before events expire.
Why does a non-interactive row represent multiple sign-ins?
Microsoft groups similar non-interactive events when application, user, IP, status, resource, and other grouping conditions match. Expand the row and use the sign-in count and timestamps before estimating frequency or duration.
Can we rely on the IP and country as physical-location proof?
No. IP geolocation is best effort, and some non-interactive confidential-client events can show the original token issuance IP. Correlate with network, device, user, application, and risk evidence.
What should be preserved for Microsoft support or an incident?
Preserve UTC time, tenant, identity/app/resource IDs, request and correlation IDs, error, authentication, policy, device/network/risk details, raw export, query/filter, schema, row count, hash, screenshots, related telemetry, timeline, and actions taken.
IT Perfection Microsoft 365 identity operations
Turn sign-in telemetry into repeatable detection, diagnosis, and proof
IT Perfection helps organizations in Irvine, Orange County, Los Angeles County, and Southern California establish sign-in-log coverage, triage identities and workloads, validate Conditional Access and authentication, route and retain evidence, build alerts and runbooks, investigate anomalies, and improve ongoing identity operations.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience.
This guide is for initial planning and operational guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, incident response engagement, or legal/compliance review. Validate current licensing, retention, tenant behavior, Microsoft documentation, privacy requirements, and evidence procedures before implementation.
