NIS2 comunicaciones seguras: la mitad del artículo 21(2)(j) que la mayoría de los programas omite

Entre febrero y junio de 2026, Sophos siguió una campaña a la que llama STAC4749. Los atacantes crearon cuentas de Microsoft Teams en dominios con apariencia de TI, llamaron a empleados haciéndose pasar por el helpdesk y los convencieron de abrir una sesión de Quick Assist. Al menos tres de esas intrusiones terminaron en el ransomware Chaos. Una pasó de la primera llamada de Teams a archivos cifrados en menos de 17 horas.

Pregúntese ahora qué usaron esas organizaciones para coordinar su respuesta. Teams. Outlook. El mismo tenant en el que el atacante ya había entrado.

Ese es el problema que los requisitos de comunicaciones seguras de NIS2 existen para resolver. El artículo 21(2)(j) es la medida que lo cubre, y es la mitad de ese artículo que la mayoría de los programas de cumplimiento nunca implementa.

El artículo 21(2)(j) tiene dos mitades, y la mayoría de los programas solo construye una

La redacción de la directiva es breve: «el uso de soluciones de autenticación multifactor o de autenticación continua, comunicaciones de voz, vídeo y texto seguras y sistemas de comunicación de emergencia seguros dentro de la entidad, cuando proceda».

Todo el mundo lee la primera parte. La MFA recibe presupuesto, un proyecto y una línea en el informe al consejo. A principios de año explicamos por qué la MFA por sí sola ya no supera una auditoría.

La segunda parte se ignora. Contiene dos obligaciones distintas: asegurar sus canales cotidianos de voz, vídeo y texto, y disponer de un sistema de comunicación de emergencia que siga funcionando cuando los canales cotidianos no lo hagan.

«Cuando proceda» no es una cláusula de escape. Es un calificador basado en el riesgo. Si decide que un control no procede, la decisión debe constar en la evaluación de riesgos con su justificación. Un auditor trata el silencio como una brecha, no como una decisión.

Artículo 21 — 10 Medidas de Ciberseguridad NIS2
🛡️
Artículo 21
10 Medidas de Ciberseguridad
📊
Gobernanza & Estrategia
1Análisis de riesgos & políticas de seguridad de la información
6Evaluación de la eficacia de las medidas de seguridad
🚨
Incidentes & Continuidad
2Gestión de incidentes & notificación
3Continuidad del negocio & recuperación ante desastres
🔗
Cadena de Suministro & Sistemas
4Seguridad de la cadena de suministro
5Seguridad en el desarrollo de sistemas de redes e información
🔐
Controles Técnicos
8Criptografía & cifrado
10Autenticación multifactor & comunicaciones seguras
👥
Personas & Activos
7Ciberhigiene & formación
9Seguridad de RRHH & control de acceso

El reglamento de ejecución dispersa el requisito en cinco secciones

El Reglamento de Ejecución (UE) 2024/2690 de la Comisión es el manual detallado para infraestructura digital, gestión de servicios TIC y proveedores digitales. Eso significa que los MSP y MSSP entran en él directamente. Las autoridades nacionales de otros sectores lo usan como referencia de lo que significa «apropiado».

No contiene ninguna sección llamada «comunicaciones seguras». Búsquela y concluirá que la obligación es escasa. No lo es. Está repartida:

El punto 3.5.3 exige planes y procedimientos de comunicación para la respuesta a incidentes: con el CSIRT o la autoridad competente, entre su propio personal y con las partes interesadas externas.

El punto 4.1.2(c) exige que el plan de continuidad de negocio y recuperación ante desastres enumere los contactos clave y los canales de comunicación internos y externos.

El punto 4.2.4(d) exige redundancia al menos parcial de «canales de comunicación apropiados», junto con la redundancia de sistemas, instalaciones y personal.

El punto 4.3.2(b) exige que el proceso de gestión de crisis defina los medios de comunicación con las autoridades competentes, tanto para las notificaciones obligatorias como para los intercambios no obligatorios.

Los puntos 6.7.2(i) y (k) exigen canales de confianza aislados entre sistemas y un plan de implementación de estándares modernos de comunicación por correo electrónico.

El punto 11.7 cubre la mitad de MFA.

La consecuencia práctica: un auditor no preguntará «¿tienen comunicaciones seguras?». Pedirá su procedimiento de respuesta a incidentes, su plan de continuidad y recuperación y su proceso de gestión de crisis, y buscará el canal de comunicación en cada uno. Si la respuesta en los tres es «correo y Teams», el hallazgo se escribe solo.

Su respuesta a incidentes corre sobre el sistema en el que está el atacante

Asuma el compromiso. No es paranoia, es comportamiento documentado.

Microsoft y CISA describen cómo Octo Tempest, más conocido como Scattered Spider, busca en el Slack, Teams y Exchange Online de la víctima conversaciones sobre su propia intrusión, y se une a las llamadas de respuesta a incidentes para saber cómo lo están cazando los defensores. En junio de 2026, se observó a afiliados de DragonForce enrutando tráfico de mando y control a través de relays legítimos de Microsoft Teams para mezclarse con el tráfico de colaboración normal.

Si el atacante tiene una cuenta privilegiada de Entra ID, cada canal que se autentica contra Entra ID es suyo para leer. Incluido el canal de Teams «de respaldo» que creó para el equipo de crisis.

Un sistema de comunicación de emergencia supera tres pruebas:

Identidad separada. No se autentica a través de su proveedor de identidad principal. Si el SSO le da acceso, un SSO comprometido se lo da al atacante.

Infraestructura separada. No está alojado en el mismo tenant, en el mismo dominio ni detrás del mismo DNS que quizá tenga que apagar.

Aprovisionado de antemano y ensayado. La lista de contactos existe sin conexión, las cuentas existen antes del incidente y el canal se ha usado en una prueba. El punto 4.1.4 exige que los planes de continuidad y recuperación se prueben a intervalos planificados. El canal de emergencia forma parte de ese plan, así que forma parte de esa prueba.

En la práctica esto no es caro. Un grupo de Signal o Threema en dispositivos gestionados por MDM con cuentas no vinculadas al SSO corporativo. Una tarjeta de contactos impresa en la carpeta de crisis. Un buzón de emergencia en otro proveedor. El coste no está en la herramienta. El coste está en la disciplina de mantenerlo al día.

Otro detalle que se pasa por alto: la alerta temprana de 24 horas del artículo 23 tiene que llegar a su CSIRT incluso cuando lo que está caído es su servidor de correo. Los datos de contacto que dio al registro nacional de entidades al registrarse son los que el CSIRT usará para devolverle la llamada. Si es un buzón en el tenant comprometido, tiene un problema de notificación además de un problema de seguridad. El procedimiento de gestión de incidentes debe nombrar explícitamente la ruta alternativa hacia el CSIRT.

Cronología de Notificación de Incidentes NIS2
24h
⚡
Alerta Temprana
Notifique a la autoridad competente (CSIRT/ANC) en las 24 horas siguientes a tener conocimiento de un incidente significativo.
Paso 1
72h
📋
Notificación de Incidente
Presente una notificación detallada en 72 horas con una evaluación inicial de la gravedad, el impacto y los indicadores de compromiso.
Paso 2
1mo
📊
Informe Final
Entregue un informe final completo en el plazo de un mes que cubra la causa raíz, las medidas adoptadas y el impacto transfronterizo.
Paso 3
24h
⚡
Alerta Temprana
Notifique a la autoridad competente (CSIRT/ANC) en las 24 horas siguientes a tener conocimiento de un incidente significativo.
72h
📋
Notificación de Incidente
Presente una notificación detallada en 72 horas con una evaluación inicial de la gravedad, el impacto y los indicadores de compromiso.
1mo
📊
Informe Final
Entregue un informe final completo en el plazo de un mes que cubra la causa raíz, las medidas adoptadas y el impacto transfronterizo.

NIS2 comunicaciones seguras es un estándar de configuración, no una compra de producto

Teams, Google Meet y Zoom cifran en tránsito. Nadie suspende una auditoría porque sus videollamadas no estén cifradas. La pregunta que realmente plantea el reglamento es: ¿quién puede llegar a su gente, por qué canales y bajo qué controles?

Traduzca eso en ajustes concretos y el panorama se aclara.

Acceso externo. STAC4749 y la campaña de Black Basta anterior dependían de que cuentas externas de Teams pudieran escribir y llamar a empleados. Restringir la federación externa a una lista de dominios socios permitidos, o bloquear el chat y las llamadas externas para la mayoría de los usuarios, elimina el punto de entrada. El punto 6.7.2(c) ya exige impedir la comunicación de red no necesaria para la operación. Esta es la versión de esa regla en la capa de colaboración.

Autenticación del correo. El punto 6.7.2(k) pide un plan de implementación de «estándares modernos de comunicación por correo electrónico acordados internacionalmente e interoperables». La guía técnica de implementación de ENISA de junio de 2025 apunta a SPF, DKIM y DMARC para la autenticación del remitente y a MTA-STS o DANE para el cifrado del transporte. Un registro DMARC en p=none es monitorización, no protección. Los auditores ya conocen la diferencia.

Herramientas aprobadas por clasificación. Su política de criptografía bajo el artículo 21(2)(h) debe indicar qué herramientas de mensajería y videoconferencia están aprobadas para cada nivel de clasificación de activos. Un consejo que discute un incidente por WhatsApp en teléfonos personales es un hallazgo, porque no hay política que lo permita ni control que lo gobierne.

Higiene de reuniones. Sala de espera activada, acceso autenticado a reuniones internas, compartir pantalla y grabar solo el anfitrión, y una regla de que nadie es anónimo en una llamada de crisis.

Voz. Troncales SIP y VoIP sobre TLS y SRTP y, en las sedes donde importa, capacidad de llamadas de emergencia que no dependa de que la red corporativa funcione.

Nada de esto exige comprar un producto nuevo. Todo exige que alguien sea dueño de la configuración y pueda exportar la evidencia.

Lo que un auditor pedirá realmente

Las autoridades de supervisión han empezado a pedir paquetes de evidencias en lugar de declaraciones de política. Cubrimos la lista general de evidencias hace dos semanas. Para el artículo 21(2)(j), espere estos ocho elementos:

1. La sección de comunicación del procedimiento de respuesta a incidentes, con canales principales y alternativos y sus responsables.
2. La sección de contactos clave y canales del plan de continuidad y recuperación, fechada dentro del ciclo de revisión vigente.
3. Una declaración de redundancia de canales de comunicación según el punto 4.2.4(d).
4. Un registro de prueba que demuestre que el canal de emergencia se usó en un ejercicio.
5. Una exportación de la configuración de acceso externo de Teams o Google Workspace.
6. Registros DNS de DMARC, MTA-STS y, donde se use, DANE.
7. La lista de herramientas de comunicación aprobadas, vinculada a los niveles de clasificación de activos.
8. Las entradas de la evaluación de riesgos que justifican cualquier decisión de «no procede».

Si puede producir los ocho en un día, ha terminado con esta medida. Si puede producir tres, ya sabe dónde empieza el análisis de brechas.

Para los MSP, esta medida aplica dos veces

Un MSP es una entidad de gestión de servicios TIC bajo el anexo I de NIS2. El Reglamento 2024/2690 le aplica directamente. Esa es su propia obligación.

Luego está el lado del cliente. La política de seguridad de la cadena de suministro de cada cliente, bajo el punto 5.1, debe evaluar las prácticas de ciberseguridad de sus proveedores de servicios. Su capacidad de comunicarse con un cliente durante un incidente, por un canal que no sea el tenant comprometido del cliente ni su propio tenant comprometido, es una de esas prácticas.

Plantee este escenario: su RMM o su tenant de M365 está comprometido. Cuarenta clientes tienen que enterarse en cuestión de horas. Su correo es precisamente lo que está comprometido. ¿Cuál es la lista, dónde está y quién la tiene en un teléfono que no se sincroniza con el SSO corporativo?

Si no hay respuesta, ese es el primer punto de su propio plan de remediación. La Cyberbeveiligingswet neerlandesa está en vigor desde el 15 de agosto de 2026, y la RDI supervisa directamente la gestión de servicios TIC. El BSI alemán y el CCB belga llevan más tiempo haciéndolo. La doble obligación de los MSP ya no es teórica en ninguno de esos mercados.

Escalada de sanciones NIS2 — Más allá de la multa
!
Desencadenante
Incumplimiento detectado o incidente ocurrido
Una autoridad supervisora identifica una brecha de cumplimiento o una organización no cumple los requisitos NIS2
Las autoridades pueden imponer
▼
Sanciones no financieras
1
Órdenes de cumplimiento con plazos vinculantes
2
Auditorías de seguridad obligatorias a tu cargo
3
Divulgación pública de infracciones
4
Instrucciones vinculantes sobre medidas de seguridad específicas
Escala hacia
▼
Consecuencias operativas y personales
1
Suspensión de certificaciones o licencias de operación
2
Prohibición temporal de funciones directivas para individuos
3
Identificación pública de personas físicas responsables
Desencadenante
No financiero
Operativo / personal

Por dónde empezar este mes

Esto no es un proyecto con comité de dirección. Son cuatro tareas.

Elija el canal de emergencia y aprovisiónelo. Identidad separada, infraestructura separada, lista de contactos guardada sin conexión.

Póngalo por escrito. Añada el canal al procedimiento de respuesta a incidentes bajo 3.5.3 y a la sección de contactos clave del plan de continuidad y recuperación bajo 4.1.2(c).

Cierre la puerta principal. Restrinja la federación externa en Teams. Pase DMARC a p=reject cuando los informes confirmen sus remitentes legítimos.

Pruébelo. El primer mensaje de su próximo ejercicio de simulación sale solo por el canal de emergencia. Si nadie lo ve, ha aprendido algo importante en un momento oportuno.

Si quiere saber dónde se sitúa el artículo 21(2)(j) junto a las otras nueve medidas para un cliente concreto, el quick scan de NIS2Certify cubre las diez en unos diez minutos y le entrega una lista priorizada de brechas con la que trabajar.