Todas las entidades del ecosistema eIDAS 2.0 tienen obligaciones de ciberseguridad; no todas tienen el mismo nivel de control
En la primera parte de este artículo analizamos cómo la nueva ETSI EN 319 401 v3.2.1 refuerza la seguridad de la cadena de suministro de los prestadores de servicios de confianza: la cláusula 7.14, la extensión de las políticas de seguridad a proveedores directos, los nuevos requisitos de verificación, formación y control de acceso, y el anclaje con la NIS2 y el Reglamento de Ejecución 2024/2690.
Los prestadores cualificados que se auditen contra esta norma estarán mejor protegidos que nunca. Pero el ecosistema eIDAS 2.0 no se agota en ellos. A su alrededor hay miles de entidades que se conectarán al ecosistema, consumirán y alimentarán datos de identidad e integrarán sus sistemas con carteras digitales y credenciales verificables: hospitales, administraciones públicas, entidades financieras, universidades, ayuntamientos.
Todas ellas forman parte de la cadena, y la fortaleza de esa cadena se mide por su eslabón más débil.
La brecha no es entre regulados y no regulados
Conviene ser precisos. No hablamos de entidades que operen en un vacío regulatorio. La Directiva NIS2 cubre a buena parte de ellas: los hospitales entran en el sector sanitario como entidades esenciales; las entidades financieras están sujetas, además, a DORA; y las administraciones públicas, tanto a nivel central como regional, también quedan incluidas en el ámbito de la directiva. Todas tienen la obligación de adoptar medidas de seguridad en la cadena de suministro conforme al artículo 21(2)(d) de la NIS2.
Existe, no obstante, una diferencia sustancial entre tener una obligación legal genérica y estar auditado periódicamente contra requisitos técnicos específicos.
Un prestador de servicios de confianza cualificado se somete a auditorías de conformidad realizadas por organismos de evaluación acreditados, contra una norma que detalla con precisión qué procedimientos debe tener para su cadena de suministro, qué controles de acceso debe aplicar a sus proveedores, cómo debe verificar los antecedentes de las personas de terceros que acceden a sus sistemas, qué formación deben tener sus subcontratistas y cómo debe inventariar y clasificar los activos que recibe de fuera. Si no cumple, pierde su estatus de cualificado; el incentivo para hacerlo bien es, por tanto, directo e inmediato.
Un hospital sujeto a la NIS2 tiene la obligación genérica de garantizar la seguridad de su cadena de suministro, pero no existe, hoy por hoy, una norma técnica equivalente a la EN 319 401 que le diga con el mismo nivel de detalle cómo hacerlo. Su supervisión no pasa por una auditoría de conformidad contra criterios técnicos específicos de cadena de suministro; el mecanismo de control es distinto y, en la práctica, menos granular.
Luego están las entidades que directamente quedan fuera del radar. La NIS2 se aplica a entidades medianas y grandes; un ayuntamiento pequeño, un centro de salud comarcal o una universidad de tamaño reducido pueden no alcanzar el umbral de aplicación de la directiva. Y, sin embargo, esas mismas entidades pueden estar conectándose al ecosistema eIDAS 2.0 porque necesitan ofrecer servicios de administración electrónica, gestionar historiales médicos o verificar identidades de estudiantes.
A esto se añade un problema de calendario: la transposición de la NIS2 a nivel nacional acumula retrasos en muchos Estados miembros y la madurez en ciberseguridad de estos sectores es muy desigual. Que exista la obligación legal no significa que se esté cumpliendo con el mismo rigor que en el sector de servicios de confianza, donde la auditoría de conformidad es condición para operar.
El resultado es una brecha, y no entre regulados y no regulados, sino entre quienes están sujetos a un modelo de supervisión detallado, específico y auditable, y quienes tienen obligaciones más generales, supervisión menos granular e implantación desigual. Esa brecha es exactamente lo que un atacante busca.
Escenarios de ataque que explotan la brecha
Datos envenenados desde el origen. Una administración pública conecta su base de datos de ciudadanos, un sistema que lleva décadas funcionando, con el nuevo sistema de emisión de credenciales del eIDAS 2.0. El sistema tiene vulnerabilidades que nunca fueron parcheadas porque «funciona y no hay presupuesto para tocarlo». La administración tiene obligaciones de ciberseguridad bajo la NIS2, pero su evaluación de riesgos en la cadena de suministro no ha llegado al nivel de detalle de una auditoría contra la EN 319 401.
Un atacante explota la vulnerabilidad, accede a la base de datos, modifica registros de identidad y obtiene credenciales digitales legítimas a nombre de identidades falsas. El prestador cualificado del eIDAS 2.0 no detecta nada porque confía en que los datos que recibe son íntegros; su auditoría de conformidad está en orden, pero los datos están envenenados desde el origen.
Escalada de privilegios en un sistema hospitalario integrado. Un hospital integra su sistema de gestión de historiales médicos con el Espacio Europeo de Datos de Salud, que requiere autenticación mediante eIDAS 2.0. El hospital es una entidad esencial bajo la NIS2 y tiene obligaciones de ciberseguridad. Pero su sistema legacy tiene vulnerabilidades de escalada de privilegios que no han sido detectadas porque la supervisión de la NIS2 en el sector sanitario no entra al nivel de detalle de auditar componente por componente la cadena de suministro tecnológica del hospital.
Un atacante compromete una cuenta con permisos bajos, escala a administrador del sistema legacy y, desde ahí, accede a las claves de integración con el ecosistema eIDAS 2.0. Puede suplantar al hospital, emitir certificados médicos falsos, modificar historiales clínicos y acceder a datos sensibles de pacientes.
El proveedor compartido con distinto nivel de control. Un proveedor de módulos criptográficos suministra sus productos tanto a prestadores cualificados como a administraciones públicas y entidades financieras. Un atacante compromete el módulo para que genere claves predecibles. Los prestadores cualificados, obligados por la EN 319 401 v3.2.1 a mantener procedimientos específicos de cadena de suministro, inventarios de activos clasificados y controles sobre sus proveedores, están en mejor posición para detectar la anomalía; aunque conviene no sobrevender esta capacidad, pues un compromiso de fábrica puede superar incluso auditorías rigurosas, como ilustra el caso de Dual_EC_DRBG en los productos de Juniper. Las entidades que utilizan el mismo módulo sin estar sujetas a ese nivel de control técnico, por su parte, probablemente no lo detecten.
La actualización que unos verifican y otros no. Un atacante compromete el sistema de distribución de actualizaciones de un proveedor de software utilizado tanto por prestadores cualificados como por organismos públicos. Los prestadores cualificados, con sus procedimientos de control de cambios auditados, validan la integridad de la actualización antes de desplegarla. El ayuntamiento que usa el mismo software, quizá por debajo del umbral de la NIS2, la instala automáticamente sin ninguna verificación. El atacante tiene su punto de entrada al ecosistema.
La cadena no termina donde termina la norma
Estos escenarios comparten un patrón: en todos ellos el prestador cualificado hace su trabajo, cumple la EN 319 401 v3.2.1, tiene sus controles de cadena de suministro y pasa sus auditorías; y, en todos ellos, el ataque entra por otro sitio.
Esto no es un fallo de la norma. La EN 319 401 v3.2.1 hace exactamente lo que debe hacer: blindar a los prestadores de confianza con requisitos detallados y auditables. El problema es que la cadena de confianza del eIDAS 2.0 se extiende mucho más allá de los prestadores cualificados, y el nivel de protección desciende bruscamente cuando salimos de su perímetro.
Mientras esa brecha exista, los atacantes la encontrarán. No buscan la puerta más reforzada, sino la ventana que alguien dejó abierta.
En la tercera parte de este artículo bajamos al terreno más operativo: por qué los sistemas legacy son el mayor amplificador de riesgo en esta ecuación, qué precedentes reales tenemos ya y qué puede hacer cualquier organización, esté o no sujeta a una norma técnica específica, para no ser la ventana abierta.
