Reuniones sensibles en Teams: cómo protegerlas sin frenar al resto de la empresa

PorSebastian
Opciones de una reunión de junta directiva en Teams con el requisito de acceso «solo equipos de la empresa» seleccionado

Una junta directiva, una negociación de fusión o una reunión con los abogados de un litigio se hacen hoy en la misma plataforma que la reunión semanal de equipo, y con la misma protección. Hasta ahora, exigir controles más estrictos para las reuniones sensibles de Teams obligaba a elegir entre dos malas opciones. Una era endurecer la política para todo Teams, con el costo en fricción para todos los usuarios. La otra era dejar la reunión crítica protegida igual que una de rutina.

Microsoft anunció en el Message Center el cambio que elimina ese dilema: Conditional Access granular para reuniones de Teams (MC1532256, publicado el 30 de octubre de 2026). En este artículo explicamos qué cambia y cuándo llega. Sobre todo, explicamos cómo dejar su tenant listo para proteger sus reuniones sensibles apenas la función esté disponible, y dónde está el valor real del control para no aplicar requisitos que no protegen nada.

Qué anunció Microsoft y cuándo llega

Según el Message Center, la función permite aplicar controles de acceso a reuniones específicas. El administrador pone a disposición requisitos de autenticación aprobados. El organizador puede exigir una verificación adicional para su reunión, como autenticación multifactor (MFA), cumplimiento del dispositivo o controles basados en ubicación. Los participantes deben cumplir la política aplicable antes de unirse a la reunión protegida.

El calendario publicado para el despliegue mundial es el siguiente:

  • Vista previa pública: inicia a finales de noviembre de 2026 y se espera que termine también a finales de noviembre.
  • Disponibilidad general: inicia a principios de enero de 2027 y se espera que termine a finales de enero de 2027.

Un punto de honestidad técnica: la función aún no está liberada. La documentación de PowerShell de Microsoft lo indica para los dos parámetros clave: el que publica los contextos en Teams y el que habilita la verificación en la política de reuniones. En ambos casos dice que la función no se ha liberado por completo y que el ajuste todavía no tiene efecto. Hoy se puede preparar el terreno, pero no probar el resultado final.

Cómo funciona: contextos de autenticación

El mecanismo se apoya en los contextos de autenticación de Microsoft Entra. Un contexto de autenticación sirve para proteger datos y acciones dentro de una aplicación, con políticas más granulares que las que se aplican a la aplicación completa. Piense en él como una etiqueta (por ejemplo, c1) a la que se asocia una política de Conditional Access. Cuando un recurso o una acción lleva esa etiqueta, el usuario debe cumplir la política vinculada.

La idea de fondo, según Microsoft, es que la mayor parte de la aplicación funcione con menos fricción y que el requisito solo se eleve cuando se accede a algo más sensible. Es exactamente lo que se busca con una reunión de junta directiva frente a una reunión semanal de equipo.

Dos datos de diseño que conviene tener presentes. Cada organización puede crear hasta 99 contextos (de c1 a c99). Y Microsoft recomienda usar nombres reutilizables, como «dispositivos de confianza», para reducir el número de contextos necesarios y mejorar la experiencia del usuario.

Dónde está el valor real del control

Antes de configurar nada, conviene responder una pregunta: ¿qué capacidad concreta le quita este control a un atacante? La respuesta depende del requisito que se elija.

Microsoft recomienda que toda organización tenga una política base de MFA para todos los usuarios y todos los recursos. Si su tenant ya la tiene, el usuario interno entra a Teams con una sesión que ya completó MFA. Un contexto que solo exija «MFA» probablemente se cumpla sin pedirle nada nuevo, porque Conditional Access evalúa los claims de esa sesión. Ese contexto da sensación de seguridad, pero agrega poco. (Esta es nuestra interpretación de cómo Conditional Access evalúa los claims; recomendamos confirmarla durante la vista previa).

El valor está en los requisitos que la MFA base no ofrece:

  • MFA resistente a phishing, mediante una fortaleza de autenticación (authentication strength). Protege contra el robo de sesión con proxies de phishing tipo AiTM, que hoy evaden la MFA tradicional.
  • Dispositivo compatible. Impide que alguien con credenciales válidas, propias o robadas, se una desde un equipo no administrado.
  • Ubicación de confianza. Útil en casos puntuales, pero con un costo operativo alto, como veremos más adelante.

Diseñe sus contextos alrededor de estos tres requisitos, no alrededor de «más MFA».

Antes de empezar

  • Licenciamiento: Conditional Access requiere Microsoft Entra ID P1. Los clientes con Microsoft 365 Business Premium también pueden usarlo, lo que cubre a buena parte de las empresas medianas de la región. El mensaje MC1532256 no menciona licencias adicionales para esta función.
  • Línea base de MFA: los contextos elevan el requisito para reuniones puntuales, pero no reemplazan la base. Microsoft recomienda una política de MFA para todos los usuarios y todos los recursos, sin exclusiones de recursos.
  • Catálogo de requisitos: defina cuántos niveles de protección necesita realmente. Un punto de partida razonable, alineado con los ejemplos de la guía de Microsoft, son tres contextos: MFA resistente a phishing, dispositivo compatible y ubicación de confianza.
  • Organizadores: identifique quiénes organizan reuniones sensibles (dirección general, finanzas, legal, seguridad). Esa lista decidirá a quién se asigna la política de reuniones en el paso 3.
  • Participantes externos: liste con qué organizaciones externas se reúnen esos organizadores (bufetes, auditores, asesores). Esa lista será necesaria en el paso 4.

Paso 1: crear los contextos de autenticación y sus políticas en Entra

Este es el trabajo de fondo y se puede hacer hoy.

  1. En el centro de administración de Microsoft Entra, vaya a Entra ID > Conditional Access > Authentication context y seleccione New authentication context.
  2. Asigne un nombre y una descripción claros, marque Publish to apps y confirme el ID (c1 a c99). Si no marca la publicación, el contexto no estará disponible para los recursos que dependen de él.
  3. Cree una política de Conditional Access. En Assignments > Target resources, seleccione Authentication context en el menú «Select what this policy applies to» y elija el contexto creado.
  4. Defina los usuarios y los controles de acceso de ese nivel. Por ejemplo, exigir la fortaleza de autenticación resistente a phishing, exigir un dispositivo compatible o limitar el acceso a ubicaciones de confianza.
  5. Siempre que sea posible, empiece en modo solo informe (report-only) y revise los registros de inicio de sesión antes de activar la política.

Una restricción a tener en cuenta: un contexto de autenticación funciona con usuarios o con identidades de carga de trabajo, pero no con ambos en la misma política.

Paso 2: publicar los contextos en Teams

Los contextos se publican en la configuración de reuniones de Teams con el parámetro PublishedEntraAuthenticationContexts del cmdlet Set-CsTeamsMeetingConfiguration. Según la documentación:

  • Cada entrada requiere el Id del contexto (de c1 a c99).
  • Opcionalmente se puede definir un PublishedName (máximo 50 caracteres) y un PublishedDescription (máximo 150 caracteres).
  • El nombre y la descripción originales de Entra se capturan al momento de publicar; si usted envía valores para esos campos, se ignoran.
  • La configuración de reuniones es única para el tenant: el único valor válido de identidad es Global.

Recomendación de GFS (no es un requisito de Microsoft): use nombres publicados que describan el requisito en lenguaje del organizador, no códigos internos. «Solo equipos de la empresa» se entiende mejor que «c2 – Compliant». La documentación actual todavía no detalla la ruta equivalente en el centro de administración de Teams, por eso no la incluimos aquí. Actualizaremos este artículo cuando la vista previa esté disponible.

Paso 3: decidir quién puede proteger reuniones

El requisito se habilita con el parámetro ConditionalAccessAttendeeVerification de las políticas de reuniones (New-CsTeamsMeetingPolicy y Set-CsTeamsMeetingPolicy). Según Microsoft:

  • Con $true, los contextos publicados quedan disponibles para que el organizador los seleccione. En las opciones de la reunión, el valor por defecto es «None».
  • Con $false, se deshabilita la aplicación de contextos de autenticación en las reuniones que organiza ese usuario.
  • El valor predeterminado documentado es $true.

Ese último punto es el que más importa. La política Global aplica a todos los usuarios que no tienen una política personalizada. Por eso, cuando la función se libere, todos los organizadores del tenant verán la opción, aunque por defecto marque «None». Crear una política personalizada para el grupo sensible no limita a nadie más por sí sola.

Hay dos caminos válidos, con trade-offs distintos:

  • Dejar la opción abierta a todos (Global en $true). El riesgo de seguridad es bajo, porque el organizador solo puede endurecer el acceso, nunca relajarlo. El costo es de soporte: cualquier organizador puede elegir «ubicación de confianza» para una reunión con externos y dejarlos fuera sin entender por qué.
  • Restringir la opción a los organizadores sensibles. Ponga la política Global en $false y asigne al grupo de organizadores sensibles una política personalizada con $true. Es el camino que recomendamos para empezar, porque permite capacitar a un grupo pequeño antes de abrir la función a toda la organización.

Este es un criterio de diseño de GFS InfoSec, no una recomendación de Microsoft.

Paso 4: preparar a los participantes externos

Las reuniones que más justifican este control (litigios, fusiones y adquisiciones, auditorías) son también las que más participantes externos tienen. Aquí está el error de diseño más probable.

El dispositivo de un abogado externo no lo administra su tenant. Si el contexto exige dispositivo compatible, ese invitado solo podrá cumplirlo si su organización confía en el cumplimiento de dispositivos del tenant de origen del invitado. Esa confianza se configura en External Identities > Cross-tenant access settings, con la opción de confianza entrante Trust compliant devices. Existe una opción equivalente para confiar en la MFA hecha en el tenant de origen. Ambas pueden activarse para todas las organizaciones o solo para organizaciones específicas.

Sin esa configuración, el participante externo no podrá cumplir el requisito y terminará en la sala de espera, que es justo donde no debería decidirse quién entra (lo vemos en la siguiente sección). Nuestra recomendación es configurar la confianza solo para las organizaciones con las que realmente se reúnen los organizadores sensibles, no para todas.

Dos matices que la documentación actual no resuelve y que deben validarse en la vista previa:

  • No está documentado si los usuarios externos que se unen por acceso externo (federación de Teams) pasan por esta evaluación igual que los invitados B2B.
  • Los participantes anónimos no tienen identidad en Entra. Lo razonable es esperar que no puedan cumplir ningún contexto. Si sus reuniones sensibles no deben admitir anónimos, bloquéelos en la política de reuniones de esos organizadores, en lugar de depender de este control.

Qué verá el participante que no cumple el requisito

Si un participante no cumple los requisitos de la reunión, la documentación indica que se le pedirá elegir entre reintentar la obtención del token o unirse a la sala de espera, si esta está habilitada.

Aquí el control puede anularse sin que nadie lo note. Si el participante que no cumple pasa a la sala de espera y alguien lo admite, la reunión protegida termina teniendo dentro a alguien que no cumplió la política. Nuestra recomendación de diseño es la siguiente:

  • En las políticas de reuniones de los organizadores sensibles, limite quién puede admitir desde la sala de espera a organizadores y coorganizadores.
  • Explique a esos organizadores que un participante en la sala de espera de una reunión protegida es una señal para verificar su identidad por otro canal, no un trámite.

Esta es una recomendación de GFS InfoSec, no una afirmación de la documentación de Microsoft sobre el comportamiento final.

¿Qué reuniones proteger primero?

Una buena regla es empezar por donde el costo de que entre alguien indebido es mayor que la fricción de un paso adicional:

  • Juntas directivas y comités ejecutivos: MFA resistente a phishing. Si ya existe la MFA base, un contexto que solo exija MFA aporta poco.
  • Cierres financieros, fusiones y adquisiciones: dispositivo compatible, para reducir el riesgo de que el contenido compartido termine en equipos no administrados. Si participan asesores externos, configure antes la confianza entre tenants (paso 4).
  • Reuniones legales y de litigios: dispositivo compatible y MFA resistente a phishing, con la misma advertencia sobre los abogados externos.
  • Salas de crisis y respuesta a incidentes: MFA resistente a phishing y, solo si la operación lo permite, ubicación de confianza. Cuidado con este último control: puede bloquear a ejecutivos o equipos que atienden el incidente desde fuera de la oficina, justo cuando más se los necesita.
  • Reuniones de recursos humanos con información sensible de personal: dispositivo compatible.

Estas sugerencias son criterio de GFS InfoSec, no requisitos de Microsoft. El principio es el mismo que aplicamos en toda administración segura de Microsoft 365: el control más fuerte donde el riesgo lo justifica, y elegido por lo que realmente impide, no por cómo suena.

Qué validar durante la vista previa

La documentación revisada no cubre todos los escenarios. Antes de desplegar de forma amplia, pruebe en un grupo piloto:

  • Si un contexto que solo exige MFA genera un nuevo desafío o se cumple con la MFA ya hecha en la sesión.
  • Cómo se comportan los invitados B2B, los usuarios de acceso externo y los participantes anónimos, con y sin la confianza entre tenants configurada.
  • Participantes que se unen por teléfono (PSTN).
  • Salas y dispositivos de Teams Rooms: Microsoft documenta que algunos controles de Conditional Access no son compatibles con estos dispositivos; confirme cuáles aplican a este caso.
  • Los clientes que usa su organización (escritorio, web y móvil).
  • Los registros de inicio de sesión en Entra, para comprobar que la política del contexto se evalúa como se espera.

Conclusión

Las reuniones sensibles ya no tienen que elegir entre la misma protección que todo lo demás o una fricción que nadie tolera, siempre que se elija el requisito correcto. La preparación es concreta:

  • Definir los niveles de protección según lo que realmente impide cada uno.
  • Crear los contextos y sus políticas en Entra.
  • Publicarlos en Teams.
  • Decidir de forma deliberada qué organizadores pueden usarlos.
  • Preparar la confianza con las organizaciones externas que participan en las reuniones sensibles.

Hacerlo antes de la vista previa de finales de noviembre le da tiempo de probar con calma y llegar a la disponibilidad general de enero de 2027 con un diseño ya validado.

En GFS InfoSec ayudamos a organizaciones de Panamá y Latinoamérica a diseñar y operar este tipo de controles dentro de nuestro servicio de administración segura de Microsoft 365. Si desea que revisemos su configuración de Conditional Access y las políticas de reuniones de Teams, escríbanos a través de gfsinfosec.com.

Lecturas relacionadas en nuestro blog: Named Locations en Microsoft Entra ID y Protección de tokens disponible para Microsoft Entra ID P1.

Fuentes

Consultadas el 9 de noviembre de 2026. Los nombres de los parámetros y la funcionalidad de la vista previa pueden cambiar hasta la disponibilidad general.

Publicaciones Similares