En la lista de servicios afectados que Microsoft publicó el jueves por la noche, Defender XDR aparece junto a Exchange Online, Teams y Copilot. Traducido a una sala de crisis: desde las siete de la tarde, hora peninsular, organizaciones de 74 países intentaron coordinarse sin correo, sin chat, sin asistente y con su consola de detección en la misma lista de averías. A mediodía del viernes, el incidente seguía abierto.
Una avería en cadena que todavía no tiene causa
La caída empezó hacia las 13:00 de la costa este de Estados Unidos, las 19:00 en España, y Downdetector registró fallos en todos esos países en menos de una hora. Microsoft ha ido cambiando su explicación por el camino. Primero habló de carga elevada. Después precisó que no la provocaba más tráfico, sino un número de servidores que habían dejado de estar disponibles de forma inesperada y sobrecargaban al resto. Más tarde apuntó a las comprobaciones automáticas de salud, que iban sacando máquinas del servicio, y llegó a señalar como posible origen el componente que procesa esas comprobaciones. Los servidores que lograba recuperar volvían a dejar de responder en cuanto recibían tráfico.
La compañía dice no tener constancia de actividad maliciosa y ha prometido un informe posterior con la causa raíz. Hasta entonces, cualquier diagnóstico es una hipótesis. Si administras un tenant, los expedientes que hay que seguir en la página de estado y en el centro de administración son EX1550543 (buzones) y MO1550821 (impacto general).
Tampoco es una rareza del calendario. Euronews recuerda que en enero Outlook y Teams ya estuvieron caídos durante horas y que en agosto una actualización defectuosa dejó tocados Outlook y Exchange Online durante varios días. Al menos tres episodios en un año dejan de ser mala suerte y pasan a ser un dato de planificación.
Primera pregunta del auditor: ¿por dónde convocasteis al comité?
En una organización que trabaja sobre Microsoft 365, lo natural es que la primera llamada de un incidente grave salga por Teams y la convocatoria formal, por Outlook. El jueves los dos canales estaban en la lista. Si el comité de crisis acabó reunido en un grupo de mensajería personal creado sobre la marcha, el fallo no fue de Microsoft. Fue del plan.
La Directiva NIS2 lo dejó escrito en 2022. Su artículo 21.2 pide en la letra c) medidas de continuidad y gestión de crisis, y en la j), cuando proceda, «sistemas seguros de comunicaciones de emergencia». España todavía no la ha transpuesto, pero esa redacción anticipa el examen que vendrá. El artículo 23.4.a) fija además una alerta temprana a la autoridad en 24 horas desde que se tiene constancia de un incidente significativo.
Nuestra lectura: si el servicio que prestas se degradó de forma grave porque cayó tu proveedor, el incidente sigue siendo tuyo. El reloj corre igual, y la alerta hay que mandarla por algún sitio que funcione.
Segunda pregunta: ¿con qué estabais mirando?
Entre los servicios afectados figuraban Defender XDR, Defender for Office 365 e Intune. Microsoft avisó de que Safe Links podía no estar verificando las URL en las que los usuarios pinchaban desde Outlook y Teams. Es decir: durante las horas en que la plantilla esperaba correos atrasados y avisos de soporte, la protección contra enlaces maliciosos trabajaba a medio gas. Euronews advierte precisamente de estafas de falso soporte que aprovechan la caída.
La IA tampoco se libró. Copilot estaba en la lista, y varios proveedores de IA informaron de fallos en las herramientas que conectan sus asistentes con Microsoft 365. Un asistente que lee el buzón para responder tiene exactamente la disponibilidad del buzón. Si tus agentes trabajan sobre Microsoft Graph, esa dependencia tiene que figurar en tu análisis de impacto con el mismo peso que el correo.
Tercera pregunta: ¿vuestro plan B vive en el mismo tenant que el A?
El ENS es más concreto que NIS2. La medida op.cont.4, «Medios alternativos», exige en categoría ALTA disponer de alternativas para los servicios contratados a terceros y para las comunicaciones, fijar un tiempo máximo para que entren en funcionamiento y que ofrezcan las mismas garantías de seguridad que los originales (Real Decreto 311/2022, anexo II). La op.ext.3 añade en su refuerzo R1 que el plan de continuidad considere la dependencia de proveedores críticos y pruebe escenarios de fallo del proveedor.
Leídas juntas, descartan un plan B muy habitual: el segundo canal que se autentica contra la misma identidad, cuelga del mismo dominio y se administra desde la misma consola. Eso es un segundo icono en el escritorio, no un segundo medio.
Esta mañana ha llegado un ejemplo de lo contrario. Fuentes del Ministerio para la Transformación Digital y de la Función Pública explicaron a EFE que la Administración General del Estado se vio poco afectada porque la mayoría de los correos de sus empleados están alojados en centros de datos propios. Sin entrar a valorar ese modelo en otros aspectos, el jueves la separación hizo su trabajo.
En Pumpún damos por buena una alternativa solo si cumple cuatro condiciones, y las cuatro se comprueban activándola, no leyendo un documento:
- No comparte proveedor de identidad con el servicio principal.
- No depende del mismo tenant ni de la misma consola de administración.
- Tiene un tiempo de activación fijado y medido, como pide op.cont.4.
- Se ha puesto en marcha de verdad en los últimos doce meses.
La matriz para el comité del lunes
Matriz de exposición: funciones que cayeron con Microsoft 365 (12-13 de noviembre de 2026)
| Función | Servicio afectado | Pregunta de control | Alternativa que cuenta | Métrica |
|---|---|---|---|---|
| Coordinación de crisis | Teams, Outlook | ¿Hay un canal que no dependa del tenant ni de su identidad? | Mensajería autoalojada o puente telefónico con directorio fuera de línea | Minutos hasta reunir al comité |
| Notificación a la autoridad | Exchange Online | ¿Puedes enviar la alerta de 24 h sin el correo corporativo? | Buzón en otro dominio y proveedor; credenciales del canal oficial fuera del SSO | Fecha de la última verificación de acceso |
| Detección y respuesta | Defender XDR | ¿Qué telemetría sigue visible si cae la consola? | Registros exportados a un SIEM propio | Retraso de ingesta, en minutos |
| Protección del correo | Defender for Office 365 (Safe Links) | ¿Quién filtra enlaces si la verificación falla? | Filtrado en pasarela o DNS bajo control propio | % de clics filtrados durante la caída |
| Gestión de dispositivos | Intune | ¿Puedes bloquear un portátil perdido durante la caída? | Procedimiento manual documentado | Minutos hasta el bloqueo |
| Asistentes de IA | Copilot, conectores de terceros | ¿Qué proceso se para si el asistente no responde? | Asistente sobre base documental propia, fuera del tenant | % de procesos con modo manual escrito |
Servicios afectados según la relación de Microsoft recogida por la prensa a 13/11/2026. Alternativas y métricas: criterio de Pumpún. Los umbrales los fija cada organización en su análisis de impacto.
Rellénala con el nombre de tus herramientas, no con el de Microsoft. Sirve igual para cualquier suite en la que correo, identidad y seguridad compartan casa, y lo que salga en rojo marca tus prioridades del primer trimestre.
Lo mínimo que debería seguir encendido
Ninguna organización va a abandonar su suite de productividad por una avería, y tampoco hace falta. Lo razonable es que una parte pequeña y bien elegida no dependa de ella: el canal donde se reúne el comité, los procedimientos de respuesta y un asistente capaz de consultarlos.
Eso es lo que desplegamos en Pumpún sobre la infraestructura del cliente, en local o en entornos aislados: canal de crisis, repositorio de procedimientos e inferencia propia, con una identidad independiente del tenant principal y un tiempo de activación medido. Si tu matriz ha salido con filas en rojo, cuéntanos cuáles y te decimos qué se puede levantar fuera del tenant y en cuánto tiempo. La próxima vez que caiga el correo, el comité debería enterarse por un canal que siga encendido.