Authentication Details Deep Dive

The AuthenticationDetails array

The AuthenticationDetails field in the sign-in log is a JSON array where each element represents one step in the authentication process. A password-only sign-in produces one element. A password-plus-MFA sign-in produces two. A passwordless FIDO2 sign-in produces one element with different properties than a password sign-in — the single step satisfies both primary authentication and MFA simultaneously.

Each element carries four fields that matter for security analysis. The authenticationMethod identifies what was used — "Password," "FIDO2 security key," "Passkey (Microsoft Authenticator)," "Windows Hello for Business," "X.509 Certificate," or "Previously satisfied." The authenticationStepResultDetail records the outcome — "MFA successfully completed," "MFA denied (user declined the authentication)," "MFA denied (fraud code reported)," or "MFA requirement satisfied by claim in the token." The authenticationStepRequirement classifies the step as "Primary authentication" or "Multifactor authentication." The succeeded boolean confirms whether this step passed.

The authenticationStepDateTime timestamps each step. The gap between steps reveals behavior — a normal user completes MFA in 5-30 seconds. An unusually long gap might indicate confusion, an MFA fatigue attack where the user initially ignored prompts before approving, or a number-matching challenge that required the user to check a secondary device.

One critical platform change affects how you read these records: since April 2025, FIDO2 sign-ins that obtain a refresh token are logged in the non-interactive sign-in table (AADNonInteractiveUserSignInLogs), not the interactive table. If you're querying only SigninLogs for FIDO2 adoption metrics, you'll undercount. Query both tables for accurate phishing-resistant coverage measurement. This change also means that a user signing in with a FIDO2 key and then accessing multiple applications will show one non-interactive sign-in per application — not one interactive sign-in. The authentication flow hasn't changed, but where the evidence lands in your analytics has.

The authenticationMethodDetail field provides finer granularity within each method category. For Authenticator, it distinguishes between push notification, number matching, and passwordless phone sign-in. For phone-based methods, it shows whether the second factor was a call or an SMS message. For OATH tokens, it distinguishes hardware from software. This detail matters because your security posture differs even within the same method category — number matching is significantly more resistant to MFA fatigue than simple push approval, even though both appear under "Microsoft Authenticator."

A field that catches new practitioners off guard is the succeeded boolean. A record where succeeded is false but the overall sign-in ResultType is 0 (success) is not contradictory — it means the first authentication step failed but a subsequent step succeeded. This happens in fallback scenarios: the user's primary method fails (Authenticator times out), and they fall back to a secondary method (phone call). Both steps appear in the array, with the first showing succeeded: false and the second showing succeeded: true. The overall sign-in succeeds because at least one valid authentication path completed.

Here is what the array looks like for three different authentication scenarios. First, a password-plus-push-notification sign-in — phishing-capable:

{
  "userPrincipalName": "p.sharma@contoso.com",
  "authenticationRequirement": "multiFactorAuthentication",
  "authenticationDetails": [
    {
      "authenticationStepDateTime": "2025-11-14T09:23:17Z",
      "authenticationMethod": "Password",
      "authenticationStepResultDetail": "Correct password",
      "authenticationStepRequirement": "Primary authentication",
      "succeeded": true
    },
    {
      "authenticationStepDateTime": "2025-11-14T09:23:29Z",
      "authenticationMethod": "Microsoft Authenticator (push notification)",
      "authenticationStepResultDetail": "MFA successfully completed",
      "authenticationStepRequirement": "Multifactor authentication",
      "succeeded": true
    }
  ]
}

Two steps: password, then push notification. The 12-second gap between steps is normal. This sign-in satisfies MFA but is vulnerable to AiTM — the proxy captures the session token after both steps complete. The Authenticator push notification does not verify the domain, so a proxied page is indistinguishable from the real one.

Now compare a FIDO2 sign-in — phishing-resistant:

{
  "userPrincipalName": "alex.security@contoso.com",
  "authenticationRequirement": "multiFactorAuthentication",
  "authenticationDetails": [
    {
      "authenticationStepDateTime": "2025-11-14T09:25:03Z",
      "authenticationMethod": "FIDO2 security key",
      "authenticationStepResultDetail": "MFA successfully completed",
      "authenticationStepRequirement": "Primary authentication",
      "succeeded": true
    }
  ]
}

One step. The FIDO2 key satisfies both primary authentication and MFA in a single cryptographic operation. The key verifies the domain — login.microsoftonline.com — cryptographically. A proxy at a different domain cannot produce a valid response because the domain doesn't match, so the authentication fails silently. This is what phishing-resistant means in practice: the method itself prevents the attack, regardless of user behavior.

The security classification

Every authenticationMethod value falls into one of three tiers. The classification determines your exposure to AiTM and your true MFA posture.

Phishing-resistant methods cryptographically verify the login domain. FIDO2, passkeys, Windows Hello for Business, and certificate-based authentication all perform a domain check as part of the cryptographic handshake. A proxy page at a different domain fails this check automatically — the user sees an error, not a successful sign-in. One authentication step satisfies both primary and MFA requirements.

Phishing-capable methods complete MFA but do not verify the domain. Password plus Authenticator push, number matching, phone call, SMS, or OATH token all rely on the user approving a challenge that the AiTM proxy can relay in real time. Number matching reduces MFA fatigue risk significantly — the user must enter a displayed number rather than just tapping "Approve" — but the proxy can display or relay the number. These methods stop password spray and credential stuffing but not AiTM.

Weak methods provide no second factor. Password-only sign-ins, app passwords, and legacy authentication protocols (IMAP, POP3, SMTP with basic auth) are directly exploitable by password spray. If your classification query returns any sign-ins in this tier, your legacy authentication blocking has gaps.

MFA satisfaction: completed versus claimed

A sign-in that shows authenticationRequirement: "multiFactorAuthentication" does not necessarily mean the user was actively challenged on that specific sign-in. There are three satisfaction scenarios, and the security implications differ significantly.

Actively completed. The user received a prompt and completed the challenge during this sign-in. The array shows two steps with the second step's authenticationStepResultDetail reading "MFA successfully completed." This is the strongest verification — the user proved their identity at the moment of access.

Satisfied by prior claim. The user completed MFA in a previous sign-in, and the token carries that claim forward. The authenticationStepResultDetail reads "MFA requirement satisfied by claim in the token." This happens when sign-in frequency policies allow it — if the policy says "require MFA every 4 hours," sign-ins within the window carry the claim without re-prompting. The user was not actively verified at this specific sign-in. For an attacker replaying a stolen token, this is the value they want to see — it means the token's MFA claim is being accepted without a fresh challenge.

Not required. No Conditional Access policy required MFA. The authenticationRequirement shows "singleFactorAuthentication" and there is no second step. This is either expected (the sign-in was to a resource not covered by MFA policy) or it reveals a gap in your CA coverage.

The query that exposes this gap across your entire tenant:

// Classify all successful sign-ins by authentication strength
// Run weekly to track phishing-resistant adoption
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| extend AuthDetail = parse_json(AuthenticationDetails)
| extend PrimaryMethod = tostring(AuthDetail[0].authenticationMethod)
| extend MFAMethod = tostring(AuthDetail[1].authenticationMethod)
| extend AuthStrength = case(
    PrimaryMethod in ("FIDO2 security key", "Passkey (Microsoft Authenticator)",
        "Windows Hello for Business", "X.509 Certificate"), "Phishing-Resistant",
    MFAMethod != "", "Phishing-Capable (MFA)",
    PrimaryMethod == "Password", "Weak (Password Only)",
    "Other")
| summarize
    SignIns = count(),
    Users = dcount(UserPrincipalName)
    by AuthStrength
| order by SignIns desc

This query gives you the tenant-wide authentication strength distribution. Run it weekly. The trend you want over time is an increasing percentage of phishing-resistant authentication and a decreasing percentage of phishing-capable — the migration that EI2 teaches you to plan and execute.

Detecting token replay through authentication claims

The most security-critical use of the AuthenticationDetails array is detecting token replay — the technique behind AiTM attacks. When an attacker replays a stolen session token, the sign-in record reveals specific indicators that are invisible if you only check the top-level status fields.

The first indicator is authenticationStepResultDetail showing "MFA requirement satisfied by claim in the token" combined with an unfamiliar IP address or location. Legitimate claim-based satisfaction happens frequently — when a user moves between applications within the same session window, each application sign-in inherits the MFA claim from the original authentication. This is normal SSO behavior. An attacker replaying a stolen token also produces claim-based satisfaction, but from an IP that doesn't match the user's established pattern. The distinction is not in the claim itself but in the network context surrounding it.

The second indicator is authenticationRequirement showing "singleFactorAuthentication" for a user who should require MFA. When a token carrying an MFA claim is replayed from a different device, the replayed session may show single-factor because the token itself carries the prior authentication state — Entra ID accepts the token's embedded claims rather than requiring a fresh challenge. The combination of single-factor requirement with a successful outcome for a user in an MFA-required group is a high-fidelity signal worth investigating.

The third indicator is the device context mismatch. The DeviceDetail object in the replayed sign-in typically shows a different operating system, browser, or device ID than the user's normal device. An AiTM attacker replaying a token from their own machine produces a sign-in where the MFA claim was satisfied on a Windows device with Chrome but the sign-in originates from a Linux device with a different Chrome version. The authentication was legitimate — the context was not.

// Detect potential token replay: MFA satisfied by claim from unusual IP
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| extend AuthDetail = parse_json(AuthenticationDetails)
| extend MFASatisfaction = tostring(AuthDetail[0].authenticationStepResultDetail)
| where MFASatisfaction has "claim in the token"
| project
    TimeGenerated,
    UserPrincipalName,
    AppDisplayName,
    IPAddress,
    Location = strcat(tostring(LocationDetails.city), ", ",
        tostring(LocationDetails.countryOrRegion)),
    MFASatisfaction,
    RiskLevelDuringSignIn,
    DeviceOS = tostring(DeviceDetail.operatingSystem)
| order by TimeGenerated desc
// Review: Are these from expected IPs and locations?
// MFA-by-claim from an unfamiliar location = investigate immediately

Any result from this query where the IP address or location doesn't match the user's normal pattern warrants immediate investigation. The attacker's replayed token produces exactly this pattern — MFA "satisfied" without a fresh challenge, from a device and network the user has never used before. EI13 turns this query into an automated detection rule.

Applying this to your environment

The authentication method distribution tells you three things about your security posture that no compliance report captures.

First, your phishing-resistant coverage percentage — how many sign-ins use methods that stop AiTM. Run the classification query and look at the "Phishing-Resistant" row. If the number is below 10%, you have almost no protection against the most dangerous identity attack in production today. The 97% of identity attacks that are password spray or brute force are stopped by any MFA method. The remaining 3% — AiTM, token theft, consent phishing — require phishing-resistant methods to prevent. That 3% is where the breaches in Section 0.7 live. EI2 addresses this directly with a phishing-resistant deployment plan.

Second, your legacy authentication exposure — how many sign-ins use password-only without any second factor. Filter the classification query for "Weak (Password Only)" and examine the applications. Legacy protocols like IMAP, POP3, and SMTP with basic auth bypass MFA entirely because the protocols don't support the interactive authentication flow where MFA challenges are issued. A user with a strong password and FIDO2 registered can still be compromised through an IMAP connection using the same password with no MFA challenge. If your classification shows any sign-ins in the weak tier, blocking legacy authentication in Conditional Access is the first policy you should deploy — it eliminates the most exploitable authentication path with no user-facing change for modern clients.

Third, your MFA satisfaction pattern — the ratio between active MFA challenges and cached claim satisfaction. A high percentage of claim-based satisfaction with long sign-in frequency windows means tokens carry authentication state for extended periods — sometimes 24 hours or more. If a token is stolen during that window, the attacker inherits the cached MFA claim and can access resources without being challenged. EI4 covers sign-in frequency tuning to balance user experience (fewer MFA prompts) against token exposure (shorter windows reduce replay risk). There is no universally correct answer — it depends on your user population, risk tolerance, and the sensitivity of the resources. The data from this query tells you where you currently stand so the design decision is informed rather than arbitrary.

Record these three numbers now. They are your authentication method baseline. Every change you make in EI2 (deploying phishing-resistant methods), EI3 (blocking legacy auth), and EI4 (tuning sign-in frequency) should move these numbers measurably. If a control deployment doesn't change the numbers, it isn't working as intended — and the AuthenticationDetails array is how you prove it to yourself and to leadership.