Archivo de la categoría: Autoridad de Certificación

32 años de certificación y firma electrónica en España (1994-2026)

En 1994 la web apenas tenía un año de vida pública y Netscape acababa de inventar SSL. En 2026, los Estados miembros apuran el plazo para ofrecer a cada ciudadano una Cartera de Identidad Digital Europea en su móvil. Entre ambos momentos caben 32 años de certificación y firma electrónica en España: pioneros privados, normas que llegaron tarde, el DNI electrónico, dos reglamentos europeos y una ley española, la 6/2020, que cerró el ciclo abierto en 1999.

En octubre de 2006 publiqué en este blog «12 años de firma electrónica en España», una versión ampliada de un artículo que publiqué en la revista eSecurity Latinoamérica. Veinte años después, merece la pena recoger aquella historia y continuarla. Las primeras partes de este artículo resumen lo que entonces conté; las siguientes, lo que ha pasado desde entonces.

1994-1999: los pioneros

El sector nació de la mano del comercio electrónico. Netscape creó SSL en 1994 y los «servidores seguros» necesitaban un certificado que acreditara su identidad. RSA escindió su departamento de certificación en una empresa nueva, Verisign, que dominó el mercado mundial, con la sudafricana Thawte como competidora agresiva en precio.

En España, en 1995, Banesto puso en marcha la primera Autoridad de Certificación privada y no académica. Era una CA de un solo nivel, sin jerarquía, que emitía certificados de servidor SSL y de correo S/MIME y que autenticaba a las tiendas conectadas a la pasarela de pagos del banco. Las páginas de novedades de banesto.es que conserva la Wayback Machine, de julio de 1997, anuncian «Banesto lanza la emisión de Certificados» junto a otros hitos de la época: el primer servidor seguro de España, la tarjeta de dinero virtual Virtu@lCash, la tienda virtual y una oficina navegable en VRML. Casi a la vez, las universidades politécnicas de Madrid y Barcelona trabajaban en proyectos académicos como ICE-TEL.

Le siguieron otras iniciativas privadas:

IPS-CA vendía certificados desde principios de 1996 y fue de las primeras en lograr que Microsoft incluyera su raíz en Internet Explorer.
ACE, la Agencia de Certificación Electrónica, se constituyó en mayo de 1997 con CECA, Sistema 4B, SERMEPA y Telefónica, y desplegó una de las primeras infraestructuras del mundo para SET, el protocolo de Visa y Mastercard para pagos con tarjeta.
FESTE, la Fundación para el Estudio de la Seguridad de las Telecomunicaciones, nació a finales de 1997 en Barcelona, presidida por Miquel Roca. Notarios, corredores de comercio y abogados aportaron la visión de la seguridad jurídica preventiva y la fe pública, que influyó en la Directiva europea.

Mientras tanto, la exportación de criptografía seguía controlada por Estados Unidos. Los navegadores fuera de ese país solo cifraban con 40 bits efectivos hasta que, en 2000, se liberalizó del todo. Lo conté con detalle en «Cuando la criptografía era un arma».

1999-2006: de la Directiva a la Ley 59/2003

El Real Decreto-ley 14/1999, de 17 de septiembre, se adelantó incluso a la Directiva 1999/93/CE, de 13 de diciembre de 1999. Pero aquella norma, y la Orden de 21 de febrero de 2000 que regulaba la acreditación de prestadores, sirvieron de poco. Preveían un registro en el Ministerio de Justicia que nunca se creó y una evaluación sin normas ni evaluadores. Durante cuatro años, la Directiva tuvo más valor práctico para los prestadores privados que la norma española que la trasponía, mientras sucesivas normas atribuían a la FNMT-RCM competencias que debían prestarse en libre competencia.

El sector se organizó igualmente. En junio de 2000 nació AECODI, la Asociación de Entidades de Confianza Digital, y en julio AC Camerfirma se independizó del Consejo Superior de Cámaras, con la red de autoridades de registro más densa del país. En 2001 llegó Firmaprofesional, ligada a los colegios profesionales catalanes. Abogados, ingenieros de caminos, registradores y notarios (con FESTE, después con la FNMT y finalmente con ANCERT) lanzaron sus propias CA. ANF AC apostó por la factura electrónica y por UBL.

Camerfirma tenía un antecedente europeo: ChamberSign, creada en 1999 por Eurochambres y varias organizaciones camerales europeas, entre ellas la española, para que las firmas electrónicas de empresas certificadas por las cámaras fueran interoperables entre países. Era, avant la lettre, la preocupación por el reconocimiento transfronterizo que eIDAS resolvería quince años después.

Las administraciones abrieron grietas en el monopolio de hecho. La AEAT, con la Orden HAC/1181/2003, admitió certificados de prestadores distintos de la FNMT. El Real Decreto 209/2003 impulsó los registros telemáticos de los ministerios. Comunidades como la valenciana (ACCV), la catalana (CatCert) y la vasca (Izenpe) reconocieron también a prestadores privados.

Los usos reales crecían despacio. Según el estudio de AECE-fecemd de 2003, solo el 37,8% de los entrevistados usaba Internet y apenas uno de cada cinco internautas compraba en línea, con la desconfianza como freno principal. Hacia 2003 la firma se usaba sobre todo en las relaciones con la AEAT, en la factura telemática (Orden HAC/3134/2002), en los partes de accidentes de trabajo del sistema Delt@ y, ya integrada, en Office XP y Acrobat. La Ley 26/2003 abrió además la puerta al voto electrónico de los accionistas en las juntas de las sociedades cotizadas.

La Ley 59/2003, de 19 de diciembre, de firma electrónica cambió las expectativas. Sustituyó el registro fallido por un censo de prestadores en el Ministerio de Ciencia y Tecnología y aclaró el régimen de los certificados reconocidos. En aquel censo figuraba, entre los prestadores de certificados no reconocidos, BANESTO CA.

El ciclo de esos primeros doce años culminó en marzo de 2006 con la expedición en Burgos del primer DNI electrónico, regulado por el Real Decreto 1553/2005.

2006-2014: la administración electrónica toma el relevo

En 2006 confiaba en que el DNIe haría ubicua la firma electrónica, con seis millones de tarjetas al año. Lo segundo se cumplió y lo primero no del todo: los lectores de tarjetas y el software de cada sistema operativo frenaron su uso masivo. El certificado en fichero de la FNMT siguió siendo, durante años, la herramienta habitual de ciudadanos y gestorías.

El impulso vino del lado normativo y de la Administración:

La Ley 11/2007, de acceso electrónico de los ciudadanos a los servicios públicos, reconoció el derecho a relacionarse electrónicamente y dio cobertura a los sellos de órgano y a la actuación administrativa automatizada.
La Ley 56/2007, de medidas de impulso de la sociedad de la información, retocó la Ley 59/2003, como esperábamos en 2006.
Los Esquemas Nacionales de Seguridad e Interoperabilidad (Reales Decretos 3/2010 y 4/2010) y la plataforma de validación @firma ordenaron el uso de certificados de distintos prestadores en todas las administraciones.
Cl@ve, desde 2014, ofreció alternativas a la tarjeta y al certificado para trámites de menor riesgo.
Las Leyes 39/2015 y 40/2015 generalizaron la obligación de relacionarse electrónicamente para empresas y profesionales y distinguieron entre identificación y firma.

En 2015, el DNI 3.0 incorporó la interfaz sin contacto (NFC), pensando ya en el móvil. Mientras, la Directiva de 1999 envejecía: había creado mercados nacionales poco interoperables, y Bruselas preparaba su sustitución por un reglamento de aplicación directa.

2014-2016: el Reglamento eIDAS

El Reglamento (UE) 910/2014, de 23 de julio, sustituyó a la Directiva 1999/93/CE y se aplica a los servicios de confianza desde el 1 de julio de 2016. Al ser un reglamento, rige directamente en todos los Estados miembros, sin trasposición. Cambió el vocabulario: de «prestadores de servicios de certificación» y «certificados reconocidos» pasamos a prestadores cualificados de servicios de confianza y certificados cualificados.

El cambio de nombre zanjaba una vieja queja. Ya en 2004 se criticaba en la revista Información Comercial Española que la versión española de la Directiva hubiera traducido «qualified certificates» como «certificados reconocidos», cuando «cualificados» era más fiel y evitaba confundirlos con la figura homónima de la normativa española. eIDAS acabó dando la razón a quienes lo pedíamos.

Sus aportaciones principales fueron cuatro:

Amplió el catálogo de servicios: además de la firma, el sello electrónico de persona jurídica, el sello de tiempo, la entrega electrónica certificada, los certificados de autenticación de sitios web y la validación y conservación de firmas y sellos.
Creó las listas de confianza nacionales: estar en ellas es la prueba de la cualificación, verificable por cualquiera en toda la Unión.
Exigió una auditoría de conformidad periódica por un organismo acreditado, apoyada en normas ETSI y CEN.
Estableció el reconocimiento mutuo de la identificación electrónica notificada, obligatorio desde septiembre de 2018, y con él el nodo eIDAS español.

España se convirtió en uno de los países con más prestadores cualificados de la Unión, con una mezcla poco frecuente de prestadores públicos, corporativos y privados. Una parte de aquel ecosistema nacido en los años noventa y dos mil se integró en grupos internacionales, y aparecieron prestadores nuevos especializados en servicios de valor añadido.

2020: la Ley 6/2020 cierra el ciclo de 1999

La Ley 6/2020, de 11 de noviembre, reguladora de determinados aspectos de los servicios electrónicos de confianza, se publicó en el BOE del 12 de noviembre y entró en vigor al día siguiente. Derogó la Ley 59/2003 y, con ella, el último resto del modelo nacido con el Real Decreto-ley de 1999. También derogó el artículo 25 de la Ley 34/2002 sobre terceros de confianza, porque el Reglamento eIDAS ya regulaba la entrega electrónica certificada y la conservación.

A diferencia de sus predecesoras, no pretende regular de forma sistemática los servicios de confianza, ya cubiertos por el Reglamento, que por primacía del Derecho de la Unión no debe reproducirse. Se limita a completarlo donde el Reglamento remitía a los Estados:

Valor probatorio: modifica la Ley de Enjuiciamiento Civil y basta acreditar que el servicio figura en la lista de confianza para que opere la presunción a favor del documento.
Certificados cualificados: vigencia máxima de cinco años, contenido obligatorio de identificadores como el número de DNI, NIE o NIF, condiciones de suspensión, y renovación «encadenada» con un certificado vigente permitida una sola vez.
Identificación a distancia: abre la puerta a métodos distintos de la presencia física con seguridad equivalente, desarrollados después por la Orden ETD/465/2021 sobre videoidentificación.
Obligaciones de los prestadores: garantía económica para prestar servicios cualificados, gestión de riesgos de seguridad y notificación de incidentes al órgano de supervisión, y un régimen sancionador para cualificados y no cualificados.

Veinte años después de aquellas quejas por una «defectuosa regulación», España tenía por fin una norma breve, coherente con el marco europeo y útil para el sector.

2024: eIDAS 2 y la Cartera de Identidad Digital Europea

El Reglamento (UE) 2024/1183, de 11 de abril, en vigor desde el 20 de mayo de 2024, modificó el Reglamento eIDAS. Su pieza central es la Cartera de Identidad Digital Europea: una aplicación que cada Estado debe ofrecer a sus ciudadanos, en la que guardar sus datos de identificación personal y otras credenciales, presentarlos de forma selectiva y firmar con firma electrónica cualificada.

Para los prestadores, eIDAS 2 añade nuevos servicios de confianza cualificados:

Declaraciones electrónicas de atributos, cualificadas o emitidas por organismos públicos responsables de fuentes auténticas, que acreditan titulaciones, apoderamientos, licencias o cualquier otro atributo. Las expliqué en «¿Qué son las declaraciones electrónicas de atributos?».
Archivo electrónico cualificado, que da continuidad a la conservación.
Libros mayores electrónicos cualificados, la versión jurídica de las DLT. Prefiero llamarlas RJT, porque el orden cronológico se preserva en el diario, no en el mayor; lo desarrollé en «De la conservación cualificada… a los servicios cualificados de archivo con orden cronológico».
Gestión de dispositivos remotos de creación de firma y sello, que consolida la firma en la nube.

El detalle técnico llega por oleadas de actos de ejecución que citan normas ETSI y CEN, y por el Architecture and Reference Framework (ARF) de la Comisión. Los sigo en esta entrada actualizada. A finales de 2026 vence el plazo para que los Estados pongan sus carteras a disposición de los ciudadanos, y en 2027 llegará la obligación de aceptarlas para muchas entidades privadas.

2025-2026: el DNI en el móvil, la cartera española y la transición postcuántica

España ha llegado a la era de la cartera por dos caminos paralelos. El primero es MiDNI, la aplicación de la Policía Nacional lanzada el 2 de abril de 2025 al amparo del Real Decreto 255/2025. Genera un código QR temporal firmado tras consultar en tiempo real la unidad de gestión del DNI, y desde abril de 2026 las entidades públicas y privadas están obligadas a aceptarlo para la identificación presencial. Es útil, pero es una solución nacional que convivirá con la Cartera de Identidad Digital Europea, y no será fácil que los ciudadanos distingan una de otra.

El segundo es la propia cartera. En octubre de 2026 el Ministerio para la Transformación Digital y de la Función Pública sometió a audiencia, con tramitación urgente, un proyecto de Real Decreto que regula su ecosistema en España: emisores, partes usuarias, fuentes auténticas y el papel de los prestadores cualificados. Como en 1999, la norma nacional llega con prisas detrás de la europea.

Mientras tanto, el sector afronta su siguiente gran cambio técnico. La amenaza del ordenador cuántico obliga a migrar a algoritmos postcuánticos y a diseñar sistemas criptoágiles, capaces de sustituir algoritmos sin rehacer las infraestructuras. Las administraciones ya han empezado a retirar las claves RSA de 2048 bits. Es la misma lección de los 40 bits de 1996: la robustez criptográfica nunca es definitiva.

Lo que enseñan 32 años

Tres constantes recorren estas tres décadas. La primera: la tecnología y el mercado van por delante de la norma, y la norma española suele llegar tarde y con prisas, aunque con la Ley 6/2020 acertó al limitarse a completar el Reglamento. La segunda: lo que impulsa la adopción no es la firma en sí, sino los servicios que la necesitan, del servidor seguro de 1995 a la sede electrónica, la factura o la cartera. La tercera: la fe pública y la seguridad jurídica preventiva, que FESTE defendía en 1997, han acabado en el corazón del modelo europeo de servicios cualificados.

En 2006 terminé con la maldición china: «vamos a vivir tiempos interesantes». Lo fueron. Los próximos, con la Cartera de Identidad Digital Europea, las declaraciones electrónicas de atributos y la criptografía postcuántica, lo serán todavía más.

Cronología

Año	Hito
1994	Netscape crea SSL; nace el mercado de certificados de servidor
1995	Banesto pone en marcha la primera CA privada no académica de España
1996	IPS-CA comercializa certificados
1997	Nacen ACE (con infraestructura SET) y FESTE; Banesto anuncia la emisión de certificados
1999	Real Decreto-ley 14/1999, Directiva 1999/93/CE y ChamberSign
2000	Nacen AECODI y AC Camerfirma como empresa independiente
2003	Orden HAC/1181/2003, Real Decreto 209/2003, Ley 26/2003 (voto electrónico en juntas) y Ley 59/2003 de firma electrónica
2006	Se expiden los primeros DNI electrónicos
2007	Ley 11/2007 de acceso electrónico y Ley 56/2007 de impulso de la sociedad de la información
2010	Esquemas Nacionales de Seguridad e Interoperabilidad
2014	Reglamento (UE) 910/2014 (eIDAS) y Cl@ve
2015	Leyes 39/2015 y 40/2015; DNI 3.0 con NFC
2016	eIDAS se aplica a los servicios de confianza (1 de julio)
2020	Ley 6/2020 de servicios electrónicos de confianza; deroga la Ley 59/2003
2021	Orden ETD/465/2021 de identificación remota por vídeo
2024	Reglamento (UE) 2024/1183 (eIDAS 2) y la Cartera de Identidad Digital Europea
2025	Real Decreto 255/2025 y lanzamiento de MiDNI
2026	MiDNI de aceptación obligatoria; proyecto de Real Decreto de la cartera española

Fuentes

Los certificados de eMudhra: el algoritmo no lo es todo. Lecciones sobre la generación de claves

1 respuesta

Una de las claves privadas de una autoridad de certificación de confianza pública era, literalmente, el número 4. Otra era el 56. Las ocho claves de las CA intermedias que la entidad de certificación india eMudhra generó en abril de 2025 eran números enteros menores que 256, cuando deberían haber sido números aleatorios de 384 bits. Cualquiera podía calcularlas en menos de un segundo a partir de los certificados públicos.

Para entender por qué esto es tan grave (y por qué un algoritmo criptográfico basado en una curva «excelente» no salvó la situación), conviene recordar brevemente cómo funciona un certificado digital y qué es realmente una clave privada. Si ya conoces estos conceptos, puedes saltarte el siguiente apartado.

Qué es una clave privada y una clave pública

Imagina una caja de mago con dos tapas, dos cerraduras y un mecanismo que gira al cerrarla. Lo que se introduce en la caja con una llave solo se puede sacar por la otra tapa, con la otra llave. Una de las llaves se define para que pueda conocerla cualquiera (la llave pública) y la otra se protege celosamente (la llave privada).

En criptografía de curva elíptica (ECDSA), la clave privada es un número secreto muy grande, y la clave pública se calcula a partir de ese número. Si el número secreto es fácil de adivinar, cualquiera puede fabricar la «llave» privada y hacerse pasar por la autoridad de certificación.

Qué es una autoridad de certificación raíz y una intermedia

Una autoridad de certificación (CA, Certification Authority) es una entidad de confianza que emite certificados digitales, los «DNI» de los sitios web. Hay una CA raíz, la de más confianza, y CA subordinadas a ella (CA intermedias), que son las que firman los certificados de los sitios web que se usan en el protocolo TLS. Si la clave privada de una CA intermedia queda comprometida, un atacante puede emitir certificados válidos para cualquier dominio (google.com, tu banco, etc.) que los navegadores aceptarían, siempre que esa CA haya superado los requisitos de aceptación del CA/Browser Forum.

Entropía y generación de claves

La seguridad de la clave privada depende de que ese número sea impredecible. Si en lugar de un número aleatorio de unos 384 bits se usa un número pequeño (como 4 o 56), cualquiera puede probar todos los valores posibles en segundos. Es como poner «0004» como combinación de la caja fuerte.

HSM y ceremonia de claves

Un HSM (Hardware Security Module) es un dispositivo físico diseñado para generar y proteger claves de forma segura. Una ceremonia de claves es el procedimiento formal (con testigos, auditores, guiones, controles duales…) que se sigue para generar las claves de una CA. El fallo del prestador de servicios de certificación eMudhra no fue del algoritmo ni, aparentemente, del HSM en sí, sino de un error en el procedimiento y en el código de automatización durante esa ceremonia.

Las claves usaban el algoritmo ECDSA sobre la curva NIST P-384, uno de los algoritmos más robustos que hoy se usan en una PKI. Y no sirvió de nada. El caso recuerda algo que en el debate sobre criptografía postcuántica y criptoagilidad a veces se olvida: el algoritmo no lo es todo. Tan importante como elegir bien la curva o el tamaño de clave es generar la clave correctamente, comprobar que se ha generado bien y poder sustituirla con rapidez cuando algo falla, incluso cuando el fallo está en el propio hardware.

Qué ha pasado

Los certificados afectados son seis CA intermedias de TLS (EM DV, EM OV y EM EV TLS CA – G3B y G3C) y dos de firma de código (EM OV CS CA – G3B y G3C), que dependían de la raíz emSign ECC Root CA – G3 y tenían además una certificación cruzada de Sectigo.

Fecha	Hecho
30 de abril de 2025	Ceremonia de generación de claves en la que se crean las intermedias
2025	Las listas de revocación (CRL) de esas intermedias aparecen con firmas no válidas (bug 1970728 de Mozilla). eMudhra las vuelve a firmar y el síntoma desaparece
17 de octubre de 2026	Un investigador firma un mensaje con las ocho claves privadas y lo comunica a los programas de raíces. Chrome (CRLSet) y Firefox (OneCRL) bloquean las intermedias en pocas horas
18 de octubre	eMudhra revoca las ocho intermedias por compromiso de la CA; Sectigo revoca las certificaciones cruzadas
19 y 20 de octubre	Bloqueo en Android, Apple y Microsoft. Mozilla retira la raíz de su almacén. Go publica CVE-2026-111943
22 de octubre	eMudhra anuncia que abandona el negocio global de certificados SSL/TLS
27 de octubre (previsto)	Chrome retira la raíz emSign ECC Root CA – G3 de su almacén

Según Google, no llegó a registrarse en Certificate Transparency (el registro histórico público de certificados emitidos) ningún certificado fraudulento emitido con esas claves, por lo que los navegadores que exigen CT no pudieron ser atacados. Pero durante año y medio, cualquiera que hubiera mirado los certificados con atención habría podido emitir certificados de cualquier dominio aceptados por clientes que no exigen CT, como muchas aplicaciones y servicios que usan bibliotecas de Go, Python, Java o Node. eMudhra estima en unos 30.000 los certificados de clientes que deben migrar.

Actualización (26 de octubre). El hilo de Mozilla sigue abierto y aporta matices:

eMudhra insiste en que ella no emitió certificados finales con esas intermedias. Pero un participante ha contado 107.107 certificados registrados en Certificate Transparency entre el 20 y el 21 de octubre bajo seis de las ocho claves, emitidos por terceros una vez que las claves eran públicas. Es la demostración práctica de que cualquiera podía firmar con ellas.
Mozilla envió el 20 de octubre una lista de preguntas con 24 horas de plazo que, a 23 de octubre, seguían sin respuesta. El programa de raíces de Chrome ha rechazado que la presión mediática justifique el retraso.
eMudhra ha anunciado que presentará su informe completo dentro del plazo de 14 días que fija la CCADB. Varias respuestas vencen el 28 de octubre.
Se ha abierto otro incidente (bug 2085612) porque los servidores de CRL y OCSP de eMudhra bloqueaban peticiones según el agente de usuario, lo que podría incumplir los Requisitos Básicos sobre disponibilidad del estado de revocación.

La causa: una curva excelente con una clave ridícula

En ECDSA, la clave privada d es un número entero elegido al azar entre 1 y el orden de la curva, y la clave pública es el punto Q = d · G, que resulta de sumar el punto generador G consigo mismo d veces. La seguridad descansa en que, con un d de 384 bits aleatorios, recuperarlo a partir de Q (el problema del logaritmo discreto en curva elíptica) es inviable. Pero si d es menor que 256, basta con calcular 4·G, 56·G… hasta encontrar el punto que coincide con la clave pública del certificado: como mucho, 255 multiplicaciones.

Certificado intermedio	Clave privada (d)
EM OV TLS CA – G3C	4
EM EV TLS CA – G3C	56
EM OV CS CA – G3B	66
EM EV TLS CA – G3B	115
EM OV TLS CA – G3B	155
EM DV TLS CA – G3B	156
EM DV TLS CA – G3C	230
EM OV CS CA – G3C	237

Para hacerse una idea del tamaño: una clave privada correcta de P-384 tiene del orden de 2³⁸⁴ posibilidades, un número de 116 cifras. Estas claves tenían menos de 256.

Según la explicación preliminar de eMudhra en el hilo del incidente en Mozilla, el HSM funcionó correctamente. El fallo estuvo en el procedimiento:

Durante la ceremonia se generaron primero pares de claves correctos.
Una prueba de envoltura y desenvoltura (wrap/unwrap) aprobada como desviación del guión, combinada con un error en el código de automatización, creó en el HSM un segundo juego de claves con entropía truncada.
Por la coincidencia de etiquetas entre ambos juegos, el script usó las claves débiles para generar las solicitudes de certificado.
La raíz firmó esas solicitudes, y las listas de revocación, firmadas con las claves buenas, empezaron a fallar. En vez de investigar por qué, se volvieron a firmar con las claves débiles.

Hay un detalle técnico que merece atención: las comprobaciones habituales de validez de la clave pública no detectan este fallo. Un punto 4·G es un punto perfectamente válido de la curva P-384: cumple la ecuación, está en el subgrupo correcto y supera la validación completa de clave pública de NIST. Solo lo delata una prueba específica, comparar la clave pública con los múltiplos pequeños del generador, o una revisión de la clave privada antes de usarla.

No es la primera vez

La historia de la criptografía aplicada está llena de algoritmos impecables arruinados por una mala generación de claves o de números aleatorios. Y varios de los casos más graves ocurrieron en dispositivos certificados.

Año	Caso	Qué falló	Lección
2008	OpenSSL de Debian (CVE-2008-0166)	Un cambio en el código dejó como única fuente de entropía el identificador de proceso: solo unas 32.000 claves posibles por tipo y tamaño, durante casi dos años	Un fallo de software en la generación anula cualquier algoritmo
2010	Consola PlayStation 3	Sony firmaba con ECDSA reutilizando siempre el mismo número aleatorio por firma, y su clave privada pudo despejarse	En ECDSA no basta con una buena clave: cada firma necesita aleatoriedad nueva
2012	Estudio «Mining your Ps and Qs» (Heninger y otros)	Miles de dispositivos de red generaban claves RSA al arrancar, sin entropía suficiente, y compartían factores primos	Los dispositivos embebidos son especialmente vulnerables
2013	Tarjetas del certificado digital ciudadano de Taiwán (Bernstein y otros)	Un generador de números aleatorios defectuoso en tarjetas certificadas permitió factorizar 184 claves RSA	La certificación del hardware no garantiza la calidad de cada clave
2017	ROCA (CVE-2017-15361)	La biblioteca RSALib de Infineon generaba primos con una estructura que permitía factorizar claves de 1024 y 2048 bits. Afectó a TPM, a YubiKey 4 y a documentos de identidad electrónicos de Estonia (unos 760.000), Eslovaquia y España, cuyos certificados se suspendieron	El fallo puede estar en el chip, y afectar a millones de claves a la vez
2024	EUCLEAK (CVE-2024-45678)	La implementación de ECDSA de la biblioteca de Infineon filtraba la clave por canal lateral; estuvo sin detectar unos 14 años y unas 80 evaluaciones Common Criteria	Tampoco la curva elíptica en un chip certificado es garantía absoluta
2025-2026	eMudhra	Un error en el guión de la ceremonia dejó en producción claves P-384 menores que 256	El procedimiento importa tanto como el HSM

El caso ROCA tiene especial interés en España. A principios de noviembre de 2017, la Policía anunció que suspendía los certificados de los DNI electrónicos afectados y que los sustituiría, aunque los documentos siguieron siendo válidos para identificarse y viajar. Estonia tuvo que suspender los certificados de unas 760.000 tarjetas y abrir centros temporales para renovarlos. Fue una demostración a escala nacional de lo que significa no tener criptoagilidad.

Generar en el HSM, sí; pero poder importar claves también

La buena práctica, y lo que exigen las normas para las claves de las autoridades de certificación, es generar las claves dentro de un módulo criptográfico seguro (HSM): así la clave privada nunca existe en claro fuera de un entorno protegido. Es lo correcto, pero no basta, por dos motivos.

El hardware también falla. ROCA, las tarjetas de Taiwán o EUCLEAK demuestran que el generador de claves o la biblioteca criptográfica de un chip certificado pueden tener defectos que afectan a todas las claves que produce. Cuando eso ocurre, el fabricante necesita meses para corregir el firmware y volver a certificarlo, y mientras tanto el prestador no puede generar claves fiables con ese equipo.

La diversidad es una defensa. Si un prestador puede instalar en su HSM claves generadas externamente, en otro dispositivo certificado de un fabricante distinto o en un entorno de generación aislado y auditado, no depende de un único generador de números aleatorios ni de una única biblioteca. Si se descubre un fallo en uno, puede seguir operando con el otro sin esperar a que el fabricante lo corrija. Es criptoagilidad aplicada no al algoritmo, sino al origen de las claves.

Ahora bien, el caso eMudhra tiene una ironía: las claves débiles nacieron precisamente en una prueba de envoltura y desenvoltura, que es el mecanismo con el que se exportan e importan claves entre HSM. Importar claves no es más seguro por sí mismo; exige el mismo rigor que generarlas:

La clave viaja siempre cifrada con otra clave (wrapping) y nunca en claro.
El proceso se divide entre varias personas, con conocimiento compartido y control dual (esquemas M de N, que exigen la presencia de al menos M custodios de entre N posibles).
La importación se hace en una ceremonia con guion, auditores, testigos y acta, igual que la generación.
Las pruebas se hacen en un entorno distinto del de producción, y nunca dejan material criptográfico en el HSM productivo.
Cada clave lleva una etiqueta única y se verifica, antes de firmar la solicitud de certificado, que la clave pública de la solicitud es la que se acaba de generar o importar.

Y, sobre todo, venga de donde venga la clave, hay que comprobarla antes de certificarla.

Qué revisar en una ceremonia de claves

Las normas ya obligan a documentar y supervisar la generación de claves de las autoridades de certificación. Los Requisitos Básicos del CA/Browser Forum exigen un guión de generación de claves, que la ceremonia la presencie o la grabe un auditor cualificado y que este emita un informe. En Europa, la norma ETSI EN 319 411-1, que aplican los prestadores de servicios de confianza bajo eIDAS, pide que las claves de CA se generen en dispositivos criptográficos seguros y bajo control múltiple. Los Requisitos Básicos obligan además a rechazar claves con debilidades conocidas, como las del OpenSSL de Debian o las afectadas por ROCA.

La ceremonia de eMudhra se hizo con un HSM certificado FIPS 140-2 de nivel 3 y bajo un guión aprobado, y aun así falló. Por experiencia en auditoría, añadiría a la lista de comprobaciones algunas que no siempre se hacen:

Comprobar la calidad de cada clave generada, no solo que el HSM esté certificado. Para curvas elípticas, descartar que la clave pública coincida con múltiplos pequeños del generador. Para RSA, aplicar los detectores de ROCA, las listas de claves débiles conocidas y las pruebas de primos demasiado cercanos. Existen herramientas abiertas que agrupan estas pruebas, como paranoid_crypto, de Google, aunque su repositorio se archivó en agosto de 2026; en el hilo de eMudhra ya se ha preguntado si los programas de raíces aplican este tipo de comprobaciones a todas las intermedias.
Probar la clave con el certificado ya emitido: firmar un mensaje de prueba y verificarlo con la clave pública del certificado, no con la que el sistema «cree» que tiene.
Separar de verdad las pruebas de la producción. Cualquier desviación del guión, como la prueba de envoltura de eMudhra, debe repetirse después en un entorno limpio o justificar por qué no deja rastro.
Exigir etiquetas únicas e inventario de objetos del HSM al final de la ceremonia: cuántas claves hay, cuáles y para qué.
Tratar cualquier anomalía criptográfica como un posible incidente de claves. La firma no válida de las listas de revocación en 2025 era la pista que lo explicaba todo. Volver a firmarlas para que el error desapareciera fue tapar el síntoma.
Prever la sustitución. Tener ensayado cómo revocar una intermedia, generar o importar otra y migrar a los clientes en horas, no en meses.

Conclusión

En plena transición postcuántica, buena parte del debate se centra en qué algoritmos elegir: ML-DSA, SLH-DSA, curvas elípticas o RSA de más bits. El caso eMudhra recuerda que una clave de P-384 que vale 4 es más débil que una clave RSA de 512 bits bien generada. La seguridad de una PKI depende de una cadena con muchos eslabones: el algoritmo, el generador de números aleatorios, el hardware, el guión de la ceremonia, las personas que lo ejecutan, las comprobaciones posteriores y la capacidad de reaccionar. Y la criptoagilidad no consiste solo en poder cambiar de algoritmo, sino también en poder cambiar de clave, de fabricante y de origen de las claves cuando uno de esos eslabones falla.

Fuentes

Bug 2083449: eMudhra, compromiso de claves privadas de certificados intermedios, Mozilla.
Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates, Google.
eMudhra to exit global SSL/TLS certificate business, eMudhra, 22 de octubre de 2026.
Indian certification authority eMudhra’s private keys compromised, The Register.
Eight eMudhra CA keys compromised, The Hacker News.
The eMudhra CA compromise and exit from public SSL/TLS, análisis técnico con la tabla de claves.
Factoring RSA keys from certified smart cards: Coppersmith in the wild, Bernstein y otros, 2013.
ROCA vulnerability y noticia sobre su impacto en los eID europeos, Interoperable Europe.
EUCLEAK, NinjaLab, 2024.

Rumbo a Poznań: Trusted Economy Forum 2026

1 respuesta

Después de Ginebra, Tallin y Sophia Antipolis, la siguiente parada de este otoño dedicado a la confianza digital será Poznań. Los días 14 y 15 de octubre asistiré al Trusted Economy Forum 2026, uno de los encuentros europeos con más solera en firma electrónica, identificación y servicios de confianza. Llega en el mejor momento: a dos meses del plazo de diciembre de 2026 en que los Estados miembros deben poner a disposición de sus ciudadanos la Cartera Europea de Identidad Digital.

Como conté en mi artículo sobre Ginebra, Tallin y Sophia Antipolis, cada foro aporta una pieza distinta del puzle. Ginebra aportó la gobernanza global, Tallin la certificación y los prestadores cualificados, y Sophia Antipolis la normalización y los grandes pilotos. Poznań añade algo que no siempre se encuentra en otros escenarios: el punto de vista de quienes ya están integrando carteras, firmas y verificación de identidad en procesos reales de bancos, aseguradoras, administraciones locales y empresas.

Un foro con casi dos décadas de historia

El Trusted Economy Forum es heredero del European Electronic Signature Forum, que celebró 19 ediciones. Entre 2020 y 2023 lo organizó Asseco Data Systems, y desde 2024 lo organiza Obserwatorium.biz. Pocas citas europeas pueden presumir de una continuidad así en el sector de la confianza digital.

El lema de este año es «Connected by trust». Se espera a cerca de 300 participantes de unos 20 países, con representación de la administración pública, la empresa, la universidad y la industria tecnológica. La sede es Concordia Design, en Poznań, y las sesiones serán en inglés con traducción simultánea al polaco.

El comité de programa reúne a nombres muy conocidos en el sector:

Arno Fiedler (Nimbus Technologieberatung), referente del ETSI ESI.
Sławomir Górniak, experto en Ciberseguridad de ENISA.
Viky Manaila, presidenta del Cloud Signature Consortium.
Andrzej Ruciński, Experto en identificación y firma electrónica. Presidente en Grupos de normalización
Dariusz Szostek, CEO de Szostek Digital y Profesor de la Universidad de Silesia
Michał Tabor, Socio de Obserwatorium.biz Experto en identificación y firma electrónica. Editor de estándares en ETSI.

ETSI figura como patrocinador honorífico.

Un programa en seis módulos

El programa cubre todo el recorrido de la confianza digital, desde la regulación hasta la experiencia del usuario:

On the way to European Identity Wallets. How prepared are we? Estado de la implantación de la EUDI Wallet antes de diciembre de 2026.
Trust trends. Nuevos servicios, mercados y tecnologías, entre ellos la criptografía postcuántica, la procedencia del contenido generado por IA y el Pasaporte Digital de Producto.
Digital market players. Cómo funcionar en el mercado digital de forma eficiente y conforme a la normativa.
Trust in action! Servicios de confianza, carteras e identificación remota aplicados en empresas y administraciones.
Customer in the centre! La experiencia de usuario en los servicios de confianza y la identificación electrónica.
Global Trust Services. Interoperabilidad y expansión internacional de los servicios de confianza.

Los temas de fondo son los que marcan la agenda europea: la cartera, la firma, el sello y la entrega electrónica certificada, y las declaraciones electrónicas de atributos. También el impacto del Marco Europeo de Identidad Digital y del Sistema Nacional de Ciberseguridad polaco, los modelos de negocio de la identidad digital y la administración electrónica.

Me parece un acierto que el programa combine conferencias con muchos debates. Es en los debates donde aparecen las preguntas que las presentaciones no siempre responden.

Ponentes que merece la pena escuchar

El cartel reúne a más de 60 intervinientes. Varios ya me los he encontrado en otros foros de este año, lo que confirma que se está formando una comunidad europea estable en torno a la cartera.

Carteras nacionales.
- Joanna Koczorowska y Rafał Sionkowski (COI) presentarán la cartera polaca.
- Adrian Bieschke y Björn Boening, del Ministerio Federal de Asuntos Digitales, explicarán la implantación alemana.
- Giorgia Dragoni (Politecnico di Milano) abrirá con el panorama europeo de las carteras.
Certificación. Elżbieta Andrukiewicz, del Instituto Nacional de Telecomunicaciones de Polonia, hablará de la certificación de la EUDI Wallet, un tema que seguimos de cerca en el grupo ad hoc de ENISA.
Pilotos y ecosistema europeo.
- Kevin Meijer (Asociación de Pagos de Países Bajos) y Xavier Juredieu (EUROPEUM-EDIC), ambos del consorcio WE BUILD.
- Juredieu hablará además de la hoja de ruta de EBSI.
Prestadores de confianza.
- Andrea Sassetti (Aruba PEC y AssoCertificatori), Igor Marcolongo (Tinexta InfoCert) y Marcin Szulga (Asseco Data Systems).
- Arno Fiedler, sobre C2PA y credenciales de contenido.
- Guillaume Forget (Cryptomathic), sobre el Cloud Signature Consortium como pilar de la interoperabilidad. Coincidimos de nuevo con el CSC tras la cumbre de Bogotá.
Experiencia de usuario e integración.
- Adrian Doerk (Lissi) y Andreas Freitag (Procivis).
- Aleksandra Nowak (IDENTT), sobre la integración de las partes usuarias.
Sector financiero. VISA, BNP Paribas, ING Leasing, BIK y FinTech Poland llevarán el debate a los pagos y la banca.
Mirada global. Karen Mkoyan (imID) presentará el ecosistema de Armenia, alineado con eIDAS. Es una prueba de que el modelo europeo ya se exporta.

Por qué Poznań, y por qué ahora

Lo que distingue al Trusted Economy Forum es su equilibrio. Junta a reguladores y a quienes despliegan, a grandes prestadores y a startups, y a la visión europea con la experiencia de un país, Polonia, que tiene uno de los ecosistemas de identidad digital más activos de la Unión. Que en el mismo programa convivan la cartera, la firma en la nube, la criptografía postcuántica, la procedencia del contenido de IA y el Pasaporte Digital de Producto refleja muy bien hacia dónde va el sector.

Además, el calendario no podría ser más oportuno. Dos semanas después se celebra en Bruselas el EU Digital Identity Wallet Launchpad 2026, del 29 al 30 de octubre. Es la segunda edición de la cita que comenté en EUDI Wallets Launchpad 2025. Seguramente asistiré también, así que Poznań será un buen ensayo de lo que allí se verá. Y en diciembre llegará el evento sobre identidad digital y Business Wallet que preparamos con el Observatorio Legaltech Garrigues-ICADE, continuación de la jornada del 28 de abril.

Volveré de Poznań con notas y contactos, y los compartiré aquí. Si vas a estar allí, escríbeme y nos vemos en Concordia Design.

Enlaces

Sugerencia de actualización del documento «Procedimiento de inclusión y clasificación de certificados en @firma»

Deja un comentario

He revisado el procedimiento que se utiliza en @firma para explicar la inclusión y clasificación de certificados electrónicos de los Prestadores de Servicios Electrónicos de Confianza y su validación electrónica en entornos de Administraciones Públicas. Es la versión 3.9 del documento «Procedimiento de inclusión y clasificación de certificados en @firma«, publicado en 2018.

Es un documento útil y, en algunos aspectos ya tuvo en cuenta algunos términos alineado con eIDAS —habla de certificados cualificados y de dispositivos QSCD—, pero conserva referencias del marco regulatorio anterior (la Ley 59/2003, terminología de «certificación reconocida», mención al extinto MINETUR y varias URLs obsoletas) que conviene depurar. A continuación resumo las actualizaciones que sugeriría, agrupadas en cuatro bloques. He preparado además una tabla de correcciones que he puesto a disposición de la unidad responsable de publicar el documento oficial.

1. Legislación

Ley 59/2003, de firma electrónica: está derogada. La norma vigente en el ámbito nacional es la Ley 6/2020, de 11 de noviembre, reguladora de determinados aspectos de los servicios electrónicos de confianza. Todas las remisiones a la Ley 59/2003 deberían sustituirse.
Reglamento (UE) 910/2014 (eIDAS): sigue vigente, pero está modificado por el Reglamento (UE) 2024/1183 (eIDAS2). Conviene citar esta modificación y, donde proceda, los reglamentos de ejecución de 2024, 2025 y 2026.

2. Terminología

El vocabulario de la Directiva 1999/93/CE y de la Ley 59/2003 quedó sustituido por el de eIDAS:

el «certificado reconocido» se denomina ahora «certificado cualificado«; la «firma reconocida» es ahora la «firma electrónica cualificada«.
un «prestador de servicios de certificación (PSC)» es ahora un «prestador (cualificado) de servicios electrónicos de confianza» (PSCC / QTSP). El acrónimo «PSC» ya no se lee igual.
un «dispositivo seguro de creación de firma (DSCF/SSCD)» ahora se denomina «dispositivo cualificado de creación de firma (QSCD)». El documento aún mezcla los términos SSCD y QSCD; convendría unificar al uso de las siglas QSCD.
En la lógica de lectura de la lista de confianza (TSL), las extensiones QCWithSSCD/QCNoSSCD fueron sustituidas por QCWithQSCD, QCNoQSCD y QCQSCDManagedOnBehalf (ETSI TS 119 612 v2).
Los estados y tipos heredados del modelo de acreditación anterior a eIDAS (accredited, undersupervision, supervisionceased/revoked, accreditationceased/revoked, setbynationallaw, recognisedatnationallevel, NationalRootCA-QC…) deberían revisarse: con eIDAS el estatus cualificado se expresa esencialmente como granted / withdrawn (más los transitorios), y desaparece el concepto de «acreditación».

3. Organismos

MINETUR – Ministerio de Industria, Energía y Turismo ya no existe. El organismo supervisor de los servicios electrónicos de confianza es hoy el Ministerio para la Transformación Digital y de la Función Pública – Secretaría de Estado de Digitalización e Inteligencia Artificial (SEDIA) (con una etapa intermedia como Ministerio de Asuntos Económicos y Transformación Digital).
La plataforma @firma, el Portal de Administración Electrónica (PAe) y la publicación de la lista de confianza dependen de la Secretaría General de Administración Digital (SGAD) de ese mismo ministerio (antes adscrita a Hacienda).

4. URLs y recursos

Los enlaces a minetur.gob.es (incluida la ubicación de la TSL en sede.minetur.gob.es/Prestadores/TSL/TSL.pdf) reflejan una marca ministerial obsoleta; conviene actualizarlos a la sede del Ministerio para la Transformación Digital y añadir, para la consulta a nivel UE, el eIDAS Dashboard / LOTL de la Comisión Europea.
La forja CTT (forja-ctt.administracionelectronica.gob.es) está descatalogada: los clientes y componentes de @firma se publican ahora en GitHub (github.com/ctt-gob-es) y en el PAe.
También conviene sustituir el prefijo http:// por https:// en todos los enlaces (las comunicaciones con TLS son ahora la versión por defecto), y verificar las rutas del PAe (p. ej. el «Anexo PSC» de @firma) y del soporte a integradores (CAID), que han podido cambiar de dirección.

*Esta es una sugerencia de mejora en clave colaborativa; el detalle «texto actual → propuesta → motivo» lo he recogido en una tabla que facilito a la unidad responsable. No constituye asesoramiento jurídico.*

Documento de Propuesta de Cambios

@firma_tabla_cambios_actualizacion_2026

Afirma_tabla_cambios_actualizacion_2026 Descarga

Documento actualizado incorporando los cambios

Procedimiento de inclusión y clasificación de certificados en @firma actualizado a 2026

Afirma_procedimiento_actualizado-2026 Descarga

Para informar de errores u omisiones, envíen un email a julian (at) inza.com

Cartera de Identidad Digital Europea – Arquitectura y Marco de Referencia V2.8.0

3 respuestas

La cartera de Identidad Digital Europea (EUDI Wallet, en inglés) es una aplicación digital segura y controlada por el usuario que permite a los ciudadanos gestionar su identidad oficial y otros datos personales. Permite a los usuarios solicitar información digital verificada (denominada «declaración») a prestadores de confianza (denominados «prestadores de DIP» y «prestadores de declaraciones de atributos»), almacenar dicha información y presentarla a partes usuarias (informadas) de una manera que prioriza la privacidad y la seguridad.

Se describe en un documento denominado «Arquitectura y Marco de Referencia» que va por la versión V2.8.0

Se trata de la “hoja de ruta técnica” publicada y mantenida por la Comisión Europea (en colaboración con los Estados miembros a través del European Digital Identity Cooperation Group) para garantizar que todas las carteras digitales nacionales sean interoperables, seguras y respetuosas con la privacidad en toda la Unión Europea.

Su primera versión se creó a partir de la Recomendación de la Comisión (UE) 2021/946 de junio de 2021, que pidió a los Estados miembros desarrollar una “Caja de Herramientas Común de la Unión” (Toolbox). Dentro de esa caja, el ARF es el pilar técnico principal. Posteriormente se ha ido actualizando para alinearse con el Reglamento de Identidad Digital Europea (eIDAS 2.0, Reglamento (UE) 2024/1183) y con decenas de Reglamentos de Ejecución (CIR) adoptados entre 2024 y 2026.

El ARF por sí mismo no es una norma legal (es un documento informativo y de referencia), pero recopila el articulado de actos de ejecución y es la base que usan:

Los Estados miembros para desarrollar sus propias carteras.
Los proveedores de carteras (Wallet Providers).
Los pilotos a gran escala (Large-Scale Pilots o LSP).
La propia Comisión para crear la implementación de referencia.

He traducido varias versiones anteriores y ahora presento la traducción correspondiente a la versión 2.8.0 (de febrero de 2026),

El documento de «Arquitectura y Marco de Referencia» define los siguientes aspectos del ecosistema de Cartera IDUE:

El capítulo 2 describe las principales funcionalidades de una Unidad de Cartera, desde la perspectiva del usuario.
El capítulo 3 describe las funciones clave dentro del ecosistema de Cartera IDUE, con sus responsabilidades asociadas.
El capítulo 4 describe la arquitectura del ecosistema de Cartera IDUE, incluidos sus principios de diseño, los componentes que conforman una Unidad de Cartera y las interfaces entre una Unidad de Cartera y otras entidades, los flujos de presentación de declaraciones de proximidad y remotas, las diferentes arquitecturas que pueden utilizarse para implementar un DCSC, los ciclos de vida de las principales entidades y componentes, y la implementación de la generación y presentación de seudónimos.
El capítulo 5 describe los elementos que componen una declaración de atributos, las diferentes categorías de declaraciones de atributos y los catálogos asociados, y los diferentes protocolos de presentación de cada declaración.
El capítulo 6 contiene el modelo de confianza para el ecosistema de Cartera IDUE. Para cada una de las principales entidades y componentes del ecosistema, este capítulo describe los mecanismos utilizados para garantizar que las entidades con las que interactúa puedan confiar en él a lo largo de su vida útil. Estos mecanismos pueden incluir la inscripción, la revocación, la autenticación y la autorización.
El capítulo 7 aborda la certificación de la solución de Cartera y la gestión de riesgos.
El capítulo 8 aborda la accesibilidad de todos los componentes del ecosistema de Cartera IDUE
orientados al usuario.
El capítulo 9 describe cómo se ha elaborado y se seguirá elaborando este documento.
El capítulo 10 contiene una lista de referencias.

En el documento se han tenido en cuenta los Reglamentos de Ejecución de la Comisión
adoptados:

CIR 2024/2977 relativo al DIP y al DEA,
CIR 2024/2979 relativo a la integridad y las funcionalidades básicas,
CIR 2024/2980 relativo a las notificaciones del ecosistema,
CIR 2024/2981 relativo a la certificación de soluciones de cartera,
CIR 2024/2982 sobre protocolos e interfaces,
CIR 2025/846 sobre la verificación transfronteriza de la identidad,
CIR 2025/847 sobre violaciones de seguridad de las Carteras de Identidad Digital Europea,
CIR 2025/848 sobre la inscripción de las Partes usuarias (o informadas) que confían en las carteras,
CIR 2025/849 relativa a la lista de carteras de Identidad Digital Europea certificadas,
CIR 2025/1566 sobre la verificación de la identidad y los atributos de un titular de un QC o DECA,
CIR 2025/1567 sobre la gestión de QSCD remotos como servicios de confianza cualificados,
CIR 2025/1568 sobre revisiones por pares de los sistemas de identificación electrónica,
CIR 2025/1569 relativa a los DECA y los DEA proporcionados por un organismo del sector público
responsable de una fuente auténtica, o en su nombre,
CIR 2025/1570 relativa a la notificación de información sobre QSCD certificados,
CIR 2025/1571 sobre los formatos y procedimientos para los informes anuales de los organismos de
supervisión,
CIR 2025/1572 sobre el formato y los procedimientos de notificación de la intención y la verificación
en relación con el inicio de servicios de confianza cualificados,
CIR 2025/1929 relativa a la vinculación de la fecha y la hora a los datos y al establecimiento de la
precisión de las fuentes de tiempo para la prestación de sellos de tiempo electrónicos cualificados,
CIR 2025/1942 sobre los servicios de validación cualificados para firmas electrónicas cualificadas y los servicios de validación cualificados para sellos electrónicos cualificados,
CIR 2025/1943 sobre normas de referencia para certificados cualificados de firma electrónica y
certificados cualificados de sello electrónico,
CIR 2025/1944 sobre normas de referencia para los procesos de envío y recepción de datos en los servicios de envío certificado electrónico cualificado y en lo que respecta a la interoperabilidad de dichos servicios,
CIR 2025/1945 sobre la validación de firmas electrónicas cualificadas y de sellos electrónicos
cualificados, así como sobre la validación de firmas electrónicas avanzadas basadas en certificados
cualificados y de sellos electrónicos avanzados basados en certificados cualificados,
CIR 2025/1946 sobre los servicios de conservación cualificados para las firmas electrónicas cualificadas y para los sellos electrónicos cualificados,
CIR 2025/2160 sobre normas de referencia, especificaciones y procedimientos para la gestión de
riesgos en la prestación de servicios de confianza no cualificados,
CIR 2025/2162 sobre la acreditación de Organismos de Evaluación de Conformidad que realizan la
evaluación de los prestadores de servicios de confianza cualificados y de los servicios de confianza
cualificados que prestan, el informe de evaluación de la conformidad y el sistema de evaluación de la conformidad,
CID 2025/2164 sobre la versión de la norma en la que se basa la plantilla común para las listas de
confianza,
CIR 2025/2527 sobre normas de referencia para certificados cualificados para la autenticación de sitios web,
CIR 2025/2530 sobre los requisitos para los prestadores de servicios de confianza cualificados que
prestan servicios de confianza cualificados,
CIR 2025/2531 sobre normas de referencia y especificaciones para los registros electrónicos
cualificados,
CIR 2025/2532 sobre normas de referencia y especificaciones para los servicios de archivo electrónico cualificados.
CIR 2026/248 — Firmas y sellos electrónicos avanzados: formatos que deben reconocer los organismos del sector público
CIR 2026/798 — Incorporación a distancia de usuarios a las carteras europeas de identidad digital

Con el fin de apoyar el desarrollo de una implementación de referencia de una solución de Cartera y poner a prueba su uso en diferentes casos de uso prioritarios, la Comisión lanzó una convocatoria de propuestas el 22 de febrero de 2022 en el marco del Programa Europa Digital para poner a prueba casos de uso del ecosistema de Cartera IDUE a gran escala.

El objetivo de la convocatoria de Grandes-Proyectos-Piloto (GPP, Large Scale Pilots, LSP en inglés)) es apoyar la puesta en marcha del ecosistema de Cartera IDUE en torno a una serie de casos de uso en los que participen partes interesadas tanto del sector público como del privado. Los GPP pondrán a prueba el ecosistema de Cartera IDUE tanto en contextos nacionales como transfronterizos y se integrarán en el desarrollo iterativo de la aplicación de referencia.

Los trabajos de los LSP se alinean con el ARF, que guía el diseño del sistema piloto y el desarrollo de la arquitectura, junto con el lanzamiento de la implementación de referencia.

Los LSP han proporcionado comentarios sobre el ARF a medida que desarrollaban e interactuaban con los servicios de las Partes usuarias (o informadas), los prestadores de Declaraciones Electrónicas Cualificadas de Atributos (DECA) los prestadores de Datos de identificación de Persona (DIP), los prestadores de servicios de confianza cualificados y no cualificados y los usuarios en interacciones significativas en el marco de los casos de uso propuestos.

Este es el documento:

ARF-architecture-and-reference-framework-main-and-annexes-2.8 es-ES Descarga

Certificado EPREL para Trabajadores Autónomos, Asociaciones y Cooperativas

Deja un comentario

La normativa del Registro Europeo de Productos de Etiquetado Energético (EPREL), se orienta, en su diseño, al registro de personas jurídicas como responsables de los productos, asignando al Identificador de Organización Europeo (NTR) el rol de identificación oficial de la organización, tal como se recoge en el «User Manual for Suppliers» publicada por la Comisión Europea en el sitio oficial de EPREL (última versión: 27‑06‑2025). A partir del 22 de abril de 2025, solo se admitirán sellos electrónicos que incluyan el NTR como identificador de organización, en aplicación de lo establecido en el Reglamento de Ejecución (UE) 2024/994.

Aunque es posible que el responsable de un producto eléctrico afectado por la normativa de eficiencia energética sea una persona física (o natural), como por ejemplo, un trabajador autónomo, o sea una entidad sin figura jurídica clásica (y, por tanto, sin inscripción en el Registro Mercantil), como algunos tipos de cooperativas y asociaciones, siempre que se cumplan los requisitos de verificación y de identificación establecidos, debe poder registrar productos eléctricos en EPREL.

La norma oficial de EPREL no es clara en cuanto a la forma de inscribir trabajadores autónomos, Cooperativas y Asociaciones en EPREL y en cuanto a la forma de obtener certificados cualificados para ese fin.

Sin embargo, EADTrust ha cooperado con el Registro EPREL para resolver esta problemática específica.

Aunque no existe un “manual específico” público para autónomos, asociaciones o cooperativas, sino un marco general que admite distintos tipos de organizaciones y de identificadores, EADTrust, la entidad de confianza que emite el certificado, sigue las pautas definidas por el organismo EPREL y actúa con criterio técnico y jurídico, sin añadir interpretaciones que puedan generar incertidumbre regulatoria.

Si es su caso, contacte con EADtrust en el 91 7160555 o 902 365 612

Veri-factu, SII, factura electrónica y regímenes forales: este es el mapa para no perderse (con mención al sello electrónico)

Deja un comentario

La proliferación de siglas y normativas en torno a la facturación en España puede resultar abrumadora, incluso para quienes seguimos este ecosistema de cerca.

¿Qué diferencia hay entre Veri-Factu y el SII? ¿A qué obliga ya la Ley Crea y Crece tras el Real Decreto 238/2026? ¿Qué pasa en Navarra o en el País Vasco? ¿Y el sello electrónico remoto cualificado?

En este artículo trato de trazar un mapa claro de todos estos conceptos, sus solapamientos y sus diferencias, y termino explicando por qué el sello electrónico remoto cualificado es una pieza técnica que los une a todos.

1. El terreno de juego: dos grandes familias de obligaciones

Antes de entrar en detalle, conviene distinguir dos líneas normativas que a menudo se confunden porque comparten vocabulario pero tienen objetivos distintos:

Las obligaciones de control fiscal (SII, Veri-factu): nacen de la potestad de la Agencia Tributaria para verificar en tiempo real —o casi— que las facturas emitidas existen y son íntegras. El destinatario de la información es la Administración.
La obligación de facturar electrónicamente entre empresas (Ley 18/202 Crea y Crece / Real Decreto 238/2026)
): nace del derecho del acreedor a recibir su factura en formato estructurado y de la ambición de reducir la morosidad. El destinatario es el cliente B2B.

Son obligaciones que pueden coexistir, complementarse y, en muchos casos, satisfacerse con la misma infraestructura técnica, pero que responden a lógicas diferentes.

2. El SII: el pionero del reporte en tiempo real

El Suministro Inmediato de Información (SII) se introdujo en 2017 (Real Decreto 596/2016) y obliga a determinados contribuyentes —grandes empresas, grupos de IVA, inscritos en el REDEME— a enviar a la AEAT los registros de facturación en un plazo máximo de cuatro días hábiles desde la expedición o recepción de la factura.

¿Qué se envía?

No se envía la factura en sí, sino un registro de facturación en XML con los campos esenciales (fecha, importe, NIF, tipo de IVA…). La factura original puede seguir siendo en papel o en cualquier formato, siempre que el registro llegue a tiempo.

¿Quién está obligado?

Hoy en día están obligados al SII unos 62.000 contribuyentes que representan aproximadamente el 80 % de la recaudación de IVA en España. Para el resto, sigue siendo voluntario.

La llave técnica: certificado de empresa (sello)

Las comunicaciones al SII se realizan mediante servicios web de la AEAT, autenticados con el certificado de representante de persona jurídica o el certificado de sello de persona jurídica emitido por una autoridad de certificación cualificada. Esto ya anticipa la distinción que abordaremos más adelante sobre firma vs. sello.

3. Veri-factu: integridad de secuencia en el registro en origen

Veri-factu (oficialmente, el sistema de emisión de facturas verificables regulado por el Real Decreto 1007/2023 (modificado por RD 254/2025 y RD-ley 15/2025) y desarrollado por la Orden HAC/1177/2024) tiene una naturaleza diferente al SII: no es un sistema de envío a la Administración en tiempo real (aunque puede serlo), sino un sistema de integridad en origen.

La idea central

Todo software de facturación que no esté acogido al SII deberá, a partir de su entrada en vigor, generar facturas que:

Incluyan un código QR que permita al receptor verificar la factura en la sede electrónica de la AEAT.
Incorporen un mecanismo de hashes encadenados en el sistema de control de llevanza de facturas consecutivas, de modo que cualquier alteración posterior sea detectable (adición o eliminación de registros).
Puedan enviarse a la AEAT de forma voluntaria (modalidad VERI*FACTU) o simplemente conservarse en el sistema del emisor (modalidad de registro seguro) a disposición de que lo solicite la AEAT.

¿Quién está obligado?

Todos los empresarios y profesionales no obligados al SII que utilicen sistemas informáticos de facturación, con las excepciones habituales (contribuyentes que ya están en el SII quedan fuera del ámbito de Veri-factu, precisamente porque ya reportan la información al instante).

Fecha de entrada en vigor

Tras el Real Decreto-ley 15/2025, de 2 de diciembre

Personas jurídicas (Entidades del Impuesto sobre Sociedades): 1 de enero de 2027
Personas físicas (autónomos): 1 de julio de 2027

En resumen: el SII manda el registro a Hacienda; Veri-factu garantiza que el origen de la factura no ha sido manipulado y facilita la verificación posterior. Son excluyentes

4. La factura electrónica B2B: la Ley Crea y Crece

La Ley 18/2022, de creación y crecimiento de empresas (conocida como Ley Crea y Crece), establece en su artículo 12 la obligación de facturar electrónicamente entre empresarios y profesionales en sus relaciones B2B. Esta obligación se concreta en el Real Decreto 238/2026, de 25 de marzo que señala la futura publicación de la Orden Ministerial para dar cobertura a la solución pública gestionada por la AEAT

Plazos de aplicación efectiva (contados desde la publicación de la Orden Ministerial de desarrollo de la solución pública de facturación electrónica):

12 meses → empresas con volumen de operaciones > 8 millones €.
24 meses → resto de empresarios y profesionales.

Durante los primeros 12 meses las grandes empresas podrán acompañar la factura electrónica con un PDF legible (salvo que el cliente acepte expresamente el formato estructurado).

¿Qué exige?

Que la factura se emita en un formato estructurado (UBL, CII, EDIFACT y Facturae) y se transmita por plataformas de intercambio interoperables.
Que las plataformas —tanto la pública (FACeB2B) como las privadas acreditadas— garanticen la autenticidad e integridad de las facturas.
Que el receptor no pueda rechazar la recepción de facturas electrónicas. La eliminación del requisito de aceptación del destinatario en el artículo 232 de la Directiva del IVA es el cambio del paquete “IVA en la era digital” (ViDA) con la Directiva 2025/516, el Reglamento 2025/517 y el Reglamento de Ejecución 2025/518 que permite a los Estados miembros hacer obligatoria la factura electrónica también para el receptor.

¿Qué no es la factura electrónica?

Un PDF enviado por correo electrónico no es una factura electrónica a efectos de la Ley Crea y Crece, aunque la normativa de IVA lo tolere cuando hay acuerdo entre partes. La factura electrónica en sentido estricto requiere un formato estructurado y un canal de transmisión que garantice la autenticidad.

La firma y el sello en la factura electrónica

El reglamento Facturae y el estándar FacturaE ya exigen desde hace años la firma electrónica de la factura. Para una persona jurídica (empresa), lo que técnicamente corresponde es un sello electrónico —no una firma—, tal como veremos en el apartado dedicado a esta distinción.

5. Los regímenes forales: Navarra y el País Vasco

España no tiene un sistema tributario unitario. El régimen foral de Navarra y de los tres Territorios Históricos vascos (Álava, Gipuzkoa y Bizkaia) les otorga competencia normativa propia en materia de IRPF, Impuesto de Sociedades e IVA (en el caso vasco, a través del Concierto Económico; en el caso navarro, mediante el Convenio Económico) del art. 45.3 LORAFN (Ley Orgánica 13/1982). El nuevo RD 238/2026 incluye una disposición adicional específica para garantizar la interoperabilidad.

¿Los regímenes forales tienen su propio SII y Veri-factu?

Sí, y este es un punto que sorprende a muchos:

Régimen	SII	Veri-Factu equivalente	Factura electrónica B2B (RD 238/2026)
Territorio Común (AEAT)	Real Decreto 596/2016	RD 1007/2023 (plazos 2027)	Obligatoria (plazos según volumen)
País Vasco	Propio (a través de Concierto Económico)	TicketBAI	Adaptada vía acuerdos con Haciendas Forales
Navarra	Propio (Convenio Económico)	Sistema equivalente (NaTicket u homólogo)	Adaptada vía acuerdos con Hacienda Foral

TicketBAI y BATUZ: el adelanto vasco

TicketBAI es el sistema de facturación verificable del País Vasco, conceptualmente muy similar a Veri-factu pero anterior en el tiempo: encadena facturas con hash, genera un código QR verificable y exige que el software de facturación esté certificado por las Haciendas Forales. BATUZ es el proyecto más amplio que incluye TicketBAI y el sistema de libros de registro (LROE – Libro de Registro de Operaciones Económicas), que sustituye a los modelos 130, 303 y 347 para los contribuyentes vascos.

El País Vasco, en definitiva, ha sido el laboratorio de lo que luego se ha exportado al territorio común como Veri-factu.

Implicaciones prácticas para empresas que operan en ambos territorios

Una empresa con sede en Madrid que venda a clientes en el País Vasco no está obligada a TicketBAI (esa obligación recae sobre los contribuyentes del foro vasco). Sin embargo, si tiene un establecimiento permanente en Bizkaia o es contribuyente foral, sí aplica. Las empresas que operan en ambos territorios deben implementar sistemas que puedan adaptarse a ambas normativas, o invertir en soluciones que soporten múltiples regímenes.

6. Firma electrónica y sello electrónico: la distinción que la normativa tributaria no siempre aclara

Llegamos al punto que, en mi opinión, genera más confusión técnica y jurídica en todo este ecosistema.

Lo que dice la normativa tributaria

El artículo 10 del Real Decreto 1619/2012 (Reglamento de facturación) exige que las facturas electrónicas garanticen la autenticidad del origen y la integridad del contenido mediante firma electrónica avanzada basada en certificado reconocido o cualificado. Muchos textos normativos recientes hablan genéricamente de «firma electrónica» sin mayor precisión.

Lo que dice el Reglamento eIDAS (910/2014/UE)

El Reglamento (UE) 910/2014 (eIDAS), que es de aplicación directa en toda la UE, establece una distinción fundamental:

La firma electrónica (electronic signature) es un mecanismo exclusivo de personas físicas. Solo una persona física puede «firmar» en sentido eIDAS.
El sello electrónico (electronic seal) es el mecanismo equivalente para personas jurídicas: acredita el origen y la integridad de un documento emitido por una organización, sin que deba intervenir ninguna persona física concreta.

Esta distinción no es un tecnicismo menor: una empresa que «firma» una factura con el certificado personal de su director financiero está creando un vínculo jurídico innecesario con esa persona física, exponiéndola a responsabilidades que en realidad son de la empresa. Además, cuando esa persona cambia de cargo o abandona la empresa, el sistema deja de funcionar o genera facturas con certificados caducados.

¿Por qué la normativa tributaria no lo deja claro?

La normativa tributaria española se redactó —y en muchos casos sigue redactándose— con anterioridad o sin plena integración del enfoque eIDAS. Cuando el Reglamento de facturación habla de «firma electrónica reconocida», hay que leerlo como un requisito de nivel de garantía equivalente al de un sello electrónico cualificado cuando quien emite la factura es una persona jurídica. La Directiva sobre facturación electrónica (2014/55/UE) y los estándares EN 16931 ya apuntan en esta dirección.

La lectura correcta, por tanto, es:

Si emite la factura una persona física (autónomo): usa firma electrónica cualificada.
Si emite la factura una persona jurídica (empresa, sociedad): usa sello electrónico cualificado.

El sello electrónico cualificado es el mecanismo técnico que garantiza la autenticidad e integridad tanto en Veri-Factu, en el SII como en la nueva factura electrónica B2B. Es la misma tecnología que ya se podía usar para el SII y que ahora se extiende al resto de obligaciones.”

7. El sello electrónico cualificado remoto: la pieza que lo une todo

Tanto el SII como Veri-factu, TicketBAI/BATUZ y la factura electrónica B2B requieren que las facturas o los mensajes transmitidos a las Administraciones vayan autenticados con un certificado válido de la persona jurídica emisora. El sello electrónico cualificado es el instrumento técnico-jurídico adecuado para ello.

La evolución más relevante de los últimos años es la consolidación del sello electrónico remoto: el material criptográfico (la clave privada) reside en un HSM (dispositivo cualificado de creación de firma en la nube), operado por un prestador de servicios de confianza cualificado (QTSP). El software de facturación invoca el sello a través de una API sin necesidad de gestionar localmente ningún certificado ni hardware.

Ventajas del sello remoto cualificado para la facturación

Escenario	Beneficio del sello remoto
SII (envíos masivos a AEAT)	El servidor de facturación sella miles de registros por segundo sin gestión local de tokens
Veri-factu (hash + QR)	Cada factura queda sellada en origen de forma automática e integrada en el flujo de negocio
TicketBAI / BATUZ	Los sistemas de facturación para el País Vasco ya prevén integración con APIs de sello remoto
Factura electrónica B2B	Las plataformas de intercambio pueden sellar en nombre de la empresa emisora sin depender de certificados locales que caducan o se pierden
Factura electrónica en Navarra	El sello remoto permite centralizar la emisión aunque la empresa opere bajo el Convenio Económico

8. Cuadro comparativo final

Concepto	Quién obliga	A quién aplica	Qué garantiza	Instrumento de autenticación
SII	AEAT (territorio común)	Grandes empresas y grupos de IVA	Reporte de registros en tiempo real	Certificado de sello / representante de PJ
Veri-factu	AEAT (territorio común)	Resto de empresarios no en SII	Integridad en origen + verificación QR	Hash encadenado + sello en envío voluntario
TicketBAI / BATUZ	Haciendas Forales vascas	Contribuyentes forales vascos	Integridad en origen + reporte LROE	Certificado reconocido / sello
SII foral navarro	Hacienda Foral Navarra	Contribuyentes de Navarra	Reporte de registros	Certificado emitido bajo normativa foral
Factura electrónica B2B	Ley Crea y Crece + reglamento pendiente	Todos los empresarios y profesionales	Formato estructurado + autenticidad e integridad	Sello electrónico cualificado de la PJ emisora

9. Contacte con EADTrus si necesita un sello electrónico remoto cualificado

Si tu empresa necesita adaptarse a alguno —o a varios— de los marcos normativos descritos en este artículo, la pieza transversal que simplifica todos los escenarios es el sello electrónico remoto cualificado.

EADTrust es un prestador de servicios de confianza cualificado (QTSP) inscrito en la Lista de Confianza española (TSL), que ofrece servicios de sello electrónico remoto cualificado en la nube especialmente orientados a entornos de facturación masiva. Sus características clave:

Alta disponibilidad y escalabilidad: apropiado para entornos SII con miles de operaciones diarias.
Integración por API: los sistemas de facturación (ERP, plataformas B2B, software de TicketBAI) se conectan sin cambios de arquitectura.
Cumplimiento eIDAS y normativa tributaria española: el sello es cualificado conforme al Reglamento 910/2014, lo que cubre los requisitos de autenticidad e integridad exigidos por el Reglamento de facturación y la Ley Crea y Crece.
Soporte multi-régimen: el mismo sello sirve para el SII de la AEAT, para Veri-factu, para plataformas de intercambio B2B y para los entornos forales vascos y navarro.
Gestión del ciclo de vida del certificado: renovaciones, revocaciones y auditorías sin impacto en los sistemas del cliente.

Si quieres más información sobre cómo integrar el sello remoto cualificado de EADTrust en tu plataforma de facturación, puedes contactar con su equipo técnico llamando al 917160555 (también 902 365 612) o consultar la documentación disponible en su web.

Conclusión

El ecosistema de la facturación en España es, como hemos visto, un mosaico de obligaciones con distinto origen normativo, distinto ámbito subjetivo y distintos plazos. La buena noticia es que todos estos marcos comparten una misma necesidad técnica: garantizar la autenticidad e integridad de las facturas mediante criptografía. Y la solución idónea para las personas jurídicas —que es la inmensa mayoría de los obligados— es el sello electrónico cualificado, preferiblemente en modalidad remota para facilitar la integración y la escalabilidad.

La distinción entre firma (personas físicas) y sello (personas jurídicas) que establece el Reglamento eIDAS no es un detalle menor: es el fundamento jurídico que da validez duradera a todos los documentos electrónicos que emitimos como empresas. Leer la normativa tributaria con las gafas de eIDAS no es optativo: es necesario para implementar bien.

¿Tienes dudas sobre qué sistema aplica a tu empresa o cómo integrar el sello remoto en tu plataforma? Llámanos al 917160555 o al 902 365 612.

Publicado el nuevo Reglamento de Ejecución (UE) 2026/798 para el desarrollo de la Cartera IDUE

2 respuestas

Ayer, 8 de abril de 2026, se publicó en el Diario Oficial de la Unión Europea el REGLAMENTO DE EJECUCIÓN (UE) 2026/798 DE LA COMISIÓN de 7 de abril de 2026 por el que se establecen disposiciones de aplicación del Reglamento (UE) n.^o 910/2014 del Parlamento Europeo y del Consejo en lo que respecta a las normas de referencia y especificaciones para la incorporación a distancia de usuarios a las carteras europeas de identidad digital por medios de identificación electrónica conformes con el nivel de seguridad sustancial junto con procedimientos adicionales de incorporación a distancia cuando la combinación cumpla los requisitos del nivel de seguridad alto.

Este acto de ejecución se basa en el artículo 5 bis, apartado 24, del Reglamento eIDAS (UE) 910/2014.

Su objetivo es fijar normas técnicas y especificaciones armonizadas para permitir la incorporación remota (onboarding) segura de usuarios a las carteras europeas de identidad digital (EUDI Wallets), utilizando medios de identificación electrónica (eID) de nivel de seguridad sustancial, y procedimientos adicionales para alcanzar el nivel alto. Esto garantiza confianza, seguridad y coherencia en toda la UE.

Los «Considerandos» principales:

La incorporación remota es esencial para verificar la identidad del usuario y vincularla a la cartera y al dispositivo.
Se utilizan normas ya consolidadas (basadas en ETSI) adaptadas al contexto de las carteras europeas.
Cuando el eID ya tiene nivel alto, no es necesario repetir verificaciones.
Para eID no notificados, se exige evaluación por organismos acreditados.
Se aplican plenamente las normas de protección de datos (RGPD, Reglamento 2018/1725 y Directiva 2002/58/CE).

Incluye 2 artículos:

Artículo 1: Establece que las normas de referencia y especificaciones aplicables figuran en el Anexo.
Artículo 2: Entrada en vigor y aplicabilidad (ver abajo).

El Anexo remite a la norma ETSI TS 119 461 V2.1.1 (febrero 2025) y selecciona/adapta sus cláusulas para dos escenarios:

Incorporación remota con eID de nivel sustancial (Baseline LoIP).
Procedimientos adicionales para alcanzar nivel alto (Extended LoIP).

Sección 1 – Cláusulas aplicables (selección de la ETSI TS 119 461):

Gestión de riesgos operativos, políticas y prácticas, gestión del servicio de verificación de identidad, requisitos del servicio, casos de uso concretos (con documento de identidad atendido/no atendido, por autenticación con eID, y refuerzo de nivel).

Sección 2 – Adaptaciones específicas (modificaciones importantes):

Evaluación de riesgos y políticas de prácticas.
Gestión del servicio (notificaciones, conservación de pruebas, gestión de crisis, acuerdos de cese).
Protección de datos por diseño y por defecto (limitación de datos biométricos).
Requisitos de verificación de identidad: uso de eID notificados o certificados por organismo acreditado, captura de imagen facial segura (comunicación de campo cercano con chip), tasas de falsa aceptación/rechazo (FAR/FRR).
Refuerzo de nivel: procedimientos para pasar de Baseline a Extended LoIP (solo cuando no se usó comparación facial automatizada).

Todo el proceso debe cumplir los requisitos de los Reglamentos de Ejecución (UE) 2015/1502 y ETSI EN 319 401.

Disposiciones finales

Entrada en vigor: a los veinte días de su publicación en el DOUE (es decir, el 28 de abril de 2026).
Aplicabilidad: obligatorio en todos sus elementos y directamente aplicable en todos los Estados miembros.

Con este acto de ejecución se confirma que decae (pierde aplicabilidad efectiva) la Orden ETD/465/2021 en el contexto de la incorporación remota a las carteras europeas de identidad digital (EUDI Wallets) y en las evaluaciones de conformidad de sistemas de verificación de identidad remota.

Por esta razón:

El Reglamento eIDAS 2.0 (Reglamento (UE) 2024/1183) y especialmente el Reglamento de Ejecución (UE) 2026/798 establecen un marco armonizado a nivel europeo.
Ambos remiten directamente a la norma ETSI TS 119 461 (versión 2.1.1 o posterior) como estándar único para la verificación de identidad remota.
La Orden ETD/465/2021 era una norma aplicable en España antes de la publicación del EIDAS2 (Reglamento UE 2024/1183) que detallaba cómo realizar la identificación remota y pierde sentido una vez publicada la norma europea armonizada ETSI TS 119 461.

Todavía podría utilizarse la Orden ETD/465/2021 en España para la expedición de certificados cualificados “tradicionales” (no para gestionar la identidad en «wallets»). Pero para esa funcionalidad también es posible optar por aplicar la norma ETSI TS 119 461.

Cambios a la norma ETSI TS 119 461

El Anexo del Reglamento de Ejecución da indicaciones respecto a la forma de usar la norma de referencia:

La conformidad se evalúa con arreglo a las cláusulas de ETSI TS 119 461 V2.1.1 (2025-02) enumeradas en la sección 1, con sujeción a las adaptaciones enumeradas en la sección 2.

Sección 1 — Cláusulas aplicables

5	Operational risk assessment;
6	Policies and practices;
7	Identity proofing service management and operation;
8	Identity proofing service requirements;
9.1	Introduction, compliance with the present document, general requirements for all use cases;
9.2.2	Use cases using an identity document for attended remote identity proofing;
9.2.3	Use cases using an identity document for unattended remote identity proofing;
9.2.4	Use case for identity proofing by authentication using eID means;
9.5	Use cases for additional identity proofing to enhance an identity proven by use of an eID from Baseline LoIP to Extended LoIP.

Sección 2 — Adaptaciones

1)	5	Operational risk assessment
	—	OVR-5-01: Se aplicarán los requisitos especificados en la norma ETSI EN 319401 [1], cláusula 5.
	—	Nota 1: Cuando la acreditación de la identidad sea realizada por el propio proveedor de datos de identificación de la persona, la evaluación de riesgos del proveedor de datos de identificación de la persona puede abarcar la acreditación de la identidad.
2)	6.1	Identity proofing service practice statement
	—	OVR-6.1-02: Los prestadores de servicios de acreditación de la identidad (IPSP) identificarán en su declaración de prácticas los casos de uso para los que se declara la conformidad con el presente documento.
	—	Nota 1: Cuando la acreditación de la identidad sea realizada por el propio proveedor de datos de identificación de la persona, la declaración de prácticas del servicio de acreditación de la identidad del proveedor de datos de identificación de la persona puede abarcar la información sobre la acreditación de la identidad y no será necesaria ninguna declaración de prácticas específica para la acreditación de la identidad.
3)	7.9	Vulnerabilities and incident management
	—	OVR-7.9-02: Las obligaciones de notificación con arreglo a la norma ETSI EN 319401 [1], REQ-7.9.2-02X y cláusula 7.9.3, se cumplirán según lo exigido por el contexto de la acreditación de la identidad y las obligaciones del proveedor de datos de identificación de la persona que se base en el servicio del IPSP.
	—	EJEMPLO: La notificación a la autoridad de control que supervise a un proveedor de carteras europeas de identidad digital establecido en el Estado miembro que efectúa la designación puede llevarse a cabo en cooperación entre el IPSP y el proveedor de datos de identificación de la persona.
4)	7.10	Collection of evidence
	—	OVR-7.10-01: Se aplicarán los requisitos especificados en la norma ETSI EN 319401 [1], cláusula 7.10.
	—	Nota 1: Los requisitos a largo plazo para la conservación de pruebas pueden ser cumplidos por el proveedor de datos de identificación de la persona que solicita la acreditación de la identidad en lugar de por el IPSP cuando ambos sean entidades diferentes.
	—	Nota 2: Se aplican los requisitos del punto 8.5.2 del presente documento.
5)	7.11	Business continuity management
	—	OVR-7.11-02: Los procesos para la gestión de crisis con arreglo a la norma ETSI EN 319401 [1], REQ-7.11.3-01X, serán los requeridos por el contexto de la acreditación de la identidad y las obligaciones del proveedor de datos de identificación de la persona que se base en el servicio del IPSP.
6)	7.12	Termination and termination plans
	—	OVR-7.12-01: Se aplicarán los requisitos especificados en la norma ETSI EN 319401 [1], cláusula 7.12, excepto REQ-7.12-11.
	—	Nota: Cuando el IPSP y el proveedor de datos de identificación de la persona que solicita la acreditación de la identidad sean entidades diferentes, pueden acordar una asistencia mutua o unilateral a la hora de establecer planes de cese.
7)	8.1	Initiation
	—	INI-8.1-05: En caso de que el proceso de acreditación de la identidad a distancia se interrumpa o falle, el IPSP garantizará que se proporcionen a las personas explicaciones suficientes y vías de recurso, en particular en el caso de la acreditación de la identidad a distancia no atendida. La información debe garantizar que las personas puedan contribuir eficazmente a la rápida resolución del problema y, en caso necesario, ejercer sus derechos como interesados, como el derecho de rectificación o la posibilidad de impugnar la decisión, contra el responsable del tratamiento pertinente.
8)	8.2.1	General requirements
	—	COL-8.2.1-08: El IPSP aplicará medidas para garantizar el cumplimiento de los requisitos de protección de datos desde el diseño y por defecto de conformidad con el artículo 25 del Reglamento (UE) 2016/679 durante el proceso de incorporación, especialmente en lo que respecta al tratamiento de datos biométricos. Las medidas pertinentes podrán consistir en controles criptográficos, dispositivos y medidas organizativas adecuados que mejoren la privacidad. Tales medidas deben limitar la recogida de datos a lo estrictamente necesario para el tratamiento de los datos biométricos y cualquier otro dato personal que deba recogerse de las fuentes físicas y digitales de identificación a fin de vincular los datos de identificación personal del usuario a sus carteras y al dispositivo del usuario en el que esté instalada la unidad de cartera.
9)	8.2.4	Use of existing eID means as evidence
	—	[CONDICIONAL] COL-8.2.4-02X: Si el objetivo es el nivel básico de acreditación de la identidad (Baseline LoIP), los medios de identificación electrónica deberán haber sido notificados al menos como de un nivel de seguridad eIDAS sustancial o su nivel de seguridad deberá haber sido confirmado por un organismo de evaluación de la conformidad acreditado, tal como se define en el artículo 2, punto 13, del Reglamento (CE) n.^o 765/2008, o por un organismo equivalente, y, si se cumplen todos los requisitos aplicables, la evaluación dará lugar a un certificado de conformidad basado en una auditoría de certificación. Este proceso de certificación formal se basará en un proceso de evaluación de la seguridad que se refiera a los niveles de seguridad definidos para los medios de identificación electrónica notificados o para las carteras europeas de identidad digital certificadas en virtud del Reglamento (UE) n.^o 910/2014 [i.25].
	—	COL-8.2.4-02A: sin efecto.
10)	8.3.1	General requirements
	—	VAL-8.3.1-11X: El proceso de acreditación de la identidad verificará que las pruebas sean válidas en el momento de la acreditación de la identidad.
11)	8.3.3	Validation of physical identity document
	—	VAL-8.3.3-21: La eficacia de las medidas para cumplir los requisitos VAL-8.3.3-05X, VAL-8.3.3-05A, VAL-8.3.3-05B, VAL-8.3.3-05C, VAL-8.3.3-07A y VAL-8.3.3-07X será confirmada por un organismo de evaluación de la conformidad acreditado, tal como se define en el artículo 2, punto 13, del Reglamento (CE) n.^o 765/2008, o por un organismo equivalente.
	—	VAL-8.3.3-22: La imagen facial de referencia del documento físico de identidad se recogerá utilizando la comunicación de campo cercano y el proceso llevará a cabo la autenticación pasiva o activa del chip del documento físico de identidad.
12)	9.1	Introduction, compliance with the present document, general requirements for all use cases
	—	USE-9.1-01X: Para ser conformes con el presente documento, los procesos de acreditación de la identidad se ajustarán al caso de uso de la cláusula 9.5 del presente documento para el nivel ampliado de acreditación de la identidad (Extended LoIP).
	—	USE-9.1-03X: sin efecto.
13)	9.2.3.4	Use case for automated operation
	—	USE-9.2.3.4-04: El IPSP establecerá valores objetivo para la tasa de falsa aceptación (FAR) y la tasa de falso rechazo (RRF), sobre la base de un análisis de riesgos y su procedimiento de inteligencia sobre amenazas, siguiendo la metodología establecida en el informe de ENISA «Methodology for sectoral cybersecurity assessments» («Metodología para las evaluaciones sectoriales de la ciberseguridad», documento en inglés) [i.28] o una metodología equivalente, en procesos de acreditación de identidad totalmente automatizados. Los valores objetivo utilizados por el IPSP serán iguales o inferiores a los establecidos para los casos de uso de carácter híbrido, cuando existan. El IPSP mantendrá estos valores objetivo para la FAR y la RRF de manera coherente, con el apoyo de un análisis de riesgos y su procedimiento de inteligencia sobre amenazas.
14)	9.5.1	General requirements
	—	Primer apartado: Cuando el solicitante sea una persona física, también una persona física que represente a una persona jurídica, y se haya acreditado la identidad del solicitante al nivel básico de acreditación de la identidad (Baseline LoIP) mediante autenticación utilizando una identificación electrónica, y se requiera un refuerzo hasta el Extended LoIP, se aplicarán los requisitos siguientes.
	—	USE-9.5.1-08: La acreditación de la identidad adicional necesaria para reforzar la fiabilidad de una identidad solo es aplicable a la identificación electrónica que no se haya expedido basándose en una comparación automatizada entre imágenes faciales para el proceso de expedición inicial.
15)	9.5.2	Use case for enhancing identity proofing to Extended LoIP by a full identity proofing using an identity document
	—	USE-9.5.2-01: La acreditación de la identidad a fin de pasar del Baseline LoIP al Extended LoIP se ajustará a los requisitos del nivel ampliado de acreditación de la identidad de uno de los casos de uso descritos en las cláusulas 9.2.2 o 9.2.3 del presente documento para el Extended LoIP.
16)	9.5.3	Use case for enhancing identity proofing to Extended LoIP by use of a previously captured reference face image
	—	USE-9.5.3-01: Para captar una imagen facial de referencia y vincular los atributos de identidad necesarios a dicha imagen, se utilizará un proceso de acreditación de la identidad que cumpla los requisitos del Extended LoIP de uno de los casos de uso descritos en las cláusulas 9.2.2 o 9.2.3 del presente documento, o el proceso de acreditación de la identidad ha sido revisado por pares o certificado por un organismo de evaluación de la conformidad acreditado definido en el artículo 2, punto 13, del Reglamento (CE) n.^o 765/2008 o un organismo equivalente para cumplir el nivel de seguridad alto con arreglo al Reglamento (UE) n.^o 910/2014 [i.25].

Estos son requisitos que no se incluyen en la norma indicada: ETSI TS 119 461 V2.1.1 (2025-02) por lo que puede ser interesante tener una «norma» modificada como referencia.

Adaptación de las Entidades Financieras a la Cartera de Identidad Digital de la UE (Cartera IDUE o EUDI Wallet)

2 respuestas

En un mundo cada vez más digitalizado, la Unión Europea ha dado pasos decisivos hacia la estandarización de la identificación electrónica con la introducción de la Cartera de Identidad Digital Europea (EUDI Wallet).

Esta herramienta, regulada por el Reglamento eIDAS 2.0 (Reglamento (UE) 2024/1183), que modifica el Reglamento UE 910/2014, permite a los ciudadanos y empresas almacenar y gestionar de forma segura sus identidades digitales, incluyendo atributos como permisos de conducción, diplomas o declaraciones de atributos relativas a cuentas bancarias. También permite realizar firmas electrónicas cualificadas y sellos electrónicos cualificados. El objetivo es otorgar a los usuarios un control total sobre sus datos, facilitando el acceso a servicios en línea con una cesión mínima de información, solo la imprescindible para la gestión a realizar.

Para las entidades financieras, esta innovación no es opcional: representa una obligación legal que transforma los procesos de identificación y verificación de clientes.

La Obligatoriedad de Aceptar la EUDI Wallet

El Reglamento eIDAS 2.0 establece (artículo 5 septies) que los proveedores de servicios que estén legalmente obligados a identificar inequívocamente a sus clientes deben aceptar la EUDI Wallet como método de autenticación.

En el sector financiero, esto afecta directamente a bancos, instituciones de crédito y otras entidades reguladas, especialmente en procesos como el Know Your Customer (KYC) y procesos de Debida Diligencia para la prevención del blanqueo de capitales.

El citado artículo 5 septies del Reglamento obliga a estas entidades a integrar la cartera como una opción válida para la identificación electrónica, lo que reduce barreras transfronterizas y mejora la eficiencia en transacciones digitales.

Esta obligación se extiende a sectores como la banca, los servicios financieros y cualquier entidad sujeta a requisitos de identificación estrictos. No se trata solo de cumplimiento normativo, sino de una oportunidad para optimizar operaciones, ya que la EUDI Wallet proporciona datos verificados e inalterables directamente de fuentes auténticas, minimizando riesgos de fraude y agilizando el «onboarding» de clientes.

La adaptación requiere una integración técnica y operativa en los sistemas existentes, por un lado para el proceso de apertura de cuenta (en el que el uso de sistemas cualificados simplifica la documentación que tiene que recabar la entidad financiera) y después para añadir una opción en la pantalla web en la que se ofrece a los clientes acceder a la información y servicios asociados a su cuenta, ya que al clickar en esa opción se desencadena la funcionalidad de identificación y autenticación de la cartera.

Las entidades financieras deben:

Actualizar sus plataformas de identificación para el acceso a la banca electrónica: Incorporar APIs y SDK compatibles con la EUDI Wallet para permitir la autenticación segura. Esto implica adoptar los protocolos estandarizados que se recogen en el ARF y en los actos de ejecución para asegurar la interoperabilidad con las diferentes carteras emitidas por los Estados miembros.
Revisar sus procesos de KYC y onboarding: La cartera permite solicitar al cliente que aporte atributos (como los que figuran en la credencial inicial DIP, «Datos de Información Personal») y otros atributos exigibles según los principios de debida diligencia (quizá la presentación de una nómina o una declaración electrónica de atributos semejante, como ingresos anuales o cualificaciones profesionales), lo que simplifica la «due diligence». Las interfaces bancarias con la cartera se configuran para solicitar declaraciones de atributos y para solicitar la firma electrónica de documentos (la cartera permite realizar «QES» «qualified electronic signature» y «qualified electronic seal»). Se deberán conservar las evidencias electrónicas de la contratación (posiblemente preservadas mediante sellos de tiempo cualificados). Será preciso registrar a la entidad en el registro de «Relying Parties» o «Partes Usuarias» («Partes informadas», en mi traducción del ARF) y obtener el certificado que establece el tipo de información que puede solicitar a la cartera
Las entidades deben revisar sus contratos y «términos y condiciones» para acoger las nuevas circunstancias de apertura de cuentas y acceso a la banca electrónica y dar formación a su personal para que entiendan las nuevas circunstancias de contratación y autenticación y puedan dar soporte a los clientes.
Garantizar la seguridad y privacidad: Cumplir con el RGPD (y la LOPD/GDD) y las directrices de eIDAS 2.0, asegurando que los usuarios tengan control sobre sus datos (en ciertas condiciones, mediante divulgación selectiva y «pruebas de conocimiento cero»).
Colaborar con proveedores de confianza: Asociarse con prestadores cualificados de servicios electrónicos para implementar soluciones compatibles, como firmas electrónicas cualificadas o sellos de tiempo, que complementen la integración de la cartera.

Esta adaptación no solo permite cumplir con las exigencias regulatorias, sino que posiciona a las entidades que se anticipen, como líderes en innovación digital, mejorando la experiencia del usuario y reduciendo costes operativos.

Plazos para la Implementación

Los Estados miembros de la UE, incluyendo España, tienen la obligación de proporcionar al menos una versión de la EUDI Wallet a sus ciudadanos antes de finales de 2026 (24 meses tras la entrada en vigor del primer lote de actos de ejecución). Antes de fin de 2027 (36 meses tras la entrada en vigor de los citados actos de ejecución), la aceptación de la cartera será obligatoria para las organizaciones del sector privado reguladas, como las entidades financieras, y otras que se citan en el artículo 5 septies.

Si no se demora la decisión de acometer los cambios, queda margen para pruebas piloto y ajustes, pero empieza a ser urgente que las entidades inicien su preparación cuanto antes para evitar sanciones y aprovechar las ventajas competitivas.

Conexión con PSD3 y el Reglamento de Servicios de Pago (PSR)

La adaptación a la EUDI Wallet no puede analizarse de forma aislada en el sector financiero, sino en el contexto más amplio de la revisión del marco europeo de servicios de pago. La Comisión Europea ha propuesto sustituir la actual PSD2 por una nueva Directiva de Servicios de Pago (PSD3) y, paralelamente, aprobar un Reglamento de Servicios de Pago (PSR) de aplicación directa en todos los Estados miembros. Ambos instrumentos refuerzan los requisitos de autenticación reforzada del cliente (SCA) y abren la puerta a que la identidad digital verificada —precisamente la que proporciona la EUDI Wallet— pueda usarse como mecanismo de autenticación en el acceso a cuentas de pago y en la iniciación de operaciones.

En la práctica, esto significa que las entidades financieras que integren la cartera para sus procesos de KYC y onboarding estarán también construyendo una infraestructura compatible con las exigencias de autenticación que se avecinan con PSD3/PSR, evitando duplicidades tecnológicas. La EUDI Wallet puede actuar como un vector común de identidad verificada tanto para el cumplimiento AML como para la autenticación en el acceso a servicios de pago, lo que convierte su integración en una inversión con retorno regulatorio múltiple y no en un mero coste de cumplimiento puntual.

Consideraciones sobre la Ley 10/2010 y el Reglamento (UE) 2024/1624

La Ley 10/2010, de 28 de abril, de prevención del blanqueo de capitales y de la financiación del terrorismo, impone a las entidades financieras obligaciones estrictas de identificación y verificación de clientes (artículos 3 a 10). Los servicios cualificados a los que se refiere esta ley en su artículo 12, inspirados en el Reglamento eIDAS, incluyen mecanismos electrónicos de confianza como firmas cualificadas, sellos electrónicos y sistemas de identificación remota. Es preceptivo conservar las evidencias electrónicas que acreditan el cumplimiento de lo señalado en este artículo.

La adaptación a la EUDI Wallet, aunque establecida en un Reglamento Europeo, tiene encaje con lo dispuesto en estos requisitos, ya que la cartera actúa como un medio de identificación electrónica cualificado, reconocido en toda la UE.

El Reglamento (UE) 2024/1624 es una de las piezas centrales del nuevo paquete legislativo europeo contra el blanqueo de capitales y la financiación del terrorismo (AML/CFT). Se aprobó el 31 de mayo de 2024 y se publicó en el DOUE el 19 de junio de 2024. Su objetivo es sustituir la fragmentación normativa existente y establecer normas directamente aplicables en todos los Estados miembros para reforzar la integridad del sistema financiero europeo.

El Reglamento (UE) 2024/1620 crea la Autoridad de Lucha contra el Blanqueo de Capitales (en inglés Anti-Money Laundering Authority – AMLA) y la Financiación del Terrorismo y se modifican los Reglamentos (UE) n.º 1093/2010, 1094/2010 y 1095/2010. Recientemente AMLA ha abierto una consulta pública (9 febrero – 8 mayo 2026) sobre los Regulatory Technical Standards (RTS) previstos en el artículo 28(1) del Reglamento (UE) 2024/1624, que desarrollan en detalle cómo deben aplicar los sujetos obligados la diligencia debida con el cliente.

Estos RTS son esenciales porque convierten los principios del Reglamento AML en instrucciones operativas concretas y uniformes en toda Europa, qué información recoger, cómo verificarla, qué hacer en casos de riesgo. El «draft» señala (pág. 29) que el cumplimiento de la sección 9 se logra con el cumplimiento del Reglamento de Ejecución (UE) 2024/2977 de la Comisión, de 28 de noviembre de 2024, que establece las normas técnicas y procedimentales para la aplicación del Reglamento eIDAS 2 en lo relativo a:

Datos de identificación de la persona (PID)
Declaraciones electrónicas de atributos (EAA / QEAA)
Su expedición a las Carteras de Identidad Digital de la Unión Europea (EUDI Wallets)

La complejidad regulatoria da otra vuelta de tuerca porque, como comenté recientemente hay nuevos borradores de actos de ejecución en relación con #EIDAS2 y la EUDI Wallet y uno de ellos, precisamente, modifica el Reglamento de Ejecución (UE) 2024/2977.

El papel de la EBA y sus Directrices sobre onboarding remoto

La Autoridad Bancaria Europea (EBA) publicó el 22 de noviembre de 2022 sus Directrices sobre el uso de soluciones de incorporación remota de clientes (EBA/GL/2022/15), aplicables desde el 2 de octubre de 2023 a todas las entidades de crédito e instituciones financieras en el ámbito de la Directiva AML. Estas directrices establecen estándares comunes europeos para los procesos de diligencia debida inicial en el contexto del onboarding digital, y resultan directamente relevantes para la integración de la EUDI Wallet: la EBA reconoce expresamente en su texto que las entidades que utilicen soluciones basadas en esquemas de identificación electrónica notificados bajo eIDAS, o en servicios de confianza cualificados, pueden asumir que tales soluciones cumplen los requisitos de verificación de identidad establecidos en la Directiva, sin necesidad de duplicar las evaluaciones de gobernanza ya realizadas en el marco del propio Reglamento eIDAS. En la práctica, esto significa que una entidad financiera que integre correctamente la EUDI Wallet como mecanismo de identificación del cliente estará, de forma simultánea, cumpliendo con las exigencias de las Directrices EBA/GL/2022/15.

Las directrices deben leerse en conjunción con otras guías de la EBA, en particular las Directrices sobre Factores de Riesgo ML/TF (EBA/GL/2021/02) y las relativas a la gestión de riesgos TIC y de seguridad (EBA/GL/2019/04), lo que refuerza la necesidad de un enfoque integral en la adaptación. Cabe señalar que la propia EBA, al publicar sus directrices de 2022, ya advertía que era consciente de que la reforma del Reglamento eIDAS y la introducción de la Cartera IDUE ayudarían a superar la fragmentación existente en materia de identificación remota, pero que hasta que dicha reforma entrase en vigor, debía basar su análisis en el marco normativo entonces vigente. Ese momento ha llegado: la EUDI Wallet ya es una realidad regulatoria, y las entidades financieras tienen ahora la oportunidad de alinear su cumplimiento AML con el nuevo ecosistema de identidad digital europeo, construyendo una infraestructura de onboarding que satisfaga simultáneamente las EBA/GL/2022/15 y los requisitos del Reglamento eIDAS 2.0.

Implicaciones del Reglamento DORA en la integración de la Cartera IDUE

Las entidades financieras que acometan la integración de la EUDI Wallet no pueden ignorar que dicha integración constituye, desde la perspectiva del Reglamento (UE) 2022/2554 (DORA), plenamente aplicable desde el 17 de enero de 2025, la incorporación de una nueva función crítica soportada por TIC, con todo lo que ello implica. DORA exige que cualquier nuevo sistema o proveedor externo que dé soporte a funciones esenciales quede incorporado al marco de gestión del riesgo TIC de la entidad: los proveedores de servicios de identificación y los prestadores cualificados de servicios de confianza que participen en el ecosistema de la cartera deberán ser objeto de la diligencia debida contractual prevista en los artículos 28 y siguientes del Reglamento, incluyendo cláusulas de auditoría, acceso, localización de datos y continuidad del servicio. La clasificación de la funcionalidad de autenticación con cartera como «función importante» —lo que es previsible dado su papel central en el acceso a la banca electrónica— activaría además la obligación de realizar pruebas de resiliencia operativa periódicas sobre esos sistemas.

Desde una perspectiva de planificación, esto significa que el proyecto de integración de la EUDI Wallet debe diseñarse desde el inicio con la arquitectura documental y contractual que DORA exige, evitando tener que remediar a posteriori las carencias de un despliegue tecnológico que no tuvo en cuenta el marco de riesgo de terceros. La buena noticia es que las exigencias de DORA y las de eIDAS 2.0 son en gran medida complementarias: ambas apuntan hacia proveedores robustos, auditables y resilientes. Una entidad que seleccione proveedores de servicios de identidad digital que sean Prestadores Cualificados de Servicios de Confianza (QTSP) registrados bajo eIDAS estará, al mismo tiempo, incorporando actores que ya han superado auditorías de conformidad rigurosas, lo que facilita considerablemente la evaluación del riesgo TIC de terceros exigida por DORA.

EADTrust

EADTrust ofrece sus servicios de adecuación a la Cartera IDUE a las entidades financieras para facilitar la integración, sumándose al equipo técnico y legal que acometa la adaptación.

EADTrust puede proporcionar Declaraciones Electrónicas de Atributos de prueba, y las APIs de los protocolos a utilizar. También aporta jefes de proyecto, programadores y juristas para acometer las diferentes facetas de la adaptación. En particular para dar seguimiento al cada vez más complejo marco regulatorio.

Presta servicios cualificados complementarios como los sellos de tiempo, y el archivo electrónico de preservación que ayudan a custodiar las evidencias digitales del proceso. Con los servicios de EAD Factory la entidad financiera cuenta con todos los servicios de un PSC (Prestador de Servicios de Certificación) cualificado como si fuera parte de su propia infraestructura.

Además EADTrust ayuda a integrarse a otras entidades que forman parte de la infraestructura y del ecosistema de la Cartera IDUE: fuentes auténticas, entidades del sector público, entidades privadas que entreguen declaraciones de atributos a sus clientes o a sus empleados,…

Aunque la interoperabilidad con la «EUDI Wallet» se vea ahora como un requisito regulatorio para las entidades señaladas en el Artículo 5 septies del Reglamento UE 910 / 2014 reformado, va a ser esencial para las entidades Fintech, y para todo el sector financiero y un motor de innovación para crear nuevos servicios.

Será la evolución natural de los servicios cualificados, promoviendo una identificación más segura y eficiente en el marco normativo europeo.

EADTrust, como Prestador Cualificado de Servicios de Confianza Electrónica registrado en el Ministerio de Asuntos Económicos y Transformación Digital, es un aliado clave en esta transición. Su equipo de Servicios Profesionales, liderado por expertos en identidad digital y eIDAS, y con experiencia en proyectos en entidades financieras y administraciones públicas ofrece soporte integral para la adaptación a la EUDI Wallet, incluyendo:

Consultoría y auditorías técnicas y legales: Evaluación de sistemas actuales y planes de implementación para garantizar interoperabilidad y cumplimiento normativo. Seguimiento de la normativa aplicable, cada vez más compleja.
Implementación de soluciones EUDI: Desarrollo de integraciones para la cartera, junto con servicios de archivo electrónico cualificado y digitalización de documentos.
Formación y soporte: Capacitación para equipos en el uso de la cartera y alineación con la Ley 10/2010 y los nuevos RTS.

Además, EADTrust ya ofrece una amplia gama de servicios cualificados eIDAS, como:

Certificados electrónicos cualificados para firmas y sellos electrónicos.
Sellado de tiempo electrónico cualificado.
Notificaciones electrónicas certificadas.
Validación y preservación de documentos electrónicos.
Servicios de identidad digital y custodia electrónica.

Con precios muy atractivos y un enfoque en criptoagilidad (para resistir los retos de la computación cuántica hacia las técnicas criptográficas tradicionales), EADTrust transforma el complejo marco de cumplimiento en una ventaja competitiva, ayudando a las entidades financieras a navegar el ecosistema digital con confianza.

Para más información, contacta con el equipo de EADTrust llamando al 917160555 (o al 902 365 612) y prepárate para el futuro digital

Hoy se han publicado 4 nuevos actos de ejecución de desarrollo del Reglamento #EIDAS2

Deja un comentario

La Comisión Europea ha publicado cuatro nuevos reglamentos de ejecución en el Diario Oficial de la Unión Europea del 17 de diciembre. Ya son varias rondas de actos de ejecución, que comenzaron en diciembre de 2024, y se alcanza la publicación de 26 actos de ejecución.

Los reglamentos de ejecución publicados hoy son los siguientes:

📌 Qarchiv: servicios de archivo electrónico cualificados. REGLAMENTO DE EJECUCIÓN (UE) 2025/2532 DE LA COMISIÓN de 16 de diciembre de 2025 por el que se establecen disposiciones de aplicación del Reglamento (UE) n.o 910/2014 del Parlamento Europeo y del Consejo en lo que respecta a las normas y especificaciones de referencia para los servicios cualificados de archivo electrónico
📌 QELedgers: libros de contabilidad electrónicos cualificados. REGLAMENTO DE EJECUCIÓN (UE) 2025/2531 DE LA COMISIÓN de 16 de diciembre de 2025 por el que se establecen disposiciones de aplicación del Reglamento (UE) n.o 910/2014 del Parlamento Europeo y del Consejo en lo que respecta a las normas y especificaciones de referencia para los libros mayores electrónicos cualificados
📌 QWACs: certificados cualificados para la autenticación de sitios web. REGLAMENTO DE EJECUCIÓN (UE) 2025/2527 DE LA COMISIÓN de 16 de diciembre de 2025 por el que se establecen disposiciones de aplicación del Reglamento (UE) n.^o 910/2014 del Parlamento Europeo y del Consejo en lo que respecta a las normas de referencia para los certificados cualificados de autenticación de sitios web
📌 QTSPs: normas de cumplimiento y seguridad: proveedores de servicios de confianza cualificados. REGLAMENTO DE EJECUCIÓN (UE) 2025/2530 DE LA COMISIÓN
de 16 de diciembre de 2025 por el que se establecen disposiciones de aplicación del Reglamento (UE) 910/2014 del Parlamento Europeo y del Consejo en lo que respecta a los requisitos para los prestadores cualificados de servicios de confianza que prestan servicios de confianza cualificados.

Esta es la lista de los actos de ejecución anteriores.

Y el mapa que actualiza permanentement Joerg Lenz:

1994-1999: los pioneros

1999-2006: de la Directiva a la Ley 59/2003

2006-2014: la administración electrónica toma el relevo

2014-2016: el Reglamento eIDAS

2020: la Ley 6/2020 cierra el ciclo de 1999

2024: eIDAS 2 y la Cartera de Identidad Digital Europea

2025-2026: el DNI en el móvil, la cartera española y la transición postcuántica

Lo que enseñan 32 años

Cronología

Fuentes

Qué es una clave privada y una clave pública

Qué es una autoridad de certificación raíz y una intermedia

Entropía y generación de claves

HSM y ceremonia de claves

Qué ha pasado

La causa: una curva excelente con una clave ridícula

No es la primera vez

Generar en el HSM, sí; pero poder importar claves también

Qué revisar en una ceremonia de claves

Conclusión

Fuentes

Artículos relacionados

Un foro con casi dos décadas de historia

Un programa en seis módulos

Ponentes que merece la pena escuchar

Por qué Poznań, y por qué ahora

Enlaces

1. Legislación

2. Terminología

3. Organismos

4. URLs y recursos

1. El terreno de juego: dos grandes familias de obligaciones

2. El SII: el pionero del reporte en tiempo real

¿Qué se envía?

¿Quién está obligado?

La llave técnica: certificado de empresa (sello)

3. Veri-factu: integridad de secuencia en el registro en origen

La idea central

¿Quién está obligado?

Fecha de entrada en vigor

4. La factura electrónica B2B: la Ley Crea y Crece

¿Qué exige?

¿Qué no es la factura electrónica?

La firma y el sello en la factura electrónica

5. Los regímenes forales: Navarra y el País Vasco

¿Los regímenes forales tienen su propio SII y Veri-factu?

TicketBAI y BATUZ: el adelanto vasco

Implicaciones prácticas para empresas que operan en ambos territorios

6. Firma electrónica y sello electrónico: la distinción que la normativa tributaria no siempre aclara

Lo que dice la normativa tributaria

Lo que dice el Reglamento eIDAS (910/2014/UE)

¿Por qué la normativa tributaria no lo deja claro?

7. El sello electrónico cualificado remoto: la pieza que lo une todo

Ventajas del sello remoto cualificado para la facturación

8. Cuadro comparativo final

9. Contacte con EADTrus si necesita un sello electrónico remoto cualificado

Conclusión

Cambios a la norma ETSI TS 119 461