Sooner or later, every Power Platform admin gets the same request from their security team: “That Power Automate service account can sign in from anywhere – can we lock it down to our office network?” It sounds straightforward. But the first time you switch on a Conditional Access policy for that account, all of its connections break and your flows grind to a halt.

I ran into exactly this, and it turns out there’s a bit more to it than ticking a box. In this blog post I’ll explain why Conditional Access breaks Power Automate flows, and how to set it up properly so the service account is restricted to your network while your flows keep running quietly in the background.

Why a service account needs special treatment

A lot of Power Automate flows run under a dedicated service account. The flow’s connections (SharePoint, Outlook, Teams, and so on) are based on a user sign-in (OAuth): you authenticate the connection once, and from then on Power Automate refreshes the token silently in the background – no interactive login required.

The obvious question is: why not use a service principal or a managed identity instead? In many cases you simply can’t. Several of the most common connectors – including SharePoint and Outlook – don’t support managed identity yet. So a plain (user-based) service account is often the only option, which means it’s also subject to Conditional Access just like a human user.

Why Conditional Access breaks your flows

To understand the problem, you need to know where and when authentication actually happens:

1. The first connection (interactive). When you create or repair a connection, it happens from your client machine – an interactive sign-in where location and MFA requirements apply as expected.
2. The token refresh (automatic). When the connection’s token expires, Power Automate refreshes it automatically – but from a Microsoft datacenter where the flow runs, not from your office network.

Two technical principles follow from this, and together they explain the broken connections:

• Conditional Access is evaluated at every token issuance and refresh (roughly hourly, or near-instantly via Continuous Access Evaluation). The source IP of that refresh is a Microsoft datacenter – never your network.
• A connection authenticates against its own resource app, not against Power Automate. A SharePoint connection requests a token for Office 365 SharePoint Online, an Outlook connection for Office 365 Exchange Online, and so on. Conditional Access is therefore evaluated on the resource and the user – not on “the flow runtime”. That’s exactly why you can’t whitelist Power Automate by IP address or endpoint.

So if you create a location-based policy that covers the resources your flows use, the background token refresh – coming from a Microsoft IP – gets blocked, and the connection breaks.

What doesn’t work

Before the approach that does work, two tempting routes that don’t:

• Whitelisting Microsoft datacenter IPs. The Power Platform outbound IP ranges are large and change constantly, so keeping them current in a named location is unworkable. And because the policy is evaluated on the resource rather than the runtime IP, allowing those ranges still isn’t reliable.
• The SharePoint “network location” feature. Only Teams, Viva Engage, and Exchange support it; turn it on and every other app – including Power Automate – is blocked, even from inside your trusted boundary. Microsoft itself recommends using Entra Conditional Access for this instead.

The approach that works: block by location, exclude the flow runtime

The trick is to restrict interactive access to your network while letting the flow runtime resources keep working from anywhere. You do that with a single Conditional Access policy plus a carefully chosen exclusion list.

First, create a named location for your trusted public IP range(s) – both IPv4 and IPv6 – and mark it as trusted. Then create one policy, scoped to the service account:

The result: interactive sign-in (the maker portal, Office apps) and every non-excluded resource only work from your network, while the flow-runtime resources keep working from anywhere – so your flows don’t break.

Don’t forget MFA, sessions and password expiration

A few account-level settings make the difference between a stable service account and one that breaks every couple of weeks:

• MFA can stay on for the interactive sign-in – it’s actually a good idea. The connection is set up once, interactively and MFA-compliant, from your network; after that the token refreshes silently without a new prompt.
• Turn off “Remember multifactor authentication on trusted devices.” It shortens the token lifetime and forces connections to refresh far more often, which is a common cause of them breaking.
• Don’t apply sign-in frequency, “require re-authentication”, or token protection to the account. They force an interactive re-auth that a silent refresh can’t satisfy (token protection also binds the token to a device – and the flow runtime has none).
• Leave the resilience defaults on so flows can keep running on existing tokens during a brief Entra outage.
• Switch off password expiration for the service account. This one is easy to overlook: it isn’t a Conditional Access setting, but a password policy on the account itself. A password change breaks all connections at once – exactly the kind of surprise outage you’re trying to avoid. The account’s security should come from the location restriction and good secret management, not from a periodically expiring password.

Test it properly

Roll this out carefully:

• Create the policy in report-only mode first and use the What-If tool.
• Test in both directions: from inside your network (sign-in allowed) and from outside – a mobile hotspot is the quickest way (sign-in blocked, with AADSTS53003).
• Named location gotcha: use the IPv6 /64 prefix, not a single /128 host. Client IPv6 addresses rotate, so a single host address will match today and silently fail tomorrow. Cover IPv4 and IPv6 both, because a dual-stack connection can switch between them.
• If a token grant is blocked even from a trusted location, check the difference between the IP seen by Entra and the IP seen by the resource in the sign-in logs – they aren’t always the same, and the resource-seen IP is the one that counts for that evaluation.

The trade-off you have to accept

Here’s the honest limitation: you cannot fully restrict the flow runtime to your network, because flows run from Microsoft’s cloud. The location policy protects the interactive use of the account; the flow APIs themselves remain reachable from Microsoft infrastructure with a valid token. That’s an inherent trade-off, and it’s worth making explicit to your security stakeholders. Mitigate it the sensible way: least-privilege permissions per connector, solid secret management, and monitoring of the sign-in logs.

Wrapping up

It feels counter-intuitive at first, but the working pattern is simple once it clicks: one block-by-location policy, the right resource exclusions, and a few sensible MFA, session and password settings. That gives you a service account a person can only sign in with from your network, while your unattended flows keep humming along from the cloud.

Hopefully this saves you the broken-connections headache I ran into. Happy automating!