En vigor desde el 17 oct 2024·Día 571·

Medidas técnicas11 may. 20267 min

Autenticación multifactor NIS2: 5 clases de acceso obligatorias

La autenticación multifactor NIS2 ya no es opcional. El artículo 21(2)(j) la nombra; el Reglamento 2024/2690 indica qué factores superan una inspección.

Autenticación multifactor NIS2: 5 clases de acceso obligatoriasMedidas técnicas

El artículo 21 de la Directiva (UE) 2022/2555 enumera las medidas de ciberseguridad que toda entidad NIS2 debe aplicar. El punto (j) nombra explícitamente una de ellas: la autenticación multifactor. Dieciocho meses después de su entrada en vigor, la autenticación multifactor NIS2 ha dejado de ser una «buena práctica» para convertirse en una obligación legal — y el Reglamento de Ejecución (UE) 2024/2690 ha aclarado qué factores superarán una inspección y cuáles no.

El desplazamiento no está en el sustantivo. Está en el adjetivo. El anexo del Reglamento de Ejecución alinea NIS2 con el consenso de supervisión posterior a 2023 que comparten ENISA, ANSSI y BSI: el multifactor es necesario pero ya no suficiente. La referencia pasa a ser la autenticación resistente al phishing — una categoría que la directiva no nombra, pero hacia la que el reglamento de ejecución, las autoridades nacionales y la práctica de supervisión convergen. Los consejos que aprueben un plan del artículo 21 en 2026 heredan ese juicio.

1. Lo que el artículo 21(2)(j) exige realmente

El artículo 21(2)(j) exige «soluciones de autenticación multifactor o de autenticación continua, comunicaciones de voz, vídeo y texto seguras». La redacción es breve y el ámbito amplio. Se aplica a toda entidad de los dieciocho sectores cubiertos por la directiva, no solo a las que tratan datos personales, no solo a las que ofrecen un servicio al público.

Dos expresiones cargan la obligación. Autenticación continua — el Reglamento de Ejecución precisa que se refiere a una revalidación a nivel de sesión, no solo al inicio de sesión inicial. Soluciones — en plural, señal de que un único método no cubre todas las clases de acceso. La decisión MFA no es una casilla en la consola IAM. Es un programa que asocia la fuerza del factor al nivel de riesgo, en toda la superficie de acceso de la entidad.

El mismo artículo hace al órgano de dirección — es decir, al consejo — responsable de aprobar la política resultante. Véase las cinco responsabilidades del consejo que los administradores no pueden delegar para el encuadre de gobernanza.

2. Las cinco clases de acceso que deben llevar MFA

El Reglamento de Ejecución 2024/2690 no enumera literalmente «cinco clases». Su anexo construye la exigencia combinando los principios del artículo 21 con la base técnica. Traducido a la superficie que un CISO defiende realmente:

  1. Acceso administrativo — administrador de dominio, raíz de nube, hipervisor, CLI de equipos de red. Toda sesión privilegiada, en cualquier sistema, en cada entrada. Sin excepciones para «redes de confianza» — la segmentación es un control de contención, no un control de autenticación.
  2. Acceso remoto — VPN, RDP, servidores de salto, SSH desde fuera del perímetro de la entidad. La oleada de supervisión 2024 de ANSSI y BSI singulariza esta categoría — la mayoría del ransomware que termina en una notificación de 72 horas entró por un acceso remoto sin proteger.
  3. Acceso a aplicaciones expuestas — correo web, portales de cliente con funciones administrativas o financieras, interfaces de servicio público. Clientes y ciudadanos, no solo empleados.
  4. Acceso a datos sensibles — bases de datos de producción, sistemas financieros, historiales clínicos, repositorios de código fuente. La frontera no es «la red interna» — es la frontera de rol de la aplicación.
  5. Interfaces CI/CD e infraestructura como código — Git en el orquestador de build, claves de despliegue, gestor de secretos. Es una categoría más joven y menos codificada, pero un ataque a la cadena de suministro exitoso entra por ahí cada vez más a menudo. La misma lógica que justifica las cláusulas NIS2 para los contratos de proveedores críticos se extiende a las pipelines internas.

Cuando un supervisor pregunta «¿dónde se aplica el MFA?», la respuesta debe ser una lista, no «en todas partes». La lista es el artefacto de auditoría.

3. Por qué SMS y TOTP ya no bastan por sí solos

El anexo del Reglamento de Ejecución no menciona SMS ni TOTP por su nombre. Remite la especificación técnica al «estado de la técnica», fórmula que la directiva usa de forma deliberada para mantenerse vigente. Leído en 2026, el estado de la técnica para las clases de acceso de alto riesgo es la autenticación resistente al phishing: llaves de seguridad FIDO2 / WebAuthn, autenticadores de plataforma con attestation (Windows Hello for Business, Touch ID de macOS con attestation, Android reciente con strong-box) y passkeys sincronizadas mediante nubes con attestation del proveedor.

Multifactor es la palabra de la directiva. Resistente al phishing es la palabra de toda guía de supervisión publicada desde 2023. Las entidades NIS2 deben planificar sobre la segunda.

Las recomendaciones de autenticación de la ANSSI (Recommandations relatives à l'authentification multifacteur, 2023), el control ORP.4.A23 del IT-Grundschutz del BSI y las publicaciones de la ENISA sobre gestión de identidad convergen: los códigos SMS son vulnerables al SIM swap y a la interceptación SS7; las aplicaciones TOTP protegen frente al phishing solo si el usuario advierte un dominio incorrecto. Para los accesos administrativos y remotos, ninguno de esos factores alcanza el listón implícito de «estado de la técnica» que aplicará una autoridad en 2026.

La consecuencia práctica: el plan de despliegue hereda una arquitectura objetivo. Resistente al phishing para las tres primeras clases (administrativo, remoto, aplicaciones administrativas expuestas), TOTP tolerado como control transitorio para la cuarta (acceso a datos sensibles por empleados no privilegiados), SMS fuera del perímetro antes de fin del próximo ciclo presupuestario. La SP 800-63B Digital Identity Guidelines del NIST — formalmente una norma estadounidense, pero la referencia internacional para los niveles de garantía de autenticación — aporta la granularidad para documentar estas decisiones.

4. El rastro de auditoría que un supervisor lee

Una inspección NIS2 rara vez pide ver la configuración del proveedor de identidad. Pide el rastro de auditoría. Tres artefactos aparecen sistemáticamente en los informes de inspección publicados por BSI y ACN:

  • La política de autenticación aprobada por el consejo. Un documento — no una página de wiki — que define la fuerza del factor por clase de acceso, lista las excepciones y sus controles compensatorios, y está firmado en la fecha de la última revisión.
  • El registro de alta de factores. Una lista, por sistema, de las cuentas con un factor MFA dado de alta, el tipo de factor y la fecha de alta. El registro responde a «¿está el MFA realmente activo?» — no a «¿es exigible?», cosa que una política sola no puede demostrar.
  • El registro de excepciones. Todo sistema en el que no se aplica MFA — terminales industriales heredados, cuentas de servicio con autenticación por certificado — queda nombrado, con motivo, control compensatorio y fecha de retirada planificada. Las excepciones abiertas con más de doce meses son una bandera roja para el supervisor.

La referencia a la revisión independiente anual del programa de seguridad en nuestra guía de las 21 medidas del artículo 21 cierra el bucle — el auditor lee esos tres documentos e informa al consejo. Sin ellos, el control técnico es invisible para el regulador.

5. Desplegar sin romper la operación

El modo de fallo de un despliegue MFA no es la elección de factor. Es el bloqueo — una cuenta privilegiada que pierde el acceso a su segundo factor en el peor momento. Tres medidas extraídas de las guías publicadas reducen ese riesgo:

  • Dos factores de dos tipos distintos para cada cuenta administrativa, el segundo factor guardado fuera de línea y accesible al equipo de respuesta a incidentes en un plazo de dos horas.
  • Alta por fases, por clase de acceso, no por población de usuarios. Acceso administrativo primero (población pequeña, impacto alto), aplicaciones expuestas en segundo lugar, acceso a datos sensibles en último lugar. La lista de comprobación de autoevaluación NIS2 marca el orden que implica la matriz de clasificación del regulador.
  • Procedimientos de break-glass preparados, documentados y probados cada año. La propia cuenta break-glass se vigila en cada uso; un uso que no corresponde a un cambio planificado se trata como un incidente significativo en el sentido del artículo 23 y se notifica.

El patrón de supervisión observado en 2026 no es punitivo respecto a la velocidad de despliegue — siempre que exista la documentación. Las entidades que en 2027 sigan usando SMS para accesos administrativos mantendrán una conversación distinta.

Cómo es cuando está bien hecho

Tres señales aparecen una y otra vez en los informes de inspección publicados por las autoridades nacionales que han compartido su metodología de aplicación:

  1. Una política de autenticación aprobada por el consejo — versionada, fechada, firmada al amparo del artículo 20 de la directiva, que distingue la fuerza del factor por clase de acceso con las excepciones nombradas.
  2. Un registro de alta vivo — exportado del proveedor de identidad a la plataforma GRC de la entidad, refrescado al menos mensualmente, con una cobertura del 100 % de las cuentas administrativas y de acceso remoto.
  3. Un plan de retirada de factores débiles — fechas de obsolescencia de SMS y TOTP no atestado comprometidas por escrito, con un informe trimestral de avance al consejo.

Ninguno de estos documentos exige nueva tecnología. Exigen que los controles que ya están en producción se pongan por escrito — antes de que lo pida el supervisor.


Fuentes

  1. Directiva (UE) 2022/2555, artículo 21(2)(j) (medidas para la gestión de riesgos de ciberseguridad).
  2. Reglamento de Ejecución (UE) 2024/2690 de la Comisión de 17 de octubre de 2024 (requisitos técnicos y metodológicos).
  3. ENISA — Identity Management for Electronic Identification (citada por nombre).
  4. ANSSI — Recommandations relatives à l'authentification multifacteur et aux mots de passe (2023).
  5. BSI — IT-Grundschutz-Kompendium, control ORP.4.A23 (autenticación multifactor para acceso administrativo).
  6. NIST — Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management.