Microsoft Fabric's AADSTS50076 Error

Introduction

After an extended holiday weekend, I returned to work to find almost all of my pipelines in Microsoft Fabric completely broken. My Fabric Monitor log was just a series of red circles from the weekend.

Why???

Everything had been working fine and then it just didn't. No changes were made in our company's network connections or security policies. Things just stopped working.

I dug into the logs and couldn't find any useful error until after I manually tried running a pipeline and received this error message.

BadRequest Error fetching pipeline default identity userToken, response content: {
  "code": "LSROBOTokenFailure",
  "message": "AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '00000009-0000-0000-c000-000000000000'. Trace ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Correlation ID: 2xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Timestamp: 2026-06-24 15:00:30Z The returned error contains a claims challenge. For additional info on how to handle claims related to multifactor authentication, Conditional Access, and incremental consent, see https://aka.ms/msal-conditional-access-claims. If you are using the On-Behalf-Of flow, see https://aka.ms/msal-conditional-access-claims-obo for details.",
  "target": "PipelineDefaultIdentity-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "details": null,
  "error": null
}. FetchUserTokenForPipelineAsync

It seems there can be multiple different reasons for this to happen, but usually there is at least a reason.

Checking the Known Issues page, there is currently an active issue ID 1783, "Data Pipeline run fails with LSROBOTokenFailure due to invalid user authentication token".

Description

Fabric Data Factory pipeline runs may fail with an LSROBOTokenFailure error when the user authentication (Entra ID) access token becomes invalid. This can happen under the following circumstances: - Password change: When the user who created the pipeline changes or resets their Entra ID (Azure AD) password, the stored refresh token becomes invalid and pipeline runs fail. - Device removed or non-compliant: The device used to authenticate and create the pipeline has been deleted, disabled, or marked non-compliant in the Entra ID tenant. - Conditional Access policy blocks token issuance: Conditional Access policies in the tenant prevent the access token from being issued (for example, requiring compliant devices or multifactor authentication). This behavior is by design. Fabric Data Factory pipelines use the pipeline creator's user authentication. When the pipeline is created, an Entra ID token is generated and stored for future pipeline runs so the user doesn't need to re-authenticate each time. However, Fabric does not currently support background synchronization when the underlying authentication state changes (password reset, device removal, etc.). The error message will contain LSROBOTokenFailure along with Entra ID error codes, for example: - AADSTS700082: The refresh token has expired due to inactivity. - AADSTS50173: "The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password." - AADSTS700003: "Device object was not found in the tenant directory." - AADSTS53003: "Access has been blocked by Conditional Access policies. The access policy does not allow token issuance."

Solution/Workaround

To resolve this issue, you need to manually trigger a token refresh by editing and saving the affected pipeline(s): 1. Open the pipeline in Fabric. 2. Make a minor edit (for example, add or update the pipeline description). 3. Save the pipeline. If you have multiple pipelines affected by this issue, you can use PowerShell script to perform a bulk update: https://github.com/microsoft/fabric-samples/tree/main/docs-samples/data-factory

Solution

Yes, you read that correctly. The solution is going into each pipeline and changing something in it and then save it. So for each pipeline I went in and changed the name on an activity, saved the pipeline, undid the name change, saved it again and then ran the pipeline to make sure it ran properly.

There was a point in time though where this wasn't working yet. I did try this a few times over the course of a couple of days until one finally worked. After that it was just a matter of going in and doing it to all the other pipelines.

Conclusion

Why did this happen? No idea. No one we could find had recently changed their password and the security team does not have record of any security policies changing. Either way, if you get hit with this unfortunate annoyance, open a pipeline, make a change, save it, and try to run it. Hopefully it fixes it.

Also, if you are using OAuth 2.0 for authentication, you should really be looking into using Service Principals or Workspace Identities wherever you can so that user password changes are not an issue. It also prevents connections breaking if a user leaves a company and their credentials are turned off.

I don't have a comments section yet, so feel free to send me feedback on this blog.