MFA conforme al Artículo 21(2)(j) NIS 2
NIS 2 convierte la autenticación multifactor en un deber propio. El Artículo 21(2)(j) es donde reside la obligación, el CIR (UE) 2024/2690 §11.7 dice dónde y cuán fuerte, y el §30(2)(10) BSIG la incorpora al Derecho alemán.
La versión corta
La MFA no es opcional y no es solo algo deseable. El Artículo 21(2)(j) la sitúa en la lista de las diez medidas de ciberseguridad que toda entidad esencial e importante tiene que implantar. La misma redacción cubre también las comunicaciones de voz, vídeo y texto seguras y, donde importa, las comunicaciones de emergencia seguras dentro de su organización.
El CIR (UE) 2024/2690 §11.7 completa el detalle. Los usuarios deben autenticarse con múltiples factores o con autenticación continua cuando la clasificación del activo al que acceden así lo exija. La fortaleza de la autenticación tiene que corresponderse con esa clasificación. Las joyas de la corona necesitan una autenticación más fuerte que un portal de la carta de la cafetería.
El CIR §11.3.2 fija después un suelo firme bajo las cuentas privilegiadas. Por defecto deben existir procedimientos sólidos de identificación, autenticación y autorización (la autenticación multifactor es el ejemplo que nombra el CIR) para las cuentas privilegiadas y de administración de sistemas. Alemania traslada el deber a través del §30(2)(10) BSIG con una redacción casi idéntica.
Artículo 21(2)(j) Directiva NIS 2 (2022/2555)
el uso de soluciones de autenticación multifactor o de autenticación continua, comunicaciones de voz, vídeo y texto seguras y sistemas seguros de comunicación de emergencia en el seno de la entidad, según proceda.
El punto (j) de la lista de las diez medidas de ciberseguridad. Hace dos cosas a la vez: nombra la MFA (o la autenticación continua) como estándar de control de acceso, e incorpora al mismo deber las comunicaciones internas seguras de voz, vídeo, texto y emergencia.
CIR (UE) 2024/2690, Anexo §11.7 y §11.3
Las entidades pertinentes velarán por que los usuarios se autentiquen utilizando múltiples factores de autenticación o mecanismos de autenticación continua para acceder a las redes y los sistemas de información de las entidades pertinentes, según proceda, de conformidad con la clasificación del activo al que se vaya a acceder.
El §11 es el capítulo de control de acceso del CIR y cubre el Artículo 21(2)(i) y (j) conjuntamente. El §11.7 es la subsección específica de MFA. El §11.3.2(a) va más allá para las cuentas privilegiadas y de administración: se exigen procedimientos sólidos de identificación, autenticación (la MFA se nombra como ejemplo) y autorización. Como el CIR es un reglamento, es Derecho de la UE directamente vinculante para los sectores nombrados en su Anexo.
§30(2)(10) BSIG (Alemania)
el uso de soluciones de autenticación multifactor o de autenticación continua, comunicaciones de voz, vídeo y texto seguras y sistemas seguros de comunicación de emergencia en el seno de la entidad, según proceda.
Alemania copia el texto de la UE casi palabra por palabra. La operacionalización práctica en Alemania apunta al baustein ORP.4 de IT-Grundschutz (gestión de identidades y accesos), que es el catálogo de referencia del BSI para hacer bien la autenticación en la operación.
MFA adecuada a la clasificación del activo
Los usuarios se autentican con múltiples factores o con autenticación continua para acceder a sus redes y sistemas de información, calibrado según la clasificación del activo al que llegan. La condición previa implícita: ha clasificado sus activos. Sin una clasificación no puede cumplir la regla.
Cuentas privilegiadas: MFA por defecto
Para las cuentas privilegiadas y para las cuentas de administración de sistemas, son obligatorias una identificación, una autenticación y una autorización sólidas. El CIR nombra la autenticación multifactor como ejemplo concreto. Este es el único lugar donde la MFA deja de estar condicionada a la clasificación y se convierte en el estado por defecto.
La fortaleza de la autenticación se corresponde con la clasificación
La fortaleza de la autenticación tiene que ser adecuada a la clasificación del activo al que se accede. Ese es el segundo test. La MFA no es una sola cosa. El SMS, el TOTP basado en app, la aprobación por push, las claves de hardware FIDO2 y la autenticación basada en certificados se sitúan en peldaños muy distintos. Cuanto mayor sea la clasificación, mayor es el peldaño que necesita.
Comunicaciones seguras, no solo MFA (Artículo 21(2)(j))
El punto (j) es más amplio que la autenticación. Nombra las comunicaciones seguras de voz, vídeo y texto, y los sistemas de comunicación de emergencia dentro de la entidad, según proceda. Un despliegue de MFA por sí solo no cierra la obligación. La videoconferencia interna, la mensajería y cualquier canal de emergencia fuera de banda están dentro del mismo deber.
La clasificación del activo determina la profundidad (Artículo 21(1))
El Artículo 21(1) exige que las medidas sean adecuadas y proporcionadas. El CIR lo convierte en un test concreto para la MFA: la clasificación del activo fija la fortaleza. Un pequeño Stadtwerk no necesita claves de hardware FIDO2 para cada portal interno. Un jump host de un sistema de control es otra conversación distinta. La clasificación es la palanca, no el tamaño de la empresa por sí solo.
BSI / §30(2)(10) BSIG
Alemania copia la redacción de la UE casi literalmente en el §30(2)(10) BSIG. La referencia de implementación del BSI es el baustein ORP.4 de IT-Grundschutz (gestión de identidades y accesos), que da requisitos concretos para la emisión de credenciales, la MFA, la separación de cuentas privilegiadas y el acceso de emergencia. Si implementa ORP.4 correctamente, está dentro del deber del §30(2)(10).
Guía técnica de implementación de ENISA
La TIG de ENISA para el CIR recorre el §11 en lenguaje operativo llano y lo mapea sobre la ISO/IEC 27001:2022, el NIST CSF 2.0, la ETSI EN 319 401 y la CEN/TS 18026:2024. Si ya ejecuta ISO 27001 (controles A.5.16, A.5.17, A.8.5) tiene la mayor parte del camino hecho. La TIG también enumera la evidencia que esperan los auditores: política de MFA, clasificación de cuentas, registros de alta, registro de excepciones.
Leyes nacionales de transposición
Cada Estado miembro tiene su propia transposición de NIS 2 (Países Bajos: Cyberbeveiligingswet, Austria: NISG, Bélgica: NIS2-Wet). El deber de MFA en sí es idéntico porque reside en la directiva y en el CIR. Lo que difiere entre países: el catálogo de referencia (Grundschutz en Alemania, BIO en los Países Bajos, ningún catálogo formal en otros lugares), el canal de notificación y la autoridad de supervisión.
Tenemos MFA en la VPN, así que hemos terminado.
La MFA de la VPN es una vía de acceso. El CIR §11.7 trata del acceso a los activos en función de su clasificación, no de un dispositivo perimetral. Si un usuario privilegiado puede alcanzar un controlador de dominio, una consola de copias de seguridad, una consola de administración en la nube o un tenant SaaS sin MFA, el deber no se cumple. La clasificación del activo que hay detrás de la puerta es el test, no la puerta por la que entró.
La MFA basada en SMS sirve para todo el mundo.
El CIR §11.7.2 dice que la fortaleza de la autenticación debe corresponderse con la clasificación. El SMS y el OTP por voz son el factor más débil: el intercambio de SIM, la interceptación SS7 y el phishing los derrotan todos. Para el acceso interno ordinario el auditor puede aceptarlo. Para las joyas de la corona (consolas de administración, sistemas de control, proveedores de identidad) necesita autenticación resistente al phishing (FIDO2 / WebAuthn / smartcard). La fortaleza debe escalar con la clasificación.
Las cuentas de servicio y de sistema no necesitan MFA.
El CIR §11.3.2(a) cubre expresamente las cuentas privilegiadas y las cuentas de administración de sistemas. Las cuentas de servicio quedan fuera del alcance de la MFA humana solo si están correctamente clasificadas y usan un control sólido distinto (identidades gestionadas, credenciales de vida corta, certificados firmados, secretos emitidos por bóveda con rotación). 'Cuenta de servicio, no puede hacer MFA, exenta' no es una defensa. O está accionada por humanos (entonces MFA), o está accionada por máquinas (entonces un modelo documentado de credenciales de máquina).
La mayoría de los equipos del Mittelstand alemán empiezan en el mismo punto: MFA en cada cuenta de administrador primero (consolas de administración en la nube, admin de dominio, hipervisor, copias de seguridad, equipos de red, tenants SaaS), luego MFA en el correo, después MFA en el proveedor de identidad para todos los usuarios humanos. Eso cubre el suelo del §11.3.2 y las filas de alta clasificación de un solo movimiento. El resto se despliega a todos los usuarios humanos sobre activos clasificados dentro del primer año.
Lo que los auditores abren realmente: la lista de clasificación de activos, el informe de alta de MFA de su proveedor de identidad y el registro de excepciones. Si esos tres encajan, el deber se cumple. El hueco más profundo que vemos no es técnico, es documental: falta la clasificación de activos, así que no hay regla sobre qué activos justifican qué fortaleza de autenticación. Arregle primero la clasificación y luego el despliegue de MFA se lee solo de la lista.
El módulo ACC (control de acceso) de la plataforma lleva el deber del §11 de principio a fin. Registra los activos con su clasificación, enumera qué grupos de usuarios necesitan acceso y documenta la fortaleza de autenticación de cada fila. La misma tabla responde tanto al test del §11.7.1 (MFA según proceda) como al del §11.7.2 (la fortaleza se corresponde con la clasificación), y destaca por separado las filas de cuentas privilegiadas del §11.3.2.
La aprobación del inventario de control de acceso es nominal. Las excepciones (el sistema heredado que aún no puede hacer MFA, la integración que tiene que usar una cuenta de servicio) viven en el mismo registro con un control compensatorio documentado y una fecha de revisión. El rastro de auditoría y la exportación de evidencia de la plataforma dan al auditor los artefactos que nombra la TIG de ENISA: política, clasificación, registro de altas, registro de excepciones, todo en un mismo lugar.
- Directiva (UE) 2022/2555 (NIS 2), Artículo 21(2)(j) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Reglamento de Ejecución (UE) 2024/2690 de la Comisión (CIR), Anexo §11.3 y §11.7 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Ley del BSI (BSIG), §30(2)(10) en su redacción dada por la Ley de Implementación de NIS2 y de Refuerzo de la Ciberseguridad
- BSI IT-Grundschutz, Baustein ORP.4 'Identitäts- und Berechtigungsmanagement'
- Guía técnica de implementación de ENISA para el CIR (UE) 2024/2690 (a fecha de mayo de 2026)