Flows failing device compliance check due to them “pretending” to be running from a device they aren’t actually running from

[pb999]

When a Power Automate flow or Power BI dataset is created via an interactive session, the connections are associated with the user who creates them. It's been identified that the client device ID from where the connection is being created is also captured, but this is not visible within the connection record to either the connection owners or administrators. Subsequently, when an automated action is triggered from a flow or Power BI dataset refresh, a non-interactive sign-in is generated under the context of the "owner" of the connection and this is expected behaviour. However, it is also deemed to be running from the client device of the person who created the connection and is subject to a device compliance check if your organisation has implemented such a conditional access policy. Clearly, the automated process isn't actually being run from the client device (its running from "the cloud"). That device could be turned off and the automation would still run successfully as long as the device is marked as compliant within Azure. Aside from being a security concern, this "device spoofing" causes Power Automate flows and Power BI report refreshes to fail when organisations decommission and refresh client devices as the old devices become non-compliant. This will eventually cause EVERY flow and Power BI report within an organisation to fail (unless the organisation never upgrades their client devices)

There are 2 bugs/design faults here:-

1. Microsoft 365 automated processes, e.g. Power Automate flows and Power BI dataset refreshes SHOULD NOT be “pretending” to run from a device they are not running from. These are non-interactive sessions which ARE NOT running from a users’ physical device so SHOULD NOT be passing through that device ID in the sign-in request
2. A conditional access policy which has “Require device to be marked as compliant” should only be checking for device compliance for sign-ins which have come from a user interactive session were the activity has been initiated from a users’ physical device. You can’t expect customers to have to work out what apps are interactive, and which aren’t and decide which to include in or exclude from the device compliance check. Microsoft are adding apps all the time, so this is unmanageable. There should be some intelligent logic built into the service to understand what sign-ins have come from a user’s real device and which have come from a Microsoft server/IP address

This has already been suggested below but my idea includes some additional level of detail:-

Please do not connections to be invalid when unreg... - Power Platform Community (microsoft.com)

Flow Connection not able to self authenticaticate - Power Platform Community (microsoft.com)