In this module

EI1.4 Authentication Details Deep Dive

60-80 minutes · Module 1 · Free

Operational Objective

A sign-in log entry shows ResultType 0 (success) and AuthenticationRequirement "multifactorAuthentication." But which authentication method did the user actually use? Was it a phishing-resistant FIDO2 key or a phishing-capable push notification? Was the MFA challenge prompted by conditional access or by a per-user MFA policy? Did the user complete MFA on this sign-in or was it satisfied by a claim from a previous session? The AuthenticationDetails array answers all of these questions — but only if you know how to read it.

Deliverable: The ability to parse the AuthenticationDetails array in any sign-in log entry, determine exactly which authentication methods were used and in which sequence, distinguish between phishing-resistant and phishing-capable authentication, and verify that conditional access MFA requirements are being met with the intended methods.

⏱ Estimated completion: 18 minutes

The AuthenticationDetails array

The AuthenticationDetails field in the sign-in log is an array of JSON objects, each representing one step in the authentication process. A simple password-only sign-in has one element. A password + MFA sign-in has two elements. A passwordless sign-in (FIDO2 or passkey) has one element but with different properties than a password sign-in.

Each element in the array contains the following fields:

Expand for Deeper Context

authenticationStepDateTime — the timestamp of this authentication step. The time difference between steps reveals how long the user took to complete MFA — a normal user completes MFA in 5-30 seconds. An unusually long delay might indicate the user was confused by the prompt, or it might indicate an MFA fatigue attack where the user initially ignored the prompts before eventually approving one.

authenticationStepResultDetail — the outcome of this step: "MFA successfully completed," "MFA denied (user declined the authentication)," "MFA denied (authentication phone was not reachable)," "MFA denied (fraud code reported)," or various other outcomes. The "fraud code reported" value is significant — it means the user reported the MFA prompt as fraudulent through the Authenticator app, which should trigger an immediate investigation.

authenticationStepRequirement — whether this step was required by policy or completed voluntarily: "Primary authentication," "Multifactor authentication," "Single-factor authentication."

authenticationMethodDetail — the specific method used at this step. For primary authentication: "Password," "FIDO2 security key," "Passkey (Microsoft Authenticator)," "Windows Hello for Business," "X.509 certificate." For MFA: "Microsoft Authenticator (push notification)," "Microsoft Authenticator (number matching)," "Phone call," "SMS," "OATH hardware token," "OATH software token."

This last field is the most security-critical. It tells you whether the user authenticated with a phishing-resistant method or a phishing-capable method. If your conditional access policies require phishing-resistant authentication for privileged users (as EI4 teaches), this field is how you verify the policy is working — you should never see "Password" + "Microsoft Authenticator (push notification)" for a privileged user if your policy requires FIDO2 or passkeys.

Reading the array in KQL

The AuthenticationDetails field is stored as a JSON array, which requires specific KQL operators to parse. Here is how to extract the authentication method details:

// EI1.4 — Extract authentication method from sign-in logs
// Shows exactly which method each user used for primary auth and MFA
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0  // Successful sign-ins only
| extend AuthDetail = parse_json(AuthenticationDetails)
| extend PrimaryMethod = tostring(AuthDetail[0].authenticationMethod)
| extend PrimaryDetail = tostring(AuthDetail[0].authenticationStepResultDetail)
| extend MFAMethod = tostring(AuthDetail[1].authenticationMethod)
| extend MFADetail = tostring(AuthDetail[1].authenticationStepResultDetail)
| project 
    TimeGenerated,
    UserPrincipalName,
    PrimaryMethod,         // "Password", "FIDO2 security key", "Passkey", etc.
    PrimaryDetail,         // "MFA requirement satisfied by claim in the token", etc.
    MFAMethod,             // The second factor method (if MFA was required)
    MFADetail,             // "MFA successfully completed", etc.
    AppDisplayName,
    ConditionalAccessStatus
| order by TimeGenerated desc
// Key lookups:
// PrimaryMethod = "Password" + MFAMethod = "Microsoft Authenticator" → phishing-capable
// PrimaryMethod = "FIDO2 security key" → phishing-resistant (no MFA step needed)
// PrimaryDetail = "MFA requirement satisfied by claim in the token" → MFA from prior session

The critical distinction is between "MFA requirement satisfied by claim in the token" and "MFA successfully completed." The first means the user completed MFA in a previous session and the claim carried over — the user was not actually challenged for MFA on this specific sign-in. The second means the user actively completed an MFA challenge during this sign-in. For security verification, you want to see active MFA challenges on sensitive sign-ins, not just claim carryover from a previous session that may have occurred hours or days ago.

Phishing-resistant vs phishing-capable

The authentication method detail is the field that determines your organization's exposure to AiTM attacks. Here is the security classification:

Phishing-resistant methods (cannot be proxied through AiTM because they cryptographically verify the domain): FIDO2 security key, Passkey (Microsoft Authenticator), Passkey (synced), Windows Hello for Business, X.509 certificate (certificate-based authentication). When these methods are used, the PrimaryMethod shows the method name and there is typically no second step — the method satisfies both primary authentication and MFA in a single cryptographic operation.

// EI1.4 — Classify all sign-ins by authentication strength
// Identifies phishing-resistant vs phishing-capable across your tenant
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 
    SignInCount = count(),
    DistinctUsers = dcount(UserPrincipalName)
    by AuthStrength
| order by SignInCount desc
// Goal: Phishing-Resistant should be the largest category for privileged users
// Weak (Password Only) should be zero if legacy auth is blocked

Expand for Deeper Context

Phishing-capable methods (can be intercepted by AiTM proxy): Password + Microsoft Authenticator (push notification), Password + Microsoft Authenticator (number matching), Password + Phone call, Password + SMS, Password + OATH token. Number matching significantly reduces MFA fatigue risk but does not prevent AiTM — the proxy can display the number matching value to the attacker who reads it to the user over the phone, or the AiTM kit can relay the number in real time.

Legacy methods (should be blocked entirely): Password only (no MFA), App passwords, legacy authentication protocols (IMAP, POP3, SMTP Basic Auth). These provide no second factor and are the most exploitable authentication path.

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

Figure EI1.4 - Authentication Details Deep Dive

MFA satisfaction: completed vs claimed

A subtle but important distinction in the AuthenticationDetails is how MFA was satisfied. There are three scenarios:

MFA actively completed on this sign-in. The user received a prompt and completed the challenge. The AuthenticationDetails show two steps: primary authentication (password) and MFA (Authenticator, phone, etc.) with authenticationStepResultDetail "MFA successfully completed." This is the most secure scenario — the user proved their identity at the moment of this specific sign-in.

// EI1.4 — Find sign-ins where MFA was satisfied by claim, not active challenge
// Combined with unusual IP — potential token replay indicator
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| where AuthenticationRequirement == "multiFactorAuthentication"
| 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
| order by TimeGenerated desc
// Review: Are these from expected IPs and locations?
// MFA-by-claim from an unexpected location = investigate immediately

Expand for Deeper Context

MFA satisfied by claim from a previous session. The user completed MFA in a previous sign-in and the claim carried over. The AuthenticationDetails show authenticationStepResultDetail "MFA requirement satisfied by claim in the token." This is normal when conditional access sign-in frequency allows it — if the policy says "require MFA every 4 hours," sign-ins within the 4-hour window carry the MFA claim without re-prompting. From a security perspective, this means the user was not actively verified at this specific sign-in — they are using a cached authentication state.

MFA not required. No conditional access policy required MFA for this sign-in. AuthenticationRequirement shows "singleFactorAuthentication" and there is no second step in AuthenticationDetails. This is either expected (the resource or user group is not covered by an MFA policy) or a gap in your conditional access coverage.

For security verification, the query to run is: find all successful sign-ins to sensitive applications where MFA was satisfied by a claim rather than actively completed, and the sign-in came from a new or unusual IP. This pattern can indicate token replay — the attacker is using a token that carries an MFA claim from the legitimate user's prior authentication.

Try it yourself

Try It — Classify Your Authentication Methods

Environment: Your M365 developer tenant with Sentinel workspace.

Exercise: Run the authentication strength classification query from above against your developer tenant. Answer these questions:

1. What percentage of sign-ins are phishing-resistant vs phishing-capable? 2. Are any sign-ins in the "Weak (Password Only)" category? If so, which applications and users? 3. For your admin account, what PrimaryMethod appears? If it is "Password," your admin account is signing in with a phishing-capable method — EI2 will address this.

Then run the MFA satisfaction query. Look at how MFA was satisfied — was it actively completed or satisfied by a cached claim? For a developer tenant with few users and no configured sign-in frequency, you may see mostly active completions. In a production environment, claim-based satisfaction is common and expected.

⚠ Compliance Myth: "Our conditional access requires MFA, so all sign-ins use strong authentication"

The myth: We have a conditional access policy that requires MFA for all users. Every sign-in is protected by multi-factor authentication.

The reality: "MFA required" does not specify which MFA method. A user completing MFA with an SMS code satisfies the MFA requirement but uses a phishing-capable method. A user completing MFA with a push notification satisfies the requirement but is vulnerable to MFA fatigue. Only a user completing MFA with a FIDO2 key or passkey satisfies the requirement with a phishing-resistant method. The AuthenticationDetails array reveals exactly which method was used. If your policy says "require MFA" but your users are all using push notifications, you are protected against password spray but vulnerable to AiTM. EI4 teaches how to build conditional access policies that require specifically phishing-resistant methods — authentication strength policies, not just "require MFA."

📋 Investigation Artifact — Authentication Method Classification Reference

Use this to classify any authenticationMethod value from the sign-in logs:

Authentication Method Security Classification

Phishing-Resistant (verify domain cryptographically):

- "FIDO2 security key"

- "Passkey (Microsoft Authenticator)"

- "Passkey (synced)"

- "Windows Hello for Business"

- "X.509 Certificate"

Phishing-Capable (interceptable by AiTM proxy):

- "Password" + "Microsoft Authenticator" (push)

- "Password" + "Microsoft Authenticator" (number matching)

- "Password" + "Phone call"

- "Password" + "Text message"

- "Password" + "OATH hardware token"

- "Password" + "OATH software token"

Weak / Legacy (no second factor):

- "Password" (alone, no MFA step)

- "App password"

- Legacy protocol authentication (IMAP, POP3, SMTP Basic)

MFA Satisfaction types:

- "MFA successfully completed" → active challenge on this sign-in

- "MFA requirement satisfied by claim in the token" → cached from prior session

- "MFA denied" → user failed or declined the challenge

Compliance mapping: Authentication method monitoring supports SOC 2 CC6.1.4 (Multifactor Authentication), ISO 27001 A.9.4.2 (Secure Log-on Procedures), and NIST CSF PR.AC-7 (Authentication).

Decision point

You are reviewing NE's Entra ID security posture. You find 4 accounts with Global Administrator role, but NE's policy says maximum 2. The extra 2 were added during the AiTM incident for emergency response and never removed. Do you remove them?

Remove them — but through the proper process, not unilaterally. Notify the account owners that their emergency GA assignment is being revoked, confirm they have their standard role assignments restored, and document the removal with the rationale ('emergency assignment during INC-NE-2026-0227-001, no longer required'). Then add a PIR action item: 'Implement PIM time-limited role assignments for future incident response — emergency GA assignments auto-expire after 8 hours rather than persisting indefinitely.' The stale emergency assignment is a governance failure, not a technical failure — the fix is procedural.

NE's Entra ID security audit reveals: 4 Global Administrators (policy says 2), 23 users with Global Reader from a completed project, a break-glass account with no monitoring rule, and 3 guest accounts with no expiry date. Which finding is the highest priority?

The 4 Global Administrators — 2 extra GAs doubles the attack surface.

The break-glass account with no monitoring rule. The 4 GAs and stale Global Readers are governance issues that should be remediated — but they are existing conditions, not active threats. The unmonitored break-glass account is a critical detection gap: if the break-glass account is compromised or misused, the SOC has no alert. A break-glass account is excluded from CA policies by design — it is the most powerful and least restricted account in the tenant. Without monitoring, its compromise or misuse is invisible. Deploy the monitoring rule (any sign-in to the break-glass account = Severity 1 alert) before addressing the other findings.

The 23 stale Global Readers — this is the largest number of affected accounts.

The 3 guest accounts — external accounts without expiry are the highest risk.

You've mapped the identity threat landscape and learned to read sign-in logs.

EI0 established that every cloud attack starts with identity. EI1 took you through the signal that matters most — interactive, non-interactive, service principal, and managed identity sign-ins. Now you engineer the defences.

17 engineering modules — authentication methods, conditional access architecture, Identity Protection, PIM, token protection, application governance, and detection rules
The Defense Design Method — the six-step framework applied to every identity control you'll build
EI18 Capstone — Identity Security Architecture Design — design complete identity architectures for three realistic organisations (SMB, mid-market, regulated enterprise)
Identity Security Toolkit lab pack — deployable conditional access policies, PIM configurations, and Identity Protection risk rules
Cross-domain detection (EI16) — email-to-identity correlation and the full phishing-to-inbox-rule attack chain

Unlock the full course with Premium See Full Syllabus

← Previous Next →