Acceso condicional y automatización: por qué los Flows se quedan bloqueados después del requisito de MFA

Por qué las políticas de Acceso Condicional bloquean los Flows de n8n y Power Automate y cómo excluir correctamente las cuentas de servicio.

Cuando entra en vigor una política de acceso condicional, no solo bloquea los inicios de sesión de los usuarios, también puede afectar las automatizaciones que se ejecutan en nombre de una cuenta de servicio o a través de un Principal de Servicio. Lo decisivo es si el inicio de sesión es interactivo o no interactivo: las políticas que se aplican específicamente a usuarios y grupos tienen efecto según Microsoft Learn no automáticamente en llamadas puras de Principal de Servicio, mientras que las políticas propias para identidades de carga de trabajo pueden capturar exactamente tales llamadas. Entonces, quien de repente ve un flujo de n8n, un Flow de Power Automate o un conector con errores de inicio de sesión, debe primero comprobar qué identidad está detrás y qué política la captura. Estado: agosto de 2026.

¿Qué diferencia a una política para usuarios de una para identidades de carga de trabajo?

Una política de acceso condicional clásica se dirige a usuarios y grupos y se evalúa en cada inicio de sesión interactivo. Para cuentas no interactivas como la cuenta de sincronización de Microsoft Entra Connect o los Principales de Servicio, esto no se aplica automáticamente: Según Microsoft Learn tales cuentas están típicamente destinadas al acceso programático de servicios backend y no son capturadas por políticas basadas en usuarios. Quien quiera asegurar los accesos automatizados necesita una política separada para identidades de carga de trabajo que incluya o excluya específicamente los Principales de Servicio individuales registrados en el propio tenant. Las aplicaciones multilocatario y las identidades administradas por Microsoft explícitamente no caen bajo estas políticas.

¿Qué papel juegan las políticas base administradas por Microsoft?

Microsoft implementa sus propias políticas preconfiguradas, como un requisito de MFA para cuentas de administrador, que aparecen en la lista de políticas del centro de administración de Entra con "Microsoft" como creador. Estas políticas base se pueden personalizar o complementar con exclusiones propias, pero no se pueden modificar arbitrariamente sin duplicarlas. Según Microsoft Learn la aplicación de estas excepciones base se activa automáticamente de manera gradual desde el 15 de junio de 2026, si no se ha cambiado nada en la configuración. Para las empresas con automatizaciones existentes, esto significa: un Flow que hasta ahora había pasado desapercibido puede verse afectado por primera vez por tal cambio automático, sin que nadie haya creado activamente una nueva política.

¿Cómo se excluyen correctamente las cuentas de servicio sin crear una brecha de seguridad?

Una exclusión general de todas las cuentas de automatización de cada política no es una solución limpia, porque socava el efecto protector real del acceso condicional. Es más sensato excluir o incluir específicamente la identidad de carga de trabajo individual del conector o Principal de Servicio afectado, en lugar de eximir grupos completos de manera general. Las cuentas de cristal roto o cuentas de emergencia deben, según Microsoft, estar excluidas de cada política en principio, para que en caso de emergencia sea posible un acceso administrativo, independientemente de lo que esté bloqueado en este momento. Además, para las reglas de inclusión y exclusión para la misma identidad se aplica: la exclusión siempre gana sobre la inclusión.

¿Qué hacer si un conector de automatización se bloquea de repente después de una actualización?

El primer paso es el registro de inicio de sesión en Entra ID para ver qué política específica negó el acceso y con qué identidad se conectó el conector. A menudo se descubre que una política base aplicada recientemente o una lista de exclusiones modificada recientemente es la causa, no un error en el flujo mismo. Para las automatizaciones de producción, vale la pena documentar desde el inicio las cuentas de servicio y los Principales de Servicio y proporcionarles su propia política estrecha, en lugar de dejar que se capturen implícitamente por reglas generales. Quien conecte flujos de n8n o Power Automate a servicios de Microsoft 365 debe incorporar esta verificación firmemente en la puesta en marcha de nuevas automatizaciones, para nosotros esto forma parte estándar de cada configuración de automatización.

Preguntas frecuentes sobre acceso condicional y automatización

¿Bloquea el acceso condicional automáticamente todas las llamadas de Principal de Servicio?

No, las políticas basadas en usuarios no se aplican a las llamadas puras de Principal de Servicio según Microsoft en principio. Solo una política específicamente diseñada para identidades de carga de trabajo puede capturar tales accesos no interactivos. Si un conector se ve afectado depende, por lo tanto, de si existe realmente una política de identidad de carga de trabajo en el tenant.

¿Qué es una identidad de carga de trabajo en este contexto?

Una identidad de carga de trabajo es la identidad de una aplicación o un servicio, generalmente en forma de un Principal de Servicio registrado en el propio tenant. Se diferencia de una identidad de usuario en que ninguna persona inicia sesión interactivamente, sino que un servicio en segundo plano solicita tokens de acceso. Las políticas de acceso condicional para identidades de carga de trabajo se pueden aplicar específicamente a cada una de estas identidades.

¿Debo excluir las cuentas de emergencia de cada política?

Sí, las cuentas Break-Glass deben, según Microsoft, excluirse consistentemente de todas las políticas de acceso condicional. Esto también se aplica a políticas base nuevas o administradas por Microsoft. Sin esta exclusión, se corre el riesgo de bloquearse a sí mismo en caso de emergencia.

¿Cuándo comienza la aplicación automática de las políticas base en 2026?

Según Microsoft Learn, la aplicación de las excepciones base afectadas se activa automáticamente de manera gradual durante varias semanas desde el 15 de junio de 2026. Las empresas que no han cambiado nada en la configuración estándar deben observar cuidadosamente sus automatizaciones y conectores durante este período. Quienes hayan realizado adaptaciones propias antes no se verán afectados por el cambio automático.

Sobre NordFlux

NordFlux UG (haftungsbeschränkt)

NordFlux crea empleados digitales para las organizaciones: automatizaciones y agentes KI que asumen el trabajo repetitivo. Usted mantiene el control.

Más sobre nosotros
Análisis inicial gratuito

¿Preguntas concretas sobre automatización o IA?

En un análisis inicial gratuito hablamos directamente de su caso. Sin compromiso.