MFA adaptativa como estándar NIS2 en 2026: cómo la guía de ENISA aclaró la cláusula where-appropriate

NIS2 exige autenticación multifactor (MFA) «where appropriate» y en Alemania el mandato de ejecución del BSI entra en su fase operativa en mayo de 2026. La pregunta central para los responsables de seguridad y cumplimiento normativo no es «tenemos MFA», sino «tenemos la MFA correcta en los lugares correctos con una justificación de riesgo documentada». Quien en 2026 aún mantenga un inventario de MFA genérico tendrá una no conformidad abierta en la auditoría del BSI.

TL;DR: La MFA adaptativa se convierte en el estándar de cumplimiento NIS2 en 2026

• NIS2 §2(j) exige MFA o autenticación continua «where appropriate». La guía de ENISA del Q1 2026 ha aclarado que «appropriate» no significa «opcional», sino una evaluación de riesgo documentada por clase de cuenta.
• El mandato de ejecución del BSI entra en su fase operativa en Alemania en mayo de 2026; Bélgica se adelantó el 18 de abril de 2026. Las primeras auditorías se iniciarán a partir del Q3 de 2026, principalmente en los sectores de energía, salud, administración, banca, telecomunicaciones e ingeniería de plantas.
• La MFA adaptativa (autenticación basada en riesgo con señales de contexto en lugar de MFA genérica) es en 2026 el camino pragmático. Reduce la fricción del usuario entre un 40 y un 70 por ciento y proporciona al mismo tiempo una mejor pista de auditoría.
• Tres bloques constructivos son relevantes para el BSI en 2026: inventario de riesgo de identidad con clasificación de cuentas, motor de MFA adaptativa con señales de contexto y registro de auditoría con profundidad forense durante al menos 12 meses.
• Quien establezca ahora una arquitectura de cumplimiento sólida evitará en 2027 los riesgos de multas de hasta 10 millones de euros y se posicionará al mismo tiempo para la próxima oleada de resiliencia DORA.

Lo que la guía ENISA Q1 2026 ha aclarado sobre la cláusula «where appropriate»

La cláusula «where appropriate» de la NIS2 ha generado confusión desde la aprobación de la directiva en 2022. Muchos responsables de cumplimiento la han interpretado como un margen de discrecionalidad en el que la organización puede decidir por sí misma dónde es conveniente la MFA. La guía de ENISA del primer trimestre de 2026 ha rechazado claramente esta interpretación. «Where appropriate» significa que la organización debe presentar una evaluación de riesgo documentada por clase de cuenta, en la que se justifique para cada clase por qué se aplica la MFA o por qué no se aplica. Un inventario del tipo «tenemos MFA en Outlook» ya no es suficiente en 2026.

El requisito estructural es: inventario de riesgo de identidad. Cada clase de cuenta (cuenta de empleado, cuenta de administrador, cuenta de servicio, acceso externo de proveedor, cuenta de emergencia, cuenta de máquina) debe figurar en una tabla con evaluación de riesgo, mecanismo de MFA, justificación y fecha de revisión. La guía de ENISA menciona explícitamente el acceso privilegiado (Admin-Accounts), el acceso remoto y las cuentas externas de proveedores como áreas en las que la MFA es prácticamente siempre «appropriate». Quien no tenga MFA para estas clases tendrá una no conformidad en la auditoría del BSI.

Las obligaciones de mensajería NIS2 de abril de 2026 muestran hasta qué punto la arquitectura de cumplimiento de 2026 entra en el detalle. La MFA es uno de los bloques constructivos centrales, ya que influye directamente tanto en la seguridad de identidad como en la capacidad forense ante incidentes.

Por qué la MFA adaptativa es el camino pragmático

La MFA generalizada para todas las cuentas suena segura en principio, pero en la práctica presenta dos problemas: fricción para el usuario y debilidad en la auditoría. La fricción genera comportamientos de evasión (aceptación de push bombing, rutas débiles de restablecimiento de contraseña, cuentas en la sombra) que pueden reducir la seguridad de forma neta. La debilidad en la auditoría surge porque la MFA generalizada no ofrece auditoría contextual, es decir, no diferencia si un inicio de sesión proviene de una combinación inusual o de una configuración estándar.

La MFA adaptativa resuelve ambos problemas. Utiliza señales de contexto (identidad del dispositivo, ubicación, hora del día, perfiles de comportamiento, sensibilidad de los recursos) y decide para cada intento de inicio de sesión qué nivel de MFA se aplica. Para un acceso estándar desde el perfil de dispositivo registrado basta con un segundo factor simple. Para un acceso desde una ubicación desconocida o con un perfil de comportamiento inusual se activa un factor reforzado (clave de hardware FIDO2, confirmación biométrica) o un nivel adicional de step-up. El resultado: menos fricción en los accesos estándar, mayor seguridad en los accesos de riesgo y una traza de auditoría notablemente mejor.

En dos mandatos DACH de los últimos seis meses, el cambio de MFA generalizada a adaptativa redujo el número de prompts diarios de MFA entre un 40 y un 70 por ciento, al tiempo que multiplicó por tres a cinco la detección de inicios de sesión sospechosos. Desde el punto de vista económico, la decisión no está impulsada únicamente por el cumplimiento normativo, sino también por la experiencia de usuario y la seguridad. Los focos de MFA adaptativa de abril de 2026 muestran la eficacia operativa frente a vectores de ataque actuales como el device-code phishing.

Tres bloques de cumplimiento que deben estar en la arquitectura NIS2 de 2026

Bloque 1: inventario de riesgos de identidad con clasificación de cuentas. El primer bloque es una tabla de todas las clases de cuentas de la organización, con número, evaluación de riesgo (bajo, medio, alto, crítico), mecanismo de MFA, justificación de la elección y fecha de revisión. En una auditoría NIS2 este documento es el primero que se examina. Quien no lo tiene genera de inmediato un hallazgo abierto. Quien lo tiene pero muestra cuentas privilegiadas sin MFA robusta, también. Un inventario riguroso lleva entre cuatro y ocho semanas en una empresa mediana con 250 a 1.000 empleados.

Bloque 2: motor de MFA adaptativa con señales de contexto. El segundo bloque es la capa técnica de MFA. Las opciones disponibles en el mercado en 2026 son Microsoft Entra ID Conditional Access, Okta Adaptive MFA, Cisco Duo Beyond, Ping Identity o soluciones especializadas como Silverfort y Rublon. La elección depende del stack de identidad existente, pero los requisitos centrales son idénticos: motor de políticas basado en riesgo, soporte de FIDO2 y WebAuthn, mecanismos de step-up y registros auditables. Quien no migre este bloque a lógica adaptativa en los próximos 12 meses asumirá un nivel de seguridad y cumplimiento neto inferior.

Bloque 3: traza de auditoría con profundidad forense. El tercer bloque es el que se subestima con más frecuencia. NIS2 no solo exige la aplicación de MFA, sino su trazabilidad durante al menos 12 meses. Quien en caso de incidente no pueda reconstruir qué inicio de sesión se realizó con qué factor, cuándo y desde dónde, tiene a la vez un problema forense y un problema de cumplimiento. La arquitectura de la traza de auditoría debe ir más allá del registro del proveedor de identidad y agregar los logs en un sistema centralizado e inviolable (SIEM, repositorio de auditoría dedicado). La obligación de conservación en 2026 no se limita a 12 meses, sino que se extiende a 24 o 36 meses para los sectores críticos.

Cómo es en la práctica un plan de cumplimiento de 90 días

En la práctica consultora se ha consolidado un plan de 90 días que implementa los tres componentes en el orden correcto. Días 1 a 30: inventario de riesgos de identidad. Registro de todas las clases de cuentas, evaluación de riesgos, análisis de brechas frente al artículo NIS2 §2(j) y la guía ENISA. Resultado: tabla de riesgos de identidad con una lista de acciones clara. Días 31 a 60: decisión de arquitectura de MFA adaptativa. Análisis de mercado, prueba de concepto con dos soluciones, decisión de arquitectura con IT, seguridad, RRHH y protección de datos. Resultado: decisión de arquitectura con plan de despliegue. Días 61 a 90: despliegue piloto para cuentas privilegiadas y acceso remoto. Formación paralela a los usuarios, vías de escalada ante fricciones, endurecimiento progresivo de la política. Resultado: informe piloto con hoja de ruta de expansión a todas las clases de cuentas.

Quien complete sistemáticamente este plan de 90 días estará, a finales del tercer trimestre de 2026, en una posición en la que la auditoría del BSI encontrará cumplidos los requisitos esenciales. Quien no lo complete tendrá que subsanar los hallazgos abiertos durante la fase de auditoría a partir del Q3 de 2026, frecuentemente bajo presión de tiempo y con costes más elevados.

¿Qué ocurre si la auditoría del BSI detecta deficiencias?

La lógica de escalada del control del BSI contempla un procedimiento en tres niveles. Primer nivel: requerimientos con plazo (habitualmente de tres a seis meses) para subsanar las deficiencias. Segundo nivel: multa por incumplimiento de los requerimientos, con un marco de hasta 10 millones de euros o el 2 por ciento de la facturación anual mundial. Tercer nivel: responsabilidad personal de la dirección con patrimonio privado, si se han vulnerado de forma reconocible los deberes de diligencia. Los primeros casos de multa en los procedimientos predecesores de NIS1 han demostrado que el BSI puede aplicar el marco completo ante fallos de MFA en cuentas privilegiadas cuando la deficiencia se califica como gravemente negligente. La inversión en arquitectura de MFA adaptativa con pista de auditoría es siempre económicamente racional en comparación con el importe de las multas.

Cómo DORA endurece adicionalmente los requisitos de MFA

Para las entidades financieras, DORA añade una capa adicional. DORA exige resiliencia operativa y prescribe explícitamente en sus disposiciones de gestión de riesgos TIC la MFA para accesos privilegiados y sesiones remotas. Mientras NIS2 utiliza la lógica del «cuando proceda», el requisito de DORA es más estricto: la MFA privilegiada es obligación, no opción. Los bancos, aseguradoras y proveedores TIC terceros críticos deben cumplir en 2026 no solo la lógica de NIS2, sino también el rigor de DORA en paralelo. La línea DORA-2 de la FCA del Reino Unido de abril de 2026 proporciona la directriz regulatoria de resiliencia operativa complementaria. Quien configure su arquitectura NIS2 de forma compatible con DORA resuelve la doble capa de cumplimiento de una sola vez.

Cuáles son los hallazgos de auditoría típicos en 2026

De los primeros talleres de pre-auditoría con responsables de seguridad de empresas medianas se pueden identificar cuatro hallazgos recurrentes que en una auditoría real del BSI derivarán en requerimientos. Primero: cuentas de servicio sin MFA y sin rotación de secretos. En la mayoría de las empresas DACH existen entre 30 y 200 cuentas de servicio con contraseñas estándar que no se han rotado en años. Son la vía de escalada número uno para los atacantes y suponen un hallazgo abierto en la auditoría. Segundo: accesos externos de proveedores sin MFA robusta. Los accesos de mantenimiento de fabricantes de maquinaria, proveedores de TI y suministradores de software funcionan habitualmente sin FIDO2 ni tokens de hardware. Tercero: cuentas de emergencia sin procedimientos documentados. Quien disponga de cuentas break-glass debe documentar por escrito los procedimientos de activación y desactivación y presentarlos en la auditoría. Cuarto: consolas de administración cloud sin MFA de step-up para operaciones sensibles. Microsoft Azure Privileged Identity Management, AWS IAM Identity Center y Google Cloud Privileged Access Manager ofrecen las herramientas necesarias, pero solo se utilizan de forma consistente en la mitad de los entornos DACH.

Quien elimine sistemáticamente estos cuatro hallazgos antes de la primera auditoría del BSI ya se situará en la mitad superior de madurez en cumplimiento. Por experiencia, la resolución en un entorno de empresa mediana lleva entre ocho y dieciséis semanas, dependiendo del grado de fragmentación del ecosistema de cuentas de servicio. Quien aún no haya abordado el tema en 2026 debería reservar la próxima ronda de hoja de ruta de seguridad para ello.

Qué papel juega la MFA resistente al phishing

Un aspecto central de la guía ENISA del Q1 2026 es la recomendación de métodos de MFA resistentes al phishing para los accesos privilegiados. Las notificaciones push estándar y los OTP por SMS son comprometibles mediante herramientas de phishing como Evilginx, Modlishka o el toolkit Tycoon-2FA documentado en una oleada en abril de 2026. Las llaves hardware FIDO2, las passkeys y la autenticación biométrica con origin binding se consideran, en cambio, resistentes al phishing. Para accesos privilegiados y sesiones remotas la recomendación de 2026 es clara: únicamente factores resistentes al phishing. En la arquitectura NIS2, el inventario debería por tanto documentar el estado de resistencia al phishing de cada clase privilegiada. Quien aún utilice SMS o MFA push para cuentas de administrador tiene en 2026 un riesgo residual reconocible que con frecuencia se aborda directamente en la conversación de auditoría.

Desde el punto de vista operativo, la transición a llaves hardware FIDO2 o passkeys merece la pena especialmente para las clases de usuarios privilegiados, ya que estos usuarios son conscientes de la seguridad y no perciben la fricción adicional como una carga. Para clases amplias de empleados, la passkey es la variante ergonómicamente más elegante, porque no requiere hardware adicional y se integra sin fricciones con los dispositivos modernos. Una estrategia mixta (llaves hardware para administradores, passkeys para la plantilla, aplicaciones TOTP clásicas como factor de transición para accesos legacy) es en 2026 el camino pragmático y cumple plenamente la guía ENISA.

Preguntas frecuentes

Red: Seguir leyendo en Security Today

• Práctica operativa del informe de incidentes sanitarios de abril de 2026
• Obligaciones NIS2 para mensajería en el informe de cumplimiento WhatsApp-Signal
• MFA adaptativo contra 7 millones de intentos de phishing por device code

Fuente de la imagen de portada: Pexels / Dan Nelson (px:4973899)

Sobre el autor: Benedikt Langer

Más artículos de Benedikt Langer