Cayeron seis servicios de Microsoft 365 a la vez. Para tu plan de continuidad son uno solo

El incidente del lunes acabó llevándose por delante seis servicios que tú tienes anotados por separado: Exchange Online, SharePoint Online, OneDrive, Teams, Purview y Microsoft Defender XDR. Comparten una pieza de autenticación por debajo, y esa lista de seis nombres es lo más útil que ha salido de la noche del lunes. Te la han dado gratis y dice qué filas de tu plan de continuidad no son independientes entre sí. Una de ellas, la que menos gente va a mirar, es la consola con la que vigilas.

Las horas, incluidas las que no cuadran

Microsoft empezó a investigar «un aumento de reportes de usuarios sobre problemas de Exchange Online» a las 11:55 UTC del lunes 31 de agosto, las 13:55 hora peninsular. Cuando el problema dejó de ser solo de Exchange, el caso se siguió con otro identificador, MO1465074, al que Microsoft puso como hora oficial de inicio las 15:08 UTC.

Aquí hay que parar, porque las fuentes no cuadran y una cronología limpia sería más cómoda que honesta. BleepingComputer da las 17:30 UTC como el momento en que Microsoft reconoció el incidente EX1464935 sobre Exchange Online; Computerworld sitúa el primer mensaje de investigación cinco horas y media antes. Las dos cosas pueden ser ciertas —una es cuándo empieza a contar el reloj del proveedor, otra cuándo se enteró la mayoría de la gente— pero no son la misma hora, y elegir la que quede mejor para el relato sería hacer trampa. Si necesitas la hora exacta para un informe interno, cógela del centro de administración de tu inquilino y no de la prensa, incluida esta página.

Lo que sí es consistente es la secuencia de diagnósticos. Primero, que habían aislado «un patrón de fallo común en las peticiones afectadas de Exchange Online, asociado a la autenticación y a la conectividad de protocolo». Luego, más preciso: «problemas relacionados con una configuración de autenticación de núcleo usada por múltiples servicios internos dentro de la infraestructura de Exchange Online». Y la mitigación, a mano y servidor por servidor: «estamos haciendo una prueba manual a nivel de servidor individual para restablecer configuraciones y validar si esto resuelve el problema». Para entonces la lista ya incluía OneDrive para la Empresa, SharePoint Online, Teams, Purview y Defender XDR.

La vuelta del flujo de correo tiene el mismo problema de relojes: Computerworld la sitúa «a última hora del lunes» y el último mensaje de restauración que recoge BleepingComputer es de las 03:43 hora del este de EE. UU., ya el martes. Lo que no discute nadie es que la búsqueda seguía rota el martes.

Hay un detalle en esas horas que conviene retener por motivos prácticos: la hora oficial de inicio que Microsoft le puso al incidente ampliado, las 15:08, es anterior a la hora en la que la mayoría de las coberturas dicen que lo reconoció. El reloj que cuenta para el proveedor es el suyo, y el sitio donde está escrito es tu centro de administración. Si en algún momento vas a reclamar, a justificar un retraso ante un cliente o simplemente a explicarle a tu dirección qué pasó el lunes, exporta el historial del incidente mientras siga ahí. Es una captura de pantalla y cinco minutos, y es la única versión que luego nadie te discute.

Nadie ha confirmado que fuera un certificado caducado

El titular de esa noche fue que a Microsoft se le había olvidado renovar un certificado. La cadena real es esta: durante la caída, algunos usuarios se encontraron un mensaje de error de cliente que citaba una huella concreta —19F04B8A233DD9CE916F118056D224A1751729EA— y decía que estaba caducada; un blog alemán lo publicó esa misma noche, y de ahí salió todo lo demás. Microsoft no ha dicho eso en ningún momento. Ha dicho «configuración de autenticación». Puede acabar siendo lo mismo, o el certificado puede haber sido un síntoma.

No lo vamos a afirmar, porque no está afirmado. Y da bastante igual para lo que viene después: un certificado que vence y una configuración de autenticación mal aplicada pertenecen a la misma familia, la de la pieza compartida que decide si las demás pueden hablar entre ellas. Cuando salga el análisis definitivo cambiará el parte técnico, y no cambiará nada de lo que tú deberías mirar mañana.

Seis filas de tu plan, una sola pieza

Abre tu plan de continuidad, si lo tienes escrito. Es muy probable que el correo, la intranet documental, la mensajería y la consola de seguridad ocupen filas distintas, cada una con su criticidad y su tiempo de recuperación. Están así porque para quien trabaja son cuatro cosas distintas: cuatro logins y cuatro maneras de trabajar. Por debajo eran una sola, y el lunes se vio.

Eso tiene una consecuencia aritmética. Multiplicar disponibilidades para concluir que «es imposible que caigan las dos a la vez» solo funciona si las dos son independientes. Un compromiso de servicio se firma por servicio y no dice nada sobre la correlación entre ellos. El lunes el fallo estaba por debajo del nivel al que se escriben esos compromisos, así que ninguno de los seis te protegía de los otros cinco.

Conste que consolidar la autenticación no es un error de diseño de Microsoft. Es lo que recomendamos casi siempre: menos superficie, un solo sitio donde aplicar política, una sola cosa que auditar. Quien te diga que él lo tiene todo separado probablemente tenga el problema repartido en vez de resuelto. El precio de esa decisión es exactamente lo que se vio el lunes, y se paga entero de golpe.

Antes de que alguien saque la conclusión fácil: esto tampoco es un argumento contra el cloud. La versión local del mismo fallo existe y es peor. Un certificado de la federación de identidad que vence un domingo por la noche deja fuera al correo, a la intranet, a las aplicaciones internas y —lo divertido— al panel desde el que ibas a arreglarlo, porque también autentica contra lo mismo. La diferencia no está en la arquitectura, que es idéntica; está en que allí no hay página de estado, no hay a quién llamar y el reloj lo cuentas tú a las tres de la mañana. Lo que cambia al subir a un proveedor grande es quién paga la guardia, no si existe la pieza compartida.

El panel al que acudes cuando algo va mal estaba dentro de lo que iba mal

Vuelve a la lista de seis. Cuatro de esos nombres son herramientas de trabajo y se echan de menos enseguida. Los otros dos, Microsoft Defender XDR y Microsoft Purview, no los usa nadie para escribir un correo: son la consola de seguridad y la capa de cumplimiento y auditoría. Estuvieron degradados durante la misma ventana en la que decenas de miles de clientes reintentaban autenticarse en bucle.

Conviene ser exacto con lo poco que se sabe. «Degradado» no es «apagado», y Microsoft no detalló qué parte de cada producto lo estaba: puede ser la consola, puede ser una integración, puede ser solo la búsqueda dentro del portal. Los sensores que recogen telemetría en los equipos no dependen de que tú puedas abrir el panel, así que lo razonable es asumir que se siguió recogiendo. Lo que se para cuando el panel va a trompicones es la parte humana: mirar la cola de incidentes, lanzar una consulta y decidir.

Que quede claro lo que no estamos diciendo: no hay ni un indicio público de que nadie aprovechara esa ventana, y no lo vamos a insinuar para darle emoción al párrafo. Lo que estamos señalando es más aburrido y más útil. Un pico de fallos de autenticación es exactamente lo que produce una caída como esta, y también exactamente lo que produce un ataque de relleno de credenciales. La herramienta con la que se distinguen las dos cosas —y la que después te deja reconstruir qué pasó de verdad— estaba en la misma lista que la avería.

La versión doméstica de esto se comprueba en diez minutos y es la que nos encontramos más veces: el sistema que te avisa suele vivir dentro del sistema que vigila. Si tu monitorización manda las alertas por el correo del proveedor que se acaba de caer, ese día no te enteras de nada más, y es justo el día en que la alerta importaba. Lo mismo con el centro de administración: es donde se publica el incidente y vive dentro del mismo inquilino. El criterio que sacamos de aquí, y que aplicamos cuando se monta vigilancia gestionada, es que ni el canal de aviso ni el destino de la telemetría deberían depender de lo que están vigilando.

Sobre el plan B para el correo, en corto

Es la propuesta que aparece siempre a las cuarenta y ocho horas, y ya dedicamos un post entero a por qué montar una segunda suite «por si acaso» rara vez sale a cuenta; no lo vamos a repetir aquí. Lo que el lunes añade es una pregunta que aquel post no hacía, y que decide sola si el plan B sirve para algo: ¿contra qué identidad se autentica? Si es contra el mismo directorio, se cae contigo y da igual lo que cueste. Los hay que traen credenciales propias precisamente para este escenario; comprueba cuál te están vendiendo antes de mirar el precio.

El segundo día es el que sale caro

Recuperar el flujo de correo es lo visible. Lo que se llevó las horas de trabajo fue el martes: la búsqueda seguía degradada en Exchange Online, SharePoint Online, OneDrive y Teams —cuatro productos— y fallaban además los prompts de Microsoft 365 Copilot que necesitan datos de Microsoft 365. La gente no podía encontrar el adjunto de hace tres semanas ni el histórico de una conversación, y algunas organizaciones seguían drenando colas de correo atrasado. Hace unas semanas escribimos sobre un buscador roto que para el compromiso de servicio no era una caída, y aquí vuelve a pasar: la degradación larga y parcial no cuenta en el contador y sí cuenta en la nómina.

Cuándo esto no va contigo

Si sois veinte personas y el correo puede estar tres horas parado sin que se caiga ningún compromiso con un cliente, no hagas nada de esto. Anota la fecha, apunta qué dejó de funcionar y sigue con lo tuyo. La conversación cambia cuando el correo es donde entran los pedidos, cuando hay una obligación contractual de responder en un plazo o cuando el sector te exige demostrar que tienes un plan de continuidad. Y cambia también, aunque seáis veinte, si resulta que vuestra consola de seguridad depende del mismo sitio que vuestro correo: eso conviene saberlo un martes cualquiera y no el día que haga falta. Nosotros no podemos arreglar un certificado de Microsoft, y quien insinúe lo contrario vende humo; lo que hace un servicio de soporte 24x7 a las siete y media de la tarde de un lunes de agosto es notarlo antes que tus usuarios y decidir rápido si el problema es tuyo. Montar arquitectura para un evento de dos horas al año es una forma cara de sentirse tranquilo.

Fuentes (verificadas el 1 de septiembre de 2026): identificadores EX1464935 y MO1465074, hora de reconocimiento (17:30 UTC), lista de los seis servicios afectados y las tres citas literales de Microsoft — BleepingComputer, 31-ag.-2026; horas de 11:55 y 15:08 UTC, recuperación del correo «a última hora del lunes» y degradación de la búsqueda al segundo día en Exchange Online, SharePoint Online, OneDrive y Teams más los prompts de Copilot que requieren datos de M365 — Computerworld, 1-set.-2026; mensaje de error de cliente con la huella del certificado — Born's Tech and Windows World, 31-ag.-2026. Las horas de las dos primeras fuentes no coinciden y el post lo dice en vez de elegir una. Criterio propio, no hecho reportado: la lectura de la lista de servicios como mapa de dependencias compartidas, la observación sobre Defender XDR y Purview, y la regla de que el canal de aviso y el destino de la telemetría no dependan de lo vigilado. Microsoft no ha confirmado la causa raíz como un certificado caducado.