Entra on Nicola Suter

Chasing Entra re-authentication prompts

Mon, 01 Jun 2026 15:37:02 +0000

While troubleshooting unexpected re-authentication prompts in Entra ID, I stumbled over a legacy setting I had almost forgotten existed. The environment was piloting a new set of Conditional Access policies, and some pilot users received daily re-authentication prompts in Microsoft 365 apps, although no Conditional Access policy was forcing this.

Entra ID Protection was the first suspect, but no risk detections were present for the affected users. The actual reason was hiding in plain sight in the Entra sign-in logs, in the SessionLifetimePolicies field.

Inspecting SessionLifetimePolicies
#

A quick KQL query against SigninLogs reveals every distinct expirationRequirement reason observed in the tenant:

Distinct expirationRequirement reasons surfaced from SigninLogs

SigninLogs
| mv-expand parse_json(SessionLifetimePolicies)
| extend ExpirationRequirement = tostring(SessionLifetimePolicies.expirationRequirement)
| extend ExpirationDetail = tostring(SessionLifetimePolicies.detail)
| distinct ExpirationRequirement, ExpirationDetail

The sessionLifetimePolicy resource is also documented as part of the Microsoft Graph API¹.

Legacy MFA settings
#

The rememberMultifactorAuthenticationOnTrustedDevices value stood out and reminded me of the Azure AD days and the legacy MFA settings. Sure enough, the Remember multi-factor authentication on trusted devices setting was still enabled:

Microsoft Authenticator App Details now exposed in Entra SignInLogs

Wed, 20 May 2026 12:00:01 +0000

In response to CVE-2026-41615¹ (Microsoft Authenticator Information Disclosure Vulnerability), Microsoft started exposing the used Microsoft Authenticator app details as part of the Entra ID Sign-In Logs in the AuthenticationAppDeviceDetails column. The information can be queried via KQL. Vulnerable builds include versions prior to 6.2605.2973 (Android) and 6.8.47 (iOS), which have been patched.

You can use the below KQL query to find users with outdated Microsoft Authenticator app versions, which are vulnerable:

// https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-41615
let MinimumVersions = datatable(
 AuthenticatorOperatingSystem: string,
 PatchedAuthenticatorVersion: string
)[
 "Android", "6.2605.2973",
 "Ios", "6.8.47"
];
SigninLogs
| where isnotempty(AuthenticationAppDeviceDetails)
| extend AuthenticationAppDetails = parse_json(AuthenticationAppDeviceDetails)
| extend AuthenticatorOperatingSystem = tostring(AuthenticationAppDetails.operatingSystem)
| extend UsedAuthenticatorVersion = tostring(AuthenticationAppDetails.appVersion)
// b2b and guest accounts include: {"deviceId":"{PII Removed}"} and no authenticator details
| where isnotempty(UsedAuthenticatorVersion)
| join kind=leftouter MinimumVersions on AuthenticatorOperatingSystem
| extend isVulnerable = parse_version(UsedAuthenticatorVersion) < parse_version(PatchedAuthenticatorVersion)
| where isVulnerable
| distinct UserPrincipalName, AuthenticatorOperatingSystem, UsedAuthenticatorVersion, isVulnerable

The AuthenticationAppDeviceDetails (JSON) column itself consists of the following properties:

appVersion
clientApp
deviceId
operatingSystem

The clientApp property is really helpful, as we now also have another option to identify users who use the Authenticator light capabilities, available as part of the Outlook app:

SigninLogs
| where isnotempty(AuthenticationAppDeviceDetails)
| extend AuthenticationAppDetails = parse_json(AuthenticationAppDeviceDetails)
| extend AuthenticationAppDetailsClientApp = tostring(AuthenticationAppDetails.clientApp)
| where AuthenticationAppDetailsClientApp == "Outlook"
| distinct UserPrincipalName, AuthenticationAppDetailsClientApp

This might be relevant in your environment if you did not disable the Microsoft-managed setting for using the Authenticator light option, which, for example, does not support Conditional Access authentication strengths, passkeys, and app protection policies:

Don't let Entra ID Protection miss your next breach!

Sun, 22 Mar 2026 10:00:03 +0000

All too often, my baseVISION (IR) colleagues and I find compromised cloud accounts where many security ‘signals’ were missed—both from a prevention and detection perspective. In this blog post, I want to share some motivation and tips to help you adopt Entra ID Protection risk-based Conditional Access policies to increase your tenant’s security posture, and ensure you don’t miss the next obvious account breach.

Real-world motivation
#

Anyone who has seen an AiTM campaign in the wild will probably notice the following details from the Entra ID sign-in logs of a compromised account:

ResourceDisplayName: OfficeHome
UserAgent: axios/1.13.2

The problem? Even though Entra ID Protection flagged the sign-in as ‘High’ risk, the user could still sign in because MFA automatically remediated the sign-in risk (userPassedMfaDrivenByRiskBasedPolicy).

The bummer?
#

The environment had a Conditional Access policy in place that would have blocked users with high sign-in risk, but the policy was only in report-only mode, so the user could sign in without any issues.

Entra on Nicola Suter

Chasing Entra re-authentication prompts

Inspecting SessionLifetimePolicies #

Legacy MFA settings #