Conditional Access and Automation: why flows stop working after MFA requirements

When a Conditional Access policy applies, it blocks not only user sign-ins, it can also affect automations running on behalf of a service account or via a Service Principal. What matters is whether the sign-in is interactive or non-interactive: policies that specifically target users and groups do not automatically apply to pure Service Principal calls according to Microsoft Learn while policies specific to workload identities can capture exactly such calls. So if you suddenly see an n8n workflow, a Power Automate flow, or a connector with sign-in errors, you should first check what identity is behind it and which policy affects it. Status: August 2026.

What distinguishes a policy for users from one for workload identities?

A classic Conditional Access policy targets users and groups and is evaluated with every interactive sign-in. For non-interactive accounts like the Microsoft Entra Connect Sync Account or Service Principals, that does not automatically apply: According to Microsoft Learn such accounts are typically designed for programmatic access by backend services and are not captured by user-focused policies. If you want to secure automated access, you need a separate policy for workload identities that specifically includes or excludes individual Service Principals registered in your own tenant. Multitenant apps and Microsoft-managed identities are explicitly not covered by these policies.

What role do Microsoft-managed baseline policies play?

Microsoft rolls out its own preconfigured policies, such as MFA requirements for admin accounts, which appear in the Entra Admin Center's policy list with "Microsoft" as the creator. These baseline policies can be customized or given custom exclusions, but cannot be arbitrarily rebuilt without duplicating them. According to Microsoft Learn enforcement of these baseline exceptions has been automatically activated in phases since June 15, 2026, if no changes were made to the settings. For organizations with existing automations, this means: a flow that previously flew under the radar can be affected for the first time through such an automatic switch without anyone actively creating a new policy.

How do you properly exclude service accounts without creating a security hole?

A blanket exclusion of all automation accounts from every policy is not a clean solution because it undermines the actual protective effect of Conditional Access. It is more sensible to specifically include or exclude the individual workload identity of the affected connector or Service Principal, rather than blanket-exclude entire groups. Break-glass or emergency accounts should, according to Microsoft, generally remain excluded from every policy so that in an emergency, administrative access remains possible, regardless of what is currently blocked. Also, for include and exclude rules on the same identity: exclusion always wins over inclusion.

What to do if an automation connector is suddenly blocked after an update?

The first step is to check sign-in logging in Entra ID to see which specific policy denied access and with what identity the connector signed in. Often this reveals that a newly enforced baseline policy or a recently changed exclusion list is the culprit, not an error in the workflow itself. For production automations, it pays to document service accounts and Service Principals from the start and give them their own tight policy, rather than implicitly capturing them with general rules. Anyone connecting n8n or Power Automate flows to Microsoft 365 services should make this check a standard part of bringing new automations online,it's a standard part of every automation setup for us.

Frequently asked questions about Conditional Access and automation

Does Conditional Access automatically block all Service Principal calls?

No, according to Microsoft, user-focused policies generally do not apply to pure Service Principal calls. Only a policy specifically designed for workload identities can capture such non-interactive access. Whether a connector is affected therefore depends on whether a Workload Identity policy exists in the tenant at all.

What is a workload identity in this context?

A workload identity is the identity of an application or service, usually in the form of a Service Principal registered in your own tenant. It differs from a user identity in that no person is interactively signed in; instead, a service in the background requests access tokens. Conditional Access policies for workload identities can be targeted to individual identities.

Do I need to exclude emergency accounts from every policy?

Yes, according to Microsoft, break-glass accounts should consistently be excluded from all Conditional Access policies. This also applies to new or Microsoft-managed baseline policies. Without this exclusion, you risk locking yourself out of administration in an emergency.

When does automatic enforcement of baseline policies begin in 2026?

According to Microsoft Learn, enforcement of the affected baseline exceptions has been automatically activated in phases over several weeks since June 15, 2026. Organizations that have not changed the default settings should closely monitor their automations and connectors during this period. Anyone who made their own customizations beforehand is not affected by the automatic switch.