Azure DevOps Sign-in Failures: High Volume of Non-Interactive Sign-in Failures — Root Cause and Troubleshooting

Question

Problem description

I am experiencing a problem where a small number of users are generating a very high volume of non-interactive sign-in failures against Azure DevOps Services. These failures are occurring since April 3, 2026, and are associated with error code AADSTS70043, originating from the Azure DevOps web client using clientAssertion credentials, with Conditional Access policies showing success. I am seeking assistance to understand the root cause of these failures and how to resolve them permanently.

Environment

Azure DevOps Services backed by Microsoft Entra ID; Non-interactive sign-in flow from the Azure DevOps web client; Requests recorded as Rich Client; Credential type: clientAssertion; No specific team project, service tier, SKU, or region specified.

What I've already tried

I initially documented the case with failure code, request volume, start time, Conditional Access result, and client details. I reviewed available self-help material for Azure DevOps Conditional Access behavior, but it did not match the specific failure signature. No further troubleshooting steps or diagnostic insights were provided in the case record. I have not tried any other troubleshooting actions beyond the initial documentation.

Current status

The situation remains unresolved, with persistent high-volume sign-in failures in a subset of users. I am seeking guidance on the root cause, whether the retry behavior is by design or a defect, and recommendations for configuration or fixes to address this issue permanently.

Answer 1

Hi @Joel Varghese

The failure signature you're describing actually points to something quite ordinary, so let me walk through it.

1. AADSTS70043 means the refresh token the Azure DevOps web client is holding has exceeded its maximum lifetime or was invalidated by a sign-in frequency check. Conditional Access showing "success" just means the policies evaluated fine, the token itself is dead. Non-interactive entries are the client silently trying to renew that token, and every attempt fails until the user signs in interactively again in that browser.
2. Few users with huge volume almost always means a browser session left open somewhere: a dashboard on a wallboard or TV, a pinned tab on a second machine, or a browser profile the user never touches. The client retries on a loop, which is by design, but it can't fix itself.
3. To see what changed on April 3, check two places in Entra. First, Conditional Access policies created or modified that day with a sign-in frequency control. Second, the audit log for those users on that date: password changes, "revoke sessions" actions, or device compliance changes, all of which invalidate refresh tokens.
4. Find the exact session per user with this query in Log Analytics:

AADNonInteractiveUserSignInLogs
| where ResultType == "70043"
| summarize count() by UserPrincipalName, tostring(DeviceDetail), IPAddress, AppDisplayName

The device, browser and IP tell you where the stale session lives. Sign the user out there and sign back in, and that user's stream stops immediately. 5. If a short sign-in frequency policy covers Azure DevOps, that's the permanent fix. Azure DevOps supports Conditional Access for MFA and IP conditions, but short sign-in frequency on the web app just produces this expired-token churn. Exclude Azure DevOps from that policy or raise the interval, and for wallboard-type displays use a dedicated account. 6. Until then, treat 70043 as expected noise, not a security signal. Filter it in your alerting so real failures stay visible.

If this helped, please click Accept Answer so others chasing the same log noise can find it.

References: https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/change-application-access-policies

Answer 2

Hi @Joel Varghese ,

Thank you for reaching out to Microsoft Q & A !

Microsoft documents AADSTS70043 as a refresh token that has expired or become invalid because of Conditional Access sign-in-frequency checks. This explains the token rejection, but the high volume alone does not establish an Azure DevOps defect. The cause of the repeated requests affecting only some users remains unconfirmed. See the Microsoft Entra error-code reference.

The Conditional Access: Success status should also be read alongside the individual policy results and the overall sign-in status—not as confirmation that every token-refresh attempt succeeds. For details on interpreting individual sign-in events and their activity information, see Microsoft Entra sign-in log activity details.

Please start with these checks for one affected user:

Correlate the failed event with the actual policies. Have your Entra administrator review the event’s Conditional Access results, then open the applicable policies and inspect Session → Sign-in frequency. Compare the configured sign-in-frequency requirement with the token issue time and maximum allowed lifetime shown in the full AADSTS70043 error. This will help establish whether the rejection aligns with the configured policy.

Test a fresh Azure DevOps session. Save any work, sign out, close existing Azure DevOps tabs, and sign in through an InPrivate/incognito window if permitted. Confirm whether access succeeds and whether new 70043 events continue afterward. Record the test time and any recurrence in UTC. This is a diagnostic test, not a confirmed permanent fix; private-browser testing is included in Microsoft’s Azure DevOps troubleshooting guidance.

Could you confirm whether affected users experience an actual Azure DevOps access or session interruption, or whether these events are only visible in Entra sign-in logs? Please also share the redacted failure reason, applicable sign-in-frequency setting, and fresh-session test result.

Retain the Request ID, Correlation ID, and exact UTC timestamp for a representative failure, but do not post tokens or unredacted logs publicly.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.