EI1.2 Interactive vs Non-Interactive Sign-Ins

Why the distinction matters

When you query SigninLogs in KQL, you are querying only interactive sign-ins — the events where a user actively participated in the authentication process by entering credentials, completing MFA, or selecting an account. These are the sign-ins that represent a human decision to authenticate.

Non-interactive sign-ins — the background token refreshes, silent SSO events, and automated token exchanges that keep applications signed in — are recorded in a separate table: AADNonInteractiveUserSignInLogs. If you only query SigninLogs, you see the moments where users proved their identity. If you only query AADNonInteractiveUserSignInLogs, you see the ongoing session maintenance that keeps their access alive.

For identity security, both tables matter — but they answer different questions.

Interactive sign-ins (SigninLogs) answer: when did this user explicitly authenticate? What authentication method did they use? Did conditional access evaluate the sign-in? Was MFA required and completed? These are the events that represent a new authentication decision — the moments when Entra ID evaluated all signals and made an access determination.

Non-interactive sign-ins (AADNonInteractiveUserSignInLogs) answer: is this user's session still active? What applications are they accessing in the background? Is token refresh happening from the expected device and IP? These are the events that represent ongoing access — the automated processes that keep the user signed in to Teams, Outlook, OneDrive, and other applications that refresh their tokens silently.

The volume difference is dramatic. A typical user generates one to five interactive sign-ins per day (when they sign in to their device in the morning, when they open a new application, when they return from a session timeout). The same user generates dozens to hundreds of non-interactive sign-ins per day as their applications refresh tokens in the background. If you query both tables without filtering, the non-interactive volume overwhelms the interactive events.

How interactive authentication works

An interactive sign-in occurs when the user is directly involved in the authentication process. The browser or application redirects the user to the Entra ID sign-in page, the user provides credentials (password, passkey, or another method), MFA is presented if required, and the user completes the challenge. The full conditional access evaluation occurs during this interactive sign-in — all policies are evaluated, all signals are assessed, and the access decision is made.

Interactive sign-ins are the security-critical events for several reasons. They are the moment where the attacker's stolen credentials are used for the first time. They are the moment where conditional access can block a suspicious sign-in. They are the moment where Identity Protection evaluates the sign-in context and assigns a risk level. If you are looking for evidence of initial access (Stage 2 of the identity kill chain from EI0.6), you are looking in the interactive sign-in logs.

Common triggers for interactive sign-ins: the user opens a browser and navigates to portal.office.com for the first time that day, the user's session has expired and the application prompts for re-authentication, a conditional access policy requires sign-in frequency and the configured interval has passed, the user opens a new application for the first time, or the user's risk level changed and a risk-based policy forces re-authentication.

How non-interactive authentication works

A non-interactive sign-in occurs when an application automatically refreshes its tokens without user involvement. The most common non-interactive sign-in is a refresh token exchange — the application's existing refresh token is sent to Entra ID, and Entra ID returns a new access token (and optionally a new refresh token) without presenting any UI to the user.

Non-interactive sign-ins are important for security monitoring because they reveal the ongoing pattern of access. An attacker who stole a refresh token and is replaying it generates non-interactive sign-ins from the attacker's IP address. If the user is simultaneously generating non-interactive sign-ins from their legitimate device, you see two concurrent streams of non-interactive activity for the same user from different IP addresses — a strong indicator of token theft.

The challenge is that non-interactive sign-ins do not always trigger conditional access evaluation in the same way interactive sign-ins do. Some conditional access session controls (like sign-in frequency) apply to non-interactive token refreshes, but the full policy evaluation that occurs during an interactive sign-in may not be repeated during every token refresh. This is why Continuous Access Evaluation (CAE) exists — it extends the enforcement window beyond the interactive sign-in to include ongoing access (covered in EI7).

// EI1.2 — Compare interactive vs non-interactive volume for a user
// Shows the typical ratio: 1 interactive event to 50+ non-interactive
let targetUser = "admin@yourdomain.onmicrosoft.com";  // Replace with your admin UPN
let timeRange = 24h;
union 
    (SigninLogs 
    | where TimeGenerated > ago(timeRange) 
    | where UserPrincipalName == targetUser 
    | summarize InteractiveCount = count() by bin(TimeGenerated, 1h)
    | extend LogType = "Interactive"),
    (AADNonInteractiveUserSignInLogs 
    | where TimeGenerated > ago(timeRange) 
    | where UserPrincipalName == targetUser 
    | summarize NonInteractiveCount = count() by bin(TimeGenerated, 1h)
    | extend LogType = "Non-Interactive")
| order by TimeGenerated asc
// Expected: Non-interactive count is 10-100x higher per hour than interactive
// This is normal — it represents background token refreshes

When to query which table

For different security questions, you need different tables:

"Was this user's account used to authenticate today?" — query SigninLogs for interactive events. This tells you whether someone actively signed in as this user.

"Is a stolen token being replayed right now?" — query AADNonInteractiveUserSignInLogs. Token replay generates non-interactive events because the attacker is using the stolen token without re-authenticating. Look for non-interactive sign-ins from an IP address that differs from the user's recent interactive sign-in IP.

"What applications is this user accessing?" — query both tables. The interactive log shows which applications the user explicitly opened. The non-interactive log shows which applications are refreshing tokens in the background — a broader view of the user's access footprint.

"Did conditional access block a sign-in attempt?" — query SigninLogs with ResultType 53003 or ConditionalAccessStatus == "failure". Conditional access blocking is recorded in the interactive log because the block occurs during the initial authentication attempt.

"Is legacy authentication being used?" — query both tables with ClientAppUsed filters for "IMAP," "POP3," "SMTP," "Exchange ActiveSync," and "Other clients." Legacy protocols can appear in either table depending on the protocol and client behavior.

"How many sign-in events does this user generate per day?" — query both tables. If you only query SigninLogs, you drastically undercount. If you need a realistic volume assessment (for log ingestion cost planning or for establishing a baseline), you need the full picture from both tables.

// EI1.2 — Detect potential token replay: different IPs in interactive vs non-interactive
// for the same user within a short time window
let timeRange = 1h;
let interactiveIPs = SigninLogs
| where TimeGenerated > ago(timeRange)
| where ResultType == 0
| distinct UserPrincipalName, IPAddress;
AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(timeRange)
| where ResultType == 0
| join kind=inner interactiveIPs on UserPrincipalName
| where IPAddress != IPAddress1  // Non-interactive IP differs from interactive IP
| summarize 
    NonInteractiveIP = any(IPAddress),
    InteractiveIP = any(IPAddress1),
    EventCount = count()
    by UserPrincipalName
| where EventCount > 5  // At least 5 non-interactive events from the different IP
// Results: users with concurrent sessions from different IPs — potential token theft
// Validate: is the non-interactive IP a known VPN, proxy, or Microsoft IP?

This query is a practical token replay detection pattern. The logic: if a user interactively signed in from IP-A and simultaneously has non-interactive token refreshes from IP-B, someone else may be using a stolen token from IP-B. This pattern has false positives (VPNs, mobile network switching, Microsoft service IPs), but it is a strong starting point that EI13 refines into a production detection rule.