Para implementar controles de acceso NIS2 para la seguridad de la cadena de suministro, asigne cada proveedor directo y prestador de servicios a los sistemas, cuentas, privilegios, métodos de autenticación y registros de evidencia que utilizan. Luego aplique el principio de mínimo privilegio, MFA o autenticación continua según corresponda, controles de cuentas privilegiadas, cláusulas contractuales, monitorización y revisiones periódicas de acceso.
La seguridad de la cadena de suministro NIS2 no es un ejercicio de adquisiciones. Significa traducir cada relación con proveedores en controles aplicables sobre cuentas, credenciales compartidas, rutas de acceso remoto, acciones privilegiadas y registros.
Según el Informe de Investigaciones de Brechas de Datos 2025 de Verizon, la participación de terceros apareció en el 30% de las brechas analizadas. El DBIR 2026 muestra que la tendencia se acelera: la participación de terceros ahora aparece en el 48% de las brechas confirmadas, un aumento interanual del 60%. Con esa trayectoria, la gobernanza del acceso de proveedores ya no es un riesgo de primer nivel que pueda posponerse.
El argumento financiero es igualmente contundente. El Informe del Coste de una Brecha de Datos 2025 de IBM sitúa el coste medio de una brecha en la cadena de suministro en 4,91 millones de dólares — y estas brechas tardan un total de 267 días en identificarse y contenerse. El Artículo 21 de NIS2 y el Reglamento de Ejecución (UE) 2024/2690 convierten esto en un mandato de IAM, no en una cuestión de gestión de proveedores.
Su organización asume la responsabilidad regulatoria por cada ruta de acceso que concede a una parte externa.
Puntos clave
- La seguridad de la cadena de suministro NIS2 es un mandato de IAM, no una cuestión de gestión de proveedores. El Artículo 21(2)(d) hace que su organización sea legalmente responsable de cada ruta de acceso concedida a una parte externa — VPNs, APIs, consolas de administración SaaS, pipelines CI/CD y herramientas de soporte remoto incluidas.
- Las brechas de terceros se están acelerando. El DBIR 2026 de Verizon sitúa la participación de terceros en el 48% de las brechas confirmadas — frente al 30% del año anterior.
- La guía 2025 de ENISA exige MFA de Nivel 1 para todo acceso privilegiado de proveedores. FIDO2 y WebAuthn son los únicos métodos aceptables para cuentas de proveedores con acceso administrativo o a sistemas de producción. El OTP por SMS está marcado para eliminación progresiva.
- Las cuentas de proveedor compartidas son una brecha de cumplimiento. Las cuentas individuales nominativas, RBAC de mínimo privilegio y acceso privilegiado just-in-time son la base — no un endurecimiento opcional.
- Los registros de auditoría son la evidencia, no el plan de respaldo. El plazo de alerta temprana de 24 horas del Artículo 23 no puede cumplirse sin registros inmutables que muestren exactamente qué hizo una cuenta de proveedor y cuándo.
- La revocación de acceso debe ser automática y vinculada a eventos del ciclo de vida del contrato. Los tickets manuales de desaprovisionamiento son demasiado lentos. Cuando un contrato de proveedor termina, el acceso termina con él.
- El Registro de Control de Acceso de Proveedores es la unidad de responsabilidad. Un registro por relación con proveedor — ruta de acceso, tipo de identidad, nivel de MFA, evidencia — actualizado en cada ciclo de revisión.
Qué exige NIS2 de los controles de acceso de proveedores
El Artículo 21 de NIS2 exige que las entidades esenciales e importantes adopten medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos de ciberseguridad. El Artículo 21(2) enumera diez medidas mínimas. Cinco afectan directamente a la gobernanza del acceso de proveedores.
| Punto del Artículo 21(2) | Requisito | Implicación para el acceso de proveedores |
|---|---|---|
| (a) | Políticas sobre análisis de riesgos y seguridad de los sistemas de información | El riesgo de acceso de proveedores debe evaluarse y documentarse como parte de la postura de riesgo general de la entidad |
| (d) | Seguridad de la cadena de suministro, incluidos los aspectos relacionados con la seguridad relativos a las relaciones con proveedores directos o prestadores de servicios | Asigne cada proveedor a los sistemas y rutas de acceso que utiliza; gobierne esas relaciones mediante políticas y contratos |
| (e) | Seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas de información, incluida la gestión y divulgación de vulnerabilidades | Los sistemas gestionados por proveedores, las integraciones y los repositorios de código están dentro del alcance — incluidos los pipelines CI/CD y las APIs |
| (i) | Seguridad de los recursos humanos, políticas de control de acceso y gestión de activos | Las cuentas nominativas, los permisos basados en roles y las restricciones de acceso a nivel de activo se aplican a las identidades de proveedores, no solo al personal interno |
| (j) | MFA o soluciones de autenticación continua, cuando sea apropiado | El acceso remoto, privilegiado y a sistemas de producción por parte de proveedores requiere MFA o equivalente, proporcionado al riesgo |
La directiva no exige una herramienta única ni un método de MFA universal. Requiere medidas que sean apropiadas y proporcionadas al riesgo. Para el acceso de proveedores, eso significa identificar qué usuarios externos, cuentas de soporte, APIs e integraciones pueden alcanzar sus activos críticos — y luego aplicar controles que coincidan con la sensibilidad de lo que esas rutas exponen.
El Artículo 21(3) va más allá: las entidades deben tener en cuenta las vulnerabilidades específicas de cada proveedor directo y prestador de servicios, y la calidad general de sus prácticas de ciberseguridad. Eso convierte la gobernanza de identidad y acceso de proveedores en una obligación legal directa, no en una recomendación de buenas prácticas.
El Reglamento de Ejecución (UE) 2024/2690 traduce los requisitos de alto nivel del Artículo 21 en más de 150 controles de ciberseguridad específicos. Para las relaciones con proveedores, establece expectativas concretas sobre el aprovisionamiento de acceso, la gestión de cuentas privilegiadas y la notificación de incidentes — pasando la cuestión de cumplimiento de «¿tiene una política?» a «¿puede demostrar que los controles funcionan?»
La guía de implementación técnica 2025 de ENISA trata la política de seguridad de la cadena de suministro, la política de control de acceso y las políticas de cuentas privilegiadas como políticas temáticas requeridas bajo el marco NIS2.
Los 5 controles de acceso esenciales para el cumplimiento de la cadena de suministro NIS2
Si un proveedor tiene acceso remoto o privilegiado, la seguridad de la cadena de suministro NIS2 se convierte en un problema de control de identidad. La relación con el proveedor crea una ruta directa hacia su red y sistemas de información.
Aplicar control de acceso basado en roles (RBAC) estricto
Elimine las cuentas de proveedor compartidas. Cada ingeniero de proveedor que necesite acceso al sistema obtiene una cuenta nominativa individual vinculada a su compromiso específico. Las cuentas genéricas de «proveedor» hacen imposible la atribución durante un incidente — y la atribución es exactamente lo que exige el requisito de alerta temprana de 24 horas del Artículo 23.
Aplique el mínimo privilegio a nivel de rol: los proveedores reciben el acceso mínimo requerido para realizar sus funciones contratadas, limitado a activos específicos, no a segmentos amplios del sistema. Cuando el compromiso cambia, los permisos cambian con él.
Implementar MFA de Nivel 1 para acceso privilegiado
La guía técnica 2025 de ENISA clasifica el MFA en tres niveles. Para cualquier proveedor al que se conceda acceso administrativo o privilegiado, el Nivel 1 es la única opción aceptable.
| Nivel de MFA ENISA | Método de autenticación | Contexto de requisito NIS2 |
|---|---|---|
| Nivel 1 (más fuerte) | FIDO2, WebAuthn, llaves de seguridad de hardware | Obligatorio para todo acceso privilegiado y administrativo de proveedores. Resistente al phishing por diseño. |
| Nivel 2 (medio) | Aplicaciones autenticadoras TOTP, notificaciones push | Aceptable para cuentas de proveedor estándar sin privilegios elevados. |
| Nivel 3 (débil) | OTP por SMS, OTP por correo electrónico | Marcado para eliminación progresiva. No cumple los umbrales mínimos para entornos regulados. |
La implicación práctica: si los ingenieros de soporte de su MSP se autentican mediante SMS para acceder a sistemas de producción, eso es una brecha de cumplimiento según la guía actual de ENISA. Los métodos de Nivel 1 son resistentes al phishing porque la credencial criptográfica está vinculada al dominio específico — un sitio de phishing no puede interceptarla.
Implementar gestión de acceso privilegiado (PAM) y almacenamiento seguro de credenciales
El acceso just-in-time (JIT) es el modelo adecuado para equipos de soporte de terceros. Los privilegios elevados se conceden para una sesión definida, se registran completamente y se revocan automáticamente cuando la sesión termina. Sin acceso permanente, sin cuentas privilegiadas persistentes que se acumulan durante años de relaciones con proveedores.
Para las credenciales compartidas que no pueden eliminarse — cuentas de emergencia break-glass, cuentas de servicio de sistemas heredados, claves API compartidas — utilice una bóveda de credenciales con permisos basados en roles y una pista de auditoría completa. Un gestor de contraseñas empresarial puede centralizar las credenciales compartidas de proveedores, restringir el acceso por rol y conservar los registros que un auditor solicitará.
El Informe de Vulnerabilidades de la Cadena de Suministro 2026 de Black Kite encontró que los atacantes explotan vulnerabilidades un promedio de siete días antes de la divulgación pública, analizando más de 48.000 CVEs publicados en 2025. Las credenciales de proveedor de larga duración en pipelines CI/CD o cuentas de integración son una invitación abierta. Rote los tokens API en un calendario definido y revóquelos inmediatamente cuando una relación con un proveedor termine.
Mantener registros de auditoría inmutables
El Artículo 23 establece plazos estrictos de notificación de incidentes: una alerta temprana de 24 horas, una notificación formal de 72 horas y un informe final completo en un mes. Cumplir esos plazos sin registros de auditoría inmutables no es realista. Los registros son la evidencia — muestran exactamente qué hizo una cuenta de proveedor, cuándo y desde dónde.
Los registros deben ser resistentes a manipulaciones y conservarse el tiempo suficiente para respaldar tanto las investigaciones internas como las solicitudes de supervisión. Para las cuentas de proveedores específicamente, capture eventos de autenticación, escaladas de privilegios, actividad de sesión, cambios de configuración y acceso a datos sensibles. Cuando ocurre un incidente, la pregunta «¿qué tocó esta cuenta de proveedor?» necesita una respuesta en horas, no en semanas.
Automatizar la revocación de credenciales
Vincule el acceso del proveedor directamente a los eventos del ciclo de vida del contrato. Cuando un contrato de proveedor expira, se termina, o cuando un ingeniero nominativo deja el equipo del proveedor, la revocación de acceso debe ser inmediata y automática — no dependiente de un ticket manual que alguien recuerde crear.
Crear un Registro de Control de Acceso de Proveedores
Un Registro de Control de Acceso de Proveedores es el registro operativo que vincula una relación con un proveedor a derechos de acceso específicos y la evidencia de que esos derechos están controlados. Un registro por relación con proveedor. Esta es la unidad de responsabilidad.
El registro responde a las preguntas que un auditor, un regulador o su propio equipo de respuesta a incidentes hará: ¿quién tiene acceso, a qué, a través de qué ruta, con qué autenticación y quién lo aprobó?
| Campo | Qué registrar | Ejemplo |
|---|---|---|
| Proveedor y propietario | Nombre del proveedor y propietario interno del negocio | Proveedor de soporte en la nube — Operaciones TI |
| Ruta de acceso | VPN, ZTNA, administración SaaS, API, repositorio, soporte remoto | Cuenta VPN de proveedor |
| Tipo de identidad | Usuario nominativo, cuenta compartida, cuenta de servicio, token | Ingeniero de soporte nominativo |
| Control | Nivel de MFA, aprobación PAM, límite de tiempo, restricción IP, acceso a bóveda | MFA Nivel 1 más aprobación de sesión privilegiada |
| Evidencia | Registros, revisión de acceso, cláusula contractual, ticket | Registro de revisión trimestral |
La guía 2025 de ENISA espera que la política de seguridad de la cadena de suministro gobierne las relaciones con proveedores directos y prestadores de servicios e identifique los roles de los proveedores: proveedor de TIC, proveedor de servicios gestionados (MSP), proveedor de servicios de seguridad gestionados (MSSP) y proveedor de nube.
Sus registros deben reflejar estas distinciones. El perfil de riesgo de un MSP con acceso privilegiado a su infraestructura difiere significativamente de un proveedor SaaS con acceso API de solo lectura, y los controles deben diferir en consecuencia.
Cómo auditar su acceso actual de proveedores
Comience con un ejercicio completo de mapeo de proveedores. Liste cada conexión externa: VPNs, APIs, consolas de administración SaaS, herramientas de soporte remoto, integraciones CI/CD y acceso a repositorios. Para cada conexión, identifique el tipo de identidad, método de autenticación, nivel de privilegio y el propietario interno responsable de esa relación.
Luego trabaje a través de esta Lista de verificación previa a la auditoría de acceso de proveedores (7 puntos):
- Cada cuenta de proveedor es nominativa — no se utilizan credenciales genéricas compartidas para acceso privilegiado.
- El nivel de MFA coincide con la sensibilidad del acceso: Nivel 1 para privilegiado, Nivel 2 mínimo para estándar.
- Todas las cuentas de proveedor se aprovisionan a través de controles de directorio con desaprovisionamiento automatizado.
- Los contratos con proveedores incluyen requisitos de cuentas nominativas, obligaciones de MFA, notificación de brechas en 24 horas, derechos de auditoría y divulgación de subcontratistas.
- PAM o registro de sesiones cubre todas las sesiones privilegiadas de proveedores.
- Los tokens API y las credenciales de cuentas de servicio tienen calendarios de rotación definidos.
- La cadencia de revisión de acceso está documentada: trimestral para proveedores críticos, anual para todos los demás, inmediatamente después de cualquier terminación o incidente.
Actualice los contratos con proveedores para incluir cláusulas explícitas de notificación de brechas en 24 horas y derechos de auditoría si aún no las tienen. La guía 2025 de ENISA establece que los contratos o SLAs deben cubrir requisitos de ciberseguridad, obligaciones de notificación de incidentes, gestión de vulnerabilidades, requisitos de subcontratación y obligaciones de terminación.
El coste del incumplimiento: multas y responsabilidad personal
Las entidades esenciales enfrentan multas máximas de hasta 10 millones de euros o el 2% de la facturación anual global bajo NIS2, lo que sea mayor. Las entidades importantes enfrentan hasta 7 millones de euros o el 1,4% de la facturación. Estos son máximos administrativos — los reguladores aplican proporcionalidad — pero son el techo que su junta directiva necesita entender.
El Artículo 20 va más allá. Establece responsabilidad personal para ejecutivos de nivel C y órganos de dirección. Los ejecutivos pueden enfrentar prohibiciones temporales de ocupar puestos directivos si se determina que su organización ha sido gravemente negligente en sus obligaciones de ciberseguridad. La obligación de aprobar las medidas de gestión de riesgos de ciberseguridad y supervisar su implementación recae en la dirección, no solo en el equipo de TI.
La conexión con el acceso de proveedores es directa. Si una brecha se remonta a una cuenta de proveedor no controlada — sin MFA, sin registro de sesiones, sin desaprovisionamiento después del fin del contrato — y la dirección no puede producir evidencia de que los controles estaban en vigor y se revisaban, ese es el escenario para el que se redactó el Artículo 20.
Incorporar requisitos de acceso en contratos y revisiones de proveedores
Los controles de acceso fallan cuando los contratos con proveedores no definen responsabilidades. Traduzca la guía de ENISA en cláusulas contractuales concretas:
- Los proveedores deben usar cuentas nominativas y aplicar MFA de Nivel 1 para acceso privilegiado o remoto.
- Está prohibido compartir credenciales.
- Los proveedores deben notificar al cliente los incidentes sin demora indebida, y no más tarde de 24 horas para incidentes significativos.
- Los subcontratistas que requieran acceso deben ser divulgados y estar sujetos a controles equivalentes.
- Los proveedores deben respaldar la retención de registros y las solicitudes de auditoría.
- La información debe ser devuelta o eliminada al terminar el contrato.
Las revisiones de acceso deben seguir una cadencia definida: como mínimo anualmente para todos los proveedores, trimestralmente para proveedores con acceso privilegiado o a sistemas de producción, e inmediatamente después de un incidente, cambio de contrato, cambio de rol o terminación.
Conservar evidencia de auditoría para el cumplimiento de NIS2
La evidencia de auditoría es lo que separa un control documentado de una afirmación. Durante una auditoría interna, una revisión de cliente o una solicitud de supervisión, necesita producir registros — no descripciones de lo que pretendía hacer.
La evidencia útil incluye: registro de proveedores, matriz de control de acceso, solicitudes de acceso aprobadas, informes de inscripción de MFA, registros de aprobación PAM, permisos de bóveda de contraseñas, registros de rotación de tokens API, aprobaciones de revisión de acceso, cláusulas contractuales con proveedores, registros de notificación de incidentes, tickets de remediación de vulnerabilidades y registros de desaprovisionamiento.
La aceptación del riesgo para el acceso privilegiado de proveedores debe tener un propietario responsable. Esa aceptación, y los controles implementados, deben ser visibles para la dirección a través de informes periódicos — no enterrados en una hoja de cálculo que solo el equipo de TI puede encontrar.
10 pasos para el cumplimiento de acceso de proveedores NIS2
Mapee el acceso de proveedores, aplique controles, contracte las obligaciones, monitorice continuamente y conserve evidencia. La tabla siguiente consolida cada paso de implementación en una única referencia — úsela como una lista de verificación de trabajo, no como un ejercicio único.
| Paso | Qué hacer | Evidencia clave |
|---|---|---|
| 1 | Mapear el acceso de proveedores | Liste cada conexión externa: VPNs, APIs, consolas de administración SaaS, integraciones CI/CD, herramientas de soporte remoto. Asigne un propietario interno a cada una. |
| 2 | Crear un Registro de Control de Acceso de Proveedores | Un registro por proveedor: ruta de acceso, tipo de identidad, método de autenticación, nivel de privilegio, cadencia de revisión. |
| 3 | Aplicar cuentas nominativas y RBAC | Reemplace las cuentas de proveedor compartidas con cuentas individuales nominativas. Limite los permisos al compromiso específico, no a segmentos amplios del sistema. |
| 4 | Aplicar MFA por nivel | Nivel 1 (FIDO2/WebAuthn) para todo acceso privilegiado y remoto. Nivel 2 (TOTP) mínimo para cuentas estándar. Eliminar progresivamente el OTP por SMS. |
| 5 | Implementar PAM y almacenamiento seguro de credenciales | Acceso JIT para sesiones privilegiadas, registro completo de sesiones, bóveda para credenciales compartidas inevitables con acceso basado en roles. |
| 6 | Rotar y escanear secretos | Defina calendarios de rotación para tokens API y credenciales de cuentas de servicio. Escanee repositorios en busca de secretos expuestos. |
| 7 | Actualizar contratos con proveedores | Incluya requisitos de cuentas nominativas, obligaciones de MFA Nivel 1, notificación de brechas en 24 horas, derechos de auditoría, divulgación de subcontratistas, obligaciones de terminación. |
| 8 | Realizar revisiones de acceso | Trimestralmente para proveedores críticos, anualmente para todos los demás. Inmediatamente después de cualquier incidente, cambio de contrato o terminación. |
| 9 | Mantener registros de auditoría inmutables | Capture eventos de autenticación, escaladas de privilegios, actividad de sesión y cambios de configuración para todas las cuentas de proveedores. |
| 10 | Automatizar el desaprovisionamiento | Vincule la revocación de acceso a eventos del ciclo de vida del contrato. Sin tickets manuales — la revocación debe ser inmediata y automática. |
El Registro de Control de Acceso de Proveedores une las filas 1 a 10: un documento por relación, actualizado en cada ciclo de revisión, visible para la dirección.
Si su equipo gestiona contraseñas de proveedores compartidas o credenciales privilegiadas de proveedores, el software de compartición de contraseñas para empresas como Passwork puede ayudar a organizar el acceso, los permisos y la evidencia de auditoría en un entorno controlado. Ese es un componente dentro de un programa de control de acceso más amplio, no un sustituto del trabajo de gobernanza descrito anteriormente.
Preguntas frecuentes
¿Exige NIS2 MFA para todo acceso de proveedores?
El Artículo 21(2)(j) de NIS2 se refiere a MFA o autenticación continua «cuando sea apropiado», por lo que se aplica un enfoque basado en riesgos. La guía 2025 de ENISA exige MFA resistente al phishing de Nivel 1 (FIDO2, WebAuthn) para todo acceso privilegiado y administrativo. Los métodos de Nivel 2 son aceptables para cuentas estándar sin privilegios elevados. El OTP por SMS y correo electrónico está marcado para eliminación progresiva en entornos regulados.
¿Qué es el Reglamento de Ejecución (UE) 2024/2690?
El Reglamento de Ejecución 2024/2690 traduce los requisitos amplios del Artículo 21 de NIS2 en más de 150 controles de ciberseguridad específicos. Para la seguridad de la cadena de suministro, establece expectativas concretas sobre el aprovisionamiento de acceso de proveedores, la gestión de cuentas privilegiadas y la notificación de incidentes. Se aplica directamente a proveedores DNS, servicios en la nube, proveedores de servicios gestionados y otros tipos de entidades designadas.
¿Se aplica NIS2 a subcontratistas y cuartas partes?
El Artículo 21(2)(d) se centra en las relaciones con proveedores directos y prestadores de servicios. Los contratos deben requerir la divulgación de subcontratistas y la extensión de los requisitos de ciberseguridad siempre que el acceso del proveedor o la continuidad del servicio dependa de un subcontratista. La guía 2025 de ENISA respalda esto a través de sus recomendaciones sobre requisitos de subcontratación en los SLAs de proveedores.
¿Qué evidencia demuestra que los controles de acceso de proveedores funcionan?
La evidencia útil incluye registros de acceso de proveedores, registros de inscripción e inicio de sesión de MFA, aprobaciones de sesión PAM, cláusulas contractuales que especifican requisitos de acceso, aprobaciones de revisión de acceso con fechas, tickets de desaprovisionamiento y registros de notificación de incidentes. La combinación demuestra que los controles existen, se aplican y se revisan en un calendario definido.
¿Con qué frecuencia debe revisarse el acceso de proveedores?
Revise todo el acceso de proveedores al menos anualmente. Para proveedores con acceso privilegiado o a sistemas de producción, las revisiones trimestrales son más apropiadas. Active una revisión fuera de ciclo inmediata después de cualquier incidente, cambio de contrato, cambio de personal en el lado del proveedor o terminación de contrato.
¿Qué es un Registro de Control de Acceso de Proveedores?
Un Registro de Control de Acceso de Proveedores es un documento por relación que asigna un proveedor a las cuentas específicas, rutas de acceso, tipos de identidad, controles de autenticación y registros de evidencia asociados con esa relación. Es la unidad operativa para demostrar que el riesgo de la cadena de suministro se ha convertido en gobernanza de acceso aplicable bajo el Artículo 21 de NIS2.
Alex Muntyan
Alex Muntyan
Alex Muntyan
Tabla de contenidos
- Puntos clave
- Qué exige NIS2 de los controles de acceso de proveedores
- Los 5 controles de acceso esenciales para el cumplimiento de la cadena de suministro NIS2
- Crear un Registro de Control de Acceso de Proveedores
- Cómo auditar su acceso actual de proveedores
- El coste del incumplimiento: multas y responsabilidad personal
- Incorporar requisitos de acceso en contratos y revisiones de proveedores
- Conservar evidencia de auditoría para el cumplimiento de NIS2
- 10 pasos para el cumplimiento de acceso de proveedores NIS2
- Preguntas frecuentes
Tabla de contenidos
- Puntos clave
- Qué exige NIS2 de los controles de acceso de proveedores
- Los 5 controles de acceso esenciales para el cumplimiento de la cadena de suministro NIS2
- Crear un Registro de Control de Acceso de Proveedores
- Cómo auditar su acceso actual de proveedores
- El coste del incumplimiento: multas y responsabilidad personal
- Incorporar requisitos de acceso en contratos y revisiones de proveedores
- Conservar evidencia de auditoría para el cumplimiento de NIS2
- 10 pasos para el cumplimiento de acceso de proveedores NIS2
- Preguntas frecuentes
Gestor de contraseñas autohospedado para su empresa
Passwork ofrece la ventaja de un trabajo en equipo eficaz con contraseñas corporativas en un entorno totalmente seguro
Más información