AADSTS70044: Session expired by sign-in frequency checks (fix)

What does AADSTS70044 mean?

Microsoft’s error code reference doesn’t list AADSTS70044 (checked 30 October 2026).

The wording below comes from a Microsoft Q&A thread, not from a Microsoft documentation page. A Q&A moderator (AmanpreetSingh-MSFT) quoted it in an answer:

AADSTS70044: The session has expired or is invalid due to sign-in frequency checks by conditional access.

The person who asked quoted the sign-in log failure reason as “The session has expired or is invalid due to sign-in frequency checks by conditional access. MFA requirement satisfied by claim in the token.”

In that thread, a Conditional Access policy set sign-in frequency to one hour for a VPN app. The moderator said the backend trace showed the credential was authenticated on one day and presented the next, outside the one-hour window, so it was ignored. The same thread says old credentials are usually reused during silent authentication, through a refresh token or a Primary Refresh Token (PRT).

A second Q&A thread describes users with several browsers hitting “error code 70044” under a 30-day sign-in frequency policy. That thread gives no full message text.

Our reading: 70044 is the session-side sibling of 70043, which Microsoft does list. 70043 says the refresh token is too old for the sign-in frequency policy. 70044 says the session is. Both mean the same thing for the user: sign in again. Microsoft doesn’t document the difference.

Is it an attack?

Usually not. Users report it where a sign-in frequency policy exists, and it is the policy doing what it was configured to do.

Pattern	Likely meaning
70044 for many users shortly after a new or tightened sign-in frequency policy	The policy is now enforced. Expected.
70044 for one user, repeating every few minutes, never followed by a success	The app keeps retrying silently and never prompts. An app bug, not an attack. Our interpretation.
70044 for a user who works in several browsers	Each browser keeps its own cookies and session, so a new browser or cleared cookies starts a new sign-in. This is from a Q&A answer, not from Microsoft documentation.
70044 from an IP or device the user never uses	An old session presented from somewhere unexpected. Our reasoning, not a documented detection: the control stopped it, but check the user’s other sign-ins.

One user report adds a caution. In Q&A 852942, revoking the user’s sessions fixed the error only until the next day, and the person who asked later concluded the real cause was AD FS extranet lockout. That is their own conclusion, not a Microsoft answer, but it shows that 70044 can be the visible symptom of a different problem in federated tenants.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table 70044 is logged in. Check where it lands in your workspace first:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "70044"
| summarize Rows = count() by SourceTable

Which apps and session policies produce it. SessionLifetimePolicies is documented as “any conditional access session management policies that were applied during the sign-in event.” It is a string in both tables:

union
    (SigninLogs | project TimeGenerated, ResultType, UserPrincipalName, AppDisplayName, ClientAppUsed, SessionLifetimePolicies),
    (AADNonInteractiveUserSignInLogs | project TimeGenerated, ResultType, UserPrincipalName, AppDisplayName, ClientAppUsed, SessionLifetimePolicies)
| where TimeGenerated > ago(7d)
| where ResultType == "70044"
| summarize Rows = count(), Users = dcount(UserPrincipalName) by AppDisplayName, ClientAppUsed, SessionLifetimePolicies
| sort by Rows desc

Users stuck in a loop: many 70044 rows in a day and no success on the same app. The threshold of 20 is a starting point; tune it to your volume.

let window = 1d;
let fails =
    union
        (SigninLogs | project TimeGenerated, ResultType, UserPrincipalName, AppDisplayName),
        (AADNonInteractiveUserSignInLogs | project TimeGenerated, ResultType, UserPrincipalName, AppDisplayName)
    | where TimeGenerated > ago(window)
    | where ResultType == "70044"
    | summarize Fails = count(), LastFail = max(TimeGenerated) by UserPrincipalName, AppDisplayName
    | where Fails >= 20;
let successes =
    union
        (SigninLogs | project TimeGenerated, ResultType, UserPrincipalName, AppDisplayName),
        (AADNonInteractiveUserSignInLogs | project TimeGenerated, ResultType, UserPrincipalName, AppDisplayName)
    | where TimeGenerated > ago(window)
    | where ResultType == "0"
    | distinct UserPrincipalName, AppDisplayName;
fails
| join kind=leftanti successes on UserPrincipalName, AppDisplayName
| sort by Fails desc

How does Conditional Access affect it?

• The trigger users report is a Conditional Access sign-in frequency session control. Microsoft’s default without such a policy is “a rolling window of 90 days.”
• With Every time, Microsoft says the policy “requires full reauthentication when the session is evaluated” and “factors in five minutes of clock skew”. Microsoft also warns that every-time reauthentication without MFA “might result in sign-in looping for your users.”
• On Microsoft Entra joined and hybrid joined devices, Microsoft says unlocking the device or signing in interactively refreshes the PRT every four hours, and the PRT’s last refresh must fall inside the sign-in frequency window. On Microsoft Entra registered devices, unlocking doesn’t satisfy the policy.

How do I fix AADSTS70044?

For the user: sign in again when the app asks. If the app never shows a sign-in prompt and keeps failing, close it fully, open it again, and sign in. If that doesn’t help, tell IT the app name and the time.

For developers: treat 70044 like any interaction-required result. Don’t retry silently. The Q&A moderator’s advice: force an interactive sign-in with prompt=login for OAuth and OpenID Connect, or forceAuthN=true for SAML. In the thread, forceAuthN=true worked but made every user type their username again, so use it only on this error, not on every sign-in.

For admins:

1. Find the policy. Open the failed sign-in in the Microsoft Entra admin center and check the Conditional Access tab, or use the second query above.
2. If the interval is shorter than the app can handle, lengthen it or scope the policy to the apps and users that need it. Microsoft advises to “limit the number of applications that enforce a policy requiring users to reauthenticate every time.”
3. For a single user who keeps failing on a joined device, check that the device’s PRT refreshes. The Q&A moderator suggested comparing the event log Applications and Services Logs > Microsoft > Windows > AAD > Operational between a working and a failing user.
4. In a federated tenant, rule out AD FS problems such as extranet lockout before you change the policy. That cause comes from one user report.