MFA exceptions

Question

I have a few questions regarding MFA enforcement applicability for a user-based technical account.

The account is currently being transitioned to a connection-only model:

• no interactive usage 
• no development or deployment 
• used only for Power Platform connections and as flow owner 

Could you please clarify:

1. Is there any officially approved exception for user-based service accounts used strictly for connections (non-interactive usage only)?
2. If exceptions are possible:    

• what are the required conditions (e.g. no interactive sign-in, restricted permissions, service-only usage)?    
• who approves such exceptions?

 

3. If exceptions are NOT allowed:    

• is MFA mandatory even if the account is not used interactively at all?    
• what is the recommended target pattern for Power Platform connections (service principal / managed identity)?

Answer 1

Hey Michał, thanks for the details. Here’s what we know based on the current managed-policy landscape and partner-center guidance:

1. Official MFA exceptions for non-interactive “user” service accounts • Microsoft-managed Conditional Access policies (e.g. “Multifactor authentication for Microsoft partners and vendors”) are ENABLED by default on partner-associated tenants and can’t be edited or removed. Exceptions aren’t encouraged and generally aren’t granted. • Partner Center does let you request a “technical exception” for partner-related MFA prompts, but that exception does NOT apply when you’re using DAP/GDAP.
2. If you do pursue an exception • Conditions you’ll need to document when you submit: – The account is strictly non-interactive (no RDP/CLI/portal logins) – It only holds the minimal permissions needed for Power Platform connections – There’s no feasible workaround (e.g. migrating to a service principal or managed identity) • Who approves it: – For Partner Center exceptions, you submit via the Partner Center portal; Microsoft typically responds within 3 business days. – For Azure CLI/PowerShell Phase-2 MFA enforcement (Oct 2025), Global Admins with elevated access can temporarily postpone your tenant’s enforcement start date via the Azure portal “MfaSettings.ReactView.”
3. If no exception can be granted • Yes—MFA becomes mandatory even for non-interactive scenarios once Phase-2 enforcement kicks in. Read operations remain MFA-free, but any write/modifying action (CLI/PowerShell/API) will require MFA. • Recommended long-term pattern for Power Platform: – Service principals (App registrations) with certificate credentials or client secrets – System- or user-assigned managed identities on your resources Both support non-interactive auth flows without periodic MFA prompts and are Microsoft’s best practice for service-to-service connections.

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.

Answer 2

1. Exceptions for user-based service accounts used only for connections

There is no product-based exception in the MFA enforcement itself for user identities that perform Azure resource management or admin operations. Mandatory MFA enforcement explicitly states:

• Phase 2 MFA enforcement applies to all user accounts that make Azure resource management actions through any Azure client targeting https://management.azure.com.
• System enforcement applies to all user accounts, including break-glass, student, and administrator accounts, regardless of any user exclusions configured in Conditional Access.
• Workload identities (managed identities and service principals) are not impacted by this MFA enforcement.

User identities used as “service accounts” for automation are specifically called out as not recommended and are expected to comply with MFA once enforcement begins. Organizations are instructed to migrate such automation to workload identities instead.

Therefore, for a user-based technical account, even if intended for non-interactive/connection-only use, there is no built-in exception in the mandatory MFA enforcement model. Any relaxation can only come from how Conditional Access is configured in the tenant, not from the enforcement itself.

2. Conditions and approval if tenant-level exceptions are configured

Where Conditional Access policies are used (for example, for Terms of Use or additional MFA requirements beyond the mandatory enforcement), guidance is:

• Service accounts and service principals should be excluded from user-scoped Conditional Access policies, especially those with Terms of Use grant controls, because:
  • Service accounts are noninteractive and typically used programmatically.
  • Silent token refresh and background execution cannot satisfy interactive prompts such as Terms of Use.
• If Terms of Use must apply to users, target All cloud apps so that a single interactive sign-in (for example, Outlook or Teams) satisfies the requirement for Power Automate as well.
• Avoid short consent expiry or per-device Terms of Use for accounts used by flows, as this breaks connections.

In practice, this means:

• A tenant admin can configure Conditional Access to exclude a specific user-based technical account from certain policies (for example, Terms of Use or additional MFA prompts) to keep Power Automate connections working.
• However, this does not override the platform-wide mandatory MFA enforcement for user identities where it applies (for example, Azure resource management and Microsoft 365 admin portals).
• Approval for such exclusions is a tenant governance decision (typically security/identity administrators) rather than something granted by Microsoft as an exception to the enforcement.

3. If exceptions are not allowed / recommended pattern

3.1 MFA requirement for non-interactive user accounts

• Mandatory MFA enforcement states that every Azure tenant will require MFA, with no exception for test environments.
• All user accounts that sign in to the Microsoft 365 admin center URLs must complete MFA once enforcement starts.
• For Azure resource management, all user accounts making management calls to https://management.azure.com must complete MFA.
• User identities used for automation are explicitly called out as incompatible with MFA in non-interactive scenarios; scripts using such identities will fail with errors like “Interactive authentication is needed.”

So, for a user-based technical account:

• MFA is effectively mandatory wherever the enforcement applies, even if the account is not intended for interactive use.
• Relying on a user identity for non-interactive automation (including Power Platform connections) is not a recommended pattern because MFA and other interactive controls (Terms of Use) break silent token refresh and unattended execution.

3.2 Recommended target pattern for Power Platform connections

The recommended pattern is to move away from user-based technical accounts and adopt workload identities:

• Service principals (workload identities) are the recommended identity type for applications and automation. They:
  • Are not impacted by the mandatory MFA enforcement for user accounts.
  • Are designed for non-interactive, programmatic access.
• Managed identities are recommended where available (for Azure resources) and are also not subject to user MFA enforcement.
• For Power Automate specifically:
  • Service accounts (user identities) are not recommended as a best practice.
  • Where service accounts are used to remove dependency on the original flow owner, the guidance is to use a service principal instead to mitigate security risks.
  • Service accounts and dedicated flow connection owners should be excluded from Conditional Access policies that include Terms of Use grant controls, to avoid breaking connections.

Summary pattern for the described scenario:

• Do not rely on a user-based technical account as a long-term “connection-only” identity.
• Migrate Power Platform connections and flow ownership to a service principal (or managed identity where supported) as the target pattern.
• For any remaining user-based accounts used by flows, ensure Conditional Access does not impose Terms of Use or other interactive controls that break silent token refresh—but still expect MFA enforcement where platform-wide rules apply.

---

References:

• Mandatory multifactor authentication for Azure and admin portals
• The impact of multifactor authentication on Azure CLI in automation scenarios
• Require multifactor authentication strength for external users
• Power Automate licensing FAQ
• Recommendations for conditional access and multifactor authentication in Microsoft Power Automate (Flow)
• Troubleshoot broken connections in Microsoft Power Platform