Reading Entra ID Sign-In Logs: Token Lifetimes, Error Codes and Real Fixes
Interactive vs non-interactive, PRT vs access token, 50058 vs 50173 — a field guide to Entra sign-in logs that ends in real fixes, not shrugs.
C
CloudEngineerHub Team
Published: September 20, 2026· Last Updated: September 28, 2026·9 min read
Reading Entra ID Sign-In Logs: Tokens, Errors, Real Fixes
A user pings you with "it keeps asking me to sign in" and you have one artifact worth anything: the sign-in log. Read it well and the fix is usually a five-minute change — a token policy, a Conditional Access exclusion, a device re-registration. Read it badly and you ship a workaround that hides the symptom until the next person hits it. This is a field guide to reading interactive and non-interactive sign-ins, understanding which token actually expired, and mapping error codes to fixes that stick.
Visual Walkthrough
Decode every row of a sign-in log by understanding token mechanics.
Interactive FlowSign-In Logs & Token Lifetime — What Actually Flows6/6
1
Auth request
App redirects to Entra with client ID and requested scopes.
auth
2
Primary authentication
Password / WHfB / FIDO2 establishes the user claim.
mfa
3
MFA claim
Conditional Access demands second factor per policy.
tokens
4
Token issuance
Access + refresh tokens minted with lifetimes and claims.
Refresh token (or PRT) renews silently; logs show it as token grant.
Sign-In Logs & Token Lifetime — What Actually Flows. 1. Auth request: App redirects to Entra with client ID and requested scopes. — 2. Primary authentication: Password / WHfB / FIDO2 establishes the user claim. — 3. MFA claim: Conditional Access demands second factor per policy. — 4. Token issuance: Access + refresh tokens minted with lifetimes and claims. — 5. App validates: App checks signature, audience, expiry — session established. — 6. Renewal cycle: Refresh token (or PRT) renews silently; logs show it as token grant.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Licensing: Sign-in logs are retained 7 days on the free tier and 30 days with Entra ID P1/P2. Anything longer needs Log Analytics or Microsoft Sentinel. Continuous Access Evaluation requires Entra ID P1.
Permissions: Global Reader or Security Reader for viewing logs; Reports Reader works for the portal experience.
Graph PowerShell (Microsoft.Graph.Reports) for programmatic pulls.
Optional but valuable: diagnostic settings streaming sign-in logs to Log Analytics so you can query beyond the retention window.
Interactive, non-interactive, and service principal logs
The Entra admin center splits sign-ins into interactive (user present at the keyboard), non-interactive (token refreshes and SSO where no user intervention occurred), and service principal / managed identity (app-to-app). The portal filters non-interactive out by default, which is the number-one reason admins conclude "there are no logs" for a broken app — refresh failures are almost always non-interactive.
The fields that decide your diagnosis
For each event, three sections carry the truth:
Basic info / authentication details: which credential was used, which MFA method satisfied the claim, and per-attempt results for each requirement.
Conditional Access: every policy that applied to the request and whether it was satisfied — "Not applied: policy not enabled" versus "Failed: device not compliant" are different problems entirely.
Device info and token info: whether a Primary Refresh Token (PRT) was used, browser vs client app, and the resource the token was requested for. dsregcmd /status on the device (AzureAdPrt: YES/NO) pairs with this to close PRT questions.
Token lifetimes that actually shape your logs
Users do not sign in as often as you think — they acquire tokens. The cadence you see in the logs is dictated by these defaults:
Token
Default lifetime
What it means in logs
Access token
~1 hour (60–90 min varies)
Expiry produces silent token requests, usually non-interactive
Refresh token (public client)
90 days, sliding with use
Long-lived; revoked on password change or revokeSignInSessions
Browser session token
24 hours, rolling
Drives the daily "sign in again" in browsers; CA sign-in frequency overrides
Primary Refresh Token (PRT)
90 days, continuously extended
Device SSO; requires periodic re-auth per policy to refresh its MFA claim
ID / SAML token
~1 hour
Assertion-level; replay window short
The PRT detail that matters operationally: a PRT carries an MFA claim that is only considered fresh for a limited window. When a Conditional Access policy requires MFA and the claim is stale, the user gets an interactive prompt — not a failure. If the device has no PRT at all (hybrid join broken, WAM issues), every token request that needs device SSO shows up as silent sign-in errors instead.
Changing lifetimes: the modern levers
You have three levers, and they are not equivalent:
Conditional Access sign-in frequency — the recommended control for how often users re-authenticate in browsers and, increasingly, everywhere. Per-user, per-app, or tenant-wide; no policy objects to attach by hand.
Continuous Access Evaluation (CAE) — instead of short access tokens, CAE-enabled clients get longer-lived tokens (measured in many hours) that are revoked near-real-time on critical events: account disable, password change, high-risk detection. This is the correct answer to "I want shorter tokens for security" — revocation beats expiry for actual risk reduction.
Configurable token lifetimes (preview) — tokenLifetimePolicy objects that adjust refresh and session token maximums for specific apps. They are not honored for CAE-capable clients or most first-party workloads, so treat this as an app-specific exception tool, not a tenant strategy:
Then attach the policy to the target application's service principal. Never set isOrganizationDefault to true to "fix one app" — that changes behavior tenant-wide.
Field note: The "sign-in loop" where a user authenticates successfully and lands back on the login page is rarely a token lifetime issue. It is a session cookie problem: third-party cookie blocking, a hostname mismatch on a custom domain, or SameSite behavior in an embedded webview. Fix the session, not the token.
An error-code field guide
These are the codes that generate real tickets, with the fix that actually ends them:
Code
Meaning
Real fix
50058
Silent sign-in requested but no session/PRT exists
Fix device SSO (PRT present?), or force interactive flow for the app
50076
MFA required to satisfy policy
Expected control result; check the user completed MFA or the CA policy needs review
50053
Account locked / smart lockout triggered
Investigate source of bad passwords (often a misconfigured service retrying); IP-isolate the source
50105
User not assigned to the application
Assign user/group to the enterprise app (or enable assignment-optional deliberately)
50158
Third-party MFA challenge not satisfied
Check the external MFA provider integration and its per-app exemptions
50173
Grant expired or was revoked (password change, revocation)
User re-authenticates; if frequent, look for password resets or automation stomping sessions
50196
Loop detected — client requesting tokens in a cycle
App configuration bug; capture correlation ID and engage the app owner
53003
Blocked by Conditional Access
Read the CA tab: which policy, which requirement failed
530032
Device not compliant
Enroll/fix compliance evaluation; check the compliance policy reached the device
90094
Admin consent required
Approve consent via admin consent workflow or grant deliberately
Correlation habit: always pull the correlation ID and request ID from the failure before escalating. They are the join key between user report, log entry, and (when needed) a Microsoft support case.
FailureDetail is newer and human-readable — include it before you start pattern-matching codes from memory.
KQL: prioritize by blast radius
With sign-in logs in Log Analytics or Sentinel, interactive and non-interactive live in separate tables — query both when an app is "flaky":
KQL
1
2
3
4
5
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(24h) and ResultType != 0
| summarize Attempts = count(), AffectedUsers = dcount(UserPrincipalName)
by ResultType, AppDisplayName
| order by Attempts desc
High attempt-count with low user count is one noisy device or service account. One attempt with high user count is a policy or outage. That single distinction usually chooses your next hour.
Visual Walkthrough
The professional investigation loop every troubleshooting post assumes.
Client log, service-side report, or event channel — one at a time.
filter
2
Filter to the window
Timestamps first: start where the failure actually happened.
correlate
3
Correlate across layers
Client ↔ service ↔ event logs agree on the same story?
hypothesis
4
Form one hypothesis
State it falsifiably: "detection ran before install finished".
verify
5
Verify in clean test
Reproduce in a pilot device with logs open — then generalize.
6
Document the fix
Runbook entry: symptom → root cause → durable fix.
Log Triage Method — Collect, Filter, Correlate, Conclude. 1. Collect the right source: Client log, service-side report, or event channel — one at a time. — 2. Filter to the window: Timestamps first: start where the failure actually happened. — 3. Correlate across layers: Client ↔ service ↔ event logs agree on the same story? — 4. Form one hypothesis: State it falsifiably: "detection ran before install finished". — 5. Verify in clean test: Reproduce in a pilot device with logs open — then generalize. — 6. Document the fix: Runbook entry: symptom → root cause → durable fix.
Conditional Access interplay
Every sign-in is evaluated against your CA policy set, and the log shows each policy's verdict. Two failure patterns to internalize:
Report-only success, enforced failure: the CA tab shows report-only policies that would have blocked. Review report-only insights before enforcement, not after the 500-reports fire drill.
Compliance loops: a policy requiring compliant devices blocks the app the user needs to get compliant (Company Portal, Intune endpoints). Exempt the enrollment apps from the device-compliance requirement — this is deliberate design, not an exception rotting.
CAE changes the risk calculus here too: with CAE on, password changes and disables terminate sessions within minutes, which means your "short token lifetime" instinct can safely give way to "long-lived tokens, fast revocation."
Revocation levers when something is compromised
When a session needs to die now, in order of speed and scope:
PowerShell
1
Revoke-MgUserSignInSession -UserId$upn
revokeSignInSessions / the portal's "Revoke sessions" — invalidates refresh tokens; user re-authenticates everywhere on next use.
Password change — also revokes refresh tokens; pair with revocation for stolen-credential response.
Disable account — with CAE, near-immediate session termination; without CAE, revocation plus disable is the belt-and-suspenders combo.
Conditional Access — sign-in frequency and risk-based policies tighten the future, but they are policy, not emergency response.
Field note: Revocation does not eject already-issued access tokens for non-CAE clients. If the asset is a token-stealer scenario, revocation plus CAE-capable clients is the durable fix; otherwise accept the ~one-hour access-token window in your incident timeline.
Key takeaways
Non-interactive sign-ins are where refresh failures live; filter them in before declaring "no logs."
The CA tab, authentication details, and token info fields do the diagnosing — read them in that order.
Access tokens run about an hour; PRTs carry device SSO for 90 days and their MFA claim freshness drives interactive prompts.
Use CA sign-in frequency and CAE as primary lifetime controls; token lifetime policies are a preview-grade, app-specific exception tool.
50105 means assignment, 530032 means compliance, 53003 means read the CA tab — three different fixes for three different teams.
Log retention is 7 days free, 30 days with P1/P2; stream to Log Analytics if you need history.
Revoke-MgUserSignInSession plus password change is the emergency lever; CAE shortens what remains from ~an hour to minutes.
Frequently asked questions
Why does a user see an MFA prompt although they did MFA an hour ago?
The CA policy required MFA and the MFA claim on their token/PRT was stale, or your sign-in frequency or authentication strengths policy forces a fresh strong auth. This is expected behavior, not a defect — check which policy applied and what requirement it satisfied in the log's CA and authentication-details sections.
Are non-interactive sign-ins a security concern?
Individually, no — they are the machinery of SSO. A surge of non-interactive failures for one account, though, is a classic token-theft or misconfigured-service signal. Alert on failure rate per account, not on the raw volume of non-interactive successes.
Can I shorten access tokens tenant-wide to 15 minutes?
Not sensibly. Access token lifetime is not broadly configurable anymore, and CAE makes the idea obsolete: long-lived tokens with near-real-time revocation on risk events are strictly better than short tokens that still live their full 15 minutes after an account is compromised.
Comments
0No comments yet — be the first to share your thoughts.