Microsoft Teams trasladará su cliente web a teams.cloud.microsoft: las comprobaciones de red que los equipos de TI deben hacer ya

Microsoft va a cambiar la dirección del cliente web de Teams. Durante septiembre de 2026, quienes abran teams.microsoft.com podrían ser redirigidos a teams.cloud.microsoft. Microsoft describe el cambio como una modificación de dominio, no como una migración de funcionalidades: se espera que los enlaces y marcadores existentes sigan funcionando, y los usuarios finales no tendrán que instalar un cliente nuevo.

Suena rutinario hasta que la petición atraviesa un proxy empresarial, una pasarela web segura, una política DNS, una lista de permitidos del navegador, una política de seguridad de contenido, un manifiesto de aplicación o un control de acceso remoto. En esos entornos, una redirección no es automáticamente inocua. El navegador debe poder resolver y alcanzar el destino, la infraestructura de seguridad debe permitirlo y las aplicaciones integradas de Teams deben reconocer el nuevo origen.

El consejo inmediato es sencillo: tratar teams.cloud.microsoft como un endpoint de producción, revisar los datos de endpoints de Microsoft 365 que utiliza la organización y probar toda la experiencia web antes de que los usuarios descubran el cambio por un inicio de sesión fallido o una pestaña en blanco. La lección va más allá de Teams. Los cambios de URL de los servicios SaaS deben formar parte de la gestión de endpoints y del control de cambios, incluso cuando el proveedor afirma que no cambia ninguna funcionalidad del producto.

Qué está cambiando Microsoft

El aviso del Centro de mensajes de Microsoft MC1465764 indica que los usuarios web de Teams serán redirigidos de teams.microsoft.com a teams.cloud.microsoft antes de septiembre de 2026. El aviso clasifica el cambio como importante y señala que tiene impacto para los administradores. El destino utiliza la familia de dominios más amplia cloud.microsoft, que Microsoft introdujo para experiencias autenticadas de Microsoft 365 orientadas a los usuarios.

La migración no se presenta como un cliente nuevo de Teams ni como un sistema de cuentas distinto. Una persona que use el navegador debería seguir accediendo al mismo servicio, con las mismas conversaciones, reuniones, archivos y contexto de organización. La diferencia visible será la dirección del navegador, junto con el comportamiento de red y de las aplicaciones web que se derive de ella.

Microsoft afirma que la URL antigua redirigirá a la nueva y que los enlaces existentes seguirán funcionando. Esto reduce la interrupción para los usuarios habituales, pero no elimina la necesidad de realizar pruebas administrativas. Un marcador puede seguir una redirección HTTP; un proxy con controles estrictos puede evaluar por separado los dos nombres de host. El navegador puede cargar la página mientras una pestaña integrada falla porque su política frame-ancestors no se ha actualizado. Un firewall puede permitir teams.microsoft.com y rechazar *.cloud.microsoft.

El aviso del Centro de mensajes también indica que existe un control administrativo temporal para desactivar la redirección, pero que dicho control finalizará el 31 de diciembre de 2026. Por tanto, es una ayuda para la migración, no un modelo operativo duradero. Las organizaciones que lo utilicen deben registrar la excepción, asignarle un responsable y planificar su retirada.

La documentación pública de endpoints de Microsoft ya incluye *.teams.microsoft.com y *.teams.cloud.microsoft para Teams, junto con teams.microsoft.com y teams.cloud.microsoft. La misma documentación enumera *.cloud.microsoft como endpoint unificado obligatorio para experiencias autenticadas de Microsoft 365. La consecuencia práctica es importante: la organización debe actualizar su proceso de referencia para los endpoints, no limitarse a añadir un nombre de host en una regla aislada del firewall.

Por qué una redirección puede convertirse en una interrupción

Una redirección atraviesa varios puntos de control. Cada uno puede producir un síntoma diferente, y el usuario puede interpretarlo como “Teams no funciona” aunque el servicio de Microsoft esté operativo.

Firewalls y pasarelas web seguras

Las listas de permitidos tradicionales suelen contener nombres de host concretos. Si la política permite teams.microsoft.com pero no teams.cloud.microsoft, la primera petición puede completarse y la petición redirigida puede bloquearse. Según la pasarela, los usuarios podrían ver una página de acceso denegado, un tiempo de espera agotado, un bucle de autenticación o una carcasa incompleta de la aplicación.

Algunas organizaciones utilizan filtrado por categorías, inspección TLS o enrutamiento mediante proxy explícito. Esos controles pueden depender de nombres de certificado, categorías de URL o reglas redactadas alrededor del dominio antiguo. El nuevo host debe evaluarse según la misma política prevista. Añadir un comodín amplio sin revisar cómo lo gestiona la pasarela puede crear una exposición innecesaria; rechazar el comodín sin entender las indicaciones de Microsoft puede producir una operación frágil. La decisión correcta depende del modelo de control de cada organización, pero debe ser deliberada y quedar documentada.

DNS y comportamiento de redes divididas

Un nombre de host nuevo también entra en los flujos de DNS. Los resolutores internos, los servicios de filtrado, los productos de DNS seguro y los clientes de acceso remoto pueden aplicar políticas distintas a un dominio observado por primera vez. Hay que probar desde la red de la oficina, dispositivos conectados por VPN, escenarios de trabajo desde casa y cualquier entorno de escritorio virtual administrado. Una prueba correcta desde el portátil de un administrador no demuestra que todas las rutas de salida vayan a comportarse igual.

No conviene fijar una dirección IP para resolver este cambio. Las indicaciones de endpoints de Microsoft se expresan en términos de dominios de servicio y datos de direcciones publicados, y los servicios en la nube pueden cambiar su infraestructura subyacente. Una solución basada en IP puede fallar durante un cambio normal del servicio y eludir la intención de los controles basados en nombres de host.

Confianza del navegador y políticas de cookies

El acceso web a Teams depende tanto del comportamiento del navegador como de la conectividad de red. La guía de resolución de problemas de Microsoft para Teams identifica *.cloud.microsoft entre los dominios que podrían necesitar confianza cuando los controles del navegador restringen las cookies o los sitios de confianza. Las organizaciones que bloquean cookies de terceros, imponen listas de sitios del navegador o distribuyen políticas de grupo deben probar el inicio de sesión, el lanzamiento de reuniones y la navegación después de la redirección.

Una excepción de dominio debe limitarse a los servicios de Microsoft necesarios y gestionarse mediante el mismo proceso de revisión que otras excepciones relacionadas con la autenticación. No hay que desactivar globalmente un control de privacidad del navegador solo para conseguir que una prueba funcione. Primero hay que identificar si el problema está en el alcance de las cookies, una política de sitios de confianza, la inspección TLS, una regla del proxy o un endpoint bloqueado.

Aplicaciones y pestañas integradas en Teams

Teams también sirve de anfitrión para aplicaciones. Una pestaña personalizada, una herramienta de negocio o una aplicación de un socio puede cargarse dentro del cliente web de Teams en lugar de abrirse como página de nivel superior. En esa situación, el nuevo host cambia el origen del navegador y puede dejar al descubierto supuestos que permanecían invisibles con la dirección anterior.

La guía para desarrolladores de Teams de Microsoft indica que los responsables de las aplicaciones deben actualizar la biblioteca JavaScript de Teams a la versión 2.19.0 o posterior e inicializar la aplicación para el nuevo host. También señala que las aplicaciones que utilizan cabeceras de Content Security Policy deben incluir *.cloud.microsoft en la directiva frame-ancestors, conservando los valores existentes para mantener la compatibilidad durante la migración.

Esto no es motivo para cambiar indiscriminadamente todas las cabeceras de seguridad. Es motivo para revisar la cabecera frente a la lista real de hosts compatibles, probar la aplicación en el cliente web de Teams y comprobar que la validación de orígenes, las entradas validDomains, la configuración de cookies y el manejo de postMessage siguen correspondiendo al flujo previsto de la aplicación.

Un patrón habitual de fallo es el éxito parcial: la carcasa de Teams carga, pero una pestaña muestra un marco vacío; la pestaña se abre, pero falla la selección de archivos; o la autenticación vuelve a la aplicación sin una sesión utilizable. Antes de cambiar el código hay que registrar el host visible en el navegador y el host que aparece en las trazas de red.

Quién se ve afectado

El grupo afectado principalmente está formado por las organizaciones que utilizan Teams en un navegador y controlan el acceso saliente mediante firewalls, proxies, pasarelas web seguras, filtros DNS o políticas de navegador administrado. El cambio será menos visible para quienes utilicen únicamente el cliente de escritorio o móvil, aunque los enlaces, las transiciones de autenticación y las experiencias integradas todavía pueden incluir componentes del navegador.

Los responsables de aplicaciones de Teams constituyen un segundo grupo. Aquí se incluyen desarrolladores internos, proveedores de software, equipos de intranet y departamentos que mantienen pestañas, extensiones de mensajería, sitios web incrustados en Teams o integraciones que validan el origen de Teams. Su riesgo no se limita a la redirección inicial. Un host nuevo puede afectar a las políticas de marcos, comprobaciones de origen, supuestos sobre URI de redirección, atributos de cookies, filtros de telemetría y documentación de soporte.

Los equipos de red e identidad también deben participar. A menudo son dueños de piezas diferentes del recorrido: red gestiona la salida, endpoint gestiona la política del navegador, identidad gestiona los controles de inicio de sesión y aplicaciones gestiona el contenido integrado. Un cambio que cruza los cuatro responsables puede quedar entre colas si nadie lo trata como un único cambio de servicio.

Las organizaciones pequeñas no están automáticamente exentas. Una empresa pequeña quizá no tenga un proxy complejo, pero puede depender de un firewall administrado, de un proveedor externo de TI o de una política de navegador heredada de una organización matriz. Los entornos sencillos deben probar con rapidez, no asumir que la simplicidad garantiza la compatibilidad.

Los detalles de los endpoints que importan

La documentación de Microsoft sobre las URL y los rangos de direcciones IP de Microsoft 365 indica que los endpoints obligatorios deben ser accesibles y señala *.cloud.microsoft como destino unificado obligatorio mediante TCP 443 y UDP 443. En la sección de Teams enumera *.teams.cloud.microsoft, *.teams.microsoft.com, teams.cloud.microsoft y teams.microsoft.com, con TCP 443 y 80 y UDP 443.

Esas entradas son más útiles que copiar una lista de una publicación de foro porque Microsoft actualiza los datos de endpoints cuando cambia el servicio. La documentación explica que los datos suelen publicarse con antelación, aunque también pueden actualizarse durante el mes por escaladas de soporte, incidentes de seguridad u otras necesidades operativas inmediatas. Es un argumento sólido para automatizar el consumo del flujo de endpoints de la organización cuando sus herramientas de seguridad lo permitan.

También recuerda que las categorías de endpoints importan. Microsoft distingue destinos obligatorios, opcionales y predeterminados, y explica que una función puede depender de endpoints pertenecientes a varios grupos de carga de trabajo. Un equipo que busque simplemente “Teams” en una lista estática puede pasar por alto un endpoint común de autenticación o contenido necesario para que la experiencia completa funcione.

La secuencia operativa segura consiste en comparar los datos actuales de endpoints de Microsoft con las capas de control reales de la organización y después probar el resultado. No hay que suponer que una única lista de permitidos en el firewall perimetral representa toda la política. Un agente de seguridad de acceso a la nube, un agente del endpoint, una configuración del navegador, una zona DNS privada o una regla de túnel dividido de la VPN todavía pueden bloquear el nuevo host.

Un plan práctico de validación

1. Identificar a los usuarios y las rutas reales

Hay que empezar por un inventario, no por un cambio de reglas. Determina qué grupos abren Teams en un navegador, qué grupos utilizan escritorios virtuales, quién se conecta mediante VPN y si los contratistas o proveedores de servicios administrados utilizan rutas de salida separadas. Incluye estaciones compartidas, dispositivos de tipo kiosco y sistemas de salas de reuniones si abren enlaces de Teams basados en navegador.

Registra los controles aplicados a cada ruta: filtrado DNS, proxy, inspección TLS, firewall, pasarela web segura, política del navegador, seguridad del endpoint y política de acceso condicional de identidad. Este mapa facilita distinguir después un problema del servicio de un problema de política local.

2. Revisar la fuente de endpoints de la organización

Utiliza la documentación actual de endpoints de Microsoft 365 y, cuando sea posible, sus datos descargables o su servicio web, en lugar de depender de una hoja de cálculo mantenida localmente. Confirma que las entradas obligatorias del dominio unificado y las entradas de Teams estén representadas en los sistemas que realmente aplican el acceso.

Si la organización permite intencionadamente solo FQDN concretos, decide si teams.cloud.microsoft basta para la redirección web de Teams actual o si el comodín documentado resulta necesario para el uso más amplio de Microsoft 365. La decisión debe tomarse con el responsable de seguridad. Un comodín puede simplificar el mantenimiento, mientras que los nombres individuales ofrecen un alcance más estrecho, pero exigen un mantenimiento más frecuente.

3. Probar la redirección

Desde cada ruta de red representativa, abre la URL antigua de Teams y observa la cadena completa. Confirma que la petición llega a teams.cloud.microsoft, que el certificado se acepta, que la autenticación termina correctamente y que la aplicación acaba de cargar. Prueba con una cuenta de usuario normal y con una cuenta de administrador; las cuentas privilegiadas pueden tener políticas y estados en caché diferentes.

Utiliza las herramientas de desarrollo del navegador o los registros de la pasarela para anotar peticiones bloqueadas, códigos de estado y decisiones de política. El objetivo no es recoger una captura enorme de paquetes. Es responder a cuatro preguntas concretas: ¿resolvió DNS?, ¿pasó la conexión?, ¿se completó la redirección?, ¿cargó la aplicación todos los recursos necesarios?

Borra los datos de sitio en caché solo después de registrar el primer resultado. Limpiar la caché puede ocultar un problema de migración reproducible o crear un fallo falso que los usuarios habituales no experimentarán. Ejecuta al menos una prueba con un perfil limpio y otra con el perfil de producción administrado.

4. Probar acciones de usuario, no solo la página de inicio

Una pantalla de inicio de sesión correcta no basta. Valida las acciones que importan a la organización: abrir un chat, unirse a una reunión, iniciar una llamada si está habilitada, abrir un archivo compartido, cambiar de inquilino cuando corresponda, cargar una pestaña personalizada y utilizar cualquier integración aprobada de Teams. Prueba tanto un marcador directo del navegador como un enlace recibido por correo electrónico o una invitación de calendario.

En el caso de las reuniones, prueba el recorrido desde un enlace del calendario, porque el navegador puede atravesar pasos adicionales de redirección y autenticación. Para los archivos, prueba abrir y editar un documento representativo si ese flujo es importante. En las aplicaciones personalizadas, prueba cada pestaña crítica para el negocio y el recorrido de retorno después del inicio de sesión.

5. Comprobar las políticas de las aplicaciones integradas

Los responsables de aplicaciones deben buscar en el código fuente y la configuración referencias codificadas a teams.microsoft.com, comparaciones explícitas de origen, valores CSP de frame-ancestors, listas de dominios de confianza, URI de redirección, supuestos sobre el dominio de las cookies y filtros de telemetría. La búsqueda debe incluir la configuración de despliegue y la documentación, no solo el código de la aplicación.

Sigue la guía de aplicaciones de Teams de Microsoft para la versión de TeamsJS y el comportamiento de inicialización. Conserva los valores del host antiguo cuando sea necesaria la compatibilidad hacia atrás y añade el host nuevo de acuerdo con el modelo de seguridad de la aplicación. No sustituyas los valores antiguos a ciegas si los usuarios todavía pueden llegar mediante la URL antigua o si otros hosts de Microsoft 365 siguen siendo compatibles.

Después de cambiar cabeceras o manifiestos, prueba en todos los contextos de host compatibles. Una CSP que funciona en una pestaña de nivel superior puede rechazar un marco integrado. A la inversa, una cabecera permisiva usada en una prueba puede ocultar que la respuesta de producción la genera otro proxy inverso o una CDN.

6. Actualizar el material operativo

Busca el nombre de host antiguo de Teams en los artículos del centro de ayuda, las guías de incorporación, los formularios de solicitudes de firewall, las políticas de proxy, las políticas del navegador, las comprobaciones de monitorización y los manuales de incidentes. Conserva la URL antigua en las notas históricas cuando sea útil, pero descríbela como origen de una redirección, no como la única dirección del servicio.

También hay que actualizar la monitorización. Una comprobación sintética que exija el nombre de host final puede empezar a fallar aunque el servicio esté sano si fue escrita para la dirección antigua. Una comprobación que siga las redirecciones y verifique la página final representa mejor la experiencia, siempre que también alerte cuando la cadena de redirección cambie de forma inesperada.

Qué no se debe hacer

No indiques a los usuarios que eviten el proxy, desactiven las protecciones del navegador o utilicen un dispositivo no administrado como solución estándar. Esas acciones pueden ocultar el problema de política y crear un segundo problema de seguridad.

No desactives permanentemente la redirección solo porque el equipo de una aplicación todavía no haya probado su pestaña. El control administrativo temporal tiene una fecha de caducidad, y posponer el trabajo convierte un cambio controlado en un incidente con fecha límite. Utiliza el control únicamente cuando sea necesario para proteger la continuidad del servicio mientras se programa una corrección concreta.

No sustituyas las reglas de nombres de host por direcciones IP fijas. La infraestructura en la nube de Microsoft está diseñada para evolucionar, y una solución basada en IP puede quedar obsoleta o dirigir el tráfico de forma incorrecta.

No permitas todos los destinos *.microsoft sin revisión. La documentación pertinente de Microsoft identifica familias de dominios y categorías de endpoints específicas; ampliar el acceso más allá de la necesidad empresarial reduce el valor del control.

No consideres que una respuesta HTTP 200 de la primera página demuestra que Teams funciona. El fallo puede aparecer después de la autenticación, durante una llamada a una API, al cargar una pestaña o al abrir un archivo.

Cómo gestionar la excepción temporal

El aviso de Microsoft indica que el control administrativo para desactivar la redirección de Teams finalizará el 31 de diciembre de 2026. Si una organización lo utiliza, la excepción debe tener un motivo claro y un responsable identificado. Un registro útil incluye el inquilino o grupo de usuarios afectado, la dependencia bloqueada, el equipo de aplicaciones o redes responsable, la fecha prevista de prueba y la fecha en que se retirará la excepción.

La excepción no debe convertirse en sustituto del mantenimiento de endpoints. Si el problema es una regla del proxy, corrige la regla del proxy. Si el problema está en la CSP de una pestaña personalizada, corrige la respuesta de la aplicación. Si se trata de una integración de terceros, solicita a su responsable una ruta de migración compatible y documenta la respuesta.

Cuando una aplicación crítica para el negocio no pueda validarse a tiempo, separa el riesgo. Mantén la excepción tan limitada como permita el control disponible, monitoriza el flujo afectado y comunica la fecha de finalización al responsable del servicio. El objetivo es conservar la continuidad y mantener visible la migración.

Por qué esto es un cambio de infraestructura

Un proveedor SaaS puede cambiar un nombre de host sin modificar la funcionalidad visible para el usuario. Para el cliente, sin embargo, un nombre de host forma parte del contrato de servicio que aplican las redes, los navegadores y las aplicaciones. La dirección determina qué política coincide, qué certificado se inspecciona, qué cookies se envían, qué origen se considera de confianza y qué registros identifican el tráfico.

Por eso las migraciones de dominio merecen la misma disciplina ligera que otros cambios de producción. Debe haber un responsable, una matriz de pruebas, un plan de reversión o mitigación, una actualización de la monitorización y un canal de comunicación. No hace falta convertirlo en un proyecto grande. Sí hace falta que alguien verifique el recorrido completo en lugar de suponer que la redirección será transparente en todas partes.

El cambio también ilustra una transformación en las operaciones cloud. Los endpoints de los servicios ya no son un apéndice estático que se mantiene una vez durante el despliegue. Microsoft afirma que sus datos de endpoints cambian a medida que evolucionan los servicios y que pueden actualizarse fuera de la cadencia normal cuando las circunstancias operativas lo exigen. Las organizaciones que consumen esos datos automáticamente pueden reducir el retraso manual, pero la automatización también necesita revisión: un flujo puede actualizar un firewall mientras la CSP de la aplicación y el manual operativo permanecen sin cambios.

Una lista breve para septiembre

• Confirma si la organización utiliza Teams en el navegador.
• Revisa MC1465764 en el Centro de administración de Microsoft 365 e identifica el estado del despliegue del inquilino.
• Confirma que teams.cloud.microsoft y los endpoints pertinentes de *.cloud.microsoft estén permitidos por la política de red documentada.
• Prueba desde las rutas de oficina, VPN, acceso remoto, escritorio virtual y navegador administrado.
• Sigue la redirección y verifica el inicio de sesión, las reuniones, los archivos y las pestañas críticas de Teams.
• Revisa el filtrado DNS, las reglas del proxy, la inspección TLS y las políticas de confianza o cookies del navegador.
• Pide a los responsables de aplicaciones que comprueben TeamsJS, CSP frame-ancestors, validación de origen, manifiestos y URI de redirección.
• Actualiza la monitorización sintética, la documentación y las instrucciones del centro de ayuda.
• Registra cualquier excepción temporal de redirección con un responsable y una fecha de retirada anterior al 31 de diciembre de 2026.

La migración web de Teams será sencilla en un navegador no administrado y puede tener consecuencias en una empresa gestionada. La respuesta adecuada no es un cambio de emergencia amplio en el firewall. Es una validación breve y basada en evidencias del nuevo endpoint a través de las rutas reales que siguen los usuarios y las aplicaciones. Cuando ese trabajo termine, la redirección debería ser lo que Microsoft pretende: un cambio de dirección, no un cambio de disponibilidad.

Fuentes

El cambio, las fechas, los endpoints, las recomendaciones para aplicaciones integradas y las políticas de navegador se atribuyen en el artículo a los avisos y la documentación de Microsoft citados en el material de referencia, incluido el aviso MC1465764, la documentación de URL y rangos de direcciones IP de Microsoft 365, los requisitos para pestañas de Teams, la guía de resolución de problemas de inicio de sesión y la explicación del dominio unificado cloud.microsoft.