EWS se apaga en octubre, pero tu fecha límite es el 31 de agosto

Hay un detalle en el blog de Exchange que le da la vuelta a todos los titulares sobre el fin de EWS: a partir de octubre, dejar EwsEnabled en True con la lista de permitidos vacía deja de significar «permitir a todos» y pasa a significar «bloquear a todos». Hoy es 1 de agosto. Si en tu tenant de Microsoft 365 hay una sola aplicación que hable EWS —un archivador de correo, un CRM, la herramienta de firmas, un script que alguien escribió en 2019 y sigue corriendo—, tu fecha no es el 1 de octubre. Es el 31 de agosto, y quedan treinta días.

Exchange Web Services es la API SOAP con la que media industria ha hablado con los buzones de Exchange durante casi veinte años. Microsoft anunció su deprecación en julio de 2018, fijó en 2023 la fecha de apagado —octubre de 2026— y desde entonces la ha ido preparando con herramientas, informes y avisos. Lo que casi nadie ha leído es el cómo: el apagado no llega de golpe, llega en forma de una lista de aplicaciones permitidas que alguien tiene que escribir. Si no la escribes tú antes de que acabe agosto, la escribe Microsoft en septiembre por ti, a partir de lo que haya visto correr en tu tenant. Y esa es la diferencia entre una decisión y una fotografía.

El calendario, sin adornos

Dos precisiones antes de que alguien entre en pánico. La primera: esto es Exchange Online, no Exchange Server. Si tienes un Exchange local, tu EWS sigue donde estaba. La segunda: la lista de permitidos no es una solución, es una prórroga de seis meses. Va del 1 de octubre de 2026 al 1 de abril de 2027, y a partir de ahí no hay interruptor que valga. Todo lo que metas en esa lista sigue pendiente: lo único que cambia es la fecha en la que tendrás que resolverlo.

La trampa de la lista vacía

Hoy, un tenant con EwsEnabled en True y sin lista deja pasar a todo el mundo. A partir de octubre, ese mismo par de valores bloquea a todo el mundo. Es el tipo de cambio de semántica que no rompe nada mientras nadie lo toca y lo rompe todo el día que se aplica, y explica por qué el administrador que en agosto «lo deja configurado» sin poblar la lista se está autobloqueando con la mejor de las intenciones. Se consulta y se escribe así, en Exchange Online PowerShell:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Set-OrganizationConfig -EwsEnabled $true `
  -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

Fíjate en el segundo comando, porque aquí hay una mina enterrada: el parámetro no admite añadir ni quitar de forma incremental. Cada escritura sustituye la lista entera. El día que alguien tenga que meter una aplicación más —en octubre, con prisa, probablemente por teléfono— y no haya leído antes el valor completo, se llevará por delante todo lo demás. Por eso este trabajo termina con el valor completo guardado donde tu equipo lo pueda recuperar, con fecha y con quién lo aprobó, igual que cualquier otra configuración que solo se toca una vez al año.

Existen desde hace años otros controles —EwsApplicationAccessPolicy con EwsAllowList y EwsBlockList— que filtran por cadena de user agent. Siguen ahí, pero conviene saber qué son: el user agent es un campo de texto que elige el cliente. Como etiqueta descriptiva, útil. Como identidad, vale lo que vale. El identificador de aplicación de Entra es otra cosa, y es lo que se va a exigir a partir de octubre. Y para los buzones que sabes que ninguna integración debe tocar, existe el corte quirúrgico: Set-CASMailbox -Identity buzon@dominio -EwsEnabled $false.

El problema de verdad: no sabes quién usa EWS

Escribir la lista se resuelve con un comando. Lo que cuesta trabajo es saber qué meter dentro. Microsoft publicó en 2025 el informe de uso de EWS, y está en el centro de administración de Microsoft 365, en Informes → Uso → Exchange → pestaña de uso de EWS. Da cuatro columnas: identificador de aplicación, acción SOAP ejecutada, volumen de llamadas y fecha de última actividad en UTC. Se puede filtrar por los últimos 7, 30 o 90 días. Y trae dos letras pequeñas que cambian cómo hay que leerlo: los datos se agregan semanalmente, no a diario —así que no valides un cambio el martes por la mañana— y el filtro no llega más allá de 90 días.

El informe te da GUIDs, no nombres. Resolverlos es la parte tediosa: los de Microsoft están en la lista pública de aplicaciones de primera parte, y el resto salen de las aplicaciones empresariales de Entra ID. Que un identificador sea de Microsoft no lo saca de la conversación: la propia Microsoft mantiene una página —Baseline Security Mode Settings— con qué productos suyos siguen necesitando EWS, y es donde hay que mirar antes de dar por resuelto un GUID de primera parte. Y un criterio nuestro, dicho como criterio: los identificadores con volumen bajo y regular merecen más atención de la que reciben, porque ese patrón encaja con un proceso automático programado, y un proceso automático no tiene quien se queje el día que deja de funcionar.

Por qué la lista que escriba Microsoft no es tu lista

Aquí entramos en terreno de opinión, y lo decimos claro: lo que sigue es criterio nuestro, no política de Microsoft. La lista automática de septiembre se construye a partir del uso observado. Microsoft no publica exactamente qué ventana mira, así que no te podemos dar ese número; lo que sí sabemos es qué significa construir una lista a partir de lo que corrió. Es una fotografía de lo que se ejecutó, no una decisión sobre lo que debe ejecutarse, y eso falla en las dos direcciones.

Por lo que falta: el proceso que solo corre en el cierre trimestral, la exportación anual de un buzón a un archivo, la herramienta de migración que se enciende cuando hay una migración y duerme el resto del año. Si no se ejecutaron dentro de la ventana observada, no están en la foto; y si no están en la foto, difícilmente estarán en la lista. Lo notarás el día que toque ejecutarlos, que además suele ser un día con un cierre contable o una auditoría de por medio. Nadie relaciona un fallo de octubre con una lista que no escribió en agosto.

Por lo que sobra, que es peor: la lista automática permitirá lo que estuviera corriendo. Incluyendo esa integración que nadie recuerda haber autorizado, con permisos de aplicación sobre todos los buzones, contratada para un piloto que se abandonó. Ese acceso pasa de ser un cabo suelto a estar explícitamente en una lista blanca aprobada por nadie. Conviene recordar de dónde sale toda esta prisa: el incidente que aceleró el plan fue exactamente eso, un acceso vía EWS con permisos amplios. La lista de permitidos es, en la práctica, un ejercicio de seguridad con formato de trámite de compatibilidad, y es la mejor excusa que vas a tener este año para revisar qué aplicaciones pueden leer los buzones de tu empresa. Ese repaso es el mismo que defendíamos al hablar de la retirada del SMS como segundo factor en Entra: los plazos del fabricante son molestos, pero suelen ser la única fecha que consigue que alguien mire de verdad qué hay conectado.

Lo que Graph todavía no cubre (lo dice Microsoft)

«Migra a Graph» es un buen consejo hasta que abres la hoja de ruta de la propia Microsoft y ves la lista de huecos de paridad que siguen abiertos. Está publicada, en su documentación, ordenada por prioridad de trabajo:

• Importación y exportación de buzones, en versión preliminar — y con los buzones de grupos de Microsoft 365 y de carpetas públicas fuera.
• Importación y exportación de carpetas públicas.
• Importación y exportación de grupos de Microsoft 365.
• Archivo local (In-place Archive).
• Delta de eventos para citas periódicas.
• Notas rápidas (crear, leer, actualizar y borrar).
• Configuración de usuario y APIs de administración —dominios aceptados, pertenencia a listas de distribución, permisos de carpeta de buzón, configuración de organización, entre otros—, todas en versión preliminar.

Si tu empresa todavía vive sobre carpetas públicas —y muchas pymes viven sobre carpetas públicas aunque su departamento de IT prefiera no mencionarlo—, lo que te aprieta es el calendario más que la lista de permitidos. Y hay una palabra ahí que merece un párrafo aparte: preliminar. En versión preliminar quiere decir que existe y que puede cambiar; construir encima con la tranquilidad de un servicio en producción es otra cosa. Planificar una migración crítica contra una API en preview es una decisión legítima que se toma por escrito y con un plan B. Es la misma conversación que tuvimos con el fin de soporte de SharePoint 2016 y 2019: la fecha del fabricante no negocia, y el margen de maniobra lo da haber contado bien lo que tienes antes de que llegue.

Un apunte que ayuda a poner el tono justo: en esa misma página, Microsoft dice que está trabajando para eliminar las dependencias de EWS en sus propios productos, y cita a Outlook, Office, Teams y Dynamics 365. Ocho años después del anuncio. Lo traemos aquí para calibrar expectativas, no para hacer sangre: el fabricante actúa con transparencia y eso se agradece. Si a quien escribió la API le está costando ocho años sacársela de encima, la pregunta «¿nosotros usamos EWS?» no se responde de memoria en una reunión, sino abriendo el informe.

Los treinta días, repartidos

Agosto en España es un mes complicado para pedirle nada a nadie, y eso juega en contra en la única semana en la que hace falta que alguien externo te conteste. Así repartiríamos el mes:

• Primera semana — inventario. Abre el informe de uso a 90 días y exporta. Una fila por identificador de aplicación, con su volumen y su fecha de última actividad. Todavía no decidas nada: cuenta. Microsoft empaquetó más herramientas para esto y casi nadie las usa: hay un analizador de código EWS para revisar tus propios desarrollos, una herramienta de informes de uso y una guía para identificar aplicaciones de terceros.
• Segunda semana — nombres y dueños. Resuelve cada GUID a un nombre y a una persona responsable. Y escribe a cada fabricante dos preguntas concretas: cuál es el identificador de aplicación que tienes que permitir, y en qué fecha su producto deja de necesitar EWS. Por correo, para que quede. Esta semana es la que se atasca si empieza tarde.
• Tercera semana — lo que no sale en el informe. Siéntate con administración, con RRHH y con quien lleve el archivo legal, y pregunta qué procesos tocan el correo cada trimestre, cada semestre o una vez al año. Aquí es donde aparece la exportación que nadie había mencionado. Añade también las herramientas de copia y archivado y los scripts de administración con cuenta de servicio.
• Cuarta semana — escribir y guardar. Configura la lista completa, pon EwsEnabled en True, y guarda el valor íntegro en tu documentación con fecha y aprobación. Añade dos recordatorios al calendario: uno en octubre para comprobar que nada se ha caído, y otro no más tarde de enero de 2027 para revisar qué queda por migrar antes del 1 de abril.

Lo que no haríamos

• Meterlo todo en la lista «por si acaso». Es la tentación evidente y es lo que convierte una prórroga de seis meses en una excusa para no hacer nada hasta marzo. Cada identificador que entra ahí debería llevar detrás un nombre, un motivo y una fecha de salida.
• Aceptar «estamos trabajando en ello» como respuesta de un fabricante. Eso no es una fecha. Si tu proveedor no tiene fecha de soporte de Graph en agosto de 2026, esa información vale tanto como el propio producto y merece estar en la próxima renovación.
• Confundir la lista con el proyecto. La lista compra tiempo hasta abril de 2027. El trabajo es sacar EWS de tus integraciones, y ese trabajo tiene código, pruebas y una ventana de despliegue. Si en octubre lo único que has hecho es la lista, todavía tienes el proyecto entero por delante.
• Dejarlo para septiembre porque «Microsoft lo hace solo». Lo hace, y es justo lo que queremos evitar. Que la seguridad de tus buzones la decida un proceso automático a partir de lo que se ejecutó en verano es exactamente la clase de decisión que luego nadie recuerda haber tomado.

El eslabón que no tiene dueño

Lo interesante de este apagado es dónde cae el golpe: en la capa que casi nunca tiene dueño claro, las integraciones. El usuario seguirá abriendo Outlook sin enterarse de nada. El conector entre el ERP y el correo, la herramienta que archiva, el sistema de reservas de salas, el proceso que saca un PDF de un buzón compartido y lo deja en una carpeta. Cosas que funcionan desde hace años, que no salen en ningún organigrama y de las que solo te acuerdas cuando dejan de funcionar. En everyWAN desplegamos y gestionamos entornos Microsoft 365, y lo que vemos una y otra vez es que el inventario de servidores está impecable mientras el inventario de integraciones no existe. Ahí es donde trabajamos con datos y aplicaciones: poner nombre y dueño a lo que conecta con lo que, para que un cambio de calendario del fabricante llegue como una tarea planificada. No somos resellers de una plataforma concreta y aquí no hay nada que aprovechar del susto: lo que te podemos dar es la lista, con su fecha.

Una línea para cerrar: el 1 de octubre es la fecha de Microsoft; el 31 de agosto es la tuya. Una la decide el fabricante y la otra la decides tú, y la diferencia entre las dos es quién escribe la lista de lo que puede leer el correo de tu empresa.

Fuentes (verificadas): el calendario completo (deprecación anunciada en julio de 2018, fecha de apagado fijada en 2023, incidente Midnight Blizzard de enero de 2024 que elevó la urgencia y amplió el alcance a las aplicaciones de Microsoft, herramientas de 2025, apagado global desde octubre de 2026 y apagado total en abril de 2027), la lista de huecos de paridad con Graph y la mención a Outlook, Office, Teams y Dynamics 365 salen de la página de deprecación de EWS en Exchange Online de Microsoft Learn. El funcionamiento de la lista de permitidos —EwsAllowedAppIDs, la inversión de significado de la lista vacía a partir de octubre, la ausencia de operaciones incrementales, la población automática de septiembre y la recomendación de tenerla configurada antes de final de agosto— procede del anuncio «Introducing EWSAllowedAppIDs» del blog de Exchange y del mensaje MC1227454 del centro de mensajes de Microsoft 365 (5 de febrero de 2026), que confirma también que solo afecta a Exchange Online. Las columnas, los filtros de 7/30/90 días y la agregación semanal del informe están en la documentación del informe de uso de EWS. Los parámetros EwsEnabled, EwsAllowedAppIDs, EwsApplicationAccessPolicy, EwsAllowList y EwsBlockList, en la referencia de Set-OrganizationConfig; Set-CASMailbox -EwsEnabled, en la referencia de Set-CASMailbox. Una advertencia de honestidad: el modificador -RetrieveEwsOperationAccessPolicy de Get-OrganizationConfig procede del anuncio del blog de Exchange y todavía no aparece en la referencia publicada del cmdlet. Son criterio y opinión nuestros, no de Microsoft: la lectura de que la lista automática falla por lo que falta y por lo que sobra, la lectura de que los identificadores de volumen bajo y regular merecen atención preferente, el reparto de las cuatro semanas, la advertencia sobre guardar el valor completo de la lista y todo lo que no haríamos.