Requisitos NIS2 de seguridad de identidad: qué deben demostrar los equipos de AD y Entra

Requisitos NIS2 de seguridad de identidad: empezar por lo que el texto realmente dice

Si está intentando entender los requisitos NIS2 de seguridad de identidad, el primer error que debe evitar es tratar NIS2 como si fuera una guía de configuración de Microsoft. No lo es. La Directiva (UE) 2022/2555 fija obligaciones de gestión del riesgo y expectativas de gobernanza a nivel de la Unión. No les dice a los equipos que desplieguen Microsoft Entra Privileged Identity Management, que apliquen una plantilla concreta de Conditional Access ni que configuren una longitud específica de contraseña en Active Directory.

Esa distinción importa porque los equipos de identidad igualmente tienen que demostrar algo concreto. Aunque NIS2 no nombre productos de Microsoft, los equipos de AD y Entra todavía deben ser capaces de demostrar que el acceso privilegiado está controlado, que la autenticación es suficientemente sólida para el nivel de riesgo, que el control de acceso se aplica realmente en producción y que la monitorización permite probar violaciones de política o deriva de privilegios.

Este artículo separa deliberadamente cuatro capas:

Ese encuadre es lo que separa una revisión defendible de un artículo de compliance que sobreafirma.

¿Qué exige realmente NIS2 para la seguridad de identidad?

En el nivel más alto, el artículo 21(1) de NIS2 exige que los Estados miembros garanticen que las entidades esenciales e importantes adopten medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos que afectan a la seguridad de las redes y sistemas de información. Esa es una obligación basada en riesgo, no una checklist de producto.

La identidad aparece de forma más directa en el artículo 21(2). Para este tema, hay dos puntos especialmente relevantes:

• El artículo 21(2)(i) incluye políticas y procedimientos para evaluar la eficacia de las medidas de gestión del riesgo de ciberseguridad.
• El artículo 21(2)(j) incluye el uso de soluciones de autenticación multifactor o autenticación continua, comunicaciones seguras y sistemas seguros de comunicación de emergencia dentro de la entidad, cuando proceda.

NIS2 también aporta contexto importante en el considerando 89, que enumera prácticas básicas de ciberhigiene como principios zero trust, actualizaciones de software, segmentación de red, identity and access management y concienciación de usuarios. Ese considerando no es una baseline oculta de Microsoft. Es una señal clara de que la gobernanza de identidad, la autenticación y la disciplina de acceso forman parte del trabajo básico de seguridad que los reguladores esperan.

La lectura prudente para los equipos de identidad es esta: NIS2 no prescribe un único patrón de fabricante, pero sí espera controles de identidad defendibles, basados en riesgo, revisados y capaces de reducir el impacto de un incidente.

Dónde encaja identity and access management en NIS2

Para los equipos de AD y Entra, la pregunta práctica no es «¿qué funcionalidad de Microsoft exige NIS2?». La pregunta práctica es «¿qué objetivos de seguridad de identidad nos costaría demostrar bajo revisión?».

Una lectura técnica útil se parece más a esto:

Por eso Cumplimiento AD & Azure: NIS2, ISO 27001, CIS sigue siendo útil. Ese artículo hace un mapeo más amplio entre varios marcos. El que está leyendo ahora reduce la pregunta a un problema más difícil: qué puede demostrar realmente un equipo de identidad en una revisión orientada a NIS2.

Por qué el alcance importa: NIS2, reglas sectoriales y transposición nacional

El alcance es el punto donde muchos artículos de compliance se equivocan.

En primer lugar, NIS2 es una directiva, no un estándar de producto directamente autoejecutable. Los Estados miembros la transpongan al derecho nacional y las expectativas de supervisión dependen en parte de esa implantación nacional. Un equipo que opera en Francia, Alemania, Italia o en otro Estado miembro se enfrenta a la misma base de la UE, pero no necesariamente al mismo empaquetado supervisor, ni a los mismos documentos de referencia, ni al mismo flujo de implementación.

En segundo lugar, no todos los detalles técnicos que la gente suele asociar con NIS2 proceden del texto de la directiva. El Reglamento de Ejecución (UE) 2024/2690 establece requisitos técnicos y metodológicos para determinadas categorías de entidades cubiertas por el artículo 21(5), como proveedores de servicios DNS, proveedores de servicios cloud, operadores de centros de datos, managed service providers, managed security service providers y prestadores de servicios de confianza. Ese reglamento es importante, pero no es un atajo genérico que pueda aplicarse sin cambios a cualquier organización sujeta a NIS2.

En tercer lugar, algunas entidades también están sujetas a normas sectoriales o nacionales más específicas. Por eso una revisión seria de identidad con enfoque NIS2 necesita responder tres preguntas antes siquiera de empezar:

1. ¿Está la entidad dentro del alcance de NIS2 y en qué categoría?
2. ¿Está también cubierta por textos europeos o nacionales más específicos?
3. ¿Qué expectativas técnicas proceden de la propia directiva, cuáles de actos de ejecución y cuáles de guías nacionales?

Sin esa disciplina, los equipos acaban afirmando cosas como «NIS2 exige PIM» o «NIS2 exige contraseñas de 12 caracteres». Esas afirmaciones no son técnicamente defendibles a partir del texto de la UE por sí solo.

Controles de AD y Entra que suelen respaldar los objetivos de identidad de NIS2

NIS2 no menciona ni Active Directory ni Microsoft Entra. Pero si su entorno depende de ellos, son lugares obvios donde se buscará evidencia.

Acceso privilegiado

Una revisión madura de identidad debe poder mostrar qué usuarios y grupos tienen acceso administrativo efectivo on-premises y en Entra, cómo se concedió ese acceso y si sigue estando justificado.

Eso normalmente implica revisar:

• membresías directas y anidadas en grupos AD privilegiados
• principals con derechos equivalentes a DCSync
• derechos delegados sobre objetos AD sensibles, especialmente cuando GenericAll, WriteDACL o WriteOwner crean rutas de escalada
• asignaciones de roles Entra permanentes frente a asignaciones elegibles
• cuentas que conservan privilegios pese a la inactividad o a la deriva de propiedad

Precisamente por eso Deriva acceso privilegiado Active Directory: cómo vuelven los derechos admin tras las auditorías y Acceso privilegiado Azure: roles, PIM y administracion permanente son referencias internas pertinentes. No prueban por sí solas la conformidad con NIS2. Muestran los tipos de condiciones de identidad que a un equipo le costaría defender bajo escrutinio.

Fortaleza de autenticación

NIS2 da claramente cabida al MFA o a la autenticación continua, pero la expresión «cuando proceda» sigue siendo importante. Por eso un programa de identidad defendible debe poder explicar:

• qué cuentas privilegiadas están siempre detrás de MFA
• qué flujos administrativos y qué aplicaciones de alto riesgo están sujetos a controles de acceso reforzados
• si siguen abiertos caminos de autenticación legacy
• si el tenant todavía depende de un patrón de contraseña más excepciones

La documentación de Microsoft es útil aquí porque explica qué es realmente Conditional Access: un motor de políticas que combina señales y aplica decisiones de acceso. Eso lo convierte en evidencia de un camino de control, no en la prueba de que NIS2 haya exigido específicamente Conditional Access como producto.

Del mismo modo, Identidad Azure: MFA, metodos y Security Defaults ayuda a fijar correctamente el límite técnico: MFA es importante, pero una mala gobernanza de roles, invitados demasiado abiertos o el consentimiento malicioso de aplicaciones pueden seguir dejando una exposición de identidad significativa.

Control de acceso, invitados y permisos de aplicaciones

El alcance de identidad en NIS2 es más amplio que el simple inicio de sesión de empleados. El control de acceso también afecta a usuarios externos, acceso de aplicaciones y autoridad delegada.

Un equipo técnico debe poder demostrar:

• cómo se restringe el acceso de invitados
• quién está autorizado a invitar invitados
• si la colaboración cross-tenant está fuertemente gobernada o queda demasiado abierta
• cómo se controlan los permisos de aplicaciones y el consentimiento
• si las enterprise apps sobreprivilegiadas se revisan periódicamente

No son preocupaciones abstractas. Microsoft documenta que los application permissions pueden conceder acceso app-only y que el consentimiento de usuario o admin gobierna cómo las aplicaciones obtienen acceso a recursos protegidos. Microsoft también documenta cómo restringir la configuración de user consent para reducir consentimientos maliciosos o excesivos. Por eso Registros de Aplicaciones Azure: Apps Sobreprivilegiadas y OAuth Consent Phishing: cómo las aplicaciones maliciosas evitan el robo de contraseñas forman parte de una lectura seria del tema, aunque NIS2 nunca utilice esos nombres de producto.

Qué evidencias debe poder aportar un equipo de seguridad

Un programa débil de identity compliance suele tener buenas políticas, pero no un paquete de evidencias. Bajo una revisión orientada a NIS2, los equipos de AD y Entra deben poder aportar evidencias actuales, revisables y vinculadas directamente a los controles que afirman aplicar.

Un paquete de evidencias práctico suele incluir:

Aquí es donde Cómo auditar la seguridad de Microsoft Entra ID (Azure AD): guía práctica, Auditar la seguridad de Active Directory: checklist práctica y Supervision Seguridad AD: Event IDs y SIEM ayudan a convertir el lenguaje del marco en pasos operativos de revisión.

Brechas habituales entre la política escrita y los controles de identidad realmente aplicados

Los fallos de identidad más importantes en una lectura NIS2 no suelen venir de la ausencia de política escrita. Vienen de la brecha entre lo que la política dice y lo que el directorio o el tenant aplican realmente.

Ejemplos frecuentes:

• existe una política de mínimo privilegio, pero hay demasiados admins permanentes en Entra o demasiados grupos privilegiados permanentes en AD
• existe una política MFA, pero aún deja fuera de cobertura flujos administrativos sensibles o caminos de autenticación legacy
• existe una política de acceso de terceros, pero la configuración de invitación de invitados o el acceso cross-tenant siguen demasiado abiertos
• existe un proceso trimestral de revisión de acceso, pero nadie puede mostrar evidencia actual de que las revisiones de invitados, grupos o roles se completaron de verdad
• existe una política de gobernanza de aplicaciones, pero nadie puede mostrar el estado actual de permisos de service principals, grants app-only o configuración de consentimiento
• existe una política de auditoría y monitorización que nombra controles, pero nadie puede demostrar el estado actual de la auditoría AD o la cobertura actual de Entra audit logs

Por eso un artículo NIS2 centrado en identidad no debe terminar en slogans de gobernanza. Un equipo técnico debe ser capaz de mostrar estado aplicado, no solo intención escrita.

Contexto de Francia y ANSSI

Como este artículo es UE-first, Francia aparece aquí como contexto, no como núcleo normativo.

La página oficial de ANSSI sobre NIS2 indica que la agencia seguirá comunicando durante toda la transposición nacional, que las futuras entidades esenciales e importantes están animadas a iniciar desde ahora un enfoque de seguridad coherente con NIS2 y que, desde el 17 de marzo de 2026, ANSSI pone a disposición el Référentiel Cyber France (ReCyF) como documento de trabajo. ANSSI también indica que ReCyF no es obligatorio por defecto en esta fase y que corresponde al marco de ciberseguridad mencionado en el artículo 14 del proyecto de ley Résilience.

La lectura prudente es directa:

• ReCyF no es la propia directiva NIS2
• ReCyF no sustituye la lectura de los textos jurídicos aplicables
• las entidades basadas en Francia pueden usarlo como punto práctico de referencia frente a la supervisión nacional
• los equipos deben tratar el estado de la transposición francesa y las expectativas de ANSSI como una capa nacional que se superpone a la directiva de la UE

En ese sentido, Guía ANSSI Active Directory: cómo aplicar las recomendaciones de seguridad en la práctica es una lectura útil como complemento, pero no un sustituto del análisis NIS2.

Remediation

Incluso antes de la validación formal, los equipos deben iniciar una remediación concreta sobre los puntos que no podrían defender en una revisión. En la práctica, eso significa reducir privilegios permanentes injustificados, cerrar caminos de autenticación legacy que sigan abiertos, reforzar la gobernanza de invitados y del cross-tenant, revisar service principals sobreprivilegiados y documentar el estado corregido.

Validación después de la remediación

Un programa de identidad realmente defendible frente a una revisión NIS2 debe poder demostrar que las brechas se corrigieron, no solo que se identificaron.

Después de la remediación, los equipos deberían poder mostrar:

1. inventarios actualizados de acceso privilegiado tanto en AD como en Entra
2. evidencia actual de que los controles de autenticación fuerte se aplican donde la organización afirma que deben aplicarse
3. configuración actualizada de invitados, cross-tenant y gobernanza de aplicaciones después de los cambios
4. evidencia de auditoría actual que demuestre que los cambios de identidad siguen siendo visibles
5. una lista revisada de excepciones que separe riesgo residual de deriva o negligencia

En la práctica, las acciones que más mejoran la defendibilidad de una postura de identidad suelen ser las mismas: eliminar privilegios permanentes innecesarios, cerrar accesos legacy todavía abiertos, revisar invitados y accesos cross-tenant, inventariar service principals sobreprivilegiados y volver a ejecutar las exportaciones y registros que sirven como evidencia. El objetivo no es producir otra presentación. El objetivo es demostrar que el control anunciado sigue existiendo después de la corrección.

Ese paso de validación es el que separa un ejercicio puntual de framework de una revisión que seguirá resistiendo el siguiente ciclo de auditoría.

Cómo EtcSec ayuda a medir brechas de identidad relevantes para NIS2

Aquí EtcSec debe posicionarse de forma estrecha.

La cuestión no es afirmar que EtcSec «demuestra la conformidad NIS2». La cuestión es que ayuda a medir brechas técnicas de identidad que suelen importar cuando un equipo necesita demostrar que el acceso, la autenticación, la gobernanza de privilegios y la monitorización están realmente aplicados.

Ejemplos:

• EXCESSIVE_PRIVILEGED_ACCOUNTS
• PRIVILEGED_ACCOUNT_STALE
• DANGEROUS_GROUP_NESTING
• DCSYNC_CAPABLE
• ACL_GENERICALL
• CA_NO_MFA_REQUIREMENT
• PA_PIM_NOT_ENABLED
• GUEST_INVITATION_UNRESTRICTED
• B2B_CROSS_TENANT_OPEN
• AZ_SECURITY_DEFAULTS_DISABLED

Estos findings no crean una presunción legal. Ayudan al equipo de seguridad a responder una pregunta más difícil: si afirmamos que nuestros controles de identidad están basados en riesgo y aplicados de verdad, ¿qué evidencia técnica actual respalda esa afirmación?

Referencias primarias

• Directive (EU) 2022/2555 (NIS2) — EUR-Lex
• Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
• Resumen jurídico de EUR-Lex sobre ciberseguridad de redes y sistemas de información
• ANSSI: La directive NIS 2
• Microsoft Learn: What is Conditional Access?
• Microsoft Learn: What is Microsoft Entra Privileged Identity Management?
• Microsoft Learn: What are Microsoft Entra audit logs?
• Microsoft Learn: Overview of permissions and consent in the Microsoft identity platform
• Microsoft Learn: Configure how users consent to applications
• Microsoft Learn: Restrict guest access permissions in Microsoft Entra ID
• Microsoft Learn: What are access reviews?
• Microsoft Learn: Advanced security audit policy settings