Gestión de accesos en NIS2: Qué corregirían primero cinco expertos

De la política a la práctica: ¿quién tuvo acceso a qué, con la aprobación de quién, durante cuánto tiempo y puede demostrarlo?

Cinco líderes de ciberseguridad analizan los controles de gestión de accesos en NIS2 más difíciles de llevar a la práctica y las evidencias que las organizaciones necesitan para demostrar que funcionan.

Resumen ejecutivo

Con NIS2 ha cambiado lo que las organizaciones deben demostrar sobre la gestión de accesos. Ya no basta con implantar controles de ciberseguridad. Las organizaciones también necesitan evidencias de que esos controles funcionan, de quién es responsable de ellos y de qué ocurrió cuando alguien (o algo) accedió a un sistema crítico. Para los órganos de dirección, la obligación de demostrar que los controles de gestión de accesos existen y funcionan puede conllevar ahora responsabilidad personal.

Esas evidencias también deben abarcar algo más que a los empleados. Las cuentas de servicio, las claves de API, los proveedores y los agentes de IA pueden tener acceso a sistemas críticos. Saber que esas identidades existen, a qué pueden acceder y si ese acceso sigue estando justificado forma ya parte del mismo problema.

Los cinco líderes de ciberseguridad entrevistados para este informe abordaron ese problema desde perspectivas distintas. Debatieron qué requisito del artículo 21 de NIS2 es el más difícil de llevar a la práctica y dónde siguen estando más expuestas las organizaciones. Al final, sus respuestas volvían una y otra vez a la diferencia entre tener un control de gestión de accesos (o cualquier otro control de seguridad) y demostrar que funciona.

Participantes

Gabriel Dinu

Deputy Director, National Cyber Security Directorate of Romania
ENISA Management Board representative

Jane Frankland MBE

CEO and Founder of KnewStart

Ioannis Ntokos

IT Governance Risk & Compliance Expert (former FedEx, PwC, and Randstad)

Dr. Yiannis Pavlosoglou

Vice Governor, National Cybersecurity Authority of Greece

Alex Muntyan

CEO of Passwork

Descargo de responsabilidad: Los cuatro participantes externos de este informe intervinieron como expertos independientes. Ninguno de ellos mantiene una relación comercial con Passwork ni respalda sus productos. Sus opiniones son personales y no representan la postura de sus empleadores actuales o anteriores.

La prueba que hace tangible NIS2

La gestión de accesos en NIS2 puede definirse a partir de una pregunta fundamental: 

El resto de este informe aplica esa pregunta a las personas, los proveedores, las cuentas de servicio, las claves de API y los agentes de IA que pueden llegar a los sistemas críticos. También se pregunta si las evidencias que quedan bastan para mostrar lo que ocurrió.

El artículo 21 exige a las entidades esenciales e importantes que gestionen el riesgo de ciberseguridad mediante medidas acordes con los riesgos a los que se enfrentan. El artículo 23 establece normas estrictas y obligatorias de notificación de incidentes para las entidades esenciales e importantes que sufran un incidente cibernético significativo. Esos requisitos se aplican tanto a las entidades esenciales como a las importantes, aunque la forma de supervisarlas es diferente.

Los órganos de dirección deben aprobar las medidas de gestión de riesgos de ciberseguridad y supervisar su aplicación. Cada Estado miembro debe designar una autoridad competente que supervise y haga cumplir la directiva.

NIS2 atribuye esa responsabilidad al órgano de dirección por un motivo práctico. Sea cual sea la vía de entrada de un atacante, las credenciales robadas o mal utilizadas suelen aparecer en algún punto del camino. 

• El Data Breach Investigations Report 2026 de Verizon detectó el abuso de credenciales en el 39 % de las brechas analizadas, una proporción mayor que la de cualquier otra técnica. 
• El ENISA Threat Landscape 2026, que analizó 8257 incidentes registrados a lo largo de 2025, concluyó que el phishing representó el 77,8 % de la actividad de ingeniería social, en su mayor parte dirigida a obtener una contraseña o una sesión activa, mientras que la explotación de vulnerabilidades estuvo detrás de seis de cada diez incidentes de acceso no autorizado. Las entidades esenciales según NIS2 fueron el objetivo en el 72,9 % de los incidentes registrados.

Un consejo de administración que aprueba medidas de ciberseguridad sin preguntar cómo se controla el acceso está aprobando un plan que deja fuera su debilidad más explotada.

Esa decisión, intencionada o no, tiene consecuencias. Para las entidades esenciales, las infracciones de los artículos 21 y 23 pueden acarrear multas administrativas máximas de al menos 10 millones de euros o el 2 % del volumen de negocios anual mundial, si esta cifra es superior. 

La aplicación también avanza. El plazo inicial vencía en octubre de 2024, pero muy pocos países lo cumplieron. En julio de 2026, la Comisión Europea llevó a Irlanda, España, Francia y los Países Bajos ante el Tribunal de Justicia de la Unión Europea por no notificar medidas que transpusieran plenamente NIS2 a su legislación nacional.

El artículo 21 abarca una amplia gama de medidas de ciberseguridad, y los retos prácticos varían de una a otra. Cuando se les preguntó cuál es la más difícil de llevar a la práctica, cada experto señaló un punto distinto. 

• Pavlosoglou destacó la MFA y señaló los sistemas heredados que no la admiten, las cuentas técnicas que dejan de funcionar al activarla y las excepciones que la gente empieza a pedir casi de inmediato
• Para Dinu es la seguridad de la cadena de suministro, que considera difícil tanto de implantar para las organizaciones como de evaluar para los reguladores
• Frankland afirmó que es evaluar si las medidas de ciberseguridad son eficaces: tener un control es una cosa, y demostrar que funciona es una conversación completamente distinta
• Muntyan se centró en el control de acceso y la gestión de credenciales, en particular en si una organización puede demostrar quién tuvo acceso y qué hizo
• Ntokos eligió la gestión de incidentes, porque en cuanto se produce un incidente intervienen muchísimos procesos y personas

Cumplir esas medidas también exige algo más que controles técnicos, y a menudo depende de la cultura organizativa y de las personas que los utilizan.

Dinu compara la regulación con las leyes sobre el cinturón de seguridad. Las personas deberían abrocharse el cinturón porque las protege, no solo porque lo exija la ley, y sostiene que la ciberseguridad debería funcionar del mismo modo. En la práctica, las organizaciones tratan con demasiada frecuencia la seguridad como un coste hasta que la regulación o un incidente las obliga a actuar.

Pavlosoglou aborda el problema cultural desde otro ángulo. Preguntado por los obstáculos para el cumplimiento, señala la disposición de las organizaciones a revelar lo ocurrido cuando se produce un incidente. 

La red de CSIRT ofrece a las autoridades nacionales de toda la UE un medio para compartir información sobre ataques, de modo que la cooperación con las autoridades forma parte de la respuesta en lugar de ser una conversación que solo empieza cuando llegan las medidas de ejecución.

La cultura es más difícil de cambiar que una política. NIS2 añade otra palanca al situar la responsabilidad de esas medidas de ciberseguridad en el nivel de la dirección.

La responsabilidad cambió la conversación en el consejo

Que el órgano de dirección sea responsable de aprobar y supervisar la aplicación de NIS2 refuerza la posición del CISO, sobre todo cuando las debilidades en la gestión de accesos requieren presupuesto adicional o cambios en otras áreas del negocio.

Dinu ha visto el efecto de primera mano. Los consultores con los que habló le describieron una dirección que mostraba poco interés por las presentaciones de ciberseguridad hasta que salía a relucir la responsabilidad. Entonces, según contó, «cambió todo el ambiente de la sala». Cuando los miembros del consejo pueden ser considerados responsables, resulta mucho más difícil despachar un problema de seguridad como algo de lo que debe ocuparse el CISO.

Muntyan observa un cambio similar desde el lado del proveedor. Antes, la seguridad quizá llegaba al consejo una vez al año. En las conversaciones de Passwork con organizaciones, ahora ve que los altos ejecutivos se implican más, cuando antes los debates se quedaban en los responsables de TI y los arquitectos.

Ntokos también considera positiva la rendición de cuentas de la alta dirección. Cuando el riesgo de ciberseguridad pasa a ser una responsabilidad empresarial y financiera, sostiene, a la dirección le resulta más difícil dejarlo por completo en manos del equipo de seguridad.

Pavlosoglou señala la transposición de la Directiva NIS2 de la UE al derecho griego, según la cual el responsable de seguridad de la información (CISO) debe ser un miembro interno de la plantilla que rinda cuentas al consejo. Eso deja en manos del CISO la tarea de «traducir al lenguaje del consejo». Pone como ejemplo una organización que no tiene suficiente cobertura de identidades de usuario con la autenticación multifactor (MFA) activada. Esto, sostiene, tiene que llegar al consejo como un riesgo de exposición del negocio, con un coste y un plan asociados, o no se actuará al respecto.

Sanciones y responsabilidad de la dirección

Responsables, pero sin autoridad

Jane Frankland MBE lleva años sosteniendo que los CISO responden del riesgo cibernético sin tener autoridad para reducirlo. La responsabilidad de la seguridad y la resiliencia recae en el CISO, la aplicación de parches en TI e infraestructura, y el presupuesto para resolver ambas cosas está, una vez más, en otra parte. Cuando el riesgo persiste, quien sigue respondiendo de él es el CISO.

El consejo ha estado al otro lado de ese esquema, y allí aparece el mismo hábito.

Ese es el cambio que Frankland considera más importante y también aquel sobre el que se muestra más cauta. La responsabilidad existe sobre el papel. Que se traduzca en que los miembros del consejo hagan preguntas más difíciles depende de la aplicación efectiva, y, según dice, todavía es pronto para saberlo.

Frankland describe el objetivo más amplio como «supervivencia cibernética». Se trata de reducir el impacto de un incidente, mantener en marcha las operaciones críticas y preservar una vía de recuperación.

En el caso del consejo, las evidencias deben demostrar algo más que el hecho de que recibió un informe de seguridad. El consejo tiene que entender el riesgo material, aprobar las medidas destinadas a gestionarlo y supervisar los pasos siguientes.

La MFA se complica en cuanto llega a la organización

El artículo 21 exige a las organizaciones utilizar la MFA cuando proceda, pero lo más difícil es conseguir que funcione en toda la organización.

Pavlosoglou describe lo rápido que se acumulan las excepciones una vez activada la MFA obligatoria. En un ejemplo, el equipo de TI activa la MFA el lunes por la mañana. A las 10:00 de ese mismo día, la oficina del director pide quedar excluida. Al acercarse la tarde llega la primera solicitud para excluir las cuentas técnicas no personales (NPTA). Como se han utilizado cuentas de usuario para identidades de servicio (por ejemplo, para conectarse a sistemas de pago), activar la MFA interrumpe el servicio.

Dinu ve esa misma resistencia de los usuarios como parte del problema de implantación. La MFA cambia la forma de trabajar de las personas, así que desplegarla también implica gestionar el rechazo que surge cuando un control de seguridad añade un paso más a un proceso conocido.

Frankland advierte contra el uso de la expresión «cuando proceda» de la directiva como vía de escape. En sus palabras, no debería interpretarse como «si resulta conveniente». La robustez de la autenticación debería ajustarse a la sensibilidad del activo y al riesgo asociado al acceso. Tener la MFA implantada no significa que todos los métodos de autenticación ofrezcan el mismo nivel de protección. Frankland defiende una MFA resistente al phishing, como FIDO2, para los accesos de mayor riesgo.

Ntokos plantea algo similar desde una perspectiva operativa. Las organizaciones necesitan, en primer lugar, un inventario de su infraestructura y saber dónde residen los datos críticos. Después deben tener en cuenta los distintos entornos de trabajo. Es posible que un operario de planta no pueda llevar un teléfono móvil. Un empleado de oficina y un administrador tienen requisitos de acceso diferentes.

La tecnología heredada lo complica aún más. Una aplicación antigua puede no admitir de forma nativa la MFA moderna. Pavlosoglou advierte que las organizaciones pueden dejar zonas grises en sus políticas para dar cabida a esos sistemas, conseguir que se apruebe la política y aparentar cumplimiento sin corregir la debilidad de fondo.

Frankland llega a la misma conclusión desde el punto de vista del diseño. La pregunta deja de ser cómo acoplar la MFA a un sistema antiguo y pasa a ser cómo evitar que ese sistema sea accesible con una sola credencial.

Una opción es desplazar el control de autenticación hacia fuera. Muntyan describe cómo situar la MFA en la capa de gestión de credenciales y utilizarla para intermediar el acceso a las aplicaciones heredadas. La aplicación no adquiere de repente una autenticación moderna, pero el camino hacia sus credenciales puede someterse a controles más estrictos.

No se puede imponer un único método de autenticación a todos los usuarios y sistemas. Es mejor saber dónde se necesita una autenticación más robusta y contar con una forma defendible de tratar los sistemas que no pueden ofrecerla por sí mismos.

Las identidades no humanas pasan a formar parte del problema del acceso

Tradicionalmente, los inventarios de accesos empezaban por los empleados, pero eso ya no basta. Las claves de API, las cuentas de servicio, los scripts y los agentes de IA pueden llevar autoridad hasta los sistemas críticos. Algunos siguen activos mucho después de que haya desaparecido el motivo por el que se crearon.

Muntyan ve otro problema en la forma de almacenar los secretos. Si el sistema aprobado resulta engorroso, los equipos buscan otro lugar donde guardar las claves de API, los tokens y otras credenciales. Esos «escondites» generan una dispersión de secretos (secrets sprawl) y hacen más difícil saber qué credenciales existen o quién puede usarlas.

Lo que hoy preocupa a Muntyan es la asimetría. Las contraseñas están rodeadas de controles que existen porque se da por hecho que las personas fallarán, y las credenciales de máquina no han heredado casi ninguno. De cara al futuro, prevé que los agentes de IA empeoren la situación, porque pueden crear y usar credenciales a velocidad de máquina, mientras que los procesos de revisión de accesos se diseñaron pensando en personas.

Pavlosoglou cree que el coste del consumo de tokens puede acabar frenando el uso descontrolado de agentes de IA. A modo de anécdota, cita casos de CISO que durante el verano tuvieron que rastrear a empleados de organizaciones sujetas a estrictos controles regulatorios que estaban poniendo en marcha agentes para obtener pronósticos sobre partidos del Mundial.

A medida que ese uso se encarece, las organizaciones tienen otro motivo para controlar qué agentes están en funcionamiento y con qué fin. Aun así, el coste es un instrumento poco preciso. Detecta los agentes cuya factura alguien vigila, no aquellos que nadie recuerda haber creado.

Frankland lleva la cuestión más allá de la autenticación. «La autenticación nos dice quién o qué está actuando, pero no nos dice si la acción es sensata».

Un agente podría autenticarse correctamente y operar dentro de los permisos que se le han concedido de forma legítima y, aun así, realizar una acción que la organización no desearía.

Ntokos lo ve como un problema de gestión de identidades al que tendrán que adaptarse los sistemas existentes. Las organizaciones deben poder identificar a los agentes, supervisar sus acciones, limitar su alcance y revocar su acceso o hacer que caduque.

La rendición de cuentas no desaparece porque quien actúa sea un software. Dinu sostiene que usar un agente no transfiere la rendición de cuentas al software y que la responsabilidad sigue recayendo en la persona o la organización que posee o gestiona el sistema.

Los equipos de accesos deberían dejar de tratar las identidades no humanas como excepciones. Su lugar está en el inventario, junto a los empleados, los administradores y los proveedores.

El acceso de proveedores necesita su propio ciclo de vida

El acceso de terceros alimenta un problema de rendición de cuentas similar. Pavlosoglou ha estado en el lado de la seguridad en largas negociaciones de contratos y no se disculpa por el tiempo que pueden requerir. «La negociación duró diez meses», contó. «El negocio quería saber en qué punto estaba el contrato. Pero, mientras no acordáramos cómo íbamos a tratar a los proveedores en cuanto a cláusulas de indemnización, responsabilidades y los KPI, más blandos pero igual de importantes, no tenía sentido avanzar con el retorno de la inversión en seguridad (ROSI) que aportaría el tercero».

Eso incluía si el proveedor tenía que notificar una brecha y cuándo, si el cliente tenía derecho a auditarlo y quién pagaría la auditoría. Algunos de esos detalles pueden quedar ocultos en las cláusulas de indemnización o en las condiciones del ciberseguro. Como dijo Pavlosoglou, «incluso palabras sueltas y comas pueden marcar una gran diferencia».

Su consejo es empezar por los proveedores que tienen acceso a sistemas críticos y revisar lo que ya consta por escrito. NIS2 da a los equipos de seguridad un motivo para volver al departamento jurídico y asegurarse de que los contratos cubren el acceso que tienen esos proveedores.

Dinu ve la misma dificultad desde el otro lado de la mesa. La seguridad de la cadena de suministro es la medida del artículo 21 sobre la que más preguntan las partes interesadas de la DNSC, y las preguntas pueden parecer básicas: qué proveedores, qué medidas, impuestas por quién. Lo interpreta como una señal de lo difícil que es evaluar este requisito, y la autoridad se enfrenta a su propia versión del problema al redactar normas que deben encajar en más de una docena de sectores y en entidades de todos los tamaños.

Frankland sostiene que el acceso de proveedores debería ser atribuible, limitado y revocable. También se muestra escéptica ante la tendencia a confiar demasiado en los cuestionarios. Un cuestionario cumplimentado no demuestra que los controles declarados estén funcionando. Las organizaciones también deben mirar más allá de sus proveedores directos y entender dónde podrían introducir cuartas partes accesos o dependencias más abajo en la cadena.

Ntokos afirma que el acceso de proveedores debe gestionarse a lo largo de toda la relación, desde la incorporación hasta la salida. El nivel de acceso debería depender del trabajo que realiza el proveedor, con accesos separados o limitados en el tiempo cuando sea necesario.

Muntyan recomienda evitar las contraseñas permanentes para los proveedores, registrar su actividad y rotar las credenciales cuando finaliza el encargo. Esos controles también generan algo que la organización puede necesitar demostrar más adelante: evidencias de que el acceso del proveedor estuvo limitado y se retiró cuando dejó de ser necesario.

Las evidencias deben sobrevivir al incidente

NIS2 no establece un periodo de conservación único para los registros de acceso. Los expertos reconocieron que está muy extendida la idea errónea de que los registros de acceso deben conservarse durante 10 meses, pero sostuvieron que son las propias organizaciones las que deben determinar un periodo adecuado en función de los requisitos legales aplicables, las necesidades del negocio y su evaluación de riesgos. Las directrices técnicas de aplicación de ENISA también piden que los periodos de conservación se definan con este criterio.

La conservación es solo una parte del problema. Las organizaciones también deben decidir qué registros de acceso importan, protegerlos y asegurarse de que pueden presentarlos cuando un auditor o el equipo de respuesta a incidentes los necesite.

En este tema se suele hablar de los registros de acceso, pero los profesionales apuntan a que la pregunta más pertinente es si esos registros son fiables y utilizables.

Pavlosoglou describe el caso de fallo desde el lado del regulador. Con NIS2, las autoridades nacionales competentes supervisan el cumplimiento y, en Grecia, están obligadas a intervenir cuando una entidad sujeta a la directiva solicita ayuda durante un incidente. El estado de los sistemas de información que encuentran al llegar determina cuánto pueden hacer.

La respuesta debería partir del servicio crítico, sostiene. Las organizaciones deben determinar qué registros son necesarios para entender la actividad en torno a ese servicio, en lugar de interpretar NIS2 como una instrucción para registrarlo todo de forma indiscriminada.

De esa situación no hay forma de recuperarse a posteriori. Cuando la autoridad ya está en el edificio, la organización tiene los registros o no los tiene, y el dinero ahorrado al dejar desactivado el registro ya se ha gastado muchas veces.

Para Frankland, hay otro problema. Conservar los logs sirve de poco si pueden alterarse o si no es posible reconstruir la actividad entre los distintos sistemas.

Ntokos se centra en cómo se gestionan esas evidencias. Las organizaciones necesitan políticas de conservación y de registro, un almacenamiento adecuado, marcas de tiempo, sincronización y cadena de custodia. Antes de preocuparse por la rapidez con la que pueden recuperarse las evidencias, deben asegurarse de que se han conservado correctamente.

Muntyan también hace hincapié en la recuperación. Si un regulador o el equipo de respuesta a incidentes solicita evidencias, sostiene que los equipos deberían poder presentarlas en cuestión de minutos o en una hora, en lugar de pasar días reuniendo registros de distintos sistemas.

El cumplimiento debería sacar a la luz las debilidades, no ocultarlas

Una puntuación de cumplimiento perfecta puede ser menos tranquilizadora de lo que parece.

Dinu menciona Cyber Fundamentals, o el modelo de autoevaluación CyFun desarrollado por la autoridad belga de ciberseguridad, en el que las organizaciones se autoevalúan cada año y las entidades esenciales presentan un plan para abordar las áreas de no conformidad. No se espera que todos los controles obtengan una puntuación perfecta. Según dijo, los reguladores estarían «bastante preocupados» si así fuera.

La tolerancia de Dinu hacia las puntuaciones imperfectas nace de haber visto lo que ocurre cuando los reguladores exigen puntuaciones impecables.

Dinu afirma que un incidente puede cambiar esa actitud rápidamente. Ha visto organizaciones que pasaron de tratar la ciberseguridad como un ejercicio de cumplimiento a tomarse el riesgo en serio después de sufrir un ataque en primera persona.

Muntyan señala que, históricamente, los incidentes han sido el detonante para que las organizaciones mejoren la gestión de accesos, pero eso está cambiando. Cada vez más clientes corporativos preguntan a sus proveedores cómo gestionan las credenciales antes de firmar un contrato. Para un proveedor, esa pregunta llega antes que cualquier regulador, y quien la formula es el cliente.

Para Pavlosoglou, las credenciales expuestas pueden ser un detonante más personal. Menciona el conocido efecto «name and shame» (señalar públicamente): las pruebas de que alguien puede hacerse pasar por su identidad digital hacen que el riesgo sea mucho más difícil de ignorar.

Ntokos sostiene que las mejoras deberían guiarse por el riesgo, en lugar de esperar a un plazo de cumplimiento o a un incidente. Frankland también actuaría antes. Su detonante es el momento en que el número de sistemas de identidad y credenciales resulta excesivo para que las personas lo gestionen de forma fiable a mano. Esperar a un incidente, una auditoría o un plazo de cumplimiento significa esperar hasta que la debilidad ya se ha convertido en un problema.

Lista de verificación de gestión de accesos en NIS2

Lo que los cinco expertos corregirían primero

Passwork, diseñado para la cuestión de las evidencias

Passwork es un gestor de contraseñas y secretos desarrollado en la UE para organizaciones que tienen que demostrar, y no solo declarar, cómo se controlan las credenciales. 

Sus funciones para el cumplimiento de NIS2 abarcan el control de acceso basado en roles (RBAC), tipos de bóveda personalizables, la aplicación obligatoria de la MFA en todo el sistema, la integración con AD/LDAP/SSO y registros de auditoría que pueden exportarse a un SIEM.

Passwork no decide qué servicios son críticos ni quién debe tener acceso a ellos. Esas decisiones siguen correspondiendo a la organización. Lo que sí puede hacer es ayudar a llevarlas a la práctica y conservar los registros necesarios para demostrar lo que ocurrió.

Preguntas frecuentes