Power Automate + cuenta de servicio + MFA obligatorio

Question

Hola a todos.

Quisiera poner en debate una situación que estamos empezando a tener en nuestra organización con Power Automate.

Actualmente tenemos varios flujos productivos que utilizan una cuenta de servicio basada en usuario como conexión para distintos conectores de Microsoft 365, principalmente:

• SharePoint
• Excel Online
• OneDrive
• Forms

El problema es que esta cuenta comenzó a verse afectada por la exigencia de MFA, aparentemente por políticas de seguridad del tenant o por lineamientos de Microsoft/Entra, y esto nos genera preocupación porque puede impactar en la ejecución de los flujos y en la validez de las conexiones existentes.

Sabemos que, en el corto plazo, una opción sería:

• excluir la cuenta de MFA mediante Conditional Access,
• desactivar per-user MFA si estuviera habilitado,
• reparar o recrear las conexiones afectadas.

Sin embargo, nuestra duda principal apunta al mediano y largo plazo:

Preguntas

1. ¿Usar una cuenta de servicio sin MFA mediante exclusión en Conditional Access es una solución válida y sostenible para flujos de Power Automate?
2. ¿Existe riesgo de que Microsoft vuelva a imponer MFA sobre este tipo de cuenta en el futuro, aunque hoy se la excluya?
3. Para conectores como SharePoint, Excel, OneDrive y Forms, ¿cuál consideran que es la estrategia más correcta
4. ¿Alguien pasó por una situación similar y pudo estabilizar los flujos de manera definitiva?

La intención es definir una medida que no solo resuelva el problema actual, sino que también reduzca al máximo el riesgo de que los flujos vuelvan a fallar por temas de MFA o autenticación en las conexiones.

Cualquier experiencia, recomendación o arquitectura sugerida será de mucha ayuda.

Gracias.

Hola a todos.

Quisiera poner en debate una situación que estamos empezando a tener en nuestra organización con Power Automate.

Actualmente tenemos varios flujos productivos que utilizan una cuenta de servicio basada en usuario como conexión para distintos conectores de Microsoft 365, principalmente:

• SharePoint
• Excel Online
• OneDrive
• Forms

El problema es que esta cuenta comenzó a verse afectada por la exigencia de MFA, aparentemente por políticas de seguridad del tenant o por lineamientos de Microsoft/Entra, y esto nos genera preocupación porque puede impactar en la ejecución de los flujos y en la validez de las conexiones existentes.

Sabemos que, en el corto plazo, una opción sería:

• excluir la cuenta de MFA mediante Conditional Access,
• desactivar per-user MFA si estuviera habilitado,
• reparar o recrear las conexiones afectadas.

Sin embargo, nuestra duda principal apunta al mediano y largo plazo:

Preguntas

1. ¿Usar una cuenta de servicio sin MFA mediante exclusión en Conditional Access es una solución válida y sostenible para flujos de Power Automate?
2. ¿Existe riesgo de que Microsoft vuelva a imponer MFA sobre este tipo de cuenta en el futuro, aunque hoy se la excluya?
3. Para conectores como SharePoint, Excel, OneDrive y Forms, ¿cuál consideran que es la estrategia más correcta
4. ¿Alguien pasó por una situación similar y pudo estabilizar los flujos de manera definitiva?

La intención es definir una medida que no solo resuelva el problema actual, sino que también reduzca al máximo el riesgo de que los flujos vuelvan a fallar por temas de MFA o autenticación en las conexiones.

Cualquier experiencia, recomendación o arquitectura sugerida será de mucha ayuda.

Gracias.

Answer 1

1. Excluir una cuenta de servicio basada en usuario de MFA mediante Conditional Access no es una estrategia recomendada ni sostenible para automatización.

La documentación indica que, cuando se exige MFA a identidades de usuario, estas dejan de ser válidas para escenarios de automatización porque requieren autenticación interactiva. Para automatización se deben usar métodos diseñados para ello, como identidades administradas o aplicaciones (service principals), que permiten autenticación no interactiva y no se ven afectadas por la obligatoriedad de MFA.

“MFA requirements prevent you from using Microsoft Entra user identities for authentication in automation scenarios. Organizations must switch to authentication methods designed for automation, such as managed identities or service principals, which support non-interactive automation use cases.”

Además, se indica explícitamente que cualquier escenario de automatización que use identidades de usuario debe actualizarse.

2. Sí existe riesgo de que Microsoft imponga MFA a esa cuenta de usuario en el futuro, aunque hoy esté excluida.

La obligatoriedad de MFA se está ampliando para portales de administración y operaciones críticas. Cuando se usan identidades de usuario como cuentas de servicio, se indica que:

• Todas las cuentas de usuario que inicien sesión en las aplicaciones afectadas deberán completar MFA cuando comience la aplicación obligatoria.
• Las identidades de carga de trabajo (managed identities, service principals) no se ven afectadas por esta obligatoriedad.
• Las identidades de usuario usadas como cuentas de servicio deben migrarse a identidades de carga de trabajo.

“Workload identities, such as managed identities and service principals, aren't impacted… If user identities are used to sign in as a service account to run automation…, those user identities need to sign in with MFA once enforcement begins. User identities aren't recommended for automation. You should migrate those user identities to workload identities.”

Por tanto, basar la estrategia en “excluir de MFA” a una cuenta de usuario es frágil: la dirección de la plataforma es exigir MFA a usuarios y desplazar la automatización hacia identidades de carga de trabajo.

3. Estrategia correcta para conectores como SharePoint, Excel, OneDrive y Forms en flujos de Power Automate.

En el plano de autenticación y seguridad, la estrategia alineada con las recomendaciones es:

• Dejar de usar cuentas de servicio basadas en usuario para automatización.
• Migrar a identidades de carga de trabajo (workload identities) para los escenarios donde sea posible, y aplicar Conditional Access sobre esas identidades si se requiere.

En el contexto general de MFA y automatización, la guía es:

• Descubrir cuentas de usuario que se usan como cuentas de servicio y migrarlas a workload identities.
• Reemplazar flujos que dependan de credenciales de usuario (incluido ROPC u otros métodos incompatibles con MFA) por autenticación basada en managed identity o service principal.

“We recommend that customers discover user accounts that are used as service accounts and begin to migrate them to workload identities. Migration often requires updating scripts and automation processes to use workload identities.”

Aunque el contexto proporcionado se centra en Azure CLI/PowerShell y portales de administración, el principio es el mismo para automatización con Power Automate: evitar identidades de usuario para procesos desatendidos y usar identidades de carga de trabajo que no se vean interrumpidas por MFA.

4. Estabilización de flujos frente a MFA y autenticación.

Los problemas típicos cuando se introduce MFA o Conditional Access en servicios Microsoft 365 incluyen:

• Fallos en ejecuciones futuras de flujos cuando se habilita una directiva después de crear conexiones, con errores como AADSTS50076 y necesidad de reparar o recrear conexiones bajo las nuevas condiciones de acceso.
• Fallos en la creación automática de conexiones si el usuario (o cuenta de servicio) no cumple las condiciones de la directiva (MFA, red corporativa, dispositivo administrado, etc.).

“If you enable a conditional access policy after flows and connections are created, flows fail on future runs… To resolve this issue, users must sign in to the Power Automate portal under conditions that match the access policy… and then repair or re-create the connection.”

“If users don't sign in to Power Automate by using criteria that match the policies, the automatic connection creation… fail. Users must manually create and authenticate the connections by using criteria that match the conditional access policy…”

Para estabilizar de forma definitiva:

• Evitar depender de identidades de usuario sujetas a MFA para conexiones críticas de producción.
• Donde se sigan usando usuarios, asegurarse de que las conexiones se crean y reparan siempre cumpliendo las políticas de acceso (MFA, red, dispositivo). Aun así, esto seguirá siendo frágil a cambios futuros de seguridad.
• Migrar progresivamente a identidades de carga de trabajo para automatización, que no se ven afectadas por la obligatoriedad de MFA y pueden protegerse con Conditional Access específico para workload identities.

En resumen:

• No se recomienda como solución sostenible excluir de MFA una cuenta de servicio basada en usuario.
• Sí hay riesgo de que esa cuenta quede obligada a usar MFA en el futuro.
• La estrategia correcta a medio y largo plazo es dejar de usar identidades de usuario para automatización y migrar a workload identities (managed identities o service principals), ajustando las conexiones y flujos para que no dependan de autenticación interactiva.

---

References:

• The impact of multifactor authentication on Azure PowerShell in automation scenarios
• The impact of multifactor authentication on Azure CLI in automation scenarios
• Mandatory multifactor authentication for Azure and admin portals
• Recommendations for conditional access and multifactor authentication in Microsoft Power Automate (Flow)