La noche del 31 de agosto de 2026 comenzó una caída generalizada en Microsoft 365, registrada en el centro de administración como EX1464935 y ampliada después bajo MO1465074. El impacto no se limitó al correo. Exchange Online cayó junto con Teams, SharePoint Online y OneDrive for Business, y con ellos las herramientas de gobernanza y seguridad de Purview y Defender XDR. Una empresa que llegaba a sus clientes por correo, se coordinaba internamente por chat, guardaba sus archivos en la nube y vigilaba su seguridad desde un panel perdió las cuatro cosas en el mismo momento.

Microsoft describió la causa como un problema en la configuración de autenticación central utilizada por varios servicios internos dentro de la infraestructura de Exchange Online, y aplicó una mitigación escalonada que volvió a aplicar los componentes de autenticación en una muestra de la infraestructura antes de ampliarla. El flujo de correo y la búsqueda se restablecieron el 1 de septiembre, con un impacto limitado en un pequeño subconjunto de usuarios que persistió hasta el 2 de septiembre. La interrupción completa duró más de un día, y la cola, dos.

Este no es un artículo sobre Microsoft. Todos los grandes proveedores sufren caídas, y ya hemos cubierto interrupciones en otros servicios de IA. Es un artículo sobre lo que esta caída en concreto dejó al descubierto, que es más peligroso de lo que parece a primera vista.

Lo que cuentas como seis sistemas puede ser uno solo

Pide a cualquier directivo que enumere sus sistemas y obtendrás una lista: un sistema de correo, un sistema de chat, un sistema de archivos, un sistema de seguridad. Cuatro nombres, cuatro iconos, normalmente cuatro líneas en el contrato. La suposición natural es que si uno cae no arrastra a los demás, porque son cosas distintas.

Pero los nombres no son los límites de un sistema. El límite real es lo que esos servicios comparten por debajo: quién verifica tu identidad, dónde se mantienen las sesiones, por qué red circulan. Cuando cuatro servicios comparten una sola capa de autenticación, desde el punto de vista del riesgo son un solo servicio, por muy separados que parezcan en la factura.

Lo incómodo es que esta compartición nunca se ve en tiempos normales. Al contrario, es justamente lo que te da el cómodo inicio de sesión único y la integración fluida entre el correo y los archivos. Compras la comodidad a diario y la pagas una vez cada pocos años, en un único día muy largo.

Esto se aplica tanto a una empresa saudí mediana como a una corporación global. Piensa en cuántos de tus servicios dependen de una sola cuenta de Google, o de un solo número de WhatsApp, o de un solo proveedor de hosting, o de un solo empleado que guarda las contraseñas. Cada uno de ellos es un punto único de fallo. La diferencia es que los tuyos son más pequeños y mucho más fáciles de corregir.

Mapea tus dependencias en una hora

No necesitas ninguna herramienta ni ningún consultor. Necesitas una hoja de papel, una hora y respuestas honestas. En la primera columna escribe cada operación sin la que tu negocio no puede pasar un día completo: recibir pedidos, emitir facturas, atender a los clientes, pagar las nóminas, prestar el servicio. Después hazte tres preguntas sobre cada una:

  • ¿De qué servicio externo depende esta operación? Escribe el nombre comercial sin rodeos: este proveedor de correo, esa plataforma de tienda online, esa pasarela de pago, ese proveedor de mensajería.
  • ¿Con qué cuenta o identidad inicias sesión? Normalmente aquí aparece la sorpresa. Descubrirás cuatro servicios distintos a los que se entra con una sola cuenta, o tres servicios vinculados a un solo número de móvil para los códigos de verificación.
  • Si esto se detuviera ahora mismo, ¿cuál es la alternativa en una hora? Si la respuesta es ninguna, has encontrado un punto único de fallo real y no uno teórico.

Cuando termines, una o dos entradas se repetirán en la mayoría de las filas. Esas son tus dependencias compartidas. No intentes eliminarlas todas, porque no es ni realista ni económico. Toma la fila que detiene los ingresos y ocúpate primero de esa.

El tipo de caída más evitable: las fechas de vencimiento

No todas las caídas son iguales. Algunas vienen de una complejidad que no controlas. Otras vienen de una fecha escrita en algún sitio que nadie lee. El segundo tipo es el más fácil de evitar y el que más se repite, porque lo único que necesita es seguimiento.

Estas son las fechas de vencimiento que dirigen tu negocio en silencio, y cada una de ellas debe estar en un único calendario con un responsable con nombre y apellido:

  • El certificado de cifrado de tu sitio web. Cuando caduca, tu sitio no se vuelve lento: muestra a los visitantes una advertencia de seguridad directa que les impide entrar. El efecto en las ventas es inmediato y total.
  • El registro del dominio. Olvidar renovar el dominio tumba a la vez el sitio web y el correo, porque el correo funciona sobre el mismo dominio. Es una de las peores caídas, porque corta precisamente el canal que habrías usado para dar explicaciones.
  • El certificado del sello de facturación electrónica. Las directrices técnicas detalladas de facturación electrónica de la Autoridad de Zakat, Impuestos y Aduanas (ZATCA) establecen que los contribuyentes deben renovar el identificador del sello criptográfico de sus unidades generadoras de facturas antes de que caduque el existente, y que la renovación implica revocar el identificador antiguo y emitir uno nuevo. Si se te pasa el plazo, tienes un problema de facturación, no solo un aviso.
  • Las claves de integración entre tus sistemas. El token de acceso que conecta tu tienda con tu sistema de inventario, o tu sistema con una pasarela de pago, tiene una vida útil definida. Su vencimiento no detiene ninguno de los dos sistemas, detiene el puente entre ellos, de modo que los pedidos siguen llegando mientras la sincronización se detiene en silencio. Ese es el tipo de fallo que se descubre tarde.
  • Los certificados de firma de apps y las tarjetas registradas. Un certificado de firma caducado te impide publicar una actualización en la tienda, y una tarjeta caducada en una suscripción detiene el propio servicio. Ambos suelen llegar en el peor momento posible.

La regla práctica es sencilla. Todo lo que tenga fecha de vencimiento necesita tres cosas: una alerta a sesenta días, un responsable con nombre y apellido y no un departamento, y un suplente que sepa renovarlo si el responsable no está. Si falta cualquiera de las tres, vuelves a depender de la memoria de alguien.

Qué hacer el día en que tu proveedor se cae

Cuando llega la caída, la diferencia entre una empresa que parece profesional y otra que parece desbordada no es la velocidad de reparación, ya que la reparación no está en tus manos de todos modos. La diferencia son tres cosas que preparaste de antemano:

  • Un canal de comunicación fuera de la capa que cayó. Si toda tu coordinación interna vive en una sola herramienta, no tienes coordinación cuando esa herramienta cae. Basta con un grupo de respaldo en un canal realmente distinto, además de una lista de contactos guardada fuera del sistema.
  • Un modo manual declarado para las operaciones críticas. ¿Cómo recibes un pedido, registras un pago y prestas un servicio sin el sistema? Escríbelo hoy en una página y entrégasela al equipo. Las empresas que escriben esa página pierden horas. Las que no la escriben pierden un día.
  • Un mensaje listo para el cliente. A los clientes les enfada menos la caída que el silencio. Una nota breve que diga qué está afectado, cuál es la solución provisional y cuándo llega la próxima actualización convierte un fallo en una situación gestionada. No prometas una hora de solución que no controlas.

Cuando termine, hazte una sola pregunta y nada más: ¿qué hemos aprendido hoy sobre nuestras dependencias que no sabíamos? La respuesta vale más que cualquier informe, y suele ser una sola línea que merece un solo cambio.

La visión de Origami

En nuestro trabajo, lo que más sorprende a los empresarios rara vez es la caída en sí. Es descubrir que sistemas que creían independientes cayeron juntos. Una decisión basada en la creencia de que tenemos alternativas se viene abajo cuando resulta que todas las alternativas pasan por la misma puerta. Por eso empezamos cualquier conversación sobre continuidad mapeando las dependencias y no comprando una herramienta, porque la herramienta que compres bien puede estar sobre la misma capa y aumentar el riesgo en lugar de reducirlo.

También creemos que la respuesta correcta a una caída como esta no es huir de la nube. La infraestructura en la nube de un proveedor serio es más fiable que lo que la mayoría de las empresas puede construir y operar por sí misma, y una interrupción ocasional no cambia eso. La respuesta correcta es saber con precisión qué operaciones se detienen y cuáles continúan, y haberlo elegido de forma deliberada en lugar de descubrirlo un mal día. La continuidad no es un sistema que se compra. Es un conjunto de pequeñas decisiones que tomas cuando nada te presiona para tomarlas.

Conclusión

Un único fallo en una capa de autenticación compartida detuvo seis productos durante más de un día en empresas de todo el mundo. La lección no es cambiar de proveedor, sino saber qué comparten realmente tus sistemas bajo la superficie. Empieza con una tabla de tres columnas que deje al descubierto tus dependencias, pon todas las fechas de vencimiento en un único calendario con un responsable con nombre y apellido, y escribe la página del modo manual antes de necesitarla. Son unas tres horas de trabajo entre tú y un día entero de parálisis, lo que la convierte en la inversión en continuidad más barata que existe.

Fuentes