Users keep being asked to sign in again: Entra sign-in frequency and AADSTS70043

When users say Outlook, Teams or the browser keeps asking them to sign in, the cause is rarely a bug. Usually two or three reauthentication settings are stacked on top of each other, and the strictest one wins. In this post I'll show how to find the setting behind each prompt in the sign-in logs, how to consolidate your session settings into one clean design, and how to prove the prompts have stopped.

Symptoms#

• Browser users see the sign-in page every time they reopen the browser, or answer Stay signed in? again and again.
• Outlook, Teams or OneDrive on a managed Windows device asks for a password or MFA every few hours or days.
• On a phone, each Microsoft app prompts for MFA separately.
• The Microsoft Entra sign-in logs show interrupts or failures like these:

AADSTS70043: The refresh token has expired or is invalid due to sign-in frequency checks by Conditional Access.
AADSTS50140: This error occurred due to "Keep me signed in" interrupt when the user was signing-in.
AADSTS50078: Presented multifactor authentication has expired due to policies configured by your administrator.
AADSTS700082: The refresh token has expired due to inactivity.
AADSTS50133: The session isn't valid due to password expiration or recent password change.
AADSTS50173: The provided grant has expired due to it being revoked, a fresh auth token is needed.

Not all of these are problems: 50140 is just the Stay signed in? question, and 50133 or 50173 after a password change or revocation are expected.

Why it happens#

Out of the box, Microsoft Entra ID uses a rolling 90-day window for user sign-in frequency and doesn't ask for credentials again unless the session's security posture changes, for example a password change, a noncompliant device or a disabled account. Prompts beyond that come from settings someone added:

• Conditional Access sign-in frequency. A periodic value (hours or days) or Every time. It now covers MFA as well as the first factor, and a refresh token that outlives it fails with 70043.
• Remember multifactor authentication (1 to 365 days) in the legacy MFA service settings. Below 90 days it shortens the default prompt cycle for Office clients, and combined with sign-in frequency it can prompt unexpectedly.
• Show option to remain signed in in company branding. Without a persistent cookie, every browser restart means a new sign-in.
• Token lifetime policies. Refresh and session token lifetimes were retired on January 30, 2021 in favor of Conditional Access, but old access token lifetime policies may still be assigned to apps.

The most restrictive setting always wins: Remember MFA at 14 days plus Stay signed in means a prompt every 14 days. The device matters too. On a device with no identity in Entra ID, each app holds its own refresh token, so each one prompts. On Microsoft Entra joined and hybrid joined devices, unlock or sign-in refreshes the Primary Refresh Token (PRT) only every four hours, and sign-in frequency is compared against that refresh time; on Entra registered devices, unlocking doesn't satisfy sign-in frequency at all.

How to fix it#

1. Read the prompt in the sign-in logs#

In the Microsoft Entra admin center, go to Entra ID › Monitoring & health › Sign-in logs, filter on the user and check both the interactive and the non-interactive user sign-ins (refresh token failures such as 70043 are usually non-interactive). Open an event and check:

• Authentication Details › Session Lifetime Policies Applied: which session rule caused the reauthentication.
• Conditional Access: the policies that applied and their session controls.

If you stream sign-in logs to Log Analytics, measure how widespread it is:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType in ("70043", "50078", "50140", "700082")
| summarize Events = count(), Users = dcount(UserPrincipalName) by ResultType, AppDisplayName, ClientAppUsed
| order by Events desc

2. Inventory every reauthentication setting#

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyTokenLifetimePolicy | ForEach-Object {
    $_ | Select-Object Id, DisplayName, Definition
    Get-MgPolicyTokenLifetimePolicyApplyTo -TokenLifetimePolicyId $_.Id
}

In a federated tenant, also check the identity provider: with AD FS browser persistence configured, the Entra session follows it.

3. Consolidate on one mechanism#

With Microsoft Entra ID P1 or P2, Microsoft recommends using only Conditional Access sign-in frequency and persistent browser session, and turning off Remember multifactor authentication before you rely on sign-in frequency. Without P1 or P2, keep Show option to remain signed in enabled and teach users to accept it. A persistent browser session policy overrides the branding setting, so users don't have to answer the question.

4. Scope sign-in frequency instead of applying it to everyone#

• Use periodic reauthentication for unmanaged devices, risky sign-ins and admin portals, not for every user on every app.
• Reserve Every time for specific actions such as Intune enrollment, PIM activation or risky users, and pair it with MFA; without MFA it can cause sign-in loops. For Microsoft 365 apps, use time-based sign-in frequency instead.
• Set Persistent browser session to Never persistent for unmanaged devices, so cookies don't outlive the browser there.

5. Fix the device side#

If only some devices prompt, check single sign-on rather than policy. On Windows, dsregcmd /status must show AzureAdPrt : YES with a recent update time (see my PRT deep dive). On phones, install Microsoft Authenticator as the broker for other apps. In the browser, sign in to the Edge profile; private windows get no SSO.

6. Separate revocations from policy#

50133 and 50173 follow a password change or a revocation with Revoke-MgUserSignInSession, and one fresh sign-in clears them. If prompts follow network changes, check continuous access evaluation and your named locations: see continuous access evaluation and named locations.

Verify the fix#

1. Run the user's scenario through What If and confirm that only the intended policy applies its session controls.
2. After the user's next sign-in, Session Lifetime Policies Applied lists only the rule you designed.
3. Rerun the query a week later: 70043 and 50078 appear only where you intend to enforce a short session.
4. The user closes and reopens the browser and Outlook on a managed device without being prompted.

Prevent it next time#

• Keep session lifetime in one place, Conditional Access, and document every policy that uses session controls.
• Tighten sessions by risk and device state, not for everyone: frequent prompts teach users to type credentials into anything.
• Test changes in report-only mode first, and read the sign-in logs before and after.

References#

• Conditional Access adaptive session lifetime policies (Microsoft Learn)
• Reauthentication prompts and session lifetime for Microsoft Entra multifactor authentication (Microsoft Learn)
• Microsoft Entra authentication and authorization error codes (Microsoft Learn)