Lo viejo conectado a lo nuevo, el reloj de diciembre de 2026 y las medidas que cualquier organización debería tomar ya
En las dos primeras partes de esta serie analizamos cómo la EN 319 401 v3.2.1 blinda la cadena de suministro de los prestadores de confianza cualificados, y cómo existe una brecha real entre ese nivel de protección y el que tienen el resto de las entidades que se conectarán al ecosistema eIDAS 2.0: hospitales, administraciones públicas, entidades financieras, ayuntamientos y universidades. Entidades con obligaciones de ciberseguridad bajo la NIS2 o DORA, pero con mecanismos de supervisión menos granulares, implantación desigual y, en algunos casos, fuera del alcance de cualquier directiva.
En esta tercera parte bajamos al terreno, porque detrás de esa brecha regulatoria hay un problema técnico muy concreto que la amplifica: los sistemas legacy. Y porque no basta con describir el riesgo; hace falta hablar de qué se puede hacer.
El fantasma en la máquina
Hay una verdad incómoda que rara vez aparece en las presentaciones brillantes sobre identidad digital europea: la mayoría de los sistemas críticos que deberán integrarse con el eIDAS 2.0 fueron diseñados cuando Nokia vendía teléfonos indestructibles y nadie había oído hablar de blockchain. Hospitales con sistemas de gestión de pacientes que corren en mainframes de los años ochenta; administraciones públicas con bases de datos que usan protocolos de seguridad obsoletos; infraestructuras críticas con sistemas de control industrial que nunca fueron pensados para conectarse a internet.
Y ahora el eIDAS 2.0 espera que todos estos sistemas se integren con carteras digitales, autenticación reforzada y ecosistemas de credenciales verificables.
Estos sistemas no fueron diseñados para resistir amenazas modernas. Sus protocolos de autenticación son débiles, sus mecanismos de cifrado están obsoletos y sus arquitecturas no contemplan conceptos como la confianza cero (Zero Trust) o la segregación de redes. Cuando se conectan al ecosistema eIDAS 2.0, arrastran todas sus vulnerabilidades consigo. Muchas de las organizaciones que los operan están atrapadas, pues actualizar sería técnicamente complejo o directamente imposible (el código fuente ya no existe, los desarrolladores originales no están disponibles) y reemplazarlos requeriría inversiones que no pueden asumir. El resultado son «parches» para integrar el legacy con el eIDAS 2.0: capas intermedias de software, adaptadores de protocolos, conversiones de datos. Cada capa añade un punto de fricción donde pueden aparecer vulnerabilidades.
¿Cómo valida un prestador cualificado la identidad de un ciudadano cuando la base de datos de referencia está en un sistema legacy sin auditoría de accesos? ¿Cómo se garantiza la trazabilidad cuando el sistema antiguo no registra quién modificó qué y cuándo? La EN 319 401 v3.2.1 exige al prestador que proteja los activos que recibe a través de su cadena de suministro, pero no puede resolver que el origen de esos activos sea un sistema sobre el que no tiene control ni visibilidad.
La asimetría del tiempo
Actualizar un sistema legacy crítico no es un proyecto de meses, sino de años: requiere análisis exhaustivo del código existente, rediseño de la arquitectura, migración de datos, pruebas extensivas, formación del personal y planes de contingencia. Y todo ello manteniendo operativos los servicios, porque no se puede apagar un hospital para actualizar su sistema de historiales ni paralizar una administración pública para migrar su base de datos de ciudadanos.
Mientras tanto, un atacante puede identificar vulnerabilidades en esos sistemas y ejecutar un ataque en cuestión de horas.
El eIDAS 2.0, con su calendario de implantación fijado en diciembre de 2026, está forzando integraciones que, inevitablemente, priorizarán el cumplimiento de los plazos. Y cuando el tiempo apremia, la seguridad suele ser lo primero que se sacrifica.
Los precedentes ya existen
En 2017, el ataque WannaCry paralizó el Servicio Nacional de Salud británico: hospitales colapsados, ambulancias desviadas y cirugías canceladas. El vector fue sencillo: sistemas Windows obsoletos sin parches de seguridad. El NHS sabía que sus sistemas estaban desactualizados y que eran vulnerables, pero no tenía presupuesto ni capacidad operativa para actualizarlos sin interrumpir servicios críticos.
Ese mismo dilema lo enfrentan ahora miles de organizaciones europeas que deben integrarse con el eIDAS 2.0. La diferencia es que WannaCry era ransomware relativamente simple; los atacantes que apunten al ecosistema eIDAS 2.0 serán grupos APT con recursos estatales, ciberdelincuentes sofisticados y actores motivados por el espionaje o el sabotaje estratégico. Y sus objetivos no serán solo bloquear sistemas, sino robar identidades a escala masiva, manipular credenciales digitales y socavar la confianza en la infraestructura digital europea.
En 2023, el ataque a 3CX comprometió a cientos de organizaciones globales a través de una actualización legítima envenenada, en un caso pionero de compromiso en cascada que se remontaba a otro ataque anterior contra Trading Technologies. Ese mismo año, el compromiso de Okta afectó a miles de clientes que confiaban en sus sistemas de autenticación. Ninguno de estos ataques necesitó romper al proveedor más protegido de la cadena; bastó con encontrar al más vulnerable.
Qué puede hacer cualquier organización que se conecte al eIDAS 2.0
No hace falta estar sujeto a la EN 319 401 para tomar medidas sensatas. Y para las entidades que ya tienen obligaciones bajo la NIS2 o DORA, lo que sigue puede servir como punto de partida para cerrar la brecha entre la obligación genérica y la implantación real.
Saber de quién se depende. La mayoría de las organizaciones no tienen un inventario completo de los proveedores y componentes de software que intervienen en sus sistemas críticos. La EN 319 401 v3.2.1 exige ese inventario a los TSP por una razón: sin él, es imposible evaluar riesgos ni responder a un incidente. Esa lógica se aplica a cualquier organización.
Evaluar la seguridad de las integraciones legacy. Antes de conectar un sistema antiguo al ecosistema eIDAS 2.0, alguien tiene que evaluar qué vulnerabilidades tiene ese sistema y qué riesgos introduce la integración. No como formalidad, sino como análisis técnico real.
Segregar lo que no se puede actualizar. Si un sistema legacy no puede modernizarse a tiempo, al menos debe estar aislado del resto del ecosistema mediante zonas desmilitarizadas, firewalls de aplicación y controles de acceso estrictos. Una vulnerabilidad en el legacy no debería poder propagarse al eIDAS 2.0.
Validar la integridad de lo que se recibe y de lo que se envía. Cuando un sistema moderno consume datos de un sistema legacy, debe haber mecanismos que detecten si los datos han sido manipulados. Lo mismo en sentido inverso.
Tener un plan de respuesta. Cuando se detecta que un sistema integrado con el eIDAS 2.0 ha sido comprometido, deben existir procedimientos claros y rápidos para aislarlo, revocar las credenciales afectadas y notificar a todas las partes dependientes. Improvisar durante un incidente de seguridad es la forma más eficaz de convertir un problema en una catástrofe.
No confundir el cumplimiento de plazos con la seguridad. La presión por estar conectados al eIDAS 2.0 en diciembre de 2026 no debería llevar a nadie a integrar sistemas sin las mínimas garantías. Una integración insegura no es mejor que no estar integrado; es peor, porque crea una falsa sensación de protección.
El reloj corre
Diciembre de 2026 llegará. El eIDAS 2.0 se implantará, las carteras digitales se desplegarán y miles de sistemas de distintas generaciones tecnológicas estarán conectados al ecosistema de identidad digital más ambicioso de Europa. Los prestadores de servicios de confianza cualificados estarán protegidos por la EN 319 401 v3.2.1 y sus auditorías de conformidad: un blindaje sólido y necesario. Pero la cadena no termina en ellos. A su alrededor hay entidades con obligaciones más generales, mecanismos de supervisión menos granulares, implantación desigual y, en algunos casos, sin ningún marco de referencia comparable. Entidades que operan con sistemas legacy que arrastran décadas de deuda técnica.
Esa combinación, brecha de supervisión más deuda técnica, es la que los atacantes van a explotar. Porque no buscan la puerta más reforzada, sino la ventana que alguien dejó abierta. El ecosistema eIDAS 2.0 será tan seguro como su componente menos protegido. Y, ahora mismo, ese componente no es un prestador de confianza cualificado: es un sistema de 1997 en el sótano de un ayuntamiento al que alguien le ha puesto una pasarela de integración y una fecha límite.
