Interactive vs Non-Interactive Sign-Ins

Two tables, two authentication patterns

When you query SigninLogs in Sentinel, you see only interactive sign-ins — the events where a user actively participated by entering credentials, completing MFA, or selecting an account. These represent a human decision to authenticate. A typical user generates one to five of these per day.

Non-interactive sign-ins — the background token refreshes, silent SSO events, and automated token exchanges that keep applications signed in — live in a separate table: AADNonInteractiveUserSignInLogs. A typical user generates dozens to hundreds of these per day. Teams refreshes its token every few minutes. Outlook refreshes when new mail arrives. OneDrive refreshes when syncing files. Each refresh produces a non-interactive sign-in event.

The security implications are different for each type. Interactive sign-ins 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 moments where Entra ID makes a full access decision — the enforcement point where your security controls either work or fail.

Non-interactive sign-ins answer: is this user's session still active? What applications are accessing data in the background? Is token refresh happening from the expected device and location? These reveal session persistence — the ongoing access pattern that token theft exploits. An attacker with a stolen refresh token never appears in interactive logs because they never re-authenticate — they silently refresh the token and access resources without triggering any of the controls that protect the initial sign-in.

How interactive authentication generates log entries

An interactive sign-in occurs when the user is directly involved in authentication. The browser or application redirects to the Entra ID sign-in page, the user provides a credential (password, passkey, certificate), MFA is challenged if required, and the user completes it. The full Conditional Access evaluation runs during this event — all policies assessed, all signals evaluated, access decision made.

Interactive sign-ins are the security-critical events for initial access detection. They capture the moment an attacker's stolen credentials are used for the first time. They capture the moment Conditional Access blocks a suspicious sign-in. They capture the moment Identity Protection assigns a risk level based on location, device, and behavioral signals. If you're looking for evidence of Stage 2 in the kill chain (Section 0.5), you're looking in interactive sign-ins.

Common triggers: the user opens a browser and navigates to office.com for the first time that day. A session has expired and the application forces re-authentication. A Conditional Access policy enforces sign-in frequency and the interval has passed — this is configurable per policy in EI4, typically between 1 and 24 hours for sensitive applications. The user opens an application they haven't accessed before, which triggers a new consent or authentication flow. A risk-based policy forces re-authentication because the user's risk level changed from none to medium based on an Identity Protection detection.

The ResultType field in interactive sign-ins tells you whether the authentication succeeded (0) or failed (non-zero). Common failure codes you'll see: 50126 (invalid credentials — wrong password), 53003 (Conditional Access blocked the sign-in), 50074 (MFA required but not completed), 50076 (MFA challenge presented), and 530032 (security policy blocked the sign-in). These error codes are your first triage signal — a burst of 50126 errors across multiple accounts from the same IP is a password spray. A 53003 means your CA policy worked. A 50074 followed by a successful sign-in means MFA was challenged and completed.

One important change from April 2025: FIDO2 key sign-ins that obtain a refresh token are now logged in non-interactive sign-in logs, not interactive. This reflects the technical reality — the FIDO2 key authenticates once interactively, and subsequent refresh token acquisitions are non-interactive even though they involve the key. If you're tracking FIDO2 adoption by counting interactive sign-ins with AuthenticationMethodsUsed containing "FIDO," your numbers will be lower than expected after this change. Section 1.4 covers how to accurately measure authentication method distribution across both tables.

How non-interactive authentication generates log entries

A non-interactive sign-in occurs when an application refreshes its token without user involvement. The most common pattern is a refresh token exchange — the application sends its existing refresh token to Entra ID and receives a new access token (and optionally a new refresh token) without presenting any UI.

This is what a non-interactive token refresh looks like in the raw data:

{
  "userPrincipalName": "admin@yourdomain.onmicrosoft.com",
  "appDisplayName": "Microsoft Teams",
  "isInteractive": false,
  "incomingTokenType": "refreshToken",
  "status": { "errorCode": 0 },
  "ipAddress": "198.51.100.42",
  "deviceDetail": {
    "operatingSystem": "Windows 11",
    "browser": "Edge 124",
    "deviceId": "d8f3a2b1-..."
  },
  "conditionalAccessStatus": "success",
  "authenticationRequirement": "singleFactorAuthentication",
  "authenticationDetails": [
    {
      "authenticationMethod": "Previously satisfied",
      "succeeded": true
    }
  ]
}

The isInteractive: false flag distinguishes this from an interactive sign-in. The incomingTokenType: "refreshToken" tells you this is a token refresh, not a new authentication. The authenticationMethod: "Previously satisfied" means no new credential was presented — the existing token carried the authentication claim forward. The conditionalAccessStatus: "success" means CA evaluated (or was previously satisfied) for this token refresh.

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

The IncomingTokenType field (added in late 2024) tells you which token was presented for the refresh. The common values are refreshToken (standard application refresh), primaryRefreshToken (device-level SSO refresh via PRT), and saml20 (federated authentication). For security monitoring, PRT refreshes are the highest-value events — the PRT provides SSO across all applications, so a stolen PRT generates non-interactive sign-ins across every Microsoft 365 application simultaneously. A stolen application-specific refresh token generates events for only that application.

The challenge: non-interactive sign-ins do not always trigger full Conditional Access evaluation. Some session controls (like sign-in frequency) apply to token refreshes, but the complete policy evaluation that runs during interactive sign-ins may not repeat for every refresh. This creates a window where a stolen token can be used without encountering the same controls that protect the initial sign-in. Continuous Access Evaluation (CAE) addresses this gap — it enables near-real-time enforcement of critical events (user disabled, password changed, IP outside trusted range) even during non-interactive token refreshes. Without CAE, a stolen token remains valid until it expires naturally. With CAE, enforcement can occur within minutes. EI7 covers CAE deployment and the specific events that trigger re-evaluation.

Querying both tables for security questions

Different security questions require different tables. The table you query determines what you see — and what remains invisible.

"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 — the credential was presented, the challenge was completed. A ResultType of 0 means success. Any other value means the attempt failed, and the ResultType tells you why.

"Is a stolen token being replayed?" Query AADNonInteractiveUserSignInLogs. Token replay generates non-interactive events because the attacker uses the stolen token without re-authenticating. Look for non-interactive sign-ins from an IP that differs from the user's recent interactive sign-in IP. The IncomingTokenType field tells you whether they're replaying a refresh token or a PRT — PRT replay is more dangerous because it provides access to all applications.

"What applications is this user accessing?" Query both tables. Interactive logs show which apps the user explicitly opened. Non-interactive logs show which apps are refreshing tokens silently — a broader view of the access footprint. The AppDisplayName field in non-interactive logs often reveals applications the user doesn't realize are running, like background sync services and mobile mail clients.

"Did Conditional Access block a sign-in?" Query SigninLogs with ConditionalAccessStatus == "failure" or ResultType == 53003. CA blocking is recorded in the interactive log because the block occurs during the initial authentication attempt. A successful block is evidence your policy is working — track these as a positive security metric.

"Is legacy authentication being used?" Query both tables. Filter by ClientAppUsed for IMAP, POP3, SMTP, Exchange ActiveSync, and "Other clients." Legacy protocols appear in either table depending on the protocol and client behavior. Any legacy authentication is a security gap — these protocols don't support MFA and are the primary target for password spray attacks.

"How many sign-in events does this user generate daily?" Query both tables. If you only query SigninLogs, you drastically undercount — you'll see 5 events when the real number is 500. For log ingestion cost planning, storage capacity assessment, and establishing a realistic baseline, you need the full volume from both tables.

Run this query to see the volume ratio in your own environment:

// Compare interactive vs non-interactive volume per user
// Expected ratio: 1 interactive to 50-100+ non-interactive
let timeRange = 24h;
union
    (SigninLogs
    | where TimeGenerated > ago(timeRange)
    | where ResultType == 0
    | summarize Interactive = count() by UserPrincipalName),
    (AADNonInteractiveUserSignInLogs
    | where TimeGenerated > ago(timeRange)
    | where ResultType == 0
    | summarize NonInteractive = count() by UserPrincipalName)
| summarize Interactive = sum(Interactive),
    NonInteractive = sum(NonInteractive)
    by UserPrincipalName
| extend Ratio = round(todouble(NonInteractive) / todouble(Interactive), 1)
| sort by NonInteractive desc
| take 20

A ratio of 50:1 to 100:1 is normal. If you see a user with a ratio of 500:1 or higher, investigate — it could indicate an automated tool or a compromised token generating excessive refresh activity.

Detecting token replay across tables

The most valuable cross-table pattern for identity security is the token replay detection: an attacker using a stolen token from a different location while the legitimate user continues their normal session.

// Detect potential token replay: different IPs in interactive
// vs non-interactive for the same user within 1 hour
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
| summarize
    NonInteractiveIP = any(IPAddress),
    InteractiveIP = any(IPAddress1),
    EventCount = count()
    by UserPrincipalName
| where EventCount > 5
// Results: users with concurrent sessions from different IPs
// Validate: is the non-interactive IP a VPN, proxy, or Microsoft IP?

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 — VPN split tunneling, mobile network switching, Microsoft service IPs that proxy token refresh requests — but it's a strong starting point. EI13 refines this into a production detection rule with IP exclusion lists, geo-distance calculations between the two IPs, and time-window correlation.

When you run this query in your developer tenant, you'll likely see zero results because your tenant has only a few accounts generating traffic from the same network. In a production environment with hundreds of users across multiple offices and remote workers, this query produces actionable results by identifying the small number of users who have concurrent sessions from geographically impossible locations. The distance between the two IPs is the key signal — two IPs in the same city might be VPN and direct connection. Two IPs on different continents with simultaneous activity is a high-confidence indicator.

The union pattern and when to use it

When you need the complete authentication picture for a user — both interactive and non-interactive — use the union operator. The two tables share the same schema for the core fields (UserPrincipalName, IPAddress, AppDisplayName, ConditionalAccessStatus, ResultType, DeviceDetail, LocationDetails), which makes union queries straightforward. The IsInteractive field (boolean) lets you distinguish the event type after the union.

// Complete sign-in timeline for a single user
// Shows both interactive and non-interactive events in sequence
let targetUser = "admin@yourdomain.onmicrosoft.com";
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1h)
| where UserPrincipalName == targetUser
| project TimeGenerated, IsInteractive,
    AppDisplayName, IPAddress, ResultType,
    AuthenticationRequirement, ConditionalAccessStatus
| sort by TimeGenerated asc

Use the union pattern when investigating a specific user's activity timeline, building a per-user baseline that captures their full authentication footprint, or analyzing application access patterns across all client types. Use single-table queries when answering specific security questions — interactive for initial access detection, non-interactive for session monitoring. The choice is driven by what you're looking for, not by a default preference.

A common mistake is using union for everything. If your query aggregates across thousands of users, the non-interactive volume dominates the results and obscures the interactive events that matter. For population-level queries like "which users authenticated with legacy protocols today" or "which users had CA policies fail," query SigninLogs alone first. Switch to the union pattern only when you need the full picture for a specific investigation or a specific user's baseline.