AADSTS53000 in Microsoft Fabric Pipelines: Device Compliance Error Explained and Fixed
Complete Error Message (As Seen in Fabric)
The pipeline fails with the following complete error message, which is important to review before troubleshooting:
BadRequest Error fetching pipeline default identity userToken, response content: {
"code": "LSROBOTokenFailure",
"message": "AADSTS53000: Device is not in required device state: compliant. Conditional Access policy requires a compliant device, and the device is not compliant. The user must enroll their device with an approved MDM provider like Intune. Trace ID: 53469a28-4971-4d4b-9338-e0dc05751a00 Correlation ID: f6524808-3ab0-49ab-8d25-7371831ab57e Timestamp: 2026-04-30 07:24:38Z 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",
"details": null,
"error": null
}
Error Time Thu Apr 30 2026 14:40:50 GMT+0200 (Central European Summer Time)
Service version 13.0.28187.37
Client version 2604.2.28902-train
Cluster URI https://wabi-north-europe-g-primary-redirect.analysis.windows.net/
Stack Trace {"AdditionalParameters":null,"ErrorCategory":null,"ErrorCode":"AzureActiveDirectoryClientUserErrorException","ErrorMessage":"Job failed to start: unable to acquire user token","ErrorParameters":null,"ErrorSource":1,"IsTransient":false,"UserInteractionRequest":null}
At first glance, this error strongly suggests a user device compliance problem, which can be misleading in the context of Microsoft Fabric pipelines.
Introduction
While working with Microsoft Fabric pipelines in enterprise environments, you may encounter device compliance–related authentication failures like the one shown above.
Although the message references Intune enrollment and compliant devices, Fabric pipelines are non-interactive service workloads. This means the root cause is usually not related to a physical user device.
This post explains why the error occurs, why common fixes don’t work, and how redeploying via Deployment Pipelines resolved the issue.
The Error Scenario
BadRequest Error fetching pipeline default identity userToken
AADSTS53000: Device is not in required device state: compliant
Conditional Access policy requires a compliant device
- Occurs in Microsoft Fabric pipelines
- Conditional Access enforces device compliance
- Pipeline runs as a service workload, not a physical device
Why This Error Is Confusing
- Fabric pipelines do not have a device
- Fabric pipelines do not enroll in Intune
- They should not be subject to device-based Conditional Access
This leads many teams to try:
- Enrolling their laptop in Intune ❌
- Changing the user who clicks Run ❌
- Retrying the pipeline ❌
None of these work consistently.
Root Cause (What’s Really Happening)
The issue is usually caused by stale or incorrect identity metadata in the target environment (for example, Prod).
This can happen when a Fabric pipeline is:
- Manually recreated in Prod
- Copied instead of promoted
- Originally authored under a different user context
Additional Observation: Expired Password of the Submitting User
In our case, further investigation showed that the password of the user shown as “Submitted by” had expired.
Because the pipeline was originally created and deployed under this user context, Fabric attempted to acquire a token using that identity. When the password was expired, token acquisition failed and surfaced as a misleading AADSTS53000 device compliance error.
To validate this:
- The pipeline was redeployed from Dev to Prod under another user
- The pipeline was executed using a different user identity
✅ The pipeline ran successfully after this change.
This confirmed that the issue was related to expired user credentials and stale identity bindings, not an actual Intune or device-compliance problem.
The Fix: Redeploy via Deployment Pipelines ✅
✅ Redeploying the pipeline from Dev to Prod using Fabric Deployment Pipelines resolved the issue completely.
Why this works
- Rebinds the pipeline to the target workspace identity
- Resets execution and ownership metadata
- Removes stale or expired user associations
- Ensures the pipeline runs as a non-interactive service workload
No Conditional Access changes were required.
Best Practices Going Forward
- ✅ Always create pipelines in Dev
- ✅ Promote using Deployment Pipelines
- ✅ Avoid manually recreating pipelines in Prod
- ✅ Keep Workspace Identity enabled for production workloads
- ✅ Treat Fabric pipelines as service identities, not user actions
Key Takeaway
In Microsoft Fabric, AADSTS53000 device-compliance errors can be caused by expired user passwords or stale identity bindings. Redeploying via Deployment Pipelines resets the execution context and resolves the issue.
Closing Thoughts
This behavior is under-documented, but understanding it can save hours of investigation and unnecessary Conditional Access changes.
If you work with Fabric in secured enterprise tenants, Deployment Pipelines are not optional—they are essential.
``
No comments:
Post a Comment