Archivo de la categoría: Cartera de empresa

Desde Poznań (Polonia): agenda y ponentes del Trusted Economy Forum 2026

Escribo desde Poznań, donde hoy, 14 de octubre, arranca el Trusted Economy Forum 2026. Como adelanté en Rumbo a Poznań: Trusted Economy Forum 2026, este foro se ha consolidado como una de las citas centroeuropeas de referencia sobre identidad digital y servicios de confianza. En aquel artículo hice una presentación general; en este quiero repasar con más detalle la agenda de los dos días y quiénes intervienen en cada sesión.

El lema de esta edición es «Connected by Trust». El foro se celebra en el edificio Concordia Design (calle Zwierzyniecka 3), a pocos minutos andando de la estación de tren, y lo organiza Obserwatorium.biz. Las sesiones son en inglés con traducción simultánea al polaco. La edición de 2025 reunió a más de 300 participantes de 15 países.

El programa se articula en seis módulos, tres por día, que combinan presentaciones breves (de unos 15 minutos) con muchos debates. Lo resumo a continuación.

Día 1 — miércoles 14 de octubre

Módulo 1: On the way to European Digital Identity Wallets

El primer bloque plantea una pregunta directa: ¿estamos preparados para la Cartera de Identidad Digital Europea?

Giorgia Dragoni (Observatorio de Identidad Digital del Politecnico di Milano) abre con la keynote «EUDI wallets landscape and its national strategies», un panorama de las estrategias nacionales de cartera.
Joanna Koczorowska (COI, el Centro de Tecnologías de la Información polaco, que es además patrocinador honorífico estratégico del foro) presenta «Ready for Polish EUDI Wallet!», sobre el estado de la cartera polaca.
Michał Tabor y Piotr Sterczała (Obserwatorium.biz) presentan el informe «Making the EUDI Wallet a Success».
Debate «Europe’s Digital Identity Ecosystem: from trust infrastructure to global reference model – is this the realistic scenario?», moderado por Andras A. Barsi (Aruba), con Katarzyna Zajkowska (Ministerio de Asuntos Digitales de Polonia), Katarzyna Seroczyńska (COI), Lal Chandran (iGrant.io), Jan Szajda (IDENTT) y Edgars Stafeckis (Trustlynx).
Elżbieta Andrukiewicz (Instituto Nacional de Telecomunicaciones de Polonia) explica la certificación de la cartera en «EUDI Wallet Certification in Practice: The Polish Experience and Future Perspectives».
Marco Mangiulli (Aruba) cierra el módulo con «Beyond the Wallet: Building Europe’s Next Trust Infrastructure».

Módulo 2: Trust trends

Nuevos servicios, mercados y tecnologías. Es el módulo más cercano a los temas que trato habitualmente en este blog.

Doble sesión sobre criptografía postcuántica: Martin Stiefel (Allaris) pregunta «Is your organisation ready for the post-quantum world?» y Piotr Rydlichowski (Centro de Supercomputación y Redes de Poznań, PCSS) plantea «Post-quantum – buzzword or real threat?».
Debate «Electronic Attestations of Attributes: The Missing Link in Digital Business Transformation?» sobre las declaraciones electrónicas de atributos, moderado por Marcin Wolski (Obserwatorium.biz), con Viktor Varga (Microsec) y Sebastian Elfors (IDnow Trust Services).
Aleksandra Nowak (IDENTT) aborda la integración de las partes usuarias en «EUDI Wallet relying party integration».
Jakub Kwiatkowski (PCSS) habla de confianza y procedencia en la inteligencia artificial: «Trust and Provenance in AI».
Debate «Business Wallet – what is it all about?», moderado por Arno Fiedler (Nimbus; vicepresidente de ETSI TC ESI), con Marcin Szulga (Asseco Data Systems), Szymon Mamrot (coordinador nacional de la Pasarela Digital Única, Ministerio de Desarrollo Económico y Tecnología) e Iñigo Barreira (Sectigo; también vicepresidente de ETSI TC ESI).
Grzegorz Sokołowski (GS1 Polonia) cierra con «Digital Product Passport and the Future of Trusted Data Exchange».

Tras la comida hay un interludio muy apropiado para la ciudad: Oliwier Sakowski, del Centro del Cifrado Enigma de Poznań, presenta «From Enigma to Modern Cryptography». Conviene recordar que fueron tres matemáticos formados en la Universidad de Poznań —Marian Rejewski, Jerzy Różycki y Henryk Zygalski— quienes rompieron por primera vez la criptografía de la máqiina Enigma, utilizada por Alemania en la segunda guerra mundial, a comienzos de los años treinta. En julio de 1939, semanas antes de la invasión alemana, compartieron sus resultados, sus réplicas de la máquina y el diseño de su bomba criptológica con los servicios de inteligencia británico y francés. Sobre esa base trabajó Alan Turing en Bletchley Park: su Bombe británica perfeccionó la idea polaca y permitió descifrar de forma sistemática las comunicaciones alemanas durante la guerra. Turing, que en 1936 ya había sentado las bases teóricas de la computación con su «máquina universal», es hoy una figura de referencia de la informática, y la historia de Enigma ilustra bien algo que seguimos aplicando en criptografía: la seguridad de un sistema no debe depender del secreto del algoritmo, sino de la solidez de las claves y de su correcta gestión.

Módulo 3: Digital market players

Jarek Sygitowicz (Authologic): «Making cross border verifiable credentials work».
Karen Mkoyan (imID) presenta el caso de Armenia: «Digital Trust Beyond the EU: Armenia’s eIDAS-Aligned Digital Trust Ecosystem».
Debate «Building a successful partnership between supervisory bodies and national QTSPs», moderado por Jon Ølnes (Signicat), con Michał Kowalewski-Li (Ministerio de Asuntos Digitales de Polonia), Artur Miękina (Asseco Data Systems), Andrea Röck (ANSSI) y Andrea Sassetti (Aruba PEC; presidente de AssoCertificatori Italia).

La jornada termina con una discusión abierta y, por la noche, con la velada de networking «Connected by Trust» en el propio Concordia Design.

Día 2 — jueves 15 de octubre

Módulo 1: Trust in action!

Implantación real de servicios de confianza, carteras y verificación de identidad en empresas y administraciones.

Andreas Freitag (Procivis): «Implement EUDI Wallet (Fast) – What are the options?».
Debate «The World of Payment, Identity and Super Wallets: One Ecosystem or Competing Digital Universes?», moderado por Beata Galas, con Jarek Sygitowicz (Authologic), Kevin Meijer (Betaalvereniging Nederland; responsable de pagos de consumo en el consorcio WE BUILD) y Tomasz Chomicki (Samsung Electronics Polonia).
Debate «Building the EUDI Wallet Ecosystem Together: Why Market Collaboration Is Essential?», moderado por Piotr Sterczała, con Piotr Brewiński (FinTech Poland), Maciej Mironiuk (Visa), Anna Koźlik (COI) y Jakub Banaś (BNP Paribas Bank Polska).
Karol Ciechoński (Ayuntamiento de Lublin) aporta la visión de la administración local: «Local administration view on new digital ecosystem».

Módulo 2: Customer in the centre!

Experiencia de usuario y modelos de negocio.

Bart Jurkowski (I’MPRO): «Ready for the Unexpected – Acting Effectively in a World of Change and Uncertainty».
Gran debate «Sector Solutions or Shared Digital Infrastructure?», moderado por Miłosz Brakoniecki (Obserwatorium.biz), con Grzegorz Wójcik (Autenti), Edgars Stafeckis (Trustlynx), Anna Sienkiewicz (ING Leasing), Andrzej Ochocki (Deutsche Telekom), Bartosz Witkowski (Signius) y Tomasz Litarowicz (Asseco Data Systems).
Adrian Doerk (Lissi) sobre la experiencia de usuario de la cartera y los retos para las partes usuarias.
Arno Fiedler (Nimbus) presenta «Proving What’s Real: C2PA, Content Credentials and the Future of Digital Trust», sobre la autenticidad del contenido digital.
Debate «What Customers Really Need», moderado por Remigiusz Lewandowski, con Piotr Andruszkiewicz (eIDAS Easy), Andrzej Zduńczyk (BIK), Krzysztof Król (UODO, la autoridad polaca de protección de datos) y Marek Pieróg (Siepomaga.pl).
Tomasz Nogol (MONET+): «Digital Identity in Insurance 2027: Opportunities You Can’t Afford to Miss».

Después de la comida, Marcin Bielicki (SENSE) habla de «habilidades blandas» para equipos de innovación, y le sigue el debate «Zero Trust Meets Digital Trust: Rethinking the Security of Electronic Transactions», moderado por Krzysztof Bogacki, con Agata Kolorz-Lentini (Autenti), Piotr Rutkowski (NASK; vicepresidente de la Asamblea General de EUROPEUM-EDIC) y Robert Poznański (Asseco Data Systems).

Módulo 3: Global Trust Services

Interoperabilidad y expansión internacional de los servicios de confianza.

Guillaume Forget (Cloud Signature Consortium; Cryptomathic): «CSC as interoperability pillar in the Trusted Digital Economy», sobre el uso de la firma electrónica más allá de los contratos (cumplimiento, prevención del fraude, facturación electrónica y cadenas de suministro).
Charla con Xavier Juredieu (EUROPEUM-EDIC; consorcio WE BUILD) sobre la hoja de ruta de EUROPEUM-EDIC y EBSI, moderada por Miłosz Brakoniecki.
Alessia Soccio (Entaksi Solutions): «Trust services as a factor of European Sovereignty – the e-Archive Case».
Michał Tabor (Obserwatorium.biz): «How to build PanEuropean eDelivery».
Debate final «How to build a bridge of trust and digital identity between Asia, America and Europe?», moderado por Guillaume Forget, con Andreea Prian (IDAKTO), Svetlanna Maleryan (imID), Łukasz Jaromin (Raidiam), Igor Marcolongo (InfoCert, grupo Tinexta) y Melany Pașca (Edge Institute, Rumanía).

La clausura está prevista para las 16:30 del jueves.

Lo que más me interesa

De un programa tan denso, hay varias sesiones que seguiré con especial atención:

El debate sobre declaraciones electrónicas de atributos. Es probablemente el servicio de confianza nuevo de eIDAS 2 con más recorrido comercial, y la pregunta del título —¿el eslabón perdido de la transformación digital de las empresas?— es exactamente la que nos hacemos los prestadores cualificados.
La relación entre organismos de supervisión y prestadores cualificados. Tener en la misma mesa al ministerio polaco, a la ANSSI francesa y a prestadores de Polonia e Italia permite comparar modelos de supervisión, algo muy útil para quienes operamos bajo la supervisión de la SEDIA en España.
La Business Wallet, con dos vicepresidentes de ETSI TC ESI en el debate, en pleno proceso de definición de la cartera empresarial europea.
La criptografía postcuántica, que aquí se presenta desde dos ángulos: la preparación de las organizaciones y el análisis de la amenaza real.
Los pilotos a gran escala, con la presencia de WE BUILD en el debate sobre pagos y en la sesión sobre EUROPEUM-EDIC y EBSI.
El puente entre Asia, América y Europa, con el caso de Armenia como ejemplo de ecosistema alineado con eIDAS fuera de la Unión, un tema que me interesa por el trabajo que hacemos en Latinoamérica.

Organización y patrocinio

El foro cuenta con el patrocinio honorífico estratégico del COI y con Asseco Data Systems como socio Gold. Entre los socios Silver están Siepomaga, IDENTT, Authologic, Signius, Aruba, Allaris y Autenti, y entre los Bronze, Crédit Agricole (EFL), QSCert, Lissi, Procivis, IDnow, Trustlynx y Monet+. Entre los patrocinadores honoríficos figuran ETSI, el Ministerio de Digitalización y el Ministerio de Desarrollo y Tecnología polacos, la UODO, NASK, el comité polaco de normalización (PKN), la Universidad Tecnológica de Poznań y el PCSS.

EADTrust y la Cartera de Identidad Digital Europea

Mi presencia en Poznań forma parte del compromiso de EADTrust con el despliegue de la Cartera de Identidad Digital Europea. EADTrust es uno de los prestadores cualificados de servicios de confianza más activos de España en el impulso de la cartera, como pueden comprobar los lectores habituales de este blog.

Ese compromiso también se traduce en eventos en España. El pasado 28 de abril coorganizamos con el Observatorio Legaltech Garrigues-ICADE la jornada «La Cartera de Identidad Digital de la UE, su implementación y transformación de la gestión de la identidad», que puede verse en vídeo en la web de la Universidad Pontificia Comillas.

Ahora estamos preparando con G-Digital, de Garrigues, dos nuevas citas: un evento ligero en diciembre de 2026 y otro más amplio, previsiblemente en abril de 2027. Buena parte de lo que estoy escuchando estos días en Poznań, y de los contactos que estoy haciendo, servirá para preparar esos encuentros. Daré más detalles aquí en cuanto estén cerrados.

Seguiré informando

En los próximos días compartiré aquí mis notas y conclusiones de las sesiones. Si también estás en Poznań y quieres que hablemos, búscame en los descansos o escríbeme a julian.inza@eadtrust.com.

Enlaces

Cartera de Identidad Digital Europea: nuevo borrador de Real Decreto, a información pública (y con prisas)

3 respuestas

El Ministerio para la Transformación Digital y de la Función Pública ha abierto el trámite de audiencia e información pública sobre el proyecto de real decreto por el que se regula el ecosistema de cartera europea de identidad digital en España de acuerdo con el marco europeo de identidad digital. Es la norma que debe completar en España el Reglamento eIDAS 2 en lo relativo a la cartera, y llega con muy poco margen: el plazo para enviar observaciones vence el 13 de octubre de 2026 y la cartera debe estar disponible, por mandato europeo, antes del 24 de diciembre de 2026.

He dedicado unos días a leer el borrador (versión V-12, de 29 de septiembre de 2026) y a compararlo con lo que ya han aprobado otros Estados miembros. Resumo aquí lo que regula, lo que echo en falta y cómo lo han resuelto fuera de nuestras fronteras, con la esperanza de animar a más personas y entidades a participar en el trámite.

Qué regula el proyecto

El proyecto es, sobre todo, una norma de designación de autoridades. En trece artículos, tres disposiciones adicionales y tres finales, reparte los papeles que el Reglamento (UE) n.º 910/2014, modificado por el Reglamento (UE) 2024/1183, encomienda a los Estados miembros:

Función	Organismo designado	Artículo
Proveedor de la cartera del Estado	Agencia Estatal de Administración Digital (AEAD)	7
Punto de contacto único	AEAD	2
Organismo de supervisión	Dirección General de Ordenación de los Servicios de Digitalización y de Comunicación Audiovisual (DGOSDCA)	3
Propietario del esquema de certificación y organismo certificador	Centro Criptológico Nacional (CCN)	4 y 9
Acreditación de organismos de evaluación de la conformidad	ENAC	5
Correspondencia transfronteriza de la identidad	AEAD, Agencia Tributaria y Dirección General de la Policía	6
Registro nacional de partes usuarias de las carteras	AEAD	11
Autorización de proveedores de certificados de acceso y de registro	DGOSDCA	12
Catálogo nacional de fuentes auténticas	Dirección General del Dato	13

Las disposiciones adicionales regulan la verificación previa de quienes expidan declaraciones electrónicas cualificadas de atributos y de los organismos públicos que expidan declaraciones electrónicas de atributos desde una fuente auténtica, y la representación de España en el Grupo de Cooperación sobre la Identidad Digital Europea.

Un plazo demasiado corto

El anuncio se publicó el 1 de octubre de 2026 y las observaciones pueden enviarse hasta el 13 oct 2026 a audienciapublica.prdcarteradigital@digital.gob.es. Son siete días hábiles, contando con que el 12 de octubre es festivo: el mínimo que permite la Ley del Gobierno.

La razón está en el propio anuncio. El Consejo de Ministros acordó el 29 de septiembre de 2026 la tramitación urgente del proyecto (art. 27.1.a de la Ley 50/1997), lo que suprime la consulta pública previa y reduce la audiencia a siete días hábiles (art. 27.2.b). La primera ocasión que tiene la sociedad para opinar sobre la norma es también la última, y dura poco más de una semana.

El anuncio añade algunos detalles prácticos. Las aportaciones deben identificar a su autor (nombre o razón social, datos de contacto y, en su caso, representación). Se consideran públicas, salvo las partes que se marquen y justifiquen como confidenciales. Junto al proyecto se publica la Memoria del Análisis de Impacto Normativo. Y llama la atención que el órgano responsable sea la Agencia Estatal de Administración Digital, la misma que el proyecto designa como proveedor de la cartera, punto de contacto único y registrador de partes usuarias.

Llegados a esta fecha, se entiende la urgencia: el Reglamento obliga a proporcionar al menos una cartera antes del 24 de diciembre de 2026, y las partes usuarias privadas obligadas deberán aceptarla antes del 24 de diciembre de 2027. Pero la prisa no debería reducir la participación a un trámite formal. Esta propuesta debería haberse publicado con más antelación, pero aprovechemos el escaso margen.

Mi manía: «cartera de identidad digital europea»

Quienes me leen ya saben que escribo «Cartera de Identidad Digital Europea» y no «cartera europea de identidad digital», que es la traducción oficial del artículo 3.42 del Reglamento. Es una manía, lo reconozco, pero tiene fundamento: lo europeo es la identidad, no la cartera. En inglés, European Digital Identity Wallet, el bloque European Digital Identity califica entero a Wallet.

La propia versión española del Reglamento me da la razón en otros pasajes:

habla del «Grupo de Cooperación sobre la Identidad Digital Europea» (art. 46 sexies);
define la «etiqueta de confianza de la UE para la cartera de identidad digital» (art. 3.50);
y usa «marco europeo de identidad digital», donde el adjetivo sí corresponde al marco.

No me hago ilusiones: el francés, el italiano o el alemán también ponen el adjetivo «europeo» junto a la cartera. Por eso no propongo cambiar la definición por las bravas, sino una cláusula de equivalencia en el real decreto y una corrección de la versión española del Reglamento. Fuera de esta excepción, defiendo lo contrario: que el real decreto respete la terminología oficial, cosa que hoy no siempre hace. Usa «autenticación fuerte» en lugar de «autenticación reforzada de usuario», habla de carteras «autorizadas» cuando el Reglamento dice «proporcionadas» y llama de cuatro maneras distintas al organismo de supervisión.

Lo que echo en falta y lo que me choca

Un real decreto que solo designa autoridades se queda corto. Estas son las carencias que me parecen más relevantes:

Supervisor y supervisado bajo el mismo techo. El artículo 46 bis exige que el organismo de supervisión actúe de forma independiente, pero DGOSDCA y AEAD pertenecen al mismo Ministerio.
Un punto de contacto único que no es único. El artículo 46 quater pide uno solo para servicios de confianza, carteras y sistemas de identificación notificados; el proyecto lo designa solo para las carteras y no coincide con el supervisor de los Prestadores Cualificados de Servicios de Confianza.
Nada sobre la verificación de atributos frente a fuentes auténticas. El artículo 45 sexies obliga a que los prestadores cualificados puedan contrastar domicilio, edad, titulaciones, poderes o datos societarios con la fuente correspondiente. Sin ese mecanismo no habrá mercado de declaraciones electrónicas cualificadas de atributos.
Personas jurídicas y representación, ausentes. El Reglamento incluye a las personas jurídicas y a quienes actúan en nombre de otros; el proyecto solo contempla titulares de DNI o NIE.
Solo la cartera del Estado. No hay procedimiento para reconocer carteras proporcionadas por mandato o de forma independiente, como permite el artículo 5 bis.2. No se indica la posibilidad de certificar las Carteras en esquemas de certificación de otros países.
El número de DNI o NIE como atributo obligatorio, que facilita vincular la actividad del usuario entre partes usuarias. La definición del PID indica que este número es opcional y probablemente no se incluirá en relaciones con ciudadanos de otros países.
Un requisito que el Reglamento no exige: condicionar la cualificación de los prestadores de declaraciones cualificadas a la conformidad con el esquema de certificación de las carteras.
Barreras a prestadores de otros Estados miembros para expedir certificados de acceso de parte usuaria.

Qué han hecho otros Estados miembros

Varios países ya han aprobado o tramitan su normativa, casi siempre con rango de ley y con bastante más contenido que la mera designación de autoridades. Doy el título en español y en la lengua original, y un resumen de lo principal. Los artículos citados proceden de los textos consultados y conviene contrastarlos con la publicación oficial.

Alemania — proyecto de ley en el Bundestag

Proyecto de Ley de aplicación de las disposiciones de la Unión sobre la Cartera de Identidad Digital Europea y de modificación de otras disposiciones (DIdG) — Entwurf eines Gesetzes zur Durchführung der unionsrechtlichen Vorschriften über die Europäische Brieftasche für die Digitale Identität sowie zur Änderung anderer Rechtsvorschriften, BT-Drs. 21/7408, de 29 de julio de 2026. Audiencia pública en el Bundestag el 6 de octubre de 2026.

Tres modelos de provisión a elección del Ministerio Federal de Digitalización: directa, por contrato público o reconociendo carteras privadas.
La Agencia Federal de Redes (BNetzA) es organismo de supervisión y punto de contacto único; la Oficina Federal de Administración (BVA), registrador de partes usuarias; la Oficina Federal de Seguridad de la Información (BSI), responsable de la certificación y de las violaciones de seguridad.
Datos de identificación de personas jurídicas a partir de los registros mercantil, de cooperativas, de fundaciones y de asociaciones; la representación se acredita con declaraciones electrónicas de atributos.
El emisor de los datos de identificación no puede ser el proveedor de la cartera, y este debe ser técnicamente incapaz de conocer su contenido.
En 24 meses, las autoridades federales deberán expedir sus documentos como declaraciones electrónicas de atributos, con valor equivalente a la forma escrita.
Multas de hasta 5 millones de euros o el 1 % del volumen de negocio (Ley de servicios de confianza).

Finlandia — en vigor desde el 1 de octubre de 2026

Proyecto de ley del Gobierno sobre la legislación complementaria del Reglamento de la UE relativo a la identificación electrónica transfronteriza, los servicios de confianza y la identidad digital europea — Hallituksen esitys eduskunnalle rajat ylittävää sähköistä tunnistamista, luottamuspalveluita ja eurooppalaista digitaalista identiteettiä koskevaa EU:n asetusta täydentäväksi lainsäädännöksi, HE 17/2026 vp. Incluye una nueva Laki digitaalisesta henkilöllisyystodistuksesta (Ley del documento de identidad digital).

Proveedor: la Agencia de Servicios Digitales y de Datos de Población (DVV). Supervisor y registrador: la Agencia de Transportes y Comunicaciones (Traficom), un organismo distinto.
Se admiten carteras privadas que cumplan los requisitos.
La Oficina de Patentes y Registros expide los datos de identificación de las personas jurídicas desde el Registro Mercantil.
Primera credencial: un certificado de identidad digital derivado del pasaporte o del documento de identidad.
Cartera gratuita y voluntaria; firma electrónica cualificada gratuita para uso no profesional.

Dinamarca — en vigor desde el 1 de abril de 2026

Ley sobre la cartera nacional de identidad digital — Lov om den nationale digitale identitetstegnebog, LOV nr. 301 af 24/02/2026.

La Agencia de Digitalización gestiona la cartera, el servicio de expedición de credenciales y el registro de partes usuarias.
Las autoridades responsables de fuentes auténticas deben expedir sus credenciales a través de ese servicio común.
Las entidades deben registrarse para recibir credenciales en línea, salvo para la mera verificación de edad; la Agencia puede suspender a quien actúe de forma fraudulenta.
Regula los efectos jurídicos de las credenciales, la responsabilidad e indemnización y el reparto de responsabilidades de tratamiento de datos.

Eslovaquia — en vigor desde el 1 de enero de 2025

Ley n.º 365/2024, de 27 de noviembre de 2024, por la que se modifica y completa la Ley n.º 272/2016 de servicios de confianza para las transacciones electrónicas en el mercado interior — Zákon z 27. novembra 2024, ktorým sa mení a dopĺňa zákon č. 272/2016 Z. z. o dôveryhodných službách pre elektronické transakcie na vnútornom trhu (n.º 365/2024 Z. z.).

El Ministerio del Interior proporciona la cartera y mantiene la lista de partes usuarias.
La Autoridad Nacional de Seguridad (NBÚ) supervisa tanto los servicios de confianza como el marco de la cartera.
Los proveedores de carteras deben ser prestadores cualificados de servicios de confianza o tener contrato con uno.
Multas de hasta 500.000 euros a proveedores de carteras y de hasta 5 millones o el 1 % a prestadores cualificados.

Luxemburgo — proyecto de ley

Proyecto de ley relativa a la implantación de la cartera de identidad digital europea y por la que se aplica el Reglamento (UE) 2024/1183 — Projet de loi relative à la mise en place du portefeuille européen d’identité numérique et portant mise en œuvre du règlement (UE) 2024/1183, n° 8583, presentado el 14 de julio de 2025.

Proveedor: el Centro de Tecnologías de la Información del Estado (CTIE). Supervisor: el Instituto Luxemburgués de Regulación (ILR), regulador independiente.
El registro de partes usuarias es público; para inscribirse se exige, entre otros, un certificado de antecedentes penales.
Los datos de identificación incluyen un número administrativo seudonimizado.
Inspecciones, medidas correctoras y multas de hasta 1 millón de euros; recurso ante el Tribunal administrativo.

Italia — en vigor, en fase de experimentación

Decreto-ley n.º 19, de 2 de marzo de 2024, de disposiciones urgentes para la aplicación del Plan de Recuperación — Decreto-legge 2 marzo 2024, n. 19, «Ulteriori disposizioni urgenti per l’attuazione del Piano nazionale di ripresa e resilienza (PNRR)», que introduce el artículo 64-quater del Código de la Administración Digital, «Sistema di portafoglio digitale italiano – Sistema IT-Wallet». Lo desarrolla el Decreto del Presidente del Consejo de Ministros de 31 de julio de 2026 sobre los organismos nacionales competentes para la identidad digital europea — «Organismi nazionali competenti per l’identità digitale europea».

Cartera pública en la aplicación IO, proporcionada por PagoPA, y carteras privadas acreditadas con requisitos de solvencia y seguros.
La Agencia para la Italia Digital (AgID) es organismo de supervisión, punto de contacto único y registrador; el Instituto Poligráfico (IPZS), proveedor de los datos de identificación; la Agencia Nacional de Ciberseguridad (ACN), propietaria del esquema de certificación.
Ocho declaraciones prioritarias, entre ellas títulos académicos, tarjeta sanitaria, permiso de conducir y tarjeta de discapacidad.

En tramitación o en estudio

Polonia: Projekt ustawy o zmianie ustawy o usługach zaufania oraz identyfikacji elektronicznej oraz niektórych innych ustaw (Proyecto de ley de modificación de la Ley de servicios de confianza e identificación electrónica y de otras leyes, UC122), publicado el 19 de febrero de 2026. Adapta mObywatel, ofrece firma cualificada gratuita para uso no profesional y obliga a las fuentes auténticas a ofrecer verificación a los prestadores cualificados.
Chequia: Návrh zákona, kterým se mění zákon č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce, zákon č. 250/2017 Sb., o elektronické identifikaci, a zákon č. 634/2004 Sb., o správních poplatcích (Proyecto de ley por el que se modifican las leyes de servicios de confianza, de identificación electrónica y de tasas administrativas), aprobado por el Gobierno en marzo de 2026. La cartera la operará un concesionario privado.
Suecia: SOU 2024:45 Kompletterande bestämmelser till EU:s reviderade förordning om elektronisk identifiering (Disposiciones complementarias al Reglamento revisado de la UE sobre identificación electrónica), informe de 2024 que propone separar proveedor (Digg) y supervisor (PTS), admitir carteras privadas y sanciones de hasta 5 millones de euros.

Participar, aunque el tiempo apriete

La comparación deja una conclusión clara: España necesitará, además de este real decreto, una norma con rango de ley que regule aspectos pendientes no cubiertos por el Reglamento EIDAS2: el valor jurídico de las declaraciones electrónicas de atributos y el encaje de la cartera con la Ley 39/2015, uso de Cl@ve, Carpeta Ciudadana, utilización en Lexnet y Citius… Pero lo urgente es mejorar el texto que hoy está en audiencia.

Animo a todas las partes interesadas en los servicios de confianza a leer el proyecto y enviar sus observaciones, hasta el 13 de octubre de 2026, a audienciapublica.prdcarteradigital@digital.gob.es.

Quien quiera comentar conmigo estas ideas y otras que se le ocurran puede escribirme a julian (at) inza.net . También puede contactar con EADTrust en info@eadtrust.com o en el 91 716 05 55.

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

Tras pasar por Ginebra y Tallin, hoy estoy en Sophia Antipolis: siguiendo los avances que se producen en torno a la EUDI Wallet

1 respuesta

A menos de tres meses del 24 de diciembre de 2026, fecha en la que cada Estado miembro debe ofrecer al menos una Cartera Europea de Identidad Digital (EUDI Wallet), septiembre me ha llevado a tres citas clave: Ginebra, Tallin y, esta semana, Sophia Antipolis, en la sede de ETSI.

Ginebra: la visión global

El mes arrancó en Ginebra con la Global Digital Collaboration Conference, del 1 al 3 de septiembre. Es un foro por invitación que coorganizan organismos intergubernamentales, de normalización y de código abierto, entre ellos ETSI, W3C, ISO, la OpenWallet Foundation, la Linux Foundation, el Banco Mundial y el PNUD.

La Cartera europea fue protagonista del tercer día, con sesiones sobre cómo se pasa de las normas exigidas por el Reglamento a la implantación real y sobre la infraestructura de confianza de la EUDI Wallet. El segundo día se habló de interconexión entre ecosistemas de identidad, de espacios de confianza globales y de cómo poner en práctica el Reglamento de Ciberresiliencia.

La conclusión de Ginebra: Europa marca el paso, pero la interoperabilidad con otras regiones exige que las listas de confianza y los formatos de credencial se entiendan fuera de la UE.

Estuve en Ginebra con Albi Rodríguez, de Garrigues. No teníamos ponencia, pero seguimos de cerca las intervenciones y aprovechamos para hablar con ponentes y asistentes. El objetivo: organizar en España, a primeros de diciembre, un evento que vaya más allá del que celebramos el 28 de abril en el Observatorio Legaltech Garrigues-ICADE, La Cartera de Identidad Digital de la Unión Europea: implementación y transformación de la gestión de la identidad. Aquella sesión en Comillas repasó el despliegue de la Cartera española, los pilotos europeos y las declaraciones electrónicas de atributos aplicadas a los poderes de representación.

Tallin: una semana de firma, confianza y certificación

Del 14 al 18 de septiembre, Tallin concentró en una sola semana buena parte del ecosistema europeo de la confianza digital. Lo conté con detalle en Una semana en Tallinn; este es el resumen:

Lunes 14: ETSI ESI CA Open Session y, por la noche, el 10.º aniversario del Cloud Signature Consortium.
Martes 15: 12.ª edición del Trust Services and eID Forum de ENISA, en el Kultuurikatel.
Miércoles 16: 18.ª edición del CA Day, organizado por D-TRUST y TÜV NORD Cert.
Jueves 17 y viernes 18: reunión del grupo de expertos ad hoc (AHWG) de ENISA sobre certificación de la Cartera.

La sesión abierta de ETSI ESI y la qDLT

El 14 de septiembre acudí a la sesión abierta de ETSI ESI como asistente y terminé como panelista. La intervención estaba prevista para Steffen Schwalm, que no pudo viajar, y me pidieron que hablara de cómo evoluciona la normalización de las tecnologías de registro distribuido (DLT, o RJT como prefiero llamarlas). Sustituir a Steffen Schwalm no era tarea fácil: pocos han hecho tanto como él por impulsar la normalización asociada a EIDAS y EIDAS2 y las tecnologías de registro distribuido en particular. Ha participado activamente en la normalización nacional e internacional (DIN, ISO, BSI, etc.) en este campo durante muchos años y representa a Alemania en ISO para el desarrollo de un estándar global en gestión de registros y blockchain.

Defendí que los libros mayores electrónicos cualificados (qDLT) son una evolución coherente de la infraestructura de confianza europea: enlazan la conservación cualificada de firmas y sellos, el archivo electrónico y la ordenación cronológica de registros. Lo desarrollé después en De la conservación cualificada de firmas y sellos a los servicios cualificados de archivo con orden cronológico (qDLT).

El foro de ENISA y el CA Day

El foro y el CA Day reunieron a supervisores, prestadores cualificados, organismos de evaluación de la conformidad e instituciones europeas y nacionales. El eje fue el estado de implantación de la Cartera en cada Estado miembro, junto con la futura Cartera Europea de Empresa, el Reglamento de Ciberresiliencia, la normalización y la criptografía postcuántica.

El grupo de expertos de certificación de carteras

La semana terminó con trabajo técnico, no con un congreso abierto. Como miembro del AHWG de ENISA, participé el 17 y 18 en la reunión sobre el esquema candidato de certificación de ciberseguridad de las carteras y los requisitos de seguridad de los prestadores de servicios relacionados. Es el trabajo que después se traduce en normas europeas y en cómo se evaluarán las carteras, y enlaza directamente con la sesión 13 de Sophia Antipolis, donde Eric Vetillard (ENISA) presenta el marco europeo de certificación.

Sophia Antipolis: las normas que sostienen la Cartera

Del 29 de septiembre al 1 de octubre, en el «ETSI/CEN workshop on EU Digital Framework centring on the EU Identity Wallet» ETSI y CEN repasan en Sophia Antipolis, junto a la Comisión Europea y ENISA, el estado de la normalización que da soporte a la Cartera. Abre Ultan Mulligan (ETSI) y, en tres días y quince sesiones, se recorre casi todo el ecosistema:

Planes de normalización de la DG CONNECT, CEN TC 224, ETSI TC ESI y ENISA.
Pilotos y carteras nacionales: WE BUILD, APTITUDE y las carteras francesa y polaca.
Declaraciones electrónicas de atributos: protocolos (OpenID4VC, ISO mdoc, perfiles de ETSI), reglamentos de esquema (rulebooks) y la identidad de GLEIF como declaración.
Privacidad: control de acceso, RGPD, pruebas de conocimiento cero y verificación de edad.
Onboarding e identificación remota: ataques de inyección biométrica, requisitos europeos para productos biométricos y la visión de Dinamarca.
Confianza: registro y certificados de acceso de partes usuarias, listas de confianza y su internacionalización, y modelos de confianza alternativos.
Firma, pruebas y certificación: firma remota desde la Cartera, planes de prueba de la Comisión, OpenID, ISO y ETSI, y el marco europeo de certificación de ciberseguridad.
Servicios financieros y Cartera de Empresa: euro digital, casos de pago de la SEPA, banca abierta y el impacto del futuro Reglamento sobre la Business Wallet en las normas de ETSI y CEN, incluidos los servicios de entrega electrónica certificada.

Es, en la práctica, el mapa de lo que falta por cerrar antes y después del 24 de diciembre.

WE BUILD y APTITUDE: los pilotos a gran escala

Los dos pilotos lanzados en septiembre y octubre de 2025 son el banco de pruebas donde las normas se encuentran con casos de uso reales. En Sophia Antipolis los presentan Laurent Bailly (Visa) por WE BUILD y Philippe Nieto (Ministerio del Interior francés) por APTITUDE.

Piloto	Coordinación	Participantes	Enfoque
WE BUILD	Ministerio de Asuntos Económicos y KVK (Países Bajos), Bolagsverket (Suecia)	Casi 200 entidades de los 27 Estados miembros; unos 25 M€ en 24 meses	Empresas (B2B, B2G, B2C): KYC, representación legal, poderes de firma, titularidad real; 13 casos de uso
APTITUDE	Francia (ANTS / France Titres)	Más de 140 organizaciones de 13 países	Credenciales de viaje, permiso de circulación móvil, billetes y check-in, pagos con autenticación reforzada

WE BUILD aporta además su propio reglamento de esquema, que presenta Esther Makaay (Signicat). Entre sus participantes hay unos 30 prestadores cualificados de servicios de confianza, lo que confirma que las declaraciones cualificadas de atributos y la firma son piezas centrales del modelo.

Los países ante el 24 de diciembre

El Reglamento (UE) 2024/1183 obliga a cada Estado miembro a ofrecer al menos una cartera certificada antes del 24 de diciembre de 2026. Según un análisis reciente de Brussels Signal, la mayoría llegará tarde:

Italia es el caso más avanzado, con cerca de 8 millones de usuarios mensuales.
Alemania prevé el lanzamiento el 2 de enero de 2027, nueve días después del plazo.
Países Bajos ha retrasado el despliegue a finales de 2027.
Bulgaria aún redacta la ley nacional necesaria para emitir carteras.

En Sophia Antipolis toman la palabra dos implantaciones nacionales: la francesa (Philippe Nieto) y la polaca (Joanna Koczorowska, Centro Central de Tecnologías de la Información). También se presentan el registro alemán de partes usuarias (Mirko Molik, SPRIND) y la visión danesa sobre identificación remota (Simon Holmgaard).

Después del plazo llega la presión de la demanda: la aceptación obligatoria por bancos y otras partes usuarias privadas se escalona durante 2027.

La agenda y sus protagonistas

Estos son los ponentes y moderadores del encuentro, sesión a sesión.

Día	Sesión	Moderación	Ponencias y ponentes
29 sept, 13:00	Bienvenida	—	Ultan Mulligan (ETSI)
29 sept	1. Planes de normalización	Franziska Granc (Nimbus)	DG CONNECT: Paolo De Rosa y Stavros Kounis · CEN: Aylin Kip (Secretaría CEN TC 224) y Alban Feraud (presidente CEN TC 224) · ETSI: Andrea Röck (vicepresidenta ETSI TC ESI) · ENISA: Philippe Magnabosco
29 sept	2. Implantación de la Cartera y pilotos	Franziska Granc (Nimbus)	WE BUILD: Laurent Bailly (Visa) · APTITUDE y cartera francesa: Philippe Nieto (Ministerio del Interior de Francia) · Cartera polaca: Joanna Koczorowska (Centro Central de TI de Polonia)
30 sept	3. Control de acceso y RGPD	Andreea Prian (IDAKTO)	Control de acceso a los activos de la Cartera (CEN): Jan Lindquist (LinalTec) · Política de divulgación integrada (ETSI): Michal Tabor (Obserwatorium.biz) · Funciones de apoyo al RGPD: Konrad Lanz (GReev)
30 sept	4. Declaraciones electrónicas de atributos: protocolos	Mirko Molik (SPRIND)	OpenID4VC: Joseph Heenan (OpenID Foundation) · ISO mdoc: ponente por confirmar · Perfiles EAA de ETSI: Juan Carlos Cruellas (UPC)
30 sept	5. Pruebas de conocimiento cero y declaraciones de la unidad de cartera	Jean-Emmanuel Perez Hernandez (Nowina)	ZKP aplicado a la Cartera: Peter Altmann (DIGG) · WUA: Sebastian Elfors (IDnow) · Política de verificación de edad: Paolo De Rosa (DG CONNECT) · Requisitos técnicos de verificación de edad: Paloma Llaneza (Certeidas, ETSI STF 681)
30 sept	6. Declaraciones de atributos: general y reglamento de esquema	Wim Coulier (itsme)	Interfaz del reglamento de esquema: Viktor Varga (Microsec) · Reglamento de WE BUILD: Esther Makaay (Signicat) · Identidad GLEIF como declaración: Christoph Schneider (GLEIF)
30 sept	7. Verificación remota de la identidad	Andrea Röck (SGDSN)	Verificación de identidad: Jon Ølnes (Signicat) · Ataques de inyección biométrica: Chris Allgrove (Ingenium Biometric Laboratories) · Requisitos europeos para productos biométricos: Raúl Sánchez-Reillo (Universidad Carlos III de Madrid) · Visión de Dinamarca: Simon Holmgaard (DGIST) · Laboratorio de pruebas: Kevin Carta (Cabinet Louis Reynaud)
30 sept	8. Onboarding de PID y declaraciones de atributos	Andrea Röck (SGDSN)	Onboarding de PID (CEN): Alban Feraud (IN Smart Identity) · Política de emisión de declaraciones (ETSI): Paloma Llaneza (Certeidas) · Identidad en el onboarding (ENISA): Eric Vetillard
30 sept	9. Registro y certificados de partes usuarias	Franziska Granc (Nimbus)	Certificados de acceso: Iñigo Barreira (Sectigo) · Registro y certificados: Michal Tabor (Obserwatorium.biz) · Registro alemán: Mirko Molik (SPRIND)
30 sept	10. Modelos de confianza	Iñigo Barreira	Modelos alternativos: Steffen Schwalm (CEN TC 19) · Listas de confianza eIDAS: Jean-Emmanuel Perez Hernandez (Nowina) · Certificados cualificados para la emisión pública de declaraciones: Viktor Varga (Microsec) · Internacionalización de las listas de confianza: Hiroshi Nakatake (GLEIF Japón)
1 oct	11. La firma y la Cartera	Michal Tabor (Obserwatorium.biz)	Requisitos de firma remota: Andrea Röck (SGDSN) · Protocolos de firma remota: Luigi Rizzo (InfoCert) · Sistemas fiables de firma en servidor: Jan Kjærsgaard (INGROUP) · Arquitectura y protocolos del Cloud Signature Consortium: Thomas Pedersen (Cryptomathic)
1 oct	12. Pruebas de la Cartera	Andrea Röck (SGDSN)	Planes de prueba de la Comisión: Oliver Terbu (CE) · Pruebas ISO mdoc: Kenichi Nakamura (Panasonic) · Pruebas OpenID: Joseph Heenan (OpenID Foundation) · Pruebas ETSI: Juan Carlos Cruellas (UPC) y Laurent Velez (ETSI)
1 oct	13. Certificación de la Cartera	Raúl Sánchez-Reillo (UC3M)	Marco europeo de certificación: Eric Vetillard (ENISA) · Grupo informal de naciones: Stéfane Mouille (CLR Labs) · Registro de riesgos: Elżbieta Andrukiewicz (CEN) · Aplicación criptográfica segura: Jan Kjærsgaard (INGROUP / CEN) · Dispositivo criptográfico seguro: Annegret Schöffel (BSI / GlobalPlatform) · Pruebas de ciberseguridad de la instancia: Kevin Carta (Cabinet Louis Reynaud / CEN)
1 oct	14. Carteras y servicios financieros	Michal Tabor (Obserwatorium.biz)	Euro digital: Fabien Deboyser (NXP) · Casos de pago de la SEPA para eIDAS: Lorenzo Gaston (Smart Payment Association) · Certificados para banca abierta: Luigi Rizzo (InfoCert)
1 oct	15. Hacia la Cartera Europea de Empresa	Arno Fiedler (vicepresidente ETSI TC ESI)	Planes regulatorios de la Comisión: Paolo De Rosa y Stavros Kounis · Impacto en normas ETSI: Paloma Llaneza (Certeidas) · Impacto en normas CEN: Alban Feraud · ERDS al servicio de la Business Wallet: Juan Carlos Cruellas (UPC)
1 oct, 15:15	Clausura	—	Arno Fiedler (ETSI) · Alban Feraud (CEN) · Paolo De Rosa (CE)

Destaca la presencia española: Paloma Llaneza, Iñigo Barreira, Juan Carlos Cruellas y Raúl Sánchez-Reillo intervienen o moderan en nueve de las quince sesiones.

La apuesta de EADTrust

En EADTrust llevamos años siguiendo de cerca la identidad digital europea, y este mes lo confirma: estar en Ginebra, Tallin y Sophia Antipolis es parte de nuestro compromiso por entender el mercado desde dentro y ayudar a impulsarlo. Como prestador cualificado de servicios de confianza, queremos estar listos para emitir declaraciones cualificadas de atributos, facilitar la firma desde la Cartera y acompañar a las partes usuarias que tendrán que aceptarla en 2027.

Ese seguimiento lo compartimos en usercentric.id, el escaparate de EADTrust sobre la identidad centrada en el usuario. Allí recogemos los avances de la Cartera en España y en Europa: explicaciones sobre su funcionamiento, el marco del Reglamento eIDAS2, qué empresas deberán adaptarse y un directorio de actores del ecosistema.

Y queremos traer esa conversación a España: junto con Garrigues estamos preparando un nuevo encuentro para primeros de diciembre, a las puertas del plazo del 24 de diciembre. Daremos los detalles muy pronto.

Si su organización se está preparando para la Cartera, puede escribirnos a info@eadtrust.com, llamar al 91 716 05 55 o visitar www.eadtrust.eu.

English Summary

Geneva, Tallinn and Sophia Antipolis: a September following the European Digital Identity Wallet.

Less than three months before 24 December, when every Member State must offer at least one certified EUDI Wallet, I have taken part in three key meetings:

Geneva (1-3 Sept). Global Digital Collaboration Conference. Together with Albi Rodríguez of Garrigues, I followed the sessions and talked with speakers and attendees to prepare a new event in Spain in early December, one that will go further than the event we held in April at the Observatorio Legaltech Garrigues-ICADE.
Tallinn (14-18 Sept). I joined the ETSI ESI Open Session as a panellist to talk about the standardisation of qualified electronic ledgers (qDLT), attended ENISA’s Trust Services and eID Forum and the CA Day, and closed the week with ENISA’s expert group on wallet certification.
Sophia Antipolis (29 Sept – 1 Oct). Across fifteen sessions, ETSI and CEN review the standards behind the Wallet: electronic attestations of attributes, zero-knowledge proofs, age verification, the relying party register, remote signing, certification and the upcoming European Business Wallet.

I also look at the WE BUILD and APTITUDE pilots and at how Member States are progressing: Italy is ahead, while most will miss the deadline.

At EADTrust we follow this market closely to help it grow, and we share what we learn on usercentric.id, our showcase of developments in Spain and across Europe.

#EUDIWallet #eIDAS2 #DigitalIdentity #ETSI #CEN #ENISA #TrustServices

¿Qué son las declaraciones electrónicas de atributos? EAA, QEAA y las del sector público Pub-EAA en eIDAS2

Deja un comentario

Una declaración electrónica de atributos (en inglés, electronic attestation of attributes, EAA) es una manifestación firmada en formato electrónico que acredita que un determinado atributo es cierto respecto de una persona física o jurídica —su edad, su titulación, su condición de administrador de una sociedad, la posesión de un permiso o licencia— sin necesidad de identificar plenamente a su titular. Es decir, no responde a «¿quién eres?», sino a «¿es cierto este dato sobre ti?». Es una de las piezas centrales que incorpora el Reglamento (UE) 2024/1183 (eIDAS 2) al modificar el Reglamento (UE) n.º 910/2014, y el complemento natural de la Cartera Europea de Identidad Digital (EUDI Wallet): la cartera guarda tu identificación de base (los Person Identification Data, PID) y, sobre ella, va sumando declaraciones de atributos emitidas por terceros de confianza.

Conviene fijar el término desde el principio. La traducción oficial del Reglamento al español habla de «declaraciones (electrónicas de atributos)», no de «atestaciones». Aunque «atestación» circula mucho por calco del inglés attestation, el término normativo en castellano es declaración, y es el que conviene usar para no introducir ambigüedad. También se ha empleado en español el término «Testimonio».

¿Cómo se distingue de la identificación electrónica?

La identificación electrónica y los medios de identidad (los PID que emite el Estado miembro o el proveedor de la cartera) sirven para probar quién eres con un determinado nivel de seguridad. Las declaraciones de atributos añaden cualidades verificables a esa identidad: que eres mayor de edad, que tienes un título de grado, que estás colegiado, que una empresa está inscrita y quién la representa. Esta separación permite algo muy potente en términos de privacidad: la divulgación selectiva. Puedes demostrar que superas los 18 años sin revelar tu fecha de nacimiento, o que estás habilitado para una profesión sin exponer el resto de tu expediente.

Los tres tipos de declaraciones de atributos

eIDAS 2 distingue tres figuras, con distinto emisor y distinto valor jurídico:

Tipo	Emisor	Verificación contra fuente auténtica	Valor jurídico
Declaración electrónica de atributos DEA (EAA) — no cualificada	Cualquier prestador de servicios (no necesariamente cualificado)	No exigida por el Reglamento	Principio de no discriminación: no se le niega efecto jurídico ni admisibilidad como prueba por ser electrónica
Declaración electrónica cualificada de atributos DECA (QEAA)	Prestador cualificado de servicios de confianza (QTSP), supervisado y auditado	Cuando el atributo figura en el Anexo VI, verificación contra la fuente auténtica correspondiente	Efecto jurídico equivalente al de la declaración en papel legalmente expedida; reconocimiento en todos los Estados miembros
Declaración expedida por un organismo del sector público responsable de una fuente auténtica, o en su nombre DEA-AAPP (pub‑EAA)	Organismo del sector público titular de la fuente auténtica (o quien actúe por él)	Por definición, procede de la propia fuente auténtica	Efecto jurídico equivalente al de la declaración en papel; misma fuerza que la QEAA en su ámbito

La diferencia clave entre EAA (DEA) y QEAA (DECA) no es solo el nivel de garantía, sino el anclaje en fuentes auténticas y la supervisión. Una QEAA la emite un QTSP sujeto a los mismos deberes de fiabilidad, auditoría y responsabilidad que el resto de servicios cualificados, y cuando el atributo pertenece a las categorías del Anexo VI (por ejemplo, dirección, edad, sexo, estado civil, nacionalidad, títulos y cualificaciones profesionales, permisos y licencias, o datos registrales de personas jurídicas) debe poder verificarse contra la fuente auténtica que lo custodia.

¿Qué es una «fuente auténtica»?

Una fuente auténtica es el repositorio o sistema, administrada por el sector público o por una entidad privada de confianza, que se reconoce como origen primario y fiable de un atributo: el registro civil para el estado civil, el registro mercantil para los datos societarios, el registro de títulos académicos para las titulaciones (de universidades públicas o privadas), la DGT para el permiso de conducción, etc. El valor de una QEAA (DECA) cae en cascada desde la calidad de esa fuente: la declaración no «inventa» el dato, lo transporta con garantías desde donde reside (porque es donde se gestiona) de forma auténtica.

Base jurídica en eIDAS 2

El régimen está en el bloque de artículos 45 ter y siguientes del Reglamento 910/2014 en su versión modificada por el Reglamento 2024/1183, junto con las definiciones del artículo 3:

Art. 45 ter (45b) — Efectos jurídicos de las declaraciones electrónicas de atributos.
Art. 45 quater (45c) — Uso de las declaraciones en los servicios públicos.
Art. 45 quinquies (45d) — Requisitos de las QEAA, desarrollados en el Anexo V.
Art. 45 sexies (45e) — Verificación de atributos contra fuentes auténticas, con la lista mínima del Anexo VI.
Art. 45 septies (45f) — Requisitos de las declaraciones expedidas por o en nombre de un organismo del sector público responsable de una fuente auténtica (pub‑EAA), en el Anexo VII.
Art. 45 octies (45g) — Expedición de declaraciones a la Cartera Europea de Identidad Digital.
Art. 45 nonies (45h) — Reglas adicionales para la prestación del servicio.

Estos preceptos se completan con los actos de ejecución de la Comisión y con las normas técnicas de ETSI y CEN que los desarrollan. (Mantengo un seguimiento actualizado de esos actos y de las normas que citan en el artículo del blog «Actos de ejecución y normas ETSI y CEN»).

¿En qué formatos se materializan?

En el plano técnico, el Architecture and Reference Framework (ARF) de la EUDI Wallet contempla dos formatos de declaración: SD‑JWT VC (con divulgación selectiva) e ISO/IEC 18013‑5 mdoc (el formato del carnet de conducir móvil). Ambos permiten presentar solo los atributos estrictamente necesarios para cada transacción, que es la esencia del modelo de minimización de datos que persigue el Reglamento.

Casos de uso

Las declaraciones de atributos habilitan escenarios cotidianos con menos fricción y menos exposición de datos: acreditar la mayoría de edad en la compra de productos para la que se exige, demostrar una titulación o una colegiación ante un empleador o un cliente, probar la representación de una empresa al firmar un contrato, o justificar la titularidad de un permiso administrativo. En el ámbito empresarial, enlazan directamente con la futura Cartera Empresarial Europea (European Business Wallet), donde los atributos societarios y de representación serán determinantes.

¿Cuándo empieza a ser exigible? Prioridades y fechas tope

El despliegue de las declaraciones de atributos va de la mano del calendario de la Cartera Europea de Identidad Digital, y ese calendario marca dos prioridades escalonadas.

La primera es el sector público. La fecha tope es el 24 de diciembre de 2026: para entonces cada Estado miembro debe haber puesto a disposición de los ciudadanos al menos una cartera, y las administraciones públicas (como partes usuarias) deben aceptarla como medio de identificación. Es el hito que concentra el esfuerzo inmediato, porque obliga a que la infraestructura de emisión y aceptación esté operativa, incluidas las primeras declaraciones de atributos que la Administración necesitará reconocer.

La segunda prioridad es el sector privado regulado, con fecha tope 24 de diciembre de 2027. A partir de ese momento, las entidades de sectores como banca, telecomunicaciones, energía, transporte, sanidad, seguros, educación o infraestructura digital deberán aceptar la cartera cuando la normativa (de la Unión, nacional o contractual) exija autenticación reforzada para la identificación en línea. Conviene subrayar el matiz: diciembre de 2026 es emisión y aceptación por el sector público, no adopción de extremo a extremo por el sector privado, que llega en 2027.

En el plano de la oferta, la categoría de QEAA (DECA) todavía está poco poblada en las listas de confianza (TSL), pero ya empieza a aparecer: varios prestadores cualificados de servicios de confianza, en distintos Estados miembros, han dado de alta el servicio de declaración electrónica cualificada de atributos, consultable en el eIDAS Dashboard. Es el caso de DigitalSign — Certificadora Digital (Portugal), Microsec — Micro Software Engineering & Consulting (Hungría) e IDnow Trust Services AB (Suecia). Son señales tempranas de que la infraestructura de emisión de atributos cualificados empieza a materializarse antes de las fechas tope de 2026 y 2027.

En resumen

Las declaraciones electrónicas de atributos son el mecanismo con el que eIDAS 2 convierte la identidad digital en algo más que un DNI electrónico: un ecosistema en el que atributos verificables, con distinto grado de garantía jurídica, viajan con el usuario en su cartera y se presentan de forma selectiva. La EAA cubre los usos donde basta la confianza sectorial; la QEAA y la pub‑EAA aportan, respectivamente, la garantía del prestador cualificado y la del propio sector público titular del dato, con efecto equivalente al del documento en papel. Con el sector público obligado en diciembre de 2026 y el privado en 2027, y los primeros prestadores ya en las listas de confianza, es el momento de entender bien esta figura.

Contacta con EADTrust si estás preparando la adopción de las Carteras IDUE en tu entidad [EADTrust — European Agency of Digital Trust. www.eadtrust.eu · info@eadtrust.com · 902 365 612 / 91 716 05 55]

English abstract: Under eIDAS 2 (Regulation (EU) 2024/1183), an electronic attestation of attributes (EAA) is a signed electronic statement confirming that a given attribute about a person or entity is true, without necessarily proving full identity. eIDAS 2 defines three types — non‑qualified EAA, qualified EAA (QEAA, issued by a QTSP and, for Annex VI attributes, verified against an authentic source), and attestations issued by or on behalf of a public sector body responsible for an authentic source (pub‑EAA) — governed by Articles 45b–45h and Annexes V, VI and VII. QEAAs and pub‑EAAs carry legal effect equivalent to paper attestations and are recognised across the EU. Public‑sector acceptance is mandatory from 24 December 2026 and the regulated private sector from 24 December 2027; early QEAA providers already appear on the Trusted Lists. Attestations are carried in the EUDI Wallet, expressed as SD‑JWT VC or ISO/IEC 18013‑5 mdoc.

Cómo incluir nombres y dos apellidos españoles compuestos en el PID (DIP) de la Cartera IDUE (EUDI Wallet)

Deja un comentario

En el PID se incluye un campo de nombre y otro de apellido, pero no se contempla un tratamiento de nombres compuestos españoles y de dos apellidos, que pueden ser también compuestos (los 2 apellidos).

Y es que hay que reconocer que la costumbre anglosajona de usar un único campo de apellido no encaja con la costumbre española, y nuestra preferencia «rasca» con la forma en que se regula el PID. Así que propongo en este artículo una forma de codificar y decodificar la estructura del nombre y los dos apellidos sin romper la interoperabilidad, y sugiero una propuesta de cómo debería evolucionar la descripción del PID en el «Rule Book» para que la cartera europea sea directamente usable en España.

Para la solución provisional me baso en la solución adoptada para las menciones científicas de autores hispanos en publicaciones internacionales, donde luna cierta normalización tipográfica resolvieron un problema análogo.

El problema de fondo

El modelo de datos de identificación de persona del PID (Person Identification Data) hereda, como casi todos los esquemas de identidad de origen anglosajón, una simplificación de partida: un campo para el nombre y un campo para el apellido. En concreto, el PID ofrece given_name (obligatorio, con los nombres intermedios incluidos), family_name (obligatorio), y opcionalmente given_name_birth y family_name_birth. Todos son cadenas de texto libre, sin subestructura.

Ese diseño encaja mal con la costumbre española, que descansa sobre dos rasgos que el campo único no sabe representar.

Primero, los dos apellidos. Un ciudadano español tiene primer y segundo apellido, y desde las reformas del Registro Civil su orden ya no es necesariamente el paterno-primero: los progenitores lo eligen y la persona adulta puede invertirlo. Por tanto, cualquier convención que hable de «apellido paterno» y «apellido materno» nace equivocada; lo correcto es hablar de primer y segundo apellido como posiciones, no como linaje.

Segundo, los componentes compuestos. Tanto el nombre de pila (José María, María del Carmen, Juan Carlos) como cada apellido pueden ser internamente compuestos: con partículas (García de la Torre, Fernández de Córdoba, del Río), con la conjunción copulativa (Ramón y Cajal, Martí i Franquès) o con guion (Sánchez-Cano).

La consecuencia es que, cuando toda esa riqueza se aplasta en family_name = "García de la Torre Martín", la cadena deja de ser decodificable sin ambigüedad: ¿es «García de la Torre» + «Martín», o «García» + «de la Torre Martín»? El espacio, que es el separador natural del texto, no distingue el hueco entre los dos apellidos del hueco interno de un apellido compuesto. Es exactamente el mismo fenómeno que llevó a la comunidad científica a normalizar la firma para que las bases de datos no descompusieran «García Pérez» en «Pérez, G.».

Dónde se regula el PID: actos de ejecución y ARF

Antes de proseguir con la propuesta conviene situar las piezas normativas, porque el PID no se regula en un solo texto. En el plano de los actos de ejecución del Reglamento eIDAS 2, el que define los atributos del PID (obligatorios y opcionales) y su ciclo de vida es el Reglamento de Ejecución (UE) 2024/2977, de 28 de noviembre de 2024, sobre datos de identificación de la persona y declaraciones electrónicas de atributos. Lo acompañan, en la misma tanda, el 2024/2979 (integridad y funcionalidades esenciales de la cartera), el 2024/2980 (notificaciones al ecosistema), el 2024/2981 (certificación de las carteras) y el 2024/2982 (protocolos e interfaces, es decir, el catálogo de estándares con los que el PID se emite y se presenta). La segunda serie, de 2025, lo roza de forma indirecta pero muy pertinente para este asunto (el 2025/846 regula el cross-border identity matching, el cotejo transfronterizo en el que la estructura del nombre es justamente lo que se compara), y en 2026 se han publicado enmiendas (que ya he mencionado en el blog) que tocan los actos nucleares, incluido el 2024/2977, por lo que conviene trabajar siempre sobre el texto consolidado.

En el plano técnico, el Architecture and Reference Framework (ARF, cuya última versión en este momento es la 3.0) desarrolla lo anterior en varias piezas: el documento principal; el Annex 1 (Definiciones); el Annex 2 (High-Level Requirements), con requisitos técnicos, algunos específicos del PID; y, sobre todo, el Annex 3.01 – PID Rulebook, que es donde se define el esquema de atributos y sus dos codificaciones, mdoc (ISO/IEC 18013-5) y SD-JWT VC. Como referencia paralela está el Annex 3.02 (mDL Rulebook), y para el ciclo completo, el Annex 4 (emisión y presentación) y el Annex 6 (certificación). Cuando en este artículo se habla de «evolucionar la descripción del PID», el objeto concreto es el Annex 3.01 y el anexo del Reglamento 2024/2977.

Esta es la relación de actos de ejecución, con indicación de cuáles inciden en el PID (los números enlazan al texto en EUR-Lex):

Acto de ejecución	Objeto	Incidencia en el PID
(UE) 2024/2977	Datos de identificación de la persona y declaraciones electrónicas de atributos	Define el PID (atributos y ciclo de vida)
(UE) 2024/2979	Integridad y funcionalidades esenciales de la cartera	Indirecta
(UE) 2024/2980	Notificaciones a la Comisión sobre el ecosistema	Indirecta
(UE) 2024/2981	Certificación de las carteras	Indirecta
(UE) 2024/2982	Protocolos e interfaces (estándares de referencia)	Formatos de emisión y presentación
(UE) 2025/846	Cotejo transfronterizo de identidades	Relevante: coteja nombre y apellidos
(UE) 2025/847	Notificación de brechas de seguridad	Indirecta
(UE) 2025/848	Registro de las partes usuarias	Indirecta
(UE) 2025/849	Lista de carteras certificadas	Indirecta
(UE) 2025/2162	Acreditación de los organismos de evaluación de la conformidad	Indirecta
(UE) 2026/1731	Enmienda a 2024/2977, 2024/2979, 2024/2980 y 2024/2982 (estándares y especificaciones)	Modifica el 2024/2977

Qué exige el Reglamento sobre estos campos

El Reglamento 2024/2977 define family_name y given_name como texto libre destinado a mostrar y cotejar la identidad; es decir, como el valor legible que una parte usuaria (relying party) enseñará a un operador o comparará con otro documento. Esto impone una restricción de diseño ineludible: el valor de presentación debe seguir siendo la forma natural del nombre. No podemos contaminarlo con marcadores estructurales, porque una parte usuaria de otro Estado miembro que no conozca nuestra convención mostraría un artefacto con símbolos a un funcionario.

De aquí se deriva el principio rector de toda esta propuesta: separar el valor de presentación del valor estructurado. La estructura interna del nombre no debe viajar dentro del campo obligatorio de display, sino en un canal que degrade con elegancia: los campos opcionales o —mejor— un subcampo estructurado en el propio Rulebook.

Qué le pedimos a una solución provisional

Mientras el esquema del PID no incorpore subcampos de nombre, necesitamos una convención que preserve la estructura dentro de los campos que hoy existen. Para que sea sólida, esa convención debe cumplir cinco requisitos:

Reversibilidad. codificar(decodificar(x)) == x. La estructura recuperada debe volver a producir exactamente la misma cadena, sin pérdida.
Seguridad de presentación (degradación elegante). Si un sistema ignora la convención, lo que muestre debe seguir siendo un nombre legible, no un artefacto.
Seguridad de codificación. El PID se serializa en CBOR/COSE (formato mdoc, ISO/IEC 18013-5) o en JSON (SD-JWT VC). El marcador elegido no debe crear peligros de escape ni de doble escape al atravesar esas capas, ni al pasar por LDAP, expresiones regulares o URLs.
No colisión con caracteres legítimos del nombre. El marcador no puede ser un carácter que aparezca de forma natural en nombres españoles (ni el espacio, ni el guion, ni el punto, ni la conjunción «y/i»).
Neutralidad respecto al orden. La convención codifica posición (primer/segundo apellido), nunca linaje.

La solución provisional: la barra inclinada

El carácter que satisface esos cinco requisitos es la barra inclinada (/). Es legal sin escape dentro de una cadena JSON y es un byte ordinario en CBOR, de modo que sobrevive intacta a ambas serializaciones y a su conversión mutua. No aparece nunca en nombres españoles, así que no colisiona con ningún componente legítimo. Y, si un sistema que desconoce la convención la muestra tal cual, produce «García de la Torre / Martín», que cualquier persona interpreta sin dificultad: degrada de forma legible en lugar de romperse.

La propuesta es, por tanto, un modelo de dos capas. La capa de presentación usa los campos obligatorios tal cual los concibe el Reglamento, con la forma natural y sin ningún marcador. La capa estructurada transporta la descomposición reversible: mientras el Rulebook no ofrezca subcampos, se codifica en banda —por ejemplo en family_name_birth o en un atributo nacional— con la barra separando solo el primer y el segundo apellido, y preservando cada componente con sus propios espacios, partículas y guiones.

El algoritmo es trivial y auditable. Estas son las reglas, con la normalización Unicode a NFC incluida y el escape por porcentaje para la —rarísima— barra literal dentro de un componente:

			
# Marcador y escape
SEP = " / "
esc(c)   = c.replace("%","%25").replace("/","%2F")
unesc(c) = c.replace("%2F","/").replace("%25","%")
codificar(primer, segundo):
    primer, segundo = NFC(primer), NFC(segundo)
    if segundo == "":  return esc(primer)          # apellido único
    return esc(primer) + SEP + esc(segundo)
decodificar(s):
    partes = NFC(s).split(SEP)
    if len(partes) == 1: return (unesc(partes[0]), "")
    return (unesc(partes[0]), unesc(SEP.join(partes[1:])))

		

Casos límite, resueltos

Apellido único (extranjeros nacionalizados, o españoles con un solo apellido): ausencia de barra. "Smith" se codifica como "Smith" y la decodificación devuelve segundo apellido vacío. El round-trip se mantiene.
Conjunción copulativa. Ramón y Cajal o Martí i Franquès pueden ser un único apellido compuesto. La barra es la única frontera autoritativa; el «y»/«i» nunca lo es. Así, "Ramón y Cajal / Ferrer" se decodifica sin ambigüedad como primer apellido «Ramón y Cajal» y segundo «Ferrer».
Barra literal en un nombre (excepcional): se codifica por porcentaje (%2F), de modo que el separador nunca se confunde con un carácter del propio nombre.
Normalización Unicode. Todo componente se normaliza a NFC y se conserva el uso registral de mayúsculas y minúsculas (partículas «de», «de la», «del» en minúscula cuando no encabezan). Sin esto, el cotejo posterior falla por diferencias de composición de las tildes.

En este contexto NFC es Normalization Form C (Forma de Normalización C, o «composición canónica»).

Todas estas reglas están verificadas con round-trip automático sobre los cuatro casos —compuesto con partículas, apellido único, conjunción copulativa y barra literal— antes de escribir una sola línea del ejemplo que sigue.

Ejemplo completo

Tomemos una persona por su estructura: nombre de pila compuesto, primer apellido con partículas y segundo apellido simple.

Elemento	Valor
Nombre de pila	José María
Primer apellido	García de la Torre
Segundo apellido	Martín
`family_name` (presentación)	García de la Torre Martín
Forma estructurada (barra)	García de la Torre / Martín

Un detalle que conviene tener presente en cualquier codificación binaria: «García de la Torre Martín» ocupa 27 bytes en UTF-8 pero solo 25 caracteres, porque cada «í» son dos bytes (0xC3 0xAD). Las longitudes que aparecen en el CBOR de abajo son de bytes, no de caracteres.

(A) Formato mdoc — ISO/IEC 18013-5 (CBOR)

En el namespace eu.europa.ec.eudi.pid.1, los atributos del PID se serializan como un mapa CBOR. Esta es la representación del ejemplo en notación diagnóstica:

			
{
  "given_name":        "José María",
  "family_name":       "García de la Torre Martín",
  "birth_date":        1004("1978-05-14"),   / tag full-date /
  "birth_place":       "ES",
  "nationality":       ["ES"],
  "family_name_birth": "García de la Torre Martín",
  "issuing_country":   "ES",
  "issuing_authority": "Ministerio del Interior"
}

		

Y su codificación real, byte a byte (hex), 230 bytes en total:

			
a8                                          # map(8)
  6a 676976656e5f6e616d65                   # "given_name"
  6c 4a6f73c3a9204d6172c3ad61               # "José María"
  6b 66616d696c795f6e616d65                 # "family_name"
  78 1b 47617263c3ad61206465206c6120        # text(27) "García de la 
        546f727265204d617274c3ad6e          #            Torre Martín"
  6a 62697274685f64617465 d9 03ec           # "birth_date" tag(1004)
        6a 313937382d30352d3134              # "1978-05-14"
  6b 62697274685f706c616365 62 4553         # "birth_place" "ES"
  6b 6e6174696f6e616c697479 81 62 4553      # "nationality" ["ES"]
  71 66616d696c795f6e616d655f6269727468     # "family_name_birth"
  78 1b 47617263c3ad61...c3ad6e             # text(27) "García…Martín"
  6f 69737375696e675f636f756e747279 62 4553 # "issuing_country" "ES"
  71 69737375696e675f617574686f72697479     # "issuing_authority"
  77 4d696e6973746572696f2064656c20496e...  # "Ministerio del Interior"

		

Cada atributo se firma, en realidad, dentro de un IssuerSignedItem envuelto en un byte string marcado con la etiqueta CBOR 24 (encoded-cbor). Para family_name:

			
# Tag 24 > bstr > { digestID, random, elementIdentifier, elementValue }
d818 5863 a4
  68 646967657374494403                     # "digestID": 3
  66 72616e646f6d 48 8f9b6c2d1e4a7f30        # "random": h'8f9b…7f30'
  71 656c656d656e744964656e746966696572      # "elementIdentifier"
     6b 66616d696c795f6e616d65               #   "family_name"
  6c 656c656d656e7456616c7565                # "elementValue"
     78 1b 47617263c3ad61...546f727265204d617274c3ad6e  # "García de la Torre Martín"

		

La forma estructurada en mdoc. El atributo family_name mantiene la forma natural; la descomposición viaja aparte, en un elemento propuesto family_name_unit, como submapa CBOR —limpio, sin marcadores en banda y con divulgación selectiva independiente:

			
a1 70 66616d696c795f6e616d655f756e6974      # { "family_name_unit":
   a2 65 6669727374 73 47617263c3ad612064...  #     "first": "García de la Torre",
      66 7365636f6e64 67 4d617274c3ad6e        #     "second": "Martín" } }

(B) Formato SD-JWT VC (JSON con divulgación selectiva)

En SD-JWT VC cada atributo divulgable se materializa en una disclosure —base64url([salt, nombre, valor])— cuyo digest SHA-256 se referencia en el array _sd del payload. Las disclosures del ejemplo (incluida la estructurada) son:

			
# family_name
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwiZmFtaWx5X25hbWUiLCJHYXJj
w61hIGRlIGxhIFRvcnJlIE1hcnTDrW4iXQ
    # [ "2GLC42sKQveCfGfryNRN9w", "family_name",
    #   "García de la Torre Martín" ]
# family_name_unit (estructura, divulgable por separado)
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwiZmFtaWx5X25hbWVfdW5pdCIs
eyJmaXJzdCI6IkdhcmPDrWEgZGUgbGEgVG9ycmUiLCJzZWNvbmQiOiJNYXJ0
w61uIn1d
    # [ "6Ij7tM-a5iVPGboS5tmvVA", "family_name_unit",
    #   { "first": "García de la Torre", "second": "Martín" } ]

		

			
// payload del JWT
{
  "vct": "urn:eudi:pid:1",
  "iss": "https://pid-provider.eadtrust.example",
  "iat": 1789000000,
  "_sd_alg": "sha-256",
  "_sd": [
    "yfz5UHtG2F_rLi1yy91D4jhgTp4E1Drr622DHtTg2h0",   // family_name
    "fXAlOjDoJjc5bDmf-t2dbtV1I3sQ85dfQqPXQVQGYPc",   // given_name
    "6b1YOIoO3h9rWMav2ohyH6ngyJOmWnjqx682KF_FInk"    // family_name_unit
  ]
}

		

La ventaja del submapa family_name_unit como disclosure propia es doble: la parte usuaria española que necesite el primer apellido para un cotejo registral puede pedirlo sin forzar la revelación del segundo, y la parte usuaria genérica sigue recibiendo family_name tal cual, sin enterarse de la estructura. Divulgación selectiva y degradación elegante en el mismo mecanismo.

(C) Formato W3C Verifiable Credentials (JSON-LD), como referencia

Donde se use el perfil W3C VC, la misma idea se expresa con un objeto anidado en credentialSubject, conservando el literal de presentación junto a la estructura:

			
"credentialSubject": {
  "given_name": "José María",
  "family_name": "García de la Torre Martín",
  "family_name_unit": { "first": "García de la Torre", "second": "Martín" }
}

		

Por qué la solución robusta no está en el separador

Es una humilde propuesta para resolver el problema, pero no es la panacea. Igual que en la firma de publicaciones científicas la normalización tipográfica acabó siendo un paliativo y la respuesta estructural fue el identificador persistente (ORCID), aquí el separador en banda es una solución de compromiso para cuando no hay más remedio. La respuesta arquitectónicamente correcta es que la estructura del nombre la conoce el registro emisor —el PID Provider parte del Registro Civil, que sí distingue primer y segundo apellido— y que esa estructura se transporte en subcampos explícitos, no incrustada en una cadena de texto que otros sistemas cotejarán a ciegas. La barra nos salva mientras tanto; el subcampo nos salva para siempre.

Lo que enseña (y advierte) el MRZ del pasaporte

Antes de que existiera el PID había ya un sistema que llevaba décadas transportando nombres de medio mundo entre administraciones: la zona de lectura mecánica (MRZ) de los documentos de viaje, normalizada en ICAO Doc 9303 (Parte 3). Merece la pena mirarla, porque valida algunas de las decisiones que proponemos aquí… y advierte de sus límites.

El MRZ tiene tres formatos —TD3 (pasaporte, 2 líneas de 44 caracteres), TD1 (tarjetas de identidad, 3 líneas de 30) y TD2 (2 líneas de 36)— y un juego de caracteres deliberadamente pobre: solo A–Z, 0–9 y el relleno <. No hay minúsculas, ni espacios, ni signos diacríticos; el espacio se representa con <.

El nombre se codifica así: identificador primario (los apellidos) + << + identificador secundario (los nombres), y dentro de cada identificador los componentes se separan con un solo <. Para «Federico García Lorca»:

GARCIA<LORCA<<FEDERICO

Dos observaciones que interesan a nuestro problema. La primera: ICAO no habla de «apellido» y «nombre», sino de identificador primario y secundario, y deja al Estado emisor decidir cómo repartir el nombre entre ambos. La serialización está fija; el reparto semántico se delega. La segunda: el pasaporte ya funciona en dos capas. El MRZ (interoperable, con pérdidas) se replica en el DG1 del chip, mientras que el nombre completo en caracteres nacionales vive en el DG11 («datos personales adicionales»). Es exactamente el patrón «verdad canónica + representación derivada» que defendemos para el PID.

Ahora la advertencia. El MRZ separa con claridad apellidos y nombres, pero no resuelve la ambigüedad de fondo: la serializa. El delimitador < colapsa en un mismo símbolo dos cosas distintas (el espacio interno de un apellido compuesto y la frontera entre dos apellidos). Ante:

GARCIA<DE<LA<TORRE<<JUAN

no hay forma de saber si «García de la Torre» es un apellido, o si son «García» y «De la Torre», o cuatro componentes sueltos. Es nuestra misma «cadena no decodificable sin ambigüedad», con otro separador. Añádase la transliteración con pérdidas (la Ñ se vuelve N, las tildes desaparecen), el truncamiento de nombres largos y las mayúsculas forzadas, y queda claro que el MRZ no puede ser ni la capa de presentación ni la fuente canónica.

La lección, por tanto, es doble. Por un lado, el MRZ confirma que se puede interoperar fijando roles claros (primario/secundario) y reglas deterministas de serialización y parseo. Por otro, demuestra empíricamente que un delimitador único sin estructura no porta la cardinalidad (cuántos apellidos hay) y que la transliteración destruye información. Es el mejor argumento a favor de lo que proponemos: subcampos explícitos para los apellidos y un valor canónico en Unicode, en lugar de confiarlo todo a la codificación in-band.

Y es también donde los servicios intermediarios de confianza encajan de forma natural: ofrecer a cada parte usuaria (RP) una capa de normalización que traduzca el PID (family_name, given_name y, cuando existan, los subcampos) a exactamente los campos que su formulario espera (un apellido, dos apellidos, nombre para mostrar), con reglas documentadas y reversibles. Así el RP deja de reinventar el parsing de nombres, que es donde hoy se concentra el sufrimiento. En definitiva: quedémonos con lo bueno del MRZ (roles claros, reglas deterministas) sin heredar lo malo (delimitadores ambiguos y transliteración destructiva).

Referencia: ICAO, Doc 9303 — Machine Readable Travel Documents, Part 3: Specifications Common to all MRTDs, disponible en icao.int.

Cómo debería evolucionar la descripción del PID

El caso español no es una excepción folclórica: Portugal encadena hasta cuatro apellidos, los países árabes construyen cadenas patronímicas, Islandia usa patronímicos en lugar de apellido de familia. Un modelo de nombre que solo contempla «nombre + apellido» es, en realidad, un problema paneuropeo que España evidencia con especial claridad. Estas son las evoluciones que, a mi juicio, deberían incorporar el Annex 3.01 (PID Rulebook) y el anexo del Reglamento 2024/2977:

Un atributo de nombre estructurado, opcional y normalizado. Añadir al esquema PID un family_name_unit (submapa first/second, ampliable a third/fourth para Portugal) y un given_name_unit con el nombre habitual marcado. Opcional, para no romper a nadie; estructurado, para no perder información.
Posición, no linaje. Nombrar los componentes por orden (first, second) y nunca por origen (paterno/materno), en coherencia con la libre elección y la inversión del orden que permite la ley española.
Divulgación selectiva por componente. Que cada subcomponente sea una claim divulgable de forma independiente, de modo que una parte usuaria pueda solicitar solo el primer apellido cuando es lo que necesita para un cotejo, minimizando datos.
Reglas de normalización explícitas en el propio Rulebook. Fijar NFC obligatorio, tratamiento de mayúsculas/minúsculas de partículas y —para el escenario provisional en banda— la barra como separador con escape por porcentaje. Escrito en la norma, no dejado al criterio de cada emisor.
Un anexo nacional (perfil español del PID). El mecanismo por el que el ARF admite perfiles y rulebooks de atributos debería acoger un anexo español que registre formalmente esta convención, del mismo modo que ya existen rulebooks para otros dominios de atributos.
Coherencia con el cotejo transfronterizo. El acto de ejecución 2025/846 sobre identity matching se apoya precisamente en el nombre y los apellidos; un PID con nombre estructurado hace ese cotejo fiable y evita repetir en la cartera los apaños ad hoc que cada nodo nacional viene arrastrando desde el conjunto mínimo de datos de eIDAS SAML.

Conclusión

El PID no fue diseñado pensando en los dos apellidos ni en los compuestos con partículas, y el campo único de texto libre es, para el caso español, estructuralmente insuficiente. La vía sensata no es maltratar el campo obligatorio de presentación —que debe seguir mostrando el nombre natural—, sino separar presentación de estructura, adoptar mientras tanto un separador que sobreviva a CBOR, JSON, LDAP y a las expresiones regulares —la barra inclinada, con sus reglas de frontera reversibles—, y, sobre todo, promover que el Annex 3.01 y el Reglamento 2024/2977 incorporen la estructura del nombre como subcampo explícito. Mientras Europa no lo haga, cada emisor español lo resolverá a su manera; y la interoperabilidad, que es justo lo que la EUDI Wallet viene a traer, se resentirá precisamente en el dato más elemental de todos: cómo nos llamamos.

Referencias normativas y técnicas

Reglamento marco. Reglamento (UE) n.º 910/2014 (eIDAS), en su versión modificada por el Reglamento (UE) 2024/1183 (eIDAS 2).

Actos de ejecución. Reglamentos de Ejecución (UE) 2024/2977 (PID y declaraciones electrónicas de atributos), 2024/2979, 2024/2980, 2024/2981 y 2024/2982 (primera serie, 28-XI-2024); 2025/846, 2025/847, 2025/848, 2025/849 y 2025/2162 (segunda serie, 2025); y la enmienda (UE) 2026/1731 (2026).

Architecture and Reference Framework (ARF). Annex 3.01 – PID Rulebook, dentro del conjunto del ARF y sus anexos (repositorio oficial de la Comisión Europea).

Formatos. ISO/IEC 18013-5 (mdoc) para la codificación CBOR/COSE; SD-JWT VC (IETF) para la codificación JSON con divulgación selectiva.

Te ayudamos

En EADTrust (European Agency of Digital Trust) acompañamos a las entidades obligadas a aceptar la Cartera Europea de Identidad Digital en su adaptación técnica y jurídica. El artículo 5 septies del Reglamento (UE) n.º 910/2014, modificado por el Reglamento (UE) 2024/1183 (eIDAS 2), impone esa aceptación a las administraciones públicas y a las partes usuarias privadas de sectores como el transporte, la energía, la banca y los servicios financieros, la seguridad social, la salud, el agua potable, los servicios postales, la infraestructura digital y las telecomunicaciones, además de a las plataformas en línea de muy gran tamaño (VLOP). Si su organización está entre ellas, podemos ayudarle a preparar la integración de la cartera con garantías de interoperabilidad y valor probatorio. Contacte en www.eadtrust.eu, info@eadtrust.com o en los teléfonos 902 365 612 y 91 716 05 55.

European Business Wallets: el nuevo Reglamento europeo entra en los trílogos

Deja un comentario

El Reglamento de las European Business Wallets (EBW) ha superado el último trámite que le faltaba antes de la negociación final. El 10 de septiembre de 2026, la comisión de Industria, Investigación y Energía (ITRE) del Parlamento Europeo adoptó su informe sobre la propuesta y respaldó abrir negociaciones con el Consejo. Con los dos colegisladores ya con posición fijada, el expediente entra en su fase decisiva: los trílogos.

Qué es la European Business Wallet

La EBW es una cartera digital para personas jurídicas, concebida para que las empresas puedan identificarse, firmar electrónicamente, otorgar poderes de representación, almacenar documentos y comunicarse de forma segura con las administraciones públicas y con otras empresas, sin necesidad de presencia física. Se construye sobre el marco de eIDAS2, del que hereda el modelo de confianza, y aspira a reducir las cargas administrativas transfronterizas dentro del mercado único: constituir una filial, responder a un requerimiento de otra administración o acreditar la representación de la sociedad deberían poder hacerse con la misma credencial en cualquier Estado miembro.

Es, en definitiva, la contraparte empresarial de la EUDI Wallet ciudadana: si eIDAS2 dio identidad digital a las personas, la EBW la lleva al plano societario.

Qué ha ocurrido en septiembre

La comisión ITRE adoptó su informe por 64 votos a favor, 7 en contra y 4 abstenciones, y aprobó abrir negociaciones interinstitucionales por 65-9-1. Conviene precisar el matiz procedimental, porque es fácil confundirlo: no se trata de una votación del pleno en primera lectura, sino de un mandato de comisión. La decisión de negociar se anuncia en la sesión plenaria siguiente (procedimiento del artículo 71 del Reglamento interno del Parlamento) y, salvo que un grupo político o una décima parte de los eurodiputados pidan que el pleno se pronuncie, los trílogos pueden arrancar a partir de ahí.

Dicho de otro modo: a día de hoy el Parlamento tiene mandato para negociar, que es exactamente lo que faltaba para sentarse a la mesa con el Consejo y la Comisión.

El recorrido legislativo, en fechas

19 de noviembre de 2025 — La Comisión Europea presenta la propuesta de Reglamento (expediente 2025/0358(COD), procedimiento legislativo ordinario).
9 de junio de 2026 — El Consejo adopta su orientación general (posición negociadora).
10 de septiembre de 2026 — La comisión ITRE del Parlamento adopta su informe y el mandato para negociar.
A continuación — Trílogos entre Parlamento, Consejo y Comisión, con el objetivo declarado de un acuerdo político antes de que termine 2026.

Las dos posiciones que llegan a la mesa

Consejo y Parlamento comparten el diagnóstico —una cartera empresarial construida sobre eIDAS2 que complemente, y no sustituya, los sistemas nacionales— pero llegan al trílogo con acentos distintos.

Eje	Consejo (9-jun-2026)	Parlamento / ITRE (10-sep-2026)
Encaje	Sobre eIDAS2; complementa, no sustituye, los sistemas nacionales	En la misma línea, evitando duplicar las carteras nacionales y la EUDI Wallet
Soberanía digital	Escrutinio de ciberseguridad más estricto para autorizar proveedores	Refuerzo marcado: prohibición de proveedores controlados por entidades o gobiernos de terceros países
Datos	—	Almacenamiento exclusivamente en la UE; prohibición de usarlos para entrenar IA de terceros países
Supervisión	Plazo de autorización de proveedores ampliado de 30 a 60 días	—
Equivalencia legal	Actos digitales equivalentes al papel, respetando requisitos nacionales	En la misma dirección
Pymes	—	Adecuación expresa a las necesidades de las pymes

(Las celdas con «—» señalan que ese punto no es el énfasis principal de esa institución, no necesariamente una discrepancia.)

Aspectos clave de la negociación

Tres frentes concentrarán la negociación. El primero es el grado de «soberanía digital»: hasta dónde llegan la prohibición de control por terceros países y la localización de datos en la UE que impulsa el Parlamento, frente a un enfoque algo más abierto en el Consejo. El segundo es la articulación fina con eIDAS2 y con las carteras nacionales y la EUDI Wallet, para que la EBW sume sin solapar ni fragmentar el ecosistema de confianza. Y el tercero son los plazos —de autorización de proveedores y de aplicación del Reglamento— y su proporcionalidad, con especial atención a las pymes, que son quienes más tienen que ganar con la simplificación y quienes más pueden sufrir una carga de cumplimiento desproporcionada.

Perspectiva

El calendario es ambicioso pero no inverosímil: con posición de Consejo desde junio y mandato del Parlamento desde septiembre, un acuerdo político antes de fin de 2026 es el objetivo que manejan las instituciones. A partir de ahí quedarían la adopción formal y, sobre todo, el desarrollo de los actos de ejecución y los plazos de despliegue, que es donde se juega de verdad la interoperabilidad con eIDAS2.

La Cartera de empresas EBW ya no es solo una propuesta con respaldo del Consejo; tiene también mandato del Parlamento, y la pelota está en los trílogos, con la soberanía digital como principal línea de fricción.

Fuentes: Consejo de la UE (nota de prensa de 9 de junio de 2026); Agence Europe y MLex sobre la votación en la comisión ITRE del 10 de septiembre de 2026; Observatorio Legislativo y Legislative Train Schedule del Parlamento Europeo (expediente 2025/0358(COD)).

Una semana en Tallinn: identidad digital, firmas electrónicas, certificación y la EUDI Wallet

1 respuesta

El 14 de septiembre viajo a Tallinn para una semana intensa de trabajo en torno a la identidad digital europea, los servicios de confianza y la certificación de la EUDI Wallet.

Estonia es un escenario natural para esto. Pocos países han llevado tan lejos el e-gobierno, la identidad electrónica y la confianza digital. Esta semana se concentran allí varias citas que, juntas, cubren casi todo el ecosistema: estándares, autoridades de certificación, firmas en la nube, implementación de eIDAS 2 y el trabajo experto sobre la certificación de la Wallet.

Después de haber estado la semana pasada (1, 2 y 3 de septiembre) en el «Global Digital Collaboration Conference 2026» seguimos profundizando en los aspectos relacionados con las carteras, la firma electrónica remota y la identidad digital.

Calendario de la semana

Día	Evento	Horario	Lugar
Lunes 14	ETSI ESI CA Open Session	13:00–18:00	Kultuurikatel, Stalker Hall
Lunes 14	CSC 10th Anniversary Celebration	18:00–22:00	F-Hoone, Telliskivi 60a/5
Martes 15	ENISA Trust Services and eID Forum (12.ª ed.)	jornada completa	Kultuurikatel
Miércoles 16	18.º CA Day (D-Trust / TÜV NORD Cert)	jornada completa	Kultuurikatel
Jueves 17 – viernes 18	AHWG de ENISA sobre la EUDI Wallet	reunión de expertos	Kultuurikatel
Jueves 17	PQC Migration Workshop (no asisto)	09:00–12:50	Kultuurikatel, Courtyard Tower

El taller de migración a criptografía post-cuántica coincide con el grupo de trabajo de la Wallet, así que me lo perderé.

Lunes 14 — ETSI ESI CA Open Session

13:00–18:00 · Kultuurikatel, Stalker Hall

Sesión abierta del comité técnico ESI (Electronic Signatures and Trust Infrastructures) de ETSI, centrada en las autoridades de certificación y en los retos del ecosistema EUDI.

Reúne a expertos, prestadores de servicios de confianza y profesionales que trabajan en la estandarización e implementación del marco eIDAS 2. El foco está en cómo se emitirán, validarán y usarán certificados e identidades digitales en los próximos años.

Kultuurikatel es la antigua central eléctrica de Tallinn. En sus instalaciones se rodó parte de Stalker de Tarkovsky, de ahí el nombre de la sala.

Lunes 14 por la noche — 10.º aniversario del Cloud Signature Consortium

18:00–22:00 · F-Hoone, Telliskivi 60a/5

El CSC celebra diez años con el lema “10 Years of Building Digital Trust — Together, Worldwide”.

Nació en 2016, coincidiendo con eIDAS, para definir un estándar abierto de firmas electrónicas remotas en la nube. Su API permite que las aplicaciones de firma y los QTSP se integren de forma interoperable. Hoy tiene más de 80 miembros en más de 40 países y su especificación está referenciada en los actos de ejecución relacionados con la EUDI Wallet.

F-Hoone está en Telliskivi Loomelinnak, otro espacio industrial reconvertido y uno de los centros creativos más vivos de la ciudad.

Martes 15 y miércoles 16 — Trust Services and eID Forum y CA Day (ENISA)

Kultuurikatel – Tallinn Creative Hub

Página del evento

El martes 15 se celebra la 12.ª edición del Trust Services and eID Forum, organizado por ENISA junto con la Comisión Europea. Es la cita anual de referencia para responsables políticos, prestadores de servicios de confianza, organismos de evaluación de la conformidad, supervisores e instituciones europeas y nacionales.En la agenda:

Estado de implantación de las EUDI Wallets en los Estados miembros
European Business Wallet
Relación del marco de identidad digital con el Cyber Resilience Act (CRA)
Situación de los servicios de confianza
Evolución de la estandarización
Efectos potenciales de la criptografía post-cuántica en la identidad digital

El miércoles 16 sigue el 18.º CA Day, organizado por D-Trust y TÜV NORD Cert, en el mismo recinto. Es la continuación natural: del debate de política y ecosistema al trabajo más específico de autoridades de certificación.

Jueves 17 y viernes 18 — AHWG de ENISA sobre la EUDI Wallet

Los días 17 y 18 participo en la reunión del Ad Hoc Working Group (AHWG) de ENISA sobre la certificación de las European Digital Identity Wallets.

Este grupo de expertos trabaja en el esquema candidato de certificación de ciberseguridad de las wallets y en los requisitos de seguridad de los prestadores de servicios relacionados. No es un congreso abierto, sino el trabajo técnico que después se traduce en el esquema europeo y en las evaluaciones que tendrán que pasar las wallets nacionales.

Por eso no podré asistir al PQC Migration Workshop del jueves 17 por la mañana en el mismo Kultuurikatel pqcsa.eu. El taller, organizado en el marco del proyecto PQCSA, aborda la migración a criptografía post-cuántica en firmas, autenticación y servicios de confianza. El tema está muy relacionado con lo que se discute esta semana (de hecho el propio Forum de ENISA incluye una sesión sobre PQC), pero coincide con el grupo de trabajo de la Wallet.

Por qué esta semana importa

En cuatro días se encadenan:

estándares y autoridades de certificación (ETSI ESI),
interoperabilidad de firmas en la nube (CSC),
el foro europeo de eIDAS y servicios de confianza (ENISA + CA Day),
el trabajo experto de certificación de la EUDI Wallet (AHWG).

Es una fotografía bastante completa del momento en que está Europa: de la estandarización a la certificación, de las firmas remotas a las wallets, y con la amenaza post-cuántica ya encima de la mesa.

Si también estás en Tallinn esos días, avísame.

El Reglamento de las «European Business Wallets»: recorrido legislativo y encaje en eIDAS2

Deja un comentario

Recorrido legislativo y encaje en eIDAS2. Estado del expediente a septiembre de 2026.

La European Business Wallet avanza en el procedimiento legislativo ordinario y estos meses concentran sus pasos decisivos. Antes de entrar en el detalle, conviene situar dónde está hoy el expediente.

Estado a septiembre de 2026: el Consejo fijó su posición negociadora (orientación general) el 9 de junio de 2026; el Comité de las Regiones adoptó su dictamen el 1 de julio de 2026; y la comisión ITRE del Parlamento Europeo tiene previsto votar su informe el 10 de septiembre de 2026, el paso que abrirá la puerta a los trílogos. A la fecha de esta entrada, la votación de ITRE es inminente pero aún no se ha celebrado, y no hay todavía posición del Pleno ni negociaciones interinstitucionales en marcha.

Qué es la European Business Wallet

La European Business Wallet (EBW) es una cartera digital pensada para toda empresa de la UE (con especial atención a las pymes) con la que identificarse digitalmente, firmar (sellar) electrónicamente y relacionarse con plena eficacia jurídica tanto con las administraciones públicas (B2G) como con otras empresas (B2B) a través de las fronteras. Entre sus funciones nucleares: identificación y autenticación con un identificador único y persistente de empresa; firmas y sellos electrónicos y sellado de tiempo; emisión, custodia e intercambio de documentos electrónicos verificados y credenciales de atributos de empresa (licencias, certificados, permisos, extractos); gestión de mandatos y poderes de representación (quién puede actuar por la sociedad); y entrega electrónica certificada y comunicación segura, habilitando además la facturación electrónica y la reutilización de datos bajo el principio de «solo una vez» (OOTS).

La Comisión la presentó como pieza de la agenda de simplificación (el «Digital Omnibus»), con una estimación de ahorro de al menos 150 000 millones de euros anuales para las empresas europeas.

Encaje en eIDAS2

La EBW se construye sobre la misma arquitectura de confianza que la cartera de identidad digital europea (EUDI Wallet) del Reglamento (UE) 910/2014 (eIDAS2), al que la propuesta modifica de forma limitada para alinear ambos instrumentos. La distinción esencial es el sujeto: la EUDI Wallet se orienta a las personas físicas, mientras que la EBW se orienta a las personas jurídicas / empresas, añadiendo la identidad organizativa, los mandatos y poderes de representación y las certificaciones asociadas a las actividades de negocio. En la práctica, la EBW reutiliza el andamiaje de servicios de confianza de eIDAS2 (firma y sello electrónicos, sellos de tiempo, entrega electrónica certificada, listas de confianza) y lo proyecta al mundo de la empresa.

Recorrido legislativo

La propuesta sigue el procedimiento legislativo ordinario (procedimiento 2025/0358(COD)). Estos son los hitos con fecha:

Fecha	Órgano	Hito
19 nov 2025	Comisión Europea	Adopción de la propuesta de Reglamento — COM(2025) 838 final.
19 ene 2026	Parlamento Europeo	Remisión anunciada en el Pleno; ITRE como comisión competente, ponente Eero Heinäluoma (S&D, FI).
20 ene 2026	SEPD (EDPS)	Dictamen 5/2026 sobre la propuesta.
18 mar 2026	CESE	Dictamen INT/1110 (ponente Philip Von Brockdorff).
~1 abr 2026	Parlamento Europeo	Proyecto de informe de ITRE (PE785.244).
23 abr 2026	Parlamento Europeo	Plazo de enmiendas en comisión.
4 jun 2026	Parlamento Europeo	Opinión de la comisión IMCO.
8 jun 2026	Parlamento Europeo	Opinión de la comisión JURI (ponente Axel Voss).
9 jun 2026	Consejo de la UE	Orientación general (posición negociadora), Consejo TTE, Presidencia chipriota.
1 jul 2026	Comité de las Regiones	Dictamen adoptado (ponente Branislav Zacharides): integración con el Portal Digital Único / OOTS y apoyo a las pymes. (Nuevo)
10 sep 2026 (previsto)	Parlamento Europeo	Votación del informe en la comisión ITRE — inminente; abre la vía a los trílogos. (Nuevo)
Pendiente	PE / Consejo	Posición del Pleno del PE y trílogos (no iniciados).

El expediente en el observatorio legislativo del Parlamento (OEIL) figura todavía como «a la espera de la decisión de la comisión».

El acuerdo general del Consejo (9 de junio de 2026)

El Consejo introdujo varios cambios de calado sobre la propuesta de la Comisión: que las EBW complementen, y no sustituyan, los sistemas nacionales B2B/B2G existentes (énfasis en la interoperabilidad); un listón más alto de ciberseguridad y de autorización para los proveedores de cartera; una ampliación del plazo de evaluación de las solicitudes de proveedor por los organismos de supervisión de 30 a hasta 60 días; y mayor remisión del detalle a actos de ejecución de la Comisión. El objetivo político reiterado es alcanzar un acuerdo para finales de 2026.

Puntos de debate

Voluntariedad frente a obligatoriedad. De momento la EBW es voluntaria para las empresas (no impone obligaciones directas de negocio), pero la cláusula de revisión podría endurecer esto más adelante.
Ámbito y solapamiento. Debe complementar los sistemas nacionales y el OOTS, no duplicarlos (insistencia del Consejo y del Comité de las Regiones).
Pymes y coste. CESE y Comité de las Regiones piden incentivos, financiación y sencillez para que la carga no recaiga en las pequeñas empresas.
Protección de datos y soberanía de nube europea. Dictamen del SEPD 5/2026; en el Parlamento se defiende que los datos de la cartera se alojen en proveedores de nube europeos y se almacenen en la UE.
Ciberseguridad y autorización de proveedores. El Consejo elevó el umbral y amplió los plazos de evaluación.

Calendario de aplicación previsible

Sujeto al resultado de la negociación, el esquema que se maneja es: entrada en vigor tras la adopción (previsiblemente a principios de 2027, con la publicación en el DOUE); a los 24 meses, obligación de todas las administraciones públicas de aceptar las funciones nucleares de la EBW (sin poder rechazar una actuación válida por el mero hecho de ser digital); y a los 3 años, revisión de la Comisión, incluida la valoración de si conviene ampliar el ámbito o hacer obligatorio su uso.

Qué aspectos requerirán nuestra atención

El siguiente hito determinante es la votación de ITRE del 10 de septiembre de 2026: fijará la posición negociadora del Parlamento y, con el mandato del Consejo ya listo desde junio, permitirá abrir los trílogos con vistas al acuerdo político de finales de 2026.

Servicios Profesionales de EADTrust

La recopilación y el análisis de esta información se enmarcan en los Servicios Profesionales de EADTrust (European Agency of Digital Trust). Si tu organización (administración pública o empresa) está valorando proyectos de adaptación a las carteras de identidad y de empresa (EUDI Wallet y European Business Wallet) o de desarrollo del ecosistema eIDAS2, en EADTrust podemos acompañarte en el análisis normativo, el diseño y la implantación.

Contacta con nosotros por correo electrónico en info@eadtrust.com o por teléfono en el 902 365 612 o en el 91 7160555. Más información en eadtrust.com.

Fuentes

Los actos de ejecución de #eIDAS2, al día, junto con las normas ETSI y CEN que citan | The eIDAS2 implementing acts, up to date and the ETSI and CEN standards they cite

2 respuestas

Los actos de ejecución de eIDAS2, al día y las normas ETSI y CEN que citan

Actualización (octubre de 2026): tras volver a revisar el texto de todos los actos en EUR-Lex, he corregido y ampliado la relación de normas. Los cambios principales son: los CIR (UE) 2026/1730 y 2026/1731 sí citan normas ETSI (TS 119 411-8, TS 119 475, TS 119 472-1/-2/-3, TS 119 412-6 y TS 119 432, entre otras); el anexo II del CIR (UE) 2025/2162 recoge las normas de referencia para evaluar cada servicio cualificado; y la descripción de la ETSI TS 119 478 era errónea (trata de las interfaces con las fuentes auténticas). El catálogo completo, con las normas ISO, título, traducción y resumen de cada una, está en la entrada posterior «Estándares publicados en el desarrollo de la Cartera de Identidad Digital Europea y del resto de aspectos cubiertos por #EIDAS2».

Este artículo actualiza el contenido de las entradas «Lista completa de actos de ejecución que acompañan a #EIDAS2» (2 de febrero de 2026) y «Cartera de Identidad Digital Europea: arquitectura y marco de referencia (ARF v2.8.0)» (12 de mayo de 2026), donde ya recogía la relación de actos de ejecución.

En aquellos artículos fui listando los actos de ejecución de eIDAS2 (Reglamento (UE) 2024/1183, que modifica el Reglamento (UE) 910/2014) a medida que se adoptaban. Esta actualización completa la lista con lo aparecido después de febrero de 2026 e incluye la información adicional sobre la que me preguntan quienes tienen que implementar algún aspecto del nuevo marco regulatorio de confianza digital: la correspondencia entre cada Reglamento de Ejecución y las normas técnicas de ETSI y CEN que lo hacen operativo, indicando entre paréntesis, junto a cada norma, el Reglamento que la menciona. Cada acto lleva enlace al texto del DOUE en español (ES) e inglés (EN).

Siglas usadas (terminología oficial en español): DEA = declaración electrónica de atributos; DECA = declaración electrónica cualificada de atributos (la variante cualificada).

Qué ha cambiado desde la última lista

Lo más reciente es un trío de reglamentos modificativos de julio de 2026 (adoptados el 15 de julio, publicados el 22 de julio), que no crean materias nuevas sino que actualizan actos existentes: CIR (UE) 2026/1730 (más transparencia en el registro de partes usuarias y nuevas normas para sus certificados de acceso y de registro, ETSI TS 119 411-8 y TS 119 475; modifica el 2025/848), CIR (UE) 2026/1731 (alinea los cuatro actos núcleo de la cartera con la versión 3.0.0 del ARF, superando la v2.8.0, e incorpora las especificaciones ETSI TS 119 472-1/-2/-3, TS 119 412-6 y TS 119 432) y CIR (UE) 2026/1735 (exige firmar o sellar los resultados de verificación contra fuentes auténticas y remite a ETSI TS 119 471 y TS 119 478). Antes de ese trío, los dos actos de 2026 fueron el CIR (UE) 2026/798 (alta remota en la cartera hasta el nivel «alto») y el CIR (UE) 2026/248 (formatos de firma/sello para el sector público, sucesor de la Decisión 2015/1506). A fecha de esta entrada (agosto de 2026), el trío 2026/1730-1731-1735 es lo más reciente publicado.

Lista completa y actualizada de actos de ejecución

Bloque cartera (EUDI Wallet) -> noviembre de 2024

CIR (UE) 2024/2977 -> datos de identificación de la persona (PID) y declaraciones electrónicas de atributos emitidas a la cartera. [ES · EN]
CIR (UE) 2024/2979 -> integridad y funcionalidades básicas de la cartera. [ES · EN]
CIR (UE) 2024/2980 -> notificaciones a la Comisión sobre el ecosistema de la cartera. [ES · EN]
CIR (UE) 2024/2981 -> certificación de las carteras. [ES · EN]
CIR (UE) 2024/2982 -> protocolos e interfaces del marco de identidad digital europea. [ES · EN]

Bloque cartera y partes usuarias -> mayo de 2025

CIR (UE) 2025/846 -> emparejamiento transfronterizo de identidades de personas físicas. [ES · EN]
CIR (UE) 2025/847 -> reacciones ante brechas de seguridad de las carteras. [ES · EN]
CIR (UE) 2025/848 -> registro de las partes usuarias (incluye los certificados de acceso de parte usuaria). [ES · EN]
CIR (UE) 2025/849 -> lista de carteras certificadas. [ES · EN]

Bloque identidad y servicios de confianza -> 29 de julio de 2025

CIR (UE) 2025/1566 -> verificación de la identidad y los atributos del solicitante (identity proofing). [ES · EN]
CIR (UE) 2025/1567 -> gestión a distancia de dispositivos de creación de firma y de sello (firma/sello «en la nube»). [ES · EN]
CIR (UE) 2025/1568 -> revisiones inter pares de los esquemas de identificación electrónica (deroga la Decisión (UE) 2015/296). [ES · EN]
CIR (UE) 2025/1569 -> declaraciones electrónicas de atributos, cualificadas y del sector público. [ES · EN]
CIR (UE) 2025/1570 -> notificación de información sobre dispositivos cualificados certificados de creación de firma y de sello. [ES · EN]
CIR (UE) 2025/1571 -> formatos y procedimientos de los informes anuales de los organismos de supervisión. [ES · EN]
CIR (UE) 2025/1572 -> notificación de intención y verificación para el inicio de servicios de confianza cualificados. [ES · EN]

Bloque servicios de confianza -> 29 de septiembre de 2025

CIR (UE) 2025/1929 -> sellos cualificados de tiempo electrónicos. [ES · EN]
CIR (UE) 2025/1942 -> servicios cualificados de validación de firmas y sellos cualificados. [ES · EN]
CIR (UE) 2025/1943 -> certificados cualificados de firma electrónica y de sello electrónico. [ES · EN]
CIR (UE) 2025/1944 -> servicios cualificados de entrega electrónica certificada (QERDS). [ES · EN]
CIR (UE) 2025/1945 -> validación de firmas/sellos cualificados y de AdES basadas en certificado cualificado. [ES · EN]
CIR (UE) 2025/1946 -> servicios cualificados de preservación de firmas y sellos electrónicos. [ES · EN]

Bloque gobernanza y servicios no cualificados -> octubre de 2025

CIR (UE) 2025/2160 -> gestión de riesgos de los servicios de confianza no cualificados. [ES · EN]
CIR (UE) 2025/2162 -> acreditación de los organismos de evaluación de la conformidad (su anexo II recoge las normas de referencia para evaluar cada servicio cualificado). [ES · EN]
CIR (UE) 2025/2164 (Decisión) -> lista de confianza: versión de la norma de la plantilla común (modifica la Decisión de Ejecución (UE) 2015/1505). [ES · EN]

Bloque servicios de confianza -> 16 de diciembre de 2025

CIR (UE) 2025/2527 -> certificados cualificados de autenticación de sitios web (QWAC). [ES · EN]
CIR (UE) 2025/2530 -> requisitos de los prestadores cualificados de servicios de confianza (acto «paraguas»). [ES · EN]
CIR (UE) 2025/2531 -> libros registro electrónicos cualificados. [ES · EN]
CIR (UE) 2025/2532 -> servicios cualificados de archivo electrónico. [ES · EN]

2026 -> lo más reciente

CIR (UE) 2026/248 -> formatos de firmas y sellos electrónicos avanzados reconocibles por el sector público (deroga la Decisión (UE) 2015/1506). [ES · EN]
CIR (UE) 2026/798 -> alta remota (onboarding) en la cartera con elevación del nivel «sustancial» al nivel «alto». [ES · EN]
CIR (UE) 2026/1730 -> modifica el CIR (UE) 2025/848 (registro de partes usuarias): más transparencia (URL de política de privacidad) y nuevas normas para los certificados de acceso y de registro (ETSI TS 119 411-8 y TS 119 475). [ES · EN]
CIR (UE) 2026/1731 -> modifica los actos núcleo de la cartera (2024/2977, 2024/2979, 2024/2980, 2024/2982) para alinearlos con el ARF v3.0.0 e incorpora las especificaciones ETSI TS 119 472 (perfiles, presentación y expedición de DEA y PID). [ES · EN]
CIR (UE) 2026/1735 -> modifica el CIR (UE) 2025/1569 (declaraciones de atributos): firma/sellado de los resultados de verificación contra fuentes auténticas. [ES · EN]

Relación de normas ETSI y CEN, con el Reglamento que las cita

Entre paréntesis, tras cada norma, figura el Reglamento de Ejecución que la menciona; cuando una norma se cita en varios actos, se indican todos. Se incluyen también algunas normas ISO cuando se citan junto a las de ETSI y CEN.

Requisito horizontal para todo prestador

ETSI EN 319 401 -> Requisitos generales de política para prestadores de servicios de confianza (CIR (UE) 2025/1566; 2025/1567; 2025/1569; 2025/1929; 2025/1942; 2025/1943; 2025/1944; 2025/1946; 2025/2160; 2025/2162; 2025/2531; 2025/2532; 2026/798; 2026/1735 (V3.2.1))

Certificados cualificados

ETSI EN 319 411-1 -> Requisitos para PSC que emiten certificados; Parte 1, general (CIR (UE) 2025/1942; 2025/1943; 2025/1944; 2025/2162; 2025/848, sustituida mediante 2026/1730)
ETSI EN 319 411-2 -> Parte 2, certificados cualificados de la UE (CIR (UE) 2025/1943; 2025/2162; 2025/2527)
ETSI EN 319 412-1/-2/-3/-5 -> perfiles de certificados y QCStatements (CIR (UE) 2025/1943; 2025/2162; 2026/1731; la parte 5, también CID 2025/2164)
ETSI EN 319 412-4 -> perfil de certificados de sitio web (CIR (UE) 2025/2162)
CEN/TS 419261:2015 -> sistemas fiables que gestionan certificados y sellos de tiempo (CIR (UE) 2025/1943)

Certificados de autenticación de sitio web (QWAC)

ETSI TS 119 411-5 -> coexistencia de los QWAC con los certificados web de confianza pública (CIR (UE) 2025/2162; 2025/2527)
ETSI TS 119 495 -> perfil sectorial bancario PSD2 / banca abierta (CIR (UE) 2025/2162; 2025/2527)

Formatos de firma y sello (AdES) y contenedores de firma

ETSI EN 319 122-1 -> CAdES (CIR (UE) 2024/2979; 2025/2162; 2025/2531; 2026/248)
ETSI EN 319 132-1 -> XAdES (CIR (UE) 2024/2979; 2025/2162; 2025/2531; 2026/248)
ETSI EN 319 142-1 -> PAdES, formato obligatorio de la cartera (CIR (UE) 2024/2979, actualizada a la V1.2.1 por 2026/1731; 2026/248)
ETSI TS 119 182-1 -> JAdES (CIR (UE) 2024/2979; 2025/2162; 2025/2531; 2026/248)
ETSI EN 319 162-1/-2 -> ASiC (contenedores de firma asociada) (CIR (UE) 2024/2979; 2026/248)
ETSI TS 103 171 / 172 / 173 / 174 -> perfiles heredados XAdES/PAdES/CAdES/ASiC, aún admitidos (CIR (UE) 2026/248, anexo II)

Cartera: declaraciones de atributos, protocolos y firma

ETSI TS 119 472-1 -> perfiles de las DEA: requisitos generales (SD-JWT VC e ISO mdoc) (CIR (UE) 2026/1731, anexo II del 2024/2979)
ETSI TS 119 472-2 -> perfiles de presentación de DEA y PID a la parte usuaria (OpenID4VP) (CIR (UE) 2026/1731, anexo II del 2024/2982)
ETSI TS 119 472-3 -> perfiles de expedición de DEA y PID (OpenID4VCI) (CIR (UE) 2026/1731, anexo I del 2024/2982 y anexo III del 2024/2979)
ETSI TS 119 412-6 -> perfiles de certificado de los proveedores de PID, carteras, DEA, DECA y DEA del sector público (CIR (UE) 2026/1731, anexo II del 2024/2979)
ETSI TS 119 432 -> protocolos de firma a distancia, interfaz de firma de la cartera (CIR (UE) 2026/1731, anexo IV del 2024/2979)

Sellos cualificados de tiempo

ETSI EN 319 421 -> política de PSC que emiten sellos de tiempo (CIR (UE) 2025/1929; 2025/2162; 2025/2532)
ETSI EN 319 422 -> protocolo de sellado de tiempo y perfil del token (CIR (UE) 2025/1929; 2025/2162)

Validación de firmas y sellos

ETSI EN 319 102-1 -> creación y validación de AdES; Parte 1 (CIR (UE) 2025/1942; 2025/1945; 2025/1946; 2025/2162)
ETSI TS 119 102-2 -> informe de validación de firma (CIR (UE) 2025/1942; 2025/1945; 2025/2162)
ETSI TS 119 441 -> política de servicios de validación (CIR (UE) 2025/1942; 2025/2162)
ETSI TS 119 442 -> perfiles de protocolo de los servicios de validación (CIR (UE) 2025/2162)
ETSI TS 119 172-1/-4 -> políticas de firma (CIR (UE) 2025/1942; 2025/1945; 2025/1946; la parte 4, también 2025/2162)
ETSI TS 119 101 -> aplicaciones de creación y validación de firma (CIR (UE) 2025/1942; 2025/1945; 2025/1946)
ETSI TS 119 612 -> Listas de confianza (Trusted Lists) (CIR (UE) 2025/1942; 2025/1945; 2025/1946; 2025/2162; CID 2025/2164)

Gestión a distancia de dispositivos (firma remota)

ETSI TS 119 431-1 -> componente del PSC que opera el dispositivo remoto de creación de firma (CIR (UE) 2025/1567; 2025/2162)

Verificación de identidad y alta remota

ETSI TS 119 461 -> verificación de identidad de los sujetos de servicios de confianza (CIR (UE) 2025/1566; 2025/2162; 2026/798)

Declaraciones electrónicas de atributos

ETSI TS 119 471 -> requisitos de política y seguridad para los proveedores de DEA (CIR (UE) 2025/2162; 2026/1735, modifica 2025/1569)
ETSI TS 119 478 -> interfaces con las fuentes auténticas (CIR (UE) 2026/1735, modifica 2025/1569)

Entrega electrónica certificada (QERDS)

ETSI EN 319 521 -> requisitos de prestadores ERDS (CIR (UE) 2025/1944; 2025/2162)
ETSI EN 319 522 (partes 1-4) -> marco, contenidos, formatos e interfaces (CIR (UE) 2025/1944; 2025/2162)
ETSI EN 319 531 y EN 319 532 -> correo electrónico certificado (REM) (CIR (UE) 2025/2162)

Preservación

ETSI TS 119 511 -> preservación a largo plazo de firmas y datos (CIR (UE) 2025/1946; 2025/2162)
ETSI TS 119 512 -> protocolos de los servicios de preservación (CIR (UE) 2025/2162)

Libros registro electrónicos

ETSI EN 319 122-1, EN 319 132-1, TS 119 182-1 -> perfiles CAdES/XAdES/JAdES, con adaptaciones (CIR (UE) 2025/2531; 2025/2162)
ISO 23257:2022 e ISO/TS 23635:2022 -> arquitectura de referencia y gobernanza de las tecnologías de registro distribuido (CIR (UE) 2025/2531; 2025/2162)

Archivo electrónico

ETSI EN 319 421 -> sellos de tiempo del servicio de archivo (CIR (UE) 2025/2532)
CEN/TS 18170:2025 -> archivo electrónico, con adaptaciones (CIR (UE) 2025/2532; 2025/2162, también para libros registro)
ISO 14721:2025 (OAIS) e ISO 14641 -> modelo de referencia de archivo y sistemas de conservación de documentos electrónicos (CIR (UE) 2025/2532 (ISO 14721); 2025/2162 (ambas))

Evaluación de la conformidad y accesibilidad

ETSI EN 319 403-1 -> requisitos para los organismos que evalúan a los prestadores (CIR (UE) 2025/2162)
ETSI EN 301 549 -> requisitos de accesibilidad de productos y servicios TIC (CIR (UE) 2025/2162)

Certificación de la cartera y de la ciberseguridad

CEN EN 17640 -> metodología de evaluación de ciberseguridad de tiempo fijo (con EN ISO/IEC 17065:2012, 17067:2013, 17021-1:2015, 17025:2017, 17020:2012 y 17029:2019, ISO/IEC 17000:2020, EN ISO/IEC 15408-3:2022, 27001:2022 y 30111:2019) (CIR (UE) 2024/2981)

Certificados de acceso y de registro de la parte usuaria

ETSI EN 319 411-1 -> política NCP para los certificados de la parte usuaria, sustituida por las dos siguientes (CIR (UE) 2025/848)
ETSI TS 119 411-8 -> política de certificados de acceso de las partes usuarias de la cartera (CIR (UE) 2026/1730, modifica 2025/848)
ETSI TS 119 475 -> certificados de registro y atributos de las partes usuarias (CIR (UE) 2026/1730, modifica 2025/848; 2026/1731)

Tabla-resumen: acto → normas ETSI/CEN

Acto de ejecución	Normas ETSI / CEN citadas
CIR (UE) 2024/2979 [ES · EN]	EN 319 122-1; EN 319 132-1; EN 319 142-1; TS 119 182-1; EN 319 162-1/-2
CIR (UE) 2024/2981 [ES · EN]	CEN EN 17640 (+ EN ISO/IEC 17065, 17067, 17021-1, 17025, 17020, 17029, 15408-3, 27001, 30111; ISO/IEC 17000)
CIR (UE) 2025/848 [ES · EN]	EN 319 411-1 (NCP), sustituida por TS 119 411-8 y TS 119 475 (CIR 2026/1730)
CIR (UE) 2025/1566 [ES · EN]	TS 119 461; EN 319 401
CIR (UE) 2025/1567 [ES · EN]	TS 119 431-1; EN 319 401
CIR (UE) 2025/1569 [ES · EN]	EN 319 401
CIR (UE) 2025/1929 [ES · EN]	EN 319 421; EN 319 422; EN 319 401
CIR (UE) 2025/1942 [ES · EN]	TS 119 441; EN 319 102-1; TS 119 102-2; TS 119 172-1/-4; TS 119 101; EN 319 401; EN 319 411-1; TS 119 612
CIR (UE) 2025/1943 [ES · EN]	EN 319 401; EN 319 411-1; EN 319 411-2; EN 319 412-1/-2/-3/-5; CEN/TS 419261:2015
CIR (UE) 2025/1944 [ES · EN]	EN 319 521; EN 319 522 (1-4); EN 319 411-1; EN 319 401
CIR (UE) 2025/1945 [ES · EN]	EN 319 102-1; TS 119 102-2; TS 119 172-1/-4; TS 119 101; TS 119 612
CIR (UE) 2025/1946 [ES · EN]	TS 119 511; EN 319 102-1; TS 119 172-1/-4; TS 119 101; TS 119 612; EN 319 401
CIR (UE) 2025/2160 [ES · EN]	EN 319 401
CIR (UE) 2025/2162 [ES · EN]	EN 319 403-1; TS 119 612; EN 319 401; EN 319 411-1/-2; EN 319 412-1/-2/-3/-4/-5; TS 119 411-5; TS 119 495; TS 119 461; TS 119 441; TS 119 442; EN 319 102-1; TS 119 102-2; TS 119 172-4; TS 119 511; TS 119 512; EN 319 421; EN 319 422; EN 319 521; EN 319 522; EN 319 531; EN 319 532; TS 119 431-1; TS 119 471; EN 319 122-1; EN 319 132-1; TS 119 182-1; CEN/TS 18170; EN 301 549 (+ EN ISO/IEC 17011, 17065, 17067, 17021-1, 17025, 17020; ISO 14641; ISO 14721; ISO 23257; ISO/TS 23635)
CIR (UE) 2025/2164 (Dec.) [ES · EN]	TS 119 612; EN 319 412-5
CIR (UE) 2025/2527 [ES · EN]	EN 319 411-2; TS 119 411-5; TS 119 495
CIR (UE) 2025/2531 [ES · EN]	EN 319 401; EN 319 122-1; EN 319 132-1; TS 119 182-1 (+ ISO 23257; ISO/TS 23635)
CIR (UE) 2025/2532 [ES · EN]	EN 319 401; EN 319 421; CEN/TS 18170:2025 (+ ISO 14721)
CIR (UE) 2026/248 [ES · EN]	EN 319 122-1; EN 319 132-1; EN 319 142-1; TS 119 182-1; EN 319 162-1/-2; TS 103 171/172/173/174 (legado)
CIR (UE) 2026/798 [ES · EN]	TS 119 461; EN 319 401
CIR (UE) 2026/1730 [ES · EN]	TS 119 411-8; TS 119 475
CIR (UE) 2026/1731 [ES · EN]	TS 119 472-1/-2/-3; TS 119 475; TS 119 412-6; EN 319 412-1/-2/-3/-5; EN 319 142-1; TS 119 432
CIR (UE) 2026/1735 [ES · EN]	TS 119 471; TS 119 478; EN 319 401

No figuran en la tabla los actos que no citan normas ETSI/CEN por número (remiten a ISO/IEC, al ARF o a otros actos): 2024/2977, 2024/2980, 2024/2982, 2025/846, 2025/847, 2025/849, 2025/1568, 2025/1570, 2025/1571, 2025/1572 y 2025/2530 (paraguas). Los actos núcleo de la cartera citan normas ETSI a través de su modificación por el CIR (UE) 2026/1731.

Enlaces oficiales (DOUE) a los actos posteriores a febrero de 2026

CIR (UE) 2026/248 (formatos de firma/sello para el sector público): [ES · EN]
CIR (UE) 2026/798 (alta remota en la cartera, nivel «alto»): [ES · EN]
CIR (UE) 2026/1730 (registro de partes usuarias, transparencia y certificados): [ES · EN]
CIR (UE) 2026/1731 (actos núcleo de la cartera, alineación con ARF v3.0.0): [ES · EN]
CIR (UE) 2026/1735 (declaraciones de atributos; firma/sellado de resultados de verificación): [ES · EN]

Nota metodológica y cautelas

Las referencias de norma y su asignación a cada Reglamento están tomadas del texto de cada acto en EUR-Lex, revisado de nuevo en octubre de 2026.

Aspectos a los que prestar atención: primero, cada Reglamento fija una versión y fecha concretas de la norma (por ejemplo, EN 319 401 v3.1.1 (2024-06), o TS 119 461 v2.1.1 (2025-02)); conviene cotejar esos sufijos contra el anexo del DOUE antes de usarlos en un pliego o auditoría. Segundo, las comprobaciones que quedaron abiertas en agosto ya están resueltas: el CIR 2025/1567 solo cita la TS 119 431-1; la TS 119 432 aparece en el CIR 2026/1731, como interfaz de firma de la cartera; y la TS 119 512 no está en el CIR 2025/1946, sino en el anexo II del CIR 2025/2162. Las versiones citadas en el CIR 2026/1735 son la TS 119 471 V1.1.1 (2025-05) y la TS 119 478 V1.1.1 (2026-01). Tercero, algunas referencias aparecen con erratas en el DOUE: «EN 3191 22-1» (CAdES, CIR 2024/2979) y, en el anexo II del CIR 2025/2162, «EN 310 401», «TS 301 549», «EN 119 511» y «EN 319 182-1».

Como es habitual, iré actualizando esta información a medida que se publiquen nuevos actos de ejecución o correcciones de errores en el DOUE.

Servicios Profesionales de EADTrust

La recopilación y el análisis de esta información se enmarcan en los Servicios Profesionales de EADTrust (European Agency of Digital Trust). Si tu organización -> administración pública o empresa -> está valorando proyectos de adaptación a las carteras de identidad digital (EUDI Wallet) o de desarrollo del ecosistema eIDAS2, en EADTrust podemos acompañarte en el análisis normativo, el diseño y la implantación.

Contacta con nosotros por correo electrónico en info@eadtrust.com o por teléfono en el [+34 917160555]. Más información en eadtrust.com.

The eIDAS2 implementing acts, up to date and the ETSI and CEN standards they cite

Update (October 2026): after reviewing the text of every act on EUR-Lex again, I have corrected and expanded the list of standards. The main changes: CIR (EU) 2026/1730 and 2026/1731 do cite ETSI standards (TS 119 411-8, TS 119 475, TS 119 472-1/-2/-3, TS 119 412-6 and TS 119 432, among others); Annex II to CIR (EU) 2025/2162 lists the reference standards for assessing each qualified service; and the description of ETSI TS 119 478 was wrong (it covers interfaces related to authentic sources). The full catalogue, including ISO standards, with title, translation and summary of each, is in the post «Estándares publicados en el desarrollo de la Cartera de Identidad Digital Europea y del resto de aspectos cubiertos por #EIDAS2». (Standards published for the European Digital Identity Wallet and the other areas covered by #EIDAS2 – in Spanish)».

An update to the posts «Complete list of implementing acts accompanying #EIDAS2» (2 February 2026) and «European Digital Identity Wallet: Architecture and Reference Framework (ARF v2.8.0)» (12 May 2026), where I already listed the implementing acts.

In those posts I listed the eIDAS2 implementing acts (Regulation (EU) 2024/1183, amending Regulation (EU) 910/2014) as they were adopted. This update closes the list with what has appeared since, and adds the mapping between each Implementing Regulation and the ETSI and CEN technical standards that make it operational, indicating in parentheses, next to each standard, the Regulation that cites it. Each act links to the OJEU text in Spanish (ES) and English (EN).

Acronyms: EAA = electronic attestation of attributes; QEAA = qualified electronic attestation of attributes.

What has changed since the last list

The most recent items are a trio of amending regulations from July 2026 (adopted 15 July, published 22 July), which update existing acts rather than creating new subject matter: CIR (EU) 2026/1730 (more transparency in the relying-party register and new standards for its access and registration certificates, ETSI TS 119 411-8 and TS 119 475; amends 2025/848), CIR (EU) 2026/1731 (aligns the four core wallet acts with ARF v3.0.0, superseding v2.8.0, and brings in ETSI TS 119 472-1/-2/-3, TS 119 412-6 and TS 119 432) and CIR (EU) 2026/1735 (requires signing or sealing verification results against authentic sources and refers to ETSI TS 119 471 and TS 119 478). Before that trio, the two 2026 acts were CIR (EU) 2026/798 (remote wallet onboarding to the «high» level) and CIR (EU) 2026/248 (AdES formats for the public sector, successor of Decision 2015/1506). As of this post (August 2026), the 2026/1730-1731-1735 trio is the most recent published.

Complete, updated list of implementing acts

Wallet batch (EUDI Wallet) -> November 2024

CIR (EU) 2024/2977 -> person identification data (PID) and electronic attestations of attributes issued to the wallet. [ES · EN]
CIR (EU) 2024/2979 -> integrity and core functionalities of the wallet. [ES · EN]
CIR (EU) 2024/2980 -> notifications to the Commission on the wallet ecosystem. [ES · EN]
CIR (EU) 2024/2981 -> certification of the wallets. [ES · EN]
CIR (EU) 2024/2982 -> protocols and interfaces of the EU digital identity framework. [ES · EN]

Wallet and relying-party batch -> May 2025

CIR (EU) 2025/846 -> cross-border identity matching of natural persons. [ES · EN]
CIR (EU) 2025/847 -> reactions to wallet security breaches. [ES · EN]
CIR (EU) 2025/848 -> registration of relying parties (incl. relying-party access certificates). [ES · EN]
CIR (EU) 2025/849 -> list of certified wallets. [ES · EN]

Identity and trust services -> 29 July 2025

CIR (EU) 2025/1566 -> verification of the applicant’s identity and attributes (identity proofing). [ES · EN]
CIR (EU) 2025/1567 -> remote management of signature/seal creation devices (cloud signing/sealing). [ES · EN]
CIR (EU) 2025/1568 -> peer reviews of eID schemes (repeals Decision (EU) 2015/296). [ES · EN]
CIR (EU) 2025/1569 -> qualified and public-sector electronic attestations of attributes. [ES · EN]
CIR (EU) 2025/1570 -> notification of information on certified QSCDs and seal creation devices. [ES · EN]
CIR (EU) 2025/1571 -> formats and procedures for supervisory bodies’ annual reports. [ES · EN]
CIR (EU) 2025/1572 -> notification of intention and verification for initiating qualified trust services. [ES · EN]

Trust services -> 29 September 2025

CIR (EU) 2025/1929 -> qualified electronic time stamps. [ES · EN]
CIR (EU) 2025/1942 -> qualified validation services for QES and qualified seals. [ES · EN]
CIR (EU) 2025/1943 -> qualified certificates for electronic signatures and seals. [ES · EN]
CIR (EU) 2025/1944 -> qualified electronic registered delivery services (QERDS). [ES · EN]
CIR (EU) 2025/1945 -> validation of QES/qualified seals and of AdES based on qualified certificates. [ES · EN]
CIR (EU) 2025/1946 -> qualified preservation services for electronic signatures and seals. [ES · EN]

Governance and non-qualified services -> October 2025

CIR (EU) 2025/2160 -> risk management for non-qualified trust services. [ES · EN]
CIR (EU) 2025/2162 -> accreditation of conformity assessment bodies (its Annex II lists the reference standards for assessing each qualified service). [ES · EN]
CIR (EU) 2025/2164 (Decision) -> trusted list: version of the standard for the common template (amends Implementing Decision (EU) 2015/1505). [ES · EN]

Trust services -> 16 December 2025

CIR (EU) 2025/2527 -> qualified website authentication certificates (QWAC). [ES · EN]
CIR (EU) 2025/2530 -> requirements for qualified trust service providers (umbrella act). [ES · EN]
CIR (EU) 2025/2531 -> qualified electronic ledgers. [ES · EN]
CIR (EU) 2025/2532 -> qualified electronic archiving services. [ES · EN]

2026 -> most recent

CIR (EU) 2026/248 -> formats of advanced electronic signatures and seals recognised by public-sector bodies (repeals Decision (EU) 2015/1506). [ES · EN]
CIR (EU) 2026/798 -> remote wallet onboarding, raising assurance from «substantial» to «high». [ES · EN]
CIR (EU) 2026/1730 -> amends CIR (EU) 2025/848 (relying-party register): more transparency (privacy-policy URL) and new standards for access and registration certificates (ETSI TS 119 411-8 and TS 119 475). [ES · EN]
CIR (EU) 2026/1731 -> amends the core wallet acts (2024/2977, 2024/2979, 2024/2980, 2024/2982) to align them with ARF v3.0.0 and brings in the ETSI TS 119 472 specifications (EAA and PID profiles, presentation and issuance). [ES · EN]
CIR (EU) 2026/1735 -> amends CIR (EU) 2025/1569 (attestations of attributes): signing/sealing of verification results against authentic sources. [ES · EN]

ETSI and CEN standards, with the Regulation that cites each

In parentheses, after each standard, is the Implementing Regulation that mentions it; where cited in several acts, all are listed. Some ISO standards are also included where they are cited alongside ETSI and CEN ones.

Horizontal requirement for every provider

ETSI EN 319 401 -> General Policy Requirements for Trust Service Providers (CIR (EU) 2025/1566; 2025/1567; 2025/1569; 2025/1929; 2025/1942; 2025/1943; 2025/1944; 2025/1946; 2025/2160; 2025/2162; 2025/2531; 2025/2532; 2026/798; 2026/1735 (V3.2.1))

Qualified certificates

ETSI EN 319 411-1 -> Requirements for TSPs issuing certificates; Part 1, general (CIR (EU) 2025/1942; 2025/1943; 2025/1944; 2025/2162; 2025/848, replaced through 2026/1730)
ETSI EN 319 411-2 -> Part 2, EU qualified certificates (CIR (EU) 2025/1943; 2025/2162; 2025/2527)
ETSI EN 319 412-1/-2/-3/-5 -> certificate profiles and QCStatements (CIR (EU) 2025/1943; 2025/2162; 2026/1731; Part 5 also CID 2025/2164)
ETSI EN 319 412-4 -> web site certificate profile (CIR (EU) 2025/2162)
CEN/TS 419261:2015 -> trustworthy systems managing certificates and time stamps (CIR (EU) 2025/1943)

Website authentication certificates (QWAC)

ETSI TS 119 411-5 -> coexistence of QWACs with publicly-trusted website certificates (CIR (EU) 2025/2162; 2025/2527)
ETSI TS 119 495 -> PSD2 / open-banking sectoral profile (CIR (EU) 2025/2162; 2025/2527)

Signature/seal formats (AdES) and containers

ETSI EN 319 122-1 -> CAdES (CIR (EU) 2024/2979; 2025/2162; 2025/2531; 2026/248)
ETSI EN 319 132-1 -> XAdES (CIR (EU) 2024/2979; 2025/2162; 2025/2531; 2026/248)
ETSI EN 319 142-1 -> PAdES, mandatory wallet format (CIR (EU) 2024/2979, updated to V1.2.1 by 2026/1731; 2026/248)
ETSI TS 119 182-1 -> JAdES (CIR (EU) 2024/2979; 2025/2162; 2025/2531; 2026/248)
ETSI EN 319 162-1/-2 -> ASiC (associated signature containers) (CIR (EU) 2024/2979; 2026/248)
ETSI TS 103 171 / 172 / 173 / 174 -> legacy XAdES/PAdES/CAdES/ASiC profiles, still accepted (CIR (EU) 2026/248, Annex II)

Wallet: attestations of attributes, protocols and signing

ETSI TS 119 472-1 -> EAA profiles: general requirements (SD-JWT VC and ISO mdoc) (CIR (EU) 2026/1731, Annex II to 2024/2979)
ETSI TS 119 472-2 -> profiles for EAA/PID presentation to relying parties (OpenID4VP) (CIR (EU) 2026/1731, Annex II to 2024/2982)
ETSI TS 119 472-3 -> profiles for EAA/PID issuance (OpenID4VCI) (CIR (EU) 2026/1731, Annex I to 2024/2982 and Annex III to 2024/2979)
ETSI TS 119 412-6 -> certificate profiles for PID, wallet, EAA, QEAA and public-sector EAA providers (CIR (EU) 2026/1731, Annex II to 2024/2979)
ETSI TS 119 432 -> remote signature creation protocols, wallet signing interface (CIR (EU) 2026/1731, Annex IV to 2024/2979)

Qualified time stamps

ETSI EN 319 421 -> policy for TSPs issuing time stamps (CIR (EU) 2025/1929; 2025/2162; 2025/2532)
ETSI EN 319 422 -> time-stamping protocol and token profile (CIR (EU) 2025/1929; 2025/2162)

Validation of signatures and seals

ETSI EN 319 102-1 -> AdES creation and validation; Part 1 (CIR (EU) 2025/1942; 2025/1945; 2025/1946; 2025/2162)
ETSI TS 119 102-2 -> signature validation report (CIR (EU) 2025/1942; 2025/1945; 2025/2162)
ETSI TS 119 441 -> validation service policy (CIR (EU) 2025/1942; 2025/2162)
ETSI TS 119 442 -> protocol profiles for validation services (CIR (EU) 2025/2162)
ETSI TS 119 172-1/-4 -> signature policies (CIR (EU) 2025/1942; 2025/1945; 2025/1946; Part 4 also 2025/2162)
ETSI TS 119 101 -> signature creation/validation applications (CIR (EU) 2025/1942; 2025/1945; 2025/1946)
ETSI TS 119 612 -> Trusted Lists (CIR (EU) 2025/1942; 2025/1945; 2025/1946; 2025/2162; CID 2025/2164)

Remote signature/seal device management

ETSI TS 119 431-1 -> TSP component operating the remote signature creation device (CIR (EU) 2025/1567; 2025/2162)

Identity verification and remote onboarding

ETSI TS 119 461 -> identity proofing of trust-service subjects (CIR (EU) 2025/1566; 2025/2162; 2026/798)

Electronic attestations of attributes

ETSI TS 119 471 -> policy and security requirements for EAA providers (CIR (EU) 2025/2162; 2026/1735, amends 2025/1569)
ETSI TS 119 478 -> interfaces related to authentic sources (CIR (EU) 2026/1735, amends 2025/1569)

Qualified electronic registered delivery (QERDS)

ETSI EN 319 521 -> ERDS provider requirements (CIR (EU) 2025/1944; 2025/2162)
ETSI EN 319 522 (parts 1-4) -> framework, contents, formats and bindings (CIR (EU) 2025/1944; 2025/2162)
ETSI EN 319 531 and EN 319 532 -> registered electronic mail (REM) (CIR (EU) 2025/2162)

Preservation

ETSI TS 119 511 -> long-term preservation of signatures and data (CIR (EU) 2025/1946; 2025/2162)
ETSI TS 119 512 -> preservation service protocols (CIR (EU) 2025/2162)

Electronic ledgers

ETSI EN 319 122-1, EN 319 132-1, TS 119 182-1 -> CAdES/XAdES/JAdES profiles, with adaptations (CIR (EU) 2025/2531; 2025/2162)
ISO 23257:2022 and ISO/TS 23635:2022 -> DLT reference architecture and governance (CIR (EU) 2025/2531; 2025/2162)

Electronic archiving

ETSI EN 319 421 -> time stamps applied by the archiving service (CIR (EU) 2025/2532)
CEN/TS 18170:2025 -> electronic archiving, with adaptations (CIR (EU) 2025/2532; 2025/2162, also for ledgers)
ISO 14721:2025 (OAIS) and ISO 14641 -> archival reference model and electronic document preservation systems (CIR (EU) 2025/2532 (ISO 14721); 2025/2162 (both))

Conformity assessment and accessibility

ETSI EN 319 403-1 -> requirements for conformity assessment bodies assessing TSPs (CIR (EU) 2025/2162)
ETSI EN 301 549 -> accessibility requirements for ICT products and services (CIR (EU) 2025/2162)

Wallet and cybersecurity certification

CEN EN 17640 -> fixed-time cybersecurity evaluation methodology (with EN ISO/IEC 17065:2012, 17067:2013, 17021-1:2015, 17025:2017, 17020:2012 and 17029:2019, ISO/IEC 17000:2020, EN ISO/IEC 15408-3:2022, 27001:2022 and 30111:2019) (CIR (EU) 2024/2981)

Relying-party access and registration certificates

ETSI EN 319 411-1 -> NCP policy for relying-party certificates, replaced by the two below (CIR (EU) 2025/848)
ETSI TS 119 411-8 -> access certificate policy for wallet relying parties (CIR (EU) 2026/1730, amends 2025/848)
ETSI TS 119 475 -> relying-party registration certificates and attributes (CIR (EU) 2026/1730, amends 2025/848; 2026/1731)

Summary table: act → ETSI/CEN standards

IMPLEMENTING ACT	ETSI / CEN STANDARDS CITED
CIR (EU) 2024/2979 [ES · EN]	EN 319 122-1; EN 319 132-1; EN 319 142-1; TS 119 182-1; EN 319 162-1/-2
CIR (EU) 2024/2981 [ES · EN]	CEN EN 17640 (+ EN ISO/IEC 17065, 17067, 17021-1, 17025, 17020, 17029, 15408-3, 27001, 30111; ISO/IEC 17000)
CIR (EU) 2025/848 [ES · EN]	EN 319 411-1 (NCP), replaced by TS 119 411-8 and TS 119 475 (CIR 2026/1730)
CIR (EU) 2025/1566 [ES · EN]	TS 119 461; EN 319 401
CIR (EU) 2025/1567 [ES · EN]	TS 119 431-1; EN 319 401
CIR (EU) 2025/1569 [ES · EN]	EN 319 401
CIR (EU) 2025/1929 [ES · EN]	EN 319 421; EN 319 422; EN 319 401
CIR (EU) 2025/1942 [ES · EN]	TS 119 441; EN 319 102-1; TS 119 102-2; TS 119 172-1/-4; TS 119 101; EN 319 401; EN 319 411-1; TS 119 612
CIR (EU) 2025/1943 [ES · EN]	EN 319 401; EN 319 411-1; EN 319 411-2; EN 319 412-1/-2/-3/-5; CEN/TS 419261:2015
CIR (EU) 2025/1944 [ES · EN]	EN 319 521; EN 319 522 (1-4); EN 319 411-1; EN 319 401
CIR (EU) 2025/1945 [ES · EN]	EN 319 102-1; TS 119 102-2; TS 119 172-1/-4; TS 119 101; TS 119 612
CIR (EU) 2025/1946 [ES · EN]	TS 119 511; EN 319 102-1; TS 119 172-1/-4; TS 119 101; TS 119 612; EN 319 401
CIR (EU) 2025/2160 [ES · EN]	EN 319 401
CIR (EU) 2025/2162 [ES · EN]	EN 319 403-1; TS 119 612; EN 319 401; EN 319 411-1/-2; EN 319 412-1/-2/-3/-4/-5; TS 119 411-5; TS 119 495; TS 119 461; TS 119 441; TS 119 442; EN 319 102-1; TS 119 102-2; TS 119 172-4; TS 119 511; TS 119 512; EN 319 421; EN 319 422; EN 319 521; EN 319 522; EN 319 531; EN 319 532; TS 119 431-1; TS 119 471; EN 319 122-1; EN 319 132-1; TS 119 182-1; CEN/TS 18170; EN 301 549 (+ EN ISO/IEC 17011, 17065, 17067, 17021-1, 17025, 17020; ISO 14641; ISO 14721; ISO 23257; ISO/TS 23635)
CIR (EU) 2025/2164 (Dec.) [ES · EN]	TS 119 612; EN 319 412-5
CIR (EU) 2025/2527 [ES · EN]	EN 319 411-2; TS 119 411-5; TS 119 495
CIR (EU) 2025/2531 [ES · EN]	EN 319 401; EN 319 122-1; EN 319 132-1; TS 119 182-1 (+ ISO 23257; ISO/TS 23635)
CIR (EU) 2025/2532 [ES · EN]	EN 319 401; EN 319 421; CEN/TS 18170:2025 (+ ISO 14721)
CIR (EU) 2026/248 [ES · EN]	EN 319 122-1; EN 319 132-1; EN 319 142-1; TS 119 182-1; EN 319 162-1/-2; TS 103 171/172/173/174 (legacy)
CIR (EU) 2026/798 [ES · EN]	TS 119 461; EN 319 401
CIR (EU) 2026/1730 [ES · EN]	TS 119 411-8; TS 119 475
CIR (EU) 2026/1731 [ES · EN]	TS 119 472-1/-2/-3; TS 119 475; TS 119 412-6; EN 319 412-1/-2/-3/-5; EN 319 142-1; TS 119 432
CIR (EU) 2026/1735 [ES · EN]	TS 119 471; TS 119 478; EN 319 401

Acts that do not cite ETSI/CEN standards by number (they refer to ISO/IEC, the ARF or other acts) are omitted from the table: 2024/2977, 2024/2980, 2024/2982, 2025/846, 2025/847, 2025/849, 2025/1568, 2025/1570, 2025/1571, 2025/1572 and 2025/2530 (umbrella). The core wallet acts cite ETSI standards through their amendment by CIR (EU) 2026/1731.

Official OJEU links to the post-February 2026 acts

CIR (EU) 2026/248 (AdES formats for the public sector): [ES · EN]
CIR (EU) 2026/798 (remote wallet onboarding, «high» level): [ES · EN]
CIR (EU) 2026/1730 (relying-party register, transparency and certificates): [ES · EN]
CIR (EU) 2026/1731 (core wallet acts, ARF v3.0.0 alignment): [ES · EN]
CIR (EU) 2026/1735 (attestations of attributes; signing of verification results): [ES · EN]

Methodological note and caveats

Standard references and their assignment to each Regulation are taken from each act’s text on EUR-Lex, reviewed again in October 2026.

Points to watch: first, each Regulation pins a specific version and date of the standard (e.g. EN 319 401 v3.1.1 (2024-06), or TS 119 461 v2.1.1 (2025-02)); check those suffixes against the OJEU annex before use in a tender or audit. Second, the checks left open in August are now resolved: CIR 2025/1567 only cites TS 119 431-1; TS 119 432 appears in CIR 2026/1731 as the wallet signing interface; and TS 119 512 is not in CIR 2025/1946 but in Annex II to CIR 2025/2162. The versions cited in CIR 2026/1735 are TS 119 471 V1.1.1 (2025-05) and TS 119 478 V1.1.1 (2026-01). Third, some references contain typos in the OJEU: «EN 3191 22-1» (CAdES, CIR 2024/2979) and, in Annex II to CIR 2025/2162, «EN 310 401», «TS 301 549», «EN 119 511» and «EN 319 182-1».

As usual, I will update this post as new acts or corrigenda are published in the OJEU.

EADTrust Professional Services

The compilation and analysis of this information are part of EADTrust’s Professional Services (European Agency of Digital Trust). If your organisation —public administration or company— is considering projects to adapt to digital identity wallets (EUDI Wallet) or to build out the eIDAS2 ecosystem, EADTrust can support you with the regulatory analysis, design and implementation.