Las políticas de acceso condicional que no escribiste ya están en tu tenant

Abre la lista de políticas de acceso condicional de tu tenant y mira la columna «Creada por». Si alguna fila dice Microsoft, esa política no la escribió nadie de tu empresa. Está en «solo informe», que suena inofensivo, y no lo es del todo: es una cuenta atrás. La va a encender Microsoft.

La mecánica está documentada y es literal: «The policy is automatically created in your tenant in a Report-only state» y «Microsoft enables these policies no less than 30 days after they're introduced in your tenant if they're left in the Report-only state». Avisan por correo y por el Centro de mensajes dos semanas antes. Y hay una nota que conviene leer entera: «In some cases, policies might be enabled faster than 30 days».

Ese número se ha movido, y en la dirección que menos le conviene a quien va justo. Cuando Microsoft arrancó con esto, en noviembre de 2023, la promesa era otra: «you'll have 90 days to review and customize (or disable) them before we turn them on». Hoy su documentación ya no promete una ventana, promete un suelo: «no menos de 30 días», más la nota de que puede ser antes. Conclusión práctica: no planifiques con el número, planifica con el mecanismo.

Las diez que hay hoy

Esta es la lista publicada por Microsoft en el momento de escribir esto. Cambia: han ido añadiendo.

Dos de esa lista —«exigir autenticación resistente a phishing a los administradores» y «bloquear la autenticación heredada»— pertenecen también al modo de seguridad de referencia del centro de administración de Microsoft 365, y ahí hay una diferencia que importa para saber a quién echarle la culpa: esas las crea el administrador, no Microsoft. Aparecen en la misma pantalla, pero con «Modo de seguridad de referencia» en la columna de creador y se gestionan desde otro sitio. Del modo de seguridad de referencia y de por qué su informe de impacto sale casi siempre a cero ya escribimos aquí.

Lo único que puedes tocar es la lista de exclusiones

Literal: «Organizations can't rename or delete any Microsoft-managed policies». Puedes excluir identidades, puedes pasarlas de «solo informe» a activada o desactivada, y puedes duplicarlas si necesitas más margen —con el aviso que la propia página incluye: «Be careful not to lower your security posture with those changes»—. Nada más.

De ahí sale la primera tarea, y es de hoy, no de dentro de un mes: tu cuenta de emergencia. Microsoft lo dice sin rodeos —«Exclude your break-glass or emergency access accounts from managed policies just like other Conditional Access policies»— y tiene toda la razón. Una cuenta rompe-cristales que no está excluida de todas las políticas, incluidas las que no escribiste, no es una cuenta rompe-cristales: es una cuenta más. La diferencia se descubre el día que no puedes entrar a arreglar por qué no puedes entrar. Cuando nos hacemos cargo de un tenant que ha llevado otro, esto es lo primero que miramos: antes que el Secure Score, antes que las políticas propias.

Las tres que rompen cosas

Ninguna de estas políticas es mala idea. Lo que tienen es efectos laterales concretos en sitios concretos, y los sitios no son los que la gente espera.

1. Bloquear el flujo de código de dispositivo

Microsoft resume el argumento en una frase difícil de rebatir: «Device code flow is rarely used by customers, but is frequently used by attackers». Es ese inicio de sesión en el que empiezas en un aparato y terminas en otro, y existe justo porque hay cacharros donde no puedes escribir una contraseña. Cacharros como una sala de reuniones con equipo de Teams. El día que esa política pasa a activada, lo que se cae no es «un usuario»: es la sala grande, un lunes a las nueve, con gente dentro. Microsoft publica una guía específica para acotar la excepción de los dispositivos de Teams sin desactivar la política entera, y esa es la forma correcta de hacerlo.

2. Bloquear la autenticación heredada

El dato que da Microsoft es demoledor: «more than 99 percent of password spray attacks use these legacy authentication protocols». Lo que ahí entra es, en sus palabras, «older clients like Office 2010, or clients that use protocols like IMAP, SMTP, or POP3», y de esa última mitad sale el inventario real de una pyme, que ya no lo dice Microsoft sino nosotros: el multifunción que escanea a correo, el ERP que manda facturas, el script que lee un buzón por IMAP para meter pedidos. Nada de eso tiene cara ni se queja en Teams: simplemente deja de funcionar, y lo normal es enterarse por el cliente que no ha recibido la factura.

3. MFA para todos los usuarios

Lo que rompe aquí no es la gente. La gente tiene Authenticator o lo instala en cinco minutos. Lo que rompe son las cuentas de servicio que alguien creó como si fueran personas: con licencia, con buzón, con contraseña en un fichero de configuración, y sin nadie detrás que pueda tocar un móvil. La propia documentación lo avisa para la política de riesgo —«All Users could include service accounts or break-glass accounts, so you might want to exclude them»— y el aviso vale igual para esta. Si no sabes cuántas tienes, ese es el inventario que hay que hacer esta semana, no la política.

El detalle que casi nadie ha leído: tus licencias dibujan el perímetro

La política de inicios de sesión de riesgo necesita Entra ID P2. Y aquí viene la parte interesante, que está escrita y nadie cita. La política se aplica a todos los usuarios solo si se cumplen dos condiciones a la vez: «If all your active users have MFA and your P2 licenses equal or exceed the total active users». Basta con que falle una —que algunos no tengan MFA o que no lleguen las licencias— para que Microsoft cree un grupo de seguridad llamado «Conditional Access: Risky sign-in multifactor authentication», lo limite a lo que tengas —«capped to your available P2 licenses»— y lo rellene él: «we select users who can satisfy MFA, prioritizing users with a directly assigned P2 license». Los invitados se quedan fuera en cualquier caso.

No es una trampa: es la consecuencia inevitable de que la protección se pague por usuario, y Microsoft lo explica sin esconderlo. Pero el resultado operativo sí merece un minuto: quién está cubierto frente a un inicio de sesión de riesgo en tu empresa lo deciden un recuento de licencias y un estado de registro de MFA, no tu análisis de riesgos. Si la dirección financiera no tiene una P2 asignada directamente, puede no estar en ese grupo. Es un grupo normal, lo puedes editar. Pero hay que mirarlo, no suponerlo.

Hay un segundo umbral en la misma línea. La política que recoge a los usuarios del MFA «por usuario» antiguo solo se dirige a organizaciones con menos de 500 usuarios en ese estado. Tiene lógica —nadie quiere mover a cinco mil personas por sorpresa— y aun así deja una ironía que conviene decir en voz alta: cuanto más grande es el lío heredado, menos ayuda automática recibes. Ahí el trabajo es tuyo, y consolidar ese MFA antiguo en acceso condicional sigue siendo una de las tareas con mejor relación esfuerzo/resultado de cualquier tenant.

Cómo saber qué te ha tocado, sin suponer

Cuatro sitios, de menos a más útil:

Si estás en valores predeterminados de seguridad, varias de estas no te llegan

Varias de estas políticas se dirigen expresamente a organizaciones «where security defaults aren't enabled», y los requisitos que lista esa misma página para el acceso condicional son Entra ID P2 o Microsoft 365 Business Premium. O sea que hay dos mundos: el que tiene valores predeterminados de seguridad —todo o nada, sin excepciones finas— y el que tiene acceso condicional. Para quien viene del primero, Microsoft ofrece otro juego de cuatro políticas de arranque: bloquear autenticación heredada, MFA para administradores, MFA para todos y MFA para la gestión de Azure. No es mal sitio por donde empezar, y no hace falta inventarse nada.

Y aun así, esto está bien

Convendría no leer este post como una queja. Microsoft está encendiendo por defecto cosas que llevamos años recomendando de una en una, cliente por cliente, y perdiendo la discusión más veces de las que nos gustaría. Su argumento, por cierto, está en la primera línea de la misma página: el MFA «continues to reduce the risk of compromise by more than 99%». Que el MFA para administradores llegue solo es una buena noticia, y a nosotros nos quita una conversación incómoda de encima.

La parte que sí hay que decir es otra, y es la de siempre en este oficio: una política que no diseñaste y no puedes borrar sigue siendo tuya el día que dispara. El que se queda fuera llama a tu teléfono, no al de Redmond. Y la única palanca que te han dejado —la lista de exclusiones— hay que haberla usado antes. Eso no es una crítica; es una tarea con fecha.

Lo que no afirmamos

Cuándo esto no va contigo

Si sois doce personas, todo el mundo tiene Authenticator, no hay multifunción que mande correo, no hay ERP de hace quince años y no hay salas de reuniones con equipo de Teams: entra, mira la lista, excluye tu cuenta de emergencia y vete a hacer otra cosa. Son veinte minutos, no un proyecto. Y lo decimos sabiendo lo que decimos: vendemos Microsoft 365 gestionado y consultoría; si después de mirar la lista no hay nada que excluir, nos alegramos y no hay factura.

Si en cambio tienes cuentas de servicio con licencia, dispositivos que inician sesión sin teclado o un MFA antiguo que nadie ha consolidado, entonces sí hay trabajo, y el trabajo no es «desactivar las políticas»: es dejar la lista de exclusiones bien puesta y quitar de en medio lo que sobrevive solo porque todavía nadie lo ha bloqueado. Es el mismo razonamiento que cuando miramos qué aplicaciones conectadas entran a tu Microsoft 365 sin pasar por el MFA: lo que decide tu exposición no es el control que activaste, es lo que se le escapa.

Fuentes (verificadas el 28 de septiembre de 2026): lista de políticas, estado inicial «solo informe», plazo de «no menos de 30 días», aviso dos semanas antes, imposibilidad de renombrar o borrar, exclusión de cuentas de emergencia, umbral de 500 usuarios de MFA por usuario, grupo limitado a las licencias P2, controles personalizados y consulta de auditoría — Microsoft Learn, «Microsoft-managed Conditional Access policies» (actualizada el 8 de agosto de 2026); anuncio original con el plazo de 90 días — Microsoft Security Blog, 6 de noviembre de 2023.