{"id":13152,"date":"2026-04-25T07:28:36","date_gmt":"2026-04-25T07:28:36","guid":{"rendered":"https:\/\/www.securitytoday.de\/2026\/04\/25\/mfa-adaptiva-cumplimiento-nis2-guia-enisa-bsi-auditoria\/"},"modified":"2026-05-20T20:28:30","modified_gmt":"2026-05-20T20:28:30","slug":"mfa-adaptiva-cumplimiento-nis2-guia-enisa-bsi-auditoria","status":"publish","type":"post","link":"https:\/\/www.securitytoday.de\/es\/2026\/04\/25\/mfa-adaptiva-cumplimiento-nis2-guia-enisa-bsi-auditoria\/","title":{"rendered":"MFA adaptativa como est\u00e1ndar NIS2 en 2026: c\u00f3mo la gu\u00eda de ENISA aclar\u00f3 la cl\u00e1usula where-appropriate"},"content":{"rendered":"\n<p><strong>NIS2 exige autenticaci\u00f3n multifactor (MFA) \u00abwhere appropriate\u00bb y en Alemania el mandato de ejecuci\u00f3n del BSI entra en su fase operativa en mayo de 2026. La pregunta central para los responsables de seguridad y cumplimiento normativo no es \u00abtenemos MFA\u00bb, sino \u00abtenemos la MFA correcta en los lugares correctos con una justificaci\u00f3n de riesgo documentada\u00bb. Quien en 2026 a\u00fan mantenga un inventario de MFA gen\u00e9rico tendr\u00e1 una no conformidad abierta en la auditor\u00eda del BSI.<\/strong><\/p>\n\n<div style=\"background:#0a1e3d;color:#fff;border-left:4px solid #69d8ed;padding:8px 14px;margin:14px 0;font-size:14px;\">5 min. de lectura<\/div>\n\n<h2 style=\"color:#0a1e3d;padding-top:64px;margin-bottom:20px;\">TL;DR: La MFA adaptativa se convierte en el est\u00e1ndar de cumplimiento NIS2 en 2026<\/h2>\n<ul>\n<li>NIS2 \u00a72(j) exige MFA o autenticaci\u00f3n continua \u00abwhere appropriate\u00bb. La gu\u00eda de ENISA del Q1 2026 ha aclarado que \u00abappropriate\u00bb no significa \u00abopcional\u00bb, sino una evaluaci\u00f3n de riesgo documentada por clase de cuenta.<\/li>\n<li>El mandato de ejecuci\u00f3n del BSI entra en su fase operativa en Alemania en mayo de 2026; B\u00e9lgica se adelant\u00f3 el 18 de abril de 2026. Las primeras auditor\u00edas se iniciar\u00e1n a partir del Q3 de 2026, principalmente en los sectores de energ\u00eda, salud, administraci\u00f3n, banca, telecomunicaciones e ingenier\u00eda de plantas.<\/li>\n<li>La MFA adaptativa (autenticaci\u00f3n basada en riesgo con se\u00f1ales de contexto en lugar de MFA gen\u00e9rica) es en 2026 el camino pragm\u00e1tico. Reduce la fricci\u00f3n del usuario entre un 40 y un 70 por ciento y proporciona al mismo tiempo una mejor pista de auditor\u00eda.<\/li>\n<li>Tres bloques constructivos son relevantes para el BSI en 2026: inventario de riesgo de identidad con clasificaci\u00f3n de cuentas, motor de MFA adaptativa con se\u00f1ales de contexto y registro de auditor\u00eda con profundidad forense durante al menos 12 meses.<\/li>\n<li>Quien establezca ahora una arquitectura de cumplimiento s\u00f3lida evitar\u00e1 en 2027 los riesgos de multas de hasta 10 millones de euros y se posicionar\u00e1 al mismo tiempo para la pr\u00f3xima oleada de resiliencia DORA.<\/li>\n<\/ul>\n\n<h2 style=\"color:#0a1e3d;padding-top:64px;margin-bottom:20px;\">Lo que la gu\u00eda ENISA Q1 2026 ha aclarado sobre la cl\u00e1usula \u00abwhere appropriate\u00bb<\/h2>\n\n<p style=\"line-height:1.8;\">La cl\u00e1usula \u00abwhere appropriate\u00bb de la NIS2 ha generado confusi\u00f3n desde la aprobaci\u00f3n de la directiva en 2022. Muchos responsables de cumplimiento la han interpretado como un margen de discrecionalidad en el que la organizaci\u00f3n puede decidir por s\u00ed misma d\u00f3nde es conveniente la MFA. La gu\u00eda de ENISA del primer trimestre de 2026 ha rechazado claramente esta interpretaci\u00f3n. \u00abWhere appropriate\u00bb significa que la organizaci\u00f3n debe presentar una evaluaci\u00f3n de riesgo documentada por clase de cuenta, en la que se justifique para cada clase por qu\u00e9 se aplica la MFA o por qu\u00e9 no se aplica. Un inventario del tipo \u00abtenemos MFA en Outlook\u00bb ya no es suficiente en 2026.<\/p>\n\n<p style=\"line-height:1.8;\">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\u00e1quina) debe figurar en una tabla con evaluaci\u00f3n de riesgo, mecanismo de MFA, justificaci\u00f3n y fecha de revisi\u00f3n. La gu\u00eda de ENISA menciona expl\u00edcitamente el acceso privilegiado (Admin-Accounts), el acceso remoto y las cuentas externas de proveedores como \u00e1reas en las que la MFA es pr\u00e1cticamente siempre \u00abappropriate\u00bb. Quien no tenga MFA para estas clases tendr\u00e1 una no conformidad en la auditor\u00eda del BSI.<\/p>\n\n<p style=\"line-height:1.8;\">Las <a href=\"https:\/\/www.securitytoday.de\/es\/2026\/04\/25\/whatsapp-signal-nis2-dora-responsabilidad-mensajeria-mdm\/\">obligaciones de mensajer\u00eda NIS2 de abril de 2026<\/a> muestran hasta qu\u00e9 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.<\/p>\n<h2 style=\"color:#0a1e3d;padding-top:64px;margin-bottom:20px;\">Por qu\u00e9 la MFA adaptativa es el camino pragm\u00e1tico<\/h2>\n\n<p style=\"line-height:1.8;\">La MFA generalizada para todas las cuentas suena segura en principio, pero en la pr\u00e1ctica presenta dos problemas: fricci\u00f3n para el usuario y debilidad en la auditor\u00eda. La fricci\u00f3n genera comportamientos de evasi\u00f3n (aceptaci\u00f3n de push bombing, rutas d\u00e9biles de restablecimiento de contrase\u00f1a, cuentas en la sombra) que pueden reducir la seguridad de forma neta. La debilidad en la auditor\u00eda surge porque la MFA generalizada no ofrece auditor\u00eda contextual, es decir, no diferencia si un inicio de sesi\u00f3n proviene de una combinaci\u00f3n inusual o de una configuraci\u00f3n est\u00e1ndar.<\/p>\n\n<p style=\"line-height:1.8;\">La MFA adaptativa resuelve ambos problemas. Utiliza se\u00f1ales de contexto (identidad del dispositivo, ubicaci\u00f3n, hora del d\u00eda, perfiles de comportamiento, sensibilidad de los recursos) y decide para cada intento de inicio de sesi\u00f3n qu\u00e9 nivel de MFA se aplica. Para un acceso est\u00e1ndar desde el perfil de dispositivo registrado basta con un segundo factor simple. Para un acceso desde una ubicaci\u00f3n desconocida o con un perfil de comportamiento inusual se activa un factor reforzado (clave de hardware FIDO2, confirmaci\u00f3n biom\u00e9trica) o un nivel adicional de step-up. El resultado: menos fricci\u00f3n en los accesos est\u00e1ndar, mayor seguridad en los accesos de riesgo y una traza de auditor\u00eda notablemente mejor.<\/p>\n\n<p style=\"line-height:1.8;\">En dos mandatos DACH de los \u00faltimos seis meses, el cambio de MFA generalizada a adaptativa redujo el n\u00famero de prompts diarios de MFA entre un 40 y un 70 por ciento, al tiempo que multiplic\u00f3 por tres a cinco la detecci\u00f3n de inicios de sesi\u00f3n sospechosos. Desde el punto de vista econ\u00f3mico, la decisi\u00f3n no est\u00e1 impulsada \u00fanicamente por el cumplimiento normativo, sino tambi\u00e9n por la experiencia de usuario y la seguridad. Los <a href=\"https:\/\/www.securitytoday.de\/es\/2026\/04\/24\/mfa-adaptativa-bajo-ataque-por-que-los-motores-de-riesgo-no-detectan-la-ola-de-7-millones-de-codigos-de-dispositivo\/\">focos de MFA adaptativa de abril de 2026<\/a> muestran la eficacia operativa frente a vectores de ataque actuales como el device-code phishing.<\/p>\n\n<h2 style=\"color:#0a1e3d;padding-top:64px;margin-bottom:20px;\">Tres bloques de cumplimiento que deben estar en la arquitectura NIS2 de 2026<\/h2>\n\n<p style=\"line-height:1.8;\"><strong>Bloque 1: inventario de riesgos de identidad con clasificaci\u00f3n de cuentas.<\/strong> El primer bloque es una tabla de todas las clases de cuentas de la organizaci\u00f3n, con n\u00famero, evaluaci\u00f3n de riesgo (bajo, medio, alto, cr\u00edtico), mecanismo de MFA, justificaci\u00f3n de la elecci\u00f3n y fecha de revisi\u00f3n. En una auditor\u00eda 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\u00e9n. Un inventario riguroso lleva entre cuatro y ocho semanas en una empresa mediana con 250 a 1.000 empleados.<\/p>\n\n<p style=\"line-height:1.8;\"><strong>Bloque 2: motor de MFA adaptativa con se\u00f1ales de contexto.<\/strong> El segundo bloque es la capa t\u00e9cnica 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\u00f3n depende del stack de identidad existente, pero los requisitos centrales son id\u00e9nticos: motor de pol\u00edticas basado en riesgo, soporte de FIDO2 y WebAuthn, mecanismos de step-up y registros auditables. Quien no migre este bloque a l\u00f3gica adaptativa en los pr\u00f3ximos 12 meses asumir\u00e1 un nivel de seguridad y cumplimiento neto inferior.<\/p>\n\n<p style=\"line-height:1.8;\"><strong>Bloque 3: traza de auditor\u00eda con profundidad forense.<\/strong> El tercer bloque es el que se subestima con m\u00e1s frecuencia. NIS2 no solo exige la aplicaci\u00f3n de MFA, sino su trazabilidad durante al menos 12 meses. Quien en caso de incidente no pueda reconstruir qu\u00e9 inicio de sesi\u00f3n se realiz\u00f3 con qu\u00e9 factor, cu\u00e1ndo y desde d\u00f3nde, tiene a la vez un problema forense y un problema de cumplimiento. La arquitectura de la traza de auditor\u00eda debe ir m\u00e1s all\u00e1 del registro del proveedor de identidad y agregar los logs en un sistema centralizado e inviolable (SIEM, repositorio de auditor\u00eda dedicado). La obligaci\u00f3n de conservaci\u00f3n en 2026 no se limita a 12 meses, sino que se extiende a 24 o 36 meses para los sectores cr\u00edticos.<\/p>\n<h2 style=\"color:#0a1e3d;padding-top:64px;margin-bottom:20px;\">C\u00f3mo es en la pr\u00e1ctica un plan de cumplimiento de 90 d\u00edas<\/h2>\n\n<p style=\"line-height:1.8;\">En la pr\u00e1ctica consultora se ha consolidado un plan de 90 d\u00edas que implementa los tres componentes en el orden correcto. D\u00edas 1 a 30: inventario de riesgos de identidad. Registro de todas las clases de cuentas, evaluaci\u00f3n de riesgos, an\u00e1lisis de brechas frente al art\u00edculo NIS2 \u00a72(j) y la gu\u00eda ENISA. Resultado: tabla de riesgos de identidad con una lista de acciones clara. D\u00edas 31 a 60: decisi\u00f3n de arquitectura de MFA adaptativa. An\u00e1lisis de mercado, prueba de concepto con dos soluciones, decisi\u00f3n de arquitectura con IT, seguridad, RRHH y protecci\u00f3n de datos. Resultado: decisi\u00f3n de arquitectura con plan de despliegue. D\u00edas 61 a 90: despliegue piloto para cuentas privilegiadas y acceso remoto. Formaci\u00f3n paralela a los usuarios, v\u00edas de escalada ante fricciones, endurecimiento progresivo de la pol\u00edtica. Resultado: informe piloto con hoja de ruta de expansi\u00f3n a todas las clases de cuentas.<\/p>\n\n<p style=\"line-height:1.8;\">Quien complete sistem\u00e1ticamente este plan de 90 d\u00edas estar\u00e1, a finales del tercer trimestre de 2026, en una posici\u00f3n en la que la auditor\u00eda del BSI encontrar\u00e1 cumplidos los requisitos esenciales. Quien no lo complete tendr\u00e1 que subsanar los hallazgos abiertos durante la fase de auditor\u00eda a partir del Q3 de 2026, frecuentemente bajo presi\u00f3n de tiempo y con costes m\u00e1s elevados.<\/p>\n\n<h3 style=\"color:#0a1e3d;\">\u00bfQu\u00e9 ocurre si la auditor\u00eda del BSI detecta deficiencias?<\/h3>\n\n<p style=\"line-height:1.8;\">La l\u00f3gica 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\u00f3n anual mundial. Tercer nivel: responsabilidad personal de la direcci\u00f3n 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\u00f3n en arquitectura de MFA adaptativa con pista de auditor\u00eda es siempre econ\u00f3micamente racional en comparaci\u00f3n con el importe de las multas.<\/p>\n\n<h3 style=\"color:#0a1e3d;\">C\u00f3mo DORA endurece adicionalmente los requisitos de MFA<\/h3>\n\n<p style=\"line-height:1.8;\">Para las entidades financieras, DORA a\u00f1ade una capa adicional. DORA exige resiliencia operativa y prescribe expl\u00edcitamente en sus disposiciones de gesti\u00f3n de riesgos TIC la MFA para accesos privilegiados y sesiones remotas. Mientras NIS2 utiliza la l\u00f3gica del \u00abcuando proceda\u00bb, el requisito de DORA es m\u00e1s estricto: la MFA privilegiada es obligaci\u00f3n, no opci\u00f3n. Los bancos, aseguradoras y proveedores TIC terceros cr\u00edticos deben cumplir en 2026 no solo la l\u00f3gica de NIS2, sino tambi\u00e9n el rigor de DORA en paralelo. La <a href=\"https:\/\/www.securitytoday.de\/es\/2026\/04\/24\/dora-2-uk-fca-resiliencia-operacional-16-abril-2026\/\">l\u00ednea DORA-2 de la FCA del Reino Unido de abril de 2026<\/a> 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.<\/p>\n\n<h3 style=\"color:#0a1e3d;\">Cu\u00e1les son los hallazgos de auditor\u00eda t\u00edpicos en 2026<\/h3>\n\n<p style=\"line-height:1.8;\">De los primeros talleres de pre-auditor\u00eda con responsables de seguridad de empresas medianas se pueden identificar cuatro hallazgos recurrentes que en una auditor\u00eda real del BSI derivar\u00e1n en requerimientos. Primero: cuentas de servicio sin MFA y sin rotaci\u00f3n de secretos. En la mayor\u00eda de las empresas DACH existen entre 30 y 200 cuentas de servicio con contrase\u00f1as est\u00e1ndar que no se han rotado en a\u00f1os. Son la v\u00eda de escalada n\u00famero uno para los atacantes y suponen un hallazgo abierto en la auditor\u00eda. 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\u00f3n y desactivaci\u00f3n y presentarlos en la auditor\u00eda. Cuarto: consolas de administraci\u00f3n 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.<\/p>\n\n<p style=\"line-height:1.8;\">Quien elimine sistem\u00e1ticamente estos cuatro hallazgos antes de la primera auditor\u00eda del BSI ya se situar\u00e1 en la mitad superior de madurez en cumplimiento. Por experiencia, la resoluci\u00f3n en un entorno de empresa mediana lleva entre ocho y diecis\u00e9is semanas, dependiendo del grado de fragmentaci\u00f3n del ecosistema de cuentas de servicio. Quien a\u00fan no haya abordado el tema en 2026 deber\u00eda reservar la pr\u00f3xima ronda de hoja de ruta de seguridad para ello.<\/p>\n\n<h3 style=\"color:#0a1e3d;\">Qu\u00e9 papel juega la MFA resistente al phishing<\/h3>\n\n<p style=\"line-height:1.8;\">Un aspecto central de la gu\u00eda ENISA del Q1 2026 es la recomendaci\u00f3n de m\u00e9todos de MFA resistentes al phishing para los accesos privilegiados. Las notificaciones push est\u00e1ndar 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\u00f3n biom\u00e9trica con origin binding se consideran, en cambio, resistentes al phishing. Para accesos privilegiados y sesiones remotas la recomendaci\u00f3n de 2026 es clara: \u00fanicamente factores resistentes al phishing. En la arquitectura NIS2, el inventario deber\u00eda por tanto documentar el estado de resistencia al phishing de cada clase privilegiada. Quien a\u00fan 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\u00f3n de auditor\u00eda.<\/p>\n\n<p style=\"line-height:1.8;\">Desde el punto de vista operativo, la transici\u00f3n 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\u00f3n adicional como una carga. Para clases amplias de empleados, la passkey es la variante ergon\u00f3micamente m\u00e1s 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\u00e1sicas como factor de transici\u00f3n para accesos legacy) es en 2026 el camino pragm\u00e1tico y cumple plenamente la gu\u00eda ENISA.<\/p>\n<h2 style=\"color:#0a1e3d;padding-top:64px;margin-bottom:20px;\">Preguntas frecuentes<\/h2>\n\n<details><summary><strong>\u00bfEs suficiente el MFA por SMS para el cumplimiento de NIS2?<\/strong><\/summary>\n<p style=\"margin:8px 0 0;padding:0;line-height:1.8;\">Para clases de riesgo bajo, tendencialmente s\u00ed; para accesos privilegiados, no. La gu\u00eda de la ENISA recomienda MFA basado en FIDO2 o TOTP para cuentas de administrador, dado que los factores SMS pueden verse comprometidos mediante SIM swapping. Un despliegue generalizado de SMS es vulnerable a auditor\u00edas del BSI en 2026.<\/p><\/details>\n\n<details><summary><strong>\u00bfCu\u00e1nto cuesta el MFA adaptativo para una empresa mediana?<\/strong><\/summary>\n<p style=\"margin:8px 0 0;padding:0;line-height:1.8;\">Para entre 250 y 1.000 empleados, los costes de licencia oscilan entre 5 y 18 euros por empleado al mes, seg\u00fan la soluci\u00f3n elegida y el alcance funcional. El esfuerzo de implementaci\u00f3n durante el primer a\u00f1o es t\u00edpicamente de 35.000 a 120.000 euros. Con un riesgo de multa de hasta 10 millones de euros, la ecuaci\u00f3n econ\u00f3mica es clara.<\/p><\/details>\n\n<details><summary><strong>\u00bfC\u00f3mo se integra el MFA adaptativo en un entorno Microsoft existente?<\/strong><\/summary>\n<p style=\"margin:8px 0 0;padding:0;line-height:1.8;\">Microsoft Entra ID Conditional Access es la soluci\u00f3n m\u00e1s natural para organizaciones con stack Microsoft. La configuraci\u00f3n requiere un inventario de identidades, la definici\u00f3n de pol\u00edticas de riesgo y la prueba de los mecanismos de step-up. Para entornos multi-cloud complejos o h\u00edbridos, proveedores de terceros como Silverfort u Okta suelen ofrecer mayor flexibilidad.<\/p><\/details>\n\n<details><summary><strong>\u00bfQu\u00e9 ocurre con las cuentas de servicio y las identidades de m\u00e1quina?<\/strong><\/summary>\n<p style=\"margin:8px 0 0;padding:0;line-height:1.8;\">El MFA cl\u00e1sico est\u00e1 dise\u00f1ado para usuarios humanos, no para cuentas de servicio. Aqu\u00ed entran en juego las Workload Identities (Managed Identities, Service Principals con autenticaci\u00f3n por certificado), la gesti\u00f3n de secretos (HashiCorp Vault, Azure Key Vault) y Workload Identity Federation. La l\u00f3gica de NIS2 exige tambi\u00e9n una evaluaci\u00f3n de riesgos documentada por clase de cuenta.<\/p><\/details>\n\n<details><summary><strong>\u00bfCon qu\u00e9 frecuencia debe actualizarse la evaluaci\u00f3n de riesgos?<\/strong><\/summary>\n<p style=\"margin:8px 0 0;padding:0;line-height:1.8;\">Como m\u00ednimo anualmente; en la pr\u00e1ctica se recomienda una actualizaci\u00f3n semestral. Ante cambios organizativos significativos (adquisiciones, nuevas \u00e1reas de negocio, migraci\u00f3n a entornos Sovereign Cloud) la evaluaci\u00f3n debe actualizarse de forma extraordinaria. Los auditores del BSI comprueban con frecuencia la vigencia de la evaluaci\u00f3n como indicador de madurez en el cumplimiento normativo.<\/p><\/details>\n\n<details><summary><strong>\u00bfC\u00f3mo se minimiza la fricci\u00f3n del usuario en la implantaci\u00f3n del MFA adaptativo?<\/strong><\/summary>\n<p style=\"margin:8px 0 0;padding:0;line-height:1.8;\">Tres pr\u00e1cticas contrastadas: en primer lugar, una fase piloto con usuarios privilegiados, quienes comprenden mejor la fricci\u00f3n y pueden aportar feedback. En segundo lugar, una comunicaci\u00f3n clara de la l\u00f3gica (por qu\u00e9 se solicita un factor ahora y por qu\u00e9 no en otro momento). En tercer lugar, mecanismos de step-down para dispositivos de confianza con una gesti\u00f3n de endpoint funcional. Quien comunica activamente la reducci\u00f3n de fricci\u00f3n gana a los usuarios para la l\u00f3gica de seguridad.<\/p><\/details>\n\n<h3 style=\"color:#0a1e3d;\">Red: Seguir leyendo en Security Today<\/h3>\n\n<ul>\n<li>Pr\u00e1ctica operativa del <a href=\"https:\/\/www.securitytoday.de\/es\/2026\/04\/24\/500000-datos-pacientes-96-horas-informe-incidente-anonimo-grupo-clinicas-dach\/\">informe de incidentes sanitarios de abril de 2026<\/a><\/li>\n<li>Obligaciones NIS2 para mensajer\u00eda en el <a href=\"https:\/\/www.securitytoday.de\/es\/2026\/04\/25\/whatsapp-signal-nis2-dora-responsabilidad-mensajeria-mdm\/\">informe de cumplimiento WhatsApp-Signal<\/a><\/li>\n<li>MFA adaptativo contra <a href=\"https:\/\/www.securitytoday.de\/es\/2026\/04\/24\/mfa-adaptativa-bajo-ataque-por-que-los-motores-de-riesgo-no-detectan-la-ola-de-7-millones-de-codigos-de-dispositivo\/\">7 millones de intentos de phishing por device code<\/a><\/li>\n<\/ul>\n\n<p><em>Fuente de la imagen de portada: Pexels \/ Dan Nelson (px:4973899)<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"NIS2 exige autenticaci\u00f3n multifactor (MFA) \u00abwhere appropriate\u00bb y en Alemania el mandato de ejecuci\u00f3n del BSI entra en su fase operativa en mayo de 2026. La pregunta central para los responsables de seguridad y cumplimiento normativo no es \u00abtenemos MFA\u00bb, sino \u00abtenemos la MFA correcta en los lugares correctos con una justificaci\u00f3n de riesgo documentada\u00bb. [&hellip;]","protected":false},"author":50,"featured_media":13281,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_focuskw":"Adaptive MFA NIS2","_yoast_wpseo_title":"MFA adaptativa como est\u00e1ndar NIS2 en 2026: c\u00f3mo la gu\u00eda de ENISA aclar\u00f3 la cl\u00e1us","_yoast_wpseo_metadesc":"La gu\u00eda ENISA Q1 2026 precis\u00f3 la cl\u00e1usula NIS2 'where appropriate'. Tres pilares de cumplimiento + plan de 90 d\u00edas + hallazgos de auditor\u00eda antes del BSI.","_yoast_wpseo_meta-robots-noindex":"","_yoast_wpseo_meta-robots-nofollow":"","_yoast_wpseo_meta-robots-adv":"","_yoast_wpseo_canonical":"","_yoast_wpseo_opengraph-title":"","_yoast_wpseo_opengraph-description":"","_yoast_wpseo_opengraph-image":"","_yoast_wpseo_opengraph-image-id":0,"_yoast_wpseo_twitter-title":"","_yoast_wpseo_twitter-description":"","_yoast_wpseo_twitter-image":"","_yoast_wpseo_twitter-image-id":0,"_evm_slot_owner":"","evm_cvss":0,"evm_risk":0,"evm_casefile":"","evm_primary_cve":"","evm_pin_until":0,"evm_external_preview_token":"","evm_external_preview_expires":"","_evm_translation_lang":"","featured_post":0,"featured_post_sortierung":0,"_wp_old_slug":[],"footnotes":""},"categories":[261],"tags":[],"class_list":["post-13152","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-strategie-governance-es"],"evm_reading_time_minutes":15,"wpml_language":"es","wpml_translation_of":13073,"_links":{"self":[{"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/posts\/13152","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/users\/50"}],"replies":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/comments?post=13152"}],"version-history":[{"count":1,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/posts\/13152\/revisions"}],"predecessor-version":[{"id":13607,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/posts\/13152\/revisions\/13607"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/media\/13281"}],"wp:attachment":[{"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/media?parent=13152"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/categories?post=13152"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/tags?post=13152"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}