Archivo de la categoría: Terceros de confianza

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


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:

TipoEmisorVerificación contra fuente auténticaValor jurídico
Declaración electrónica de atributos DEA (EAA) — no cualificadaCualquier prestador de servicios (no necesariamente cualificado)No exigida por el ReglamentoPrincipio 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 auditadoCuando el atributo figura en el Anexo VI, verificación contra la fuente auténtica correspondienteEfecto 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énticaEfecto 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.

From qualified preservation of electronic signatures and seals to qualified chronological-order archiving services (qDLT)


On 14 September 2026 I took part, in Tallinn (Estonia), in the ETSI ESI Certification Authority (CA) Open Session. I went as an attendee, but by the end of the afternoon I ended up on the panel as a speaker.

The slot had been planned for Steffen Schwalm, who in the end could not attend, and I was asked to step in to talk about how the standardisation of distributed ledger technologies (DLT) is evolving and, in particular, about what we are beginning to call qDLT: the qualified distributed ledger.

I was glad to accept, although (given the short time available to think about what to say) I told my own ideas, not those of the announced speaker.

And in this summary I set out those ideas about what is happening in the standardisation of DLTs: not so much a technological revolution arriving from outside to reinvent digital trust, but a very coherent evolution of something we have been building in Europe for almost a decade. The line of reasoning runs from the preservation of qualified signatures and seals to the ordering of archived files with respect to the moment their custody was requested from the Trust Service Provider. This is how I see it.

The starting point: preserving qualified electronic signatures and seals

The first piece is the one that has been standardised longest, and the one we sometimes forget to mention when we talk about blockchain as if it were virgin territory. Under the umbrella of the first eIDAS, ETSI developed the standard TS 119 511 (the one we usually cite simply as «511») which sets the policy and security requirements for providers offering long-term preservation of electronic signatures (or of data in general) using digital-signature techniques. Its companion, TS 119 512, defines the protocols for interoperating with those preservation services. This first variant (the qualified preservation of qualified electronic signatures and qualified electronic seals) already has its own implementing act: Commission Implementing Regulation (EU) 2025/1946, adopted on the basis of Articles 34(2) and 40 of the eIDAS Regulation. It is worth noting that these are original eIDAS articles, plain numbers, with none of the letter suffixes (Article 45a, 45b, 45c…) that English-language EU legislation uses to mark the provisions eIDAS2 kept inserting; its annex points to ETSI TS 119 511 (together with TS 119 172-4) as the reference standard.

The problem 511 solves is subtle but enormous: an electronic signature is valid today because the certificate backing it is still in force, because the cryptographic algorithms used are considered robust, and because there is an infrastructure that confirms it. But time erodes all of that. Certificates expire, authorities change, and (increasingly relevant ) algorithms age. A qualified preservation service keeps the evidence alive: it periodically reasserts integrity and validity through new time stamps or preservation techniques (such as chained hashes) and new layers of cryptographic protection, so that twenty years from now one can still prove that the document was signed and has not been altered.

This is worth pausing on, because it is exactly the ground where crypto-agility and post-quantum cryptography stop being an academic debate. Preserving for the long term means, by definition, surviving the moment when today’s algorithms cease to be trustworthy. A good preservation service is, at heart, a machine designed to migrate algorithms without losing the evidentiary thread. Whoever understands 511 already understands half of why the rest of this story matters.

The second step: qualified electronic archiving

The second eIDAS (Regulation (EU) 2024/1183) threw nothing away. It broadened. Among the new qualified trust services appears qualified electronic archiving, abbreviated in English jargon as q-earchiving, which in the European standardisation work relies on the technical specification CEN/TS 18170. Its implementing act is Commission Implementing Regulation (EU) 2025/2532, of 16 December 2025, adopted on the basis of Article 45j(2) of the Regulation (the provision eIDAS2 added for qualified electronic archiving) whose annex points precisely to CEN/TS 18170:2025 as the reference standard.

The difference with signature preservation is one of scope. 511 focuses on maintaining the validity of the cryptographic evidence of a signed document. Qualified archiving goes a step further and deals with the document as an object that must be kept intact, legible and available over time, whether signed or not, including the guarantee of its integrity, the traceability of access, and retention policies. It is the regulatory translation of a very old need — the archive — into the language of qualified trust services. For the first time, a provider can offer archiving with the same level of legal assurance already enjoyed by the signature, the seal or the time stamp.

And it is worth clearing up a common misunderstanding: archiving does not replace signature preservation, it relies on it. 511 remains the piece that guarantees the survival of the signature evidence, so a qualified electronic archiving provider can use the services of a preservation provider for that part, turning to a 511 service to keep alive the signatures and seals of the documents it holds. These are not competing services but complementary ones: archiving orchestrates the custody of the file and delegates to preservation the long-term care of the cryptographic evidence. It is exactly the layered logic that runs through this whole article.

There is also a second function of archiving worth highlighting, because it often goes unnoticed: format conversion. Keeping a document for decades is not only about its bits not changing; it is about it remaining legible. And formats age too. A file format that is universal today may become obsolete and fall out of use in favour of others, and when that happens the archiving service must be able to convert the document to the new format while preserving its content, its faithful rendering and its evidentiary value. It is, in the realm of formats, the exact parallel of what preservation does in the realm of algorithms: just as a 511 service migrates cryptographic algorithms before they cease to be trustworthy, an archiving service migrates formats before they cease to be openable. Future legibility of the data and future robustness of the cryptography are two sides of the same promise: that twenty years from now the document will not only exist, but can be opened and proven.

If preservation protects the signature, archiving protects the file. And the next step is to ask what happens when what we need to protect is not an isolated document, but the relationship among many facts over time.

The third step: temporal ordering

Here comes the most interesting novelty of the second eIDAS: electronic ledgers as a new qualified trust service. The reference specification is CEN/TS 18264, published in 2025.

And its implementing act, from the same December 2025 batch, is Commission Implementing Regulation (EU) 2025/2531, adopted on the basis of Article 45l(3) of the Regulation (the provision eIDAS2 devoted to qualified electronic ledgers).

I prefer to explain it with a simple idea: an electronic ledger is a chronologically ordered archive. It does not merely store data entries; it guarantees their temporal sequence in such a way that none can be inserted, deleted or reordered without it showing. It is, if you like, time-stamping raised to the level of a structure: we do not mark a single document with a date, but build a chain of events whose ordering is itself the proof.

And once we accept that what adds value is the guaranteed chronological ordering, the technical question that gives the session its name arises: how is that order built? And there are two legitimate answers.

The first is to use a centralised infrastructure: a single qualified provider maintains the ledger, seals it and is accountable for its integrity. It is simple to audit and fits perfectly into the qualified-provider model we already know.

The second is to use an infrastructure of interconnected nodes that replicate the information (sometimes called a distributed infrastructure): the chronological order is built through the connection of nodes that agree among themselves (through governance rules) on the sequence of entries. This is where distributed ledger technology (DLT) comes into play — not as a fashion, but as a concrete way of achieving that ordering without depending on a single point. When that distributed ledger is provided with the guarantees of a qualified trust service, we speak of qDLT: a qualified distributed ledger.

Allow me a terminological note here that I have been making for some time. The Regulation has enshrined the term DLT (Distributed Ledger Technology), and I stick to it for regulatory rigour. But, if we were to name the idea precisely, I would rather speak of RJT (Replicated Journal Technology). The reason is accounting: in double-entry bookkeeping, the chronological order of events is not kept in the ledger (the general ledger, which groups entries by account) but in the journal (the day book, which records them one after another as they happen). And since what we are preserving here is precisely the temporal sequence, the fitting name for this technology should point to the replicated journal rather than to the distributed ledger. It is, most likely, a terminological battle already lost against the official text, but no less accurate for that.

A good European example of this approach is EBSI, the European Blockchain Services Infrastructure, today governed through the figure of the Europeum-EDIC (a European digital-infrastructure consortium). EBSI shows that the distributed model is not incompatible with qualified trust: the nodes can be operated by identified administrations and providers, with governmental trust anchors, so that the result combines the resilience of distribution with the legal accountability that the eIDAS framework demands.

And it is worth noting a detail of Commission Implementing Regulation (EU) 2025/2531, because it captures this duality precisely. The implementing act requires all providers of qualified electronic ledgers to comply with the standard ETSI EN 319 401 (general policy requirements for trust service providers) and adds specific requirements for the distributed variant: when the ledger is built through nodes, the provider must also comply with ISO 23257:2022 (reference architecture for distributed ledger technologies) and ISO/TS 23635:2022 (governance guidelines). In other words, it is the implementing act itself that recognises the two variants and reserves the DLT consensus and governance standards for the distributed case, which is when we speak, properly, of qDLT. Regulation, once again, does not impose a technology: it describes guarantees and leaves the way of achieving them open.

It is worth underlining the regulatory continuity: from preservation (511) we move to qualified archiving (18170), and from there to chronological ledger, or qDLT (18264). These are not three worlds but three layers of a single idea that keeps gaining ambition: first, keeping an electronic signature fully effective; then, holding a document (signed or not) while guaranteeing its future recovery; and finally, ordering and relating the facts in a verifiable way, when that order can produce legal effects.

What a chronological ledger makes possible

The part I find most interesting (and to which I devoted much of my intervention) is not the ledger technology itself, but the functionalities it enables when we register not only the document but also its context: who its owner is, what rights it embodies and how it evolves. A well-designed chronological ledger opens the door to three capabilities that until now were hard to bring into the digital world with full guarantees.

The first is transferability (or endorsability). If the ledger records not only that a document exists, but also who its holder is, then it can equally record the transfer of that ownership. This is what allows an electronic file to be treated as an asset that changes hands: think of commercial paper, of documents of title to goods, or of any right that was traditionally «endorsed» on paper. The chronological ledger turns the chain of endorsements into a verifiable sequence of entries.

The second is obliterability (or cancellability). A right is not only transferred: it is also consumed. If a file represents a cinema ticket or admission to a show, we need to be able to mark that the right has already been exercised, so that it cannot be used twice. The ledger does not delete the entry (the evidence remains) but records indelibly its change of state: issued, transferred, consumed. It is the difference between crossing out and throwing away: the fact that a right has been exhausted is, in itself, a fact worth recording. The postmark is a good example.

The third is completeness, which I like to describe as an electronic staple. A document rarely travels alone. A contract carries annexes; a deed carries endorsements; an agreement evolves through successive versions. Think of contractual novations, in which the parties agree to modify the clauses: what matters legally is not only the latest text, but the complete relationship between the original document, its annexes and each of its evolutions. Completeness consists of keeping the document and everything that accompanies it (notes, annexes and their own versions) verifiably bound together, so that the whole is preserved as an indivisible and traceable unit. The staple does not just hold papers together: it records the order in which they were joined.

These three functionalities share one trait: they are only possible if the ledger stores more than the document. It stores its ownership, its state and its relationships. And they are only trustworthy if that information is ordered in time in a way that cannot be tampered with. That is why the qualified chronological ledger is not a technical whim, but the substrate on which one can build services that until now were tied to paper or to closed trusted intermediaries.

A database with legal ancestry: book-entry securities and EADTrust’s Cartulario

For these three functionalities to be more than a promise, one needs to manage a database associated with the service, with very specific properties: it must record, for each archived object, who its holder is, in what state the embodied right stands (and where or against whom that right is exercised) and how it relates to other documents; and it must do so in such a way that every change is recorded in sequence and is enforceable against third parties. Anyone familiar with securities law will recognise the pattern at once, because it is exactly the one governing the representation of securities through book entries («anotaciones en cuenta» in spanish): an accounting register in which ownership, transfers, encumbrances and the extinction of rights are not documented on a physical certificate but are constituted and proven by their inscription. Transferability is, in that language, the transfer of the entry; obliterability, its cancellation; completeness, the link between the principal entry and its ancillary ones. It is no coincidence: the qualified chronological ledger and the book-entry register solve the same problem (giving certainty about the ownership and state of a right over time) with the same tool: a reliable, ordered database.

At EADTrust we have been working on this idea for a long time. Our Cartulario service was designed many years ago on precisely those premises: treating the archive not as a mere repository of files, but as a register that records ownership, state and relationships, with an eye on functionalities such as endorsability, cancellability and completeness long before the European regulatory framework captured them explicitly.

And since we are on the subject of the name: Cartulario is simply the Spanish word for a cartulary (also spelled chartulary) — in the Middle Ages, the codex in which monasteries and cathedral chapters copied and safeguarded their charters, privileges and donations so they would not be lost (it is, roughly, the great-grandfather of the notarial protocol). So, all things considered, at EADTrust we have been in this business of chronological-order archiving for several centuries before the PDF was invented; the only difference is that we have swapped the vellum for a digital server and the copyist monk for a millisecond-precision time stamp.

And to that foundation Cartulario now adds a refinement that goes straight to the heart of what we were discussing in Tallinn: millisecond-precision (1 ms) time stamps associated with every archiving request. When the proof is the ordering, temporal resolution matters: having a millisecond-precision mark on each operation makes it possible to guarantee the chronological order of entries with far greater fineness, and to resolve the sequence unambiguously even when several requests pile up within a very short interval. It is, in practice, the materialisation of that idea of a «chronologically ordered archive» from which this whole line of reasoning starts.

Why this fits with the rest of the ecosystem

I do not want to close the article without connecting this story to the broader conversation about European digital identity. The ecosystem of the European wallet (EUDI Wallet) and of electronic attestations of attributes needs solid trust anchors: places where one can verifiably record who said what, about whom and when. A qualified chronological ledger (centralised or in the form of qDLT) is precisely one of those anchors. It can join the world of identity with the legal accountability of the eIDAS framework.

And all of this still rests on the first stone I mentioned at the beginning: the ability to preserve evidence over the long term and to migrate algorithms when needed. The arrival of post-quantum cryptography does not invalidate this architecture; on the contrary, it makes it more necessary. A ledger that orders documents in time must be, by design, a ledger capable of surviving the passage of time, including the time when today’s algorithms cease to protect us or the document-encoding formats are replaced by others.

That was, in essence, my thesis in Tallinn: that DLT and qDLT do not appear out of nowhere, but are the next natural rung on a ladder that began by preserving signatures, went on to archive documents, and is now learning to order facts. Seeing it this way helps a great deal not to get lost: each new standard does not replace the previous one, it adds a layer of ambition to it.

And here is my presentation summarising this article:

Try Cartulario

If you would like to experiment with these ideas on a real service, at EADTrust we make Cartulario available to anyone who wishes to try it. Its current nature is worth stating with full transparency: today it is offered as a non-qualified trust service and is pending audit to be considered a qualified service within the eIDAS framework. This distinction is no minor nuance (it is, precisely, the line that separates a trust service from a qualified trust service), and we prefer to make it clear from the outset.

Anyone who wishes to learn about it, propose a pilot project or discuss use cases (endorsability, cancellability, completeness or millisecond-precision time-stamping) can write to us at info@eadtrust.com or call us at +34 902 365 612 / +34 91 716 05 55. More information at www.eadtrust.eu.

De la conservación cualificada de firmas y sellos a los servicios cualificados de archivo con orden cronológico (qDLT)


El pasado 14 de septiembre de 2026 participé en Tallin (Estonia) en el evento ETSI ESI Certification Authority (CA) Open Session. Al principio como asistente, pero al final de la tarde participé como panelista.

La intervención estaba prevista para Steffen Schwalm, que finalmente no pudo asistir, y me pidieron que me incorporara para hablar de cómo evoluciona la estandarización de las tecnologías de registro distribuido (DLT) y, en particular, de lo que empezamos a llamar qDLT: el registro distribuido cualificado.

Acepté encantado, aunque conté mis ideas, no las del ponente anunciado, tras el corto plazo disponible para reflexionar sobre qué contar.

Y en este resumen recojo esas ideas sobre lo que está ocurriendo en la normalización de DLTs, no tanto como una revolución tecnológica que llega de fuera para reinventar la confianza digital, sino una evolución muy coherente de algo que llevamos casi una década construyendo en Europa. La cadena de razonamiento va desde la conservación de firmas y sellos cualificados a la ordenación de archivos respecto al momento en el que se pidió su custodia al Prestador de Servicios de Confianza. Así es como lo veo:

El punto de partida: conservar firmas y sellos cualificados

La primera pieza es la que lleva más tiempo normalizada y la que a veces olvidamos citar cuando hablamos de blockchain como si fuera terreno virgen. Bajo el paraguas del primer eIDAS, ETSI desarrolló la norma TS 119 511 (la que solemos citar simplemente como «511»), que fija los requisitos de política y de seguridad para los prestadores que ofrecen conservación a largo plazo de firmas electrónicas (o de datos en general) mediante técnicas de firma digital. Su compañera, la TS 119 512, define los protocolos para interoperar con esos servicios de conservación. Esta primera variante —la conservación cualificada de firmas electrónicas cualificadas y de sellos electrónicos cualificados— cuenta ya con su propio acto de ejecución: el Reglamento de Ejecución (UE) 2025/1946, dictado al amparo de los artículos 34, apartado 2, y 40 del Reglamento EIDAS. Conviene reparar en que estos son artículos originales de eIDAS y, por tanto, no llevan la numeración latina bis, ter, quater… propia de los preceptos que eIDAS2 fue insertando; su anexo remite a la ETSI TS 119 511 (con la TS 119 172-4) como norma de referencia.

El problema que resuelve la 511 es sutil pero enorme: una firma electrónica es válida hoy porque el certificado que la respalda está vigente, porque los algoritmos criptográficos empleados se consideran robustos y porque existe una infraestructura que lo confirma. Pero el tiempo erosiona todo eso. Los certificados caducan, las autoridades cambian, y (esto es cada vez más relevante) los algoritmos envejecen. Un servicio de conservación cualificado mantiene viva la evidencia: reafirma periódicamente la integridad y la validez mediante nuevos sellos de tiempo o técnicas de preservación (como hashes encadenados) y nuevas capas de protección criptográfica, de modo que dentro de veinte años se pueda seguir demostrando que aquel documento estaba firmado y que no ha sido alterado.

Aquí conviene detenerse, porque este es exactamente el terreno donde la criptoagilidad y la criptografía postcuántica dejan de ser un debate académico. Conservar a largo plazo significa, por definición, sobrevivir al momento en que los algoritmos actuales dejen de ser fiables. Un buen servicio de conservación es, en el fondo, una máquina diseñada para migrar de algoritmos sin perder el hilo probatorio. Quien entienda la 511 entiende ya la mitad de por qué el resto de esta historia importa.

El segundo paso: el archivado electrónico cualificado

El segundo eIDAS (el Reglamento (UE) 2024/1183) no tiró nada de lo anterior. Lo amplió. Entre los nuevos servicios cualificados de confianza aparece el archivado electrónico cualificado, lo que en la jerga anglosajona se abrevia como q-earchiving y que en el desarrollo normativo europeo se apoya en la especificación técnica CEN/TS 18170. Su acto de ejecución es el Reglamento de Ejecución (UE) 2025/2532, de 16 de diciembre de 2025, dictado al amparo del artículo 45 undecies, apartado 2, del Reglamento (el precepto que eIDAS2 añadió para el archivado electrónico cualificado), cuyo anexo remite precisamente a la CEN/TS 18170:2025 como norma de referencia.

La diferencia con la conservación de firmas es de alcance. La 511 se centra en mantener la validez de la evidencia criptográfica de un documento firmado. El archivado cualificado va un paso más allá y se ocupa del documento como objeto que debe conservarse íntegro, legible y disponible a lo largo del tiempo, esté firmado o no, incluyendo la garantía de su integridad, la trazabilidad de accesos y las políticas de retención. Es la traducción normativa de una necesidad muy antigua (el archivo) al lenguaje de los servicios cualificados de confianza. Por primera vez, un prestador puede ofrecer archivado con el mismo nivel de garantía jurídica que ya tenían la firma electrónica, el sello electrónico o el sellado de tiempo.

Y merece la pena deshacer un malentendido frecuente: el archivado no sustituye a la conservación de firmas, sino que se apoya en ella. La propia 511 sigue siendo la pieza que garantiza la pervivencia de la evidencia de firma, de modo que un prestador de archivado electrónico cualificado puede utilizar los servicios de un prestador de conservación para esa parte (recurrir a un servicio 511 para mantener vivas las firmas y sellos de los documentos que custodia). No estamos ante servicios que compiten, sino ante servicios que se complementan: el archivado orquesta la custodia del expediente y delega en la conservación el cuidado a largo plazo de la evidencia criptográfica. Es exactamente la lógica de capas que recorre todo este artículo.

Hay además una segunda función del archivado que merece destacarse porque a menudo pasa desapercibida: la conversión de formatos. Custodiar un documento durante décadas no consiste solo en que sus bits no cambien; consiste en que siga siendo legible. Y los formatos también envejecen. Un formato de fichero que hoy es universal puede quedar obsoleto y dejar de utilizarse en favor de otros, y cuando eso ocurra el servicio de archivado debe poder convertir el documento al nuevo formato preservando su contenido, su presentación fiel y su valor probatorio. Es, en el plano de los formatos, el paralelo exacto de lo que la conservación hace en el plano de los algoritmos: así como un servicio 511 migra de algoritmos criptográficos antes de que dejen de ser fiables, un servicio de archivado migra de formatos antes de que dejen de poder abrirse. Legibilidad futura de los datos y robustez futura de la criptografía son las dos caras de la misma promesa: que dentro de veinte años el documento no solo exista, sino que se pueda abrir y demostrar.

Si la conservación protege la firma, el archivado protege el expediente. Y el siguiente paso es preguntarse qué ocurre cuando lo que necesitamos proteger no es un documento aislado, sino la relación entre muchos hechos a lo largo del tiempo.

El tercer paso: orden temporal

Aquí entra la novedad más interesante del segundo eIDAS: los registros electrónicos (electronic ledgers) como nuevo servicio cualificado de confianza. La especificación de referencia es CEN/TS 18264, publicada en 2025.

Y su acto de ejecución, del mismo lote de diciembre de 2025, es el Reglamento de Ejecución (UE) 2025/2531, dictado al amparo del artículo 45 terdecies, apartado 3, del Reglamento (el precepto que eIDAS2 dedicó a los registros electrónicos cualificados).

Yo prefiero explicarlo con una idea sencilla: un registro electrónico es un archivo de orden cronológico. No solo guarda entradas de datos, sino que garantiza su secuencia temporal de forma que ninguna se pueda insertar, borrar o reordenar sin que se note. Es, si se quiere, un sellado de tiempo elevado a la categoría de estructura: no marcamos un único documento con una fecha, sino que construimos una cadena de acontecimientos cuya ordenación es en sí misma la prueba.

Y una vez que aceptamos que lo que aporta valor es la ordenación cronológica garantizada, surge la pregunta técnica que da nombre a la sesión: ¿cómo se construye ese orden? Y hay dos respuestas legítimas.

La primera es usando una infraestructura centralizada: un único prestador cualificado mantiene el registro, lo sella y responde de su integridad. Es sencillo de auditar y encaja perfectamente en el modelo de prestador cualificado que ya conocemos.

La segunda es usando una infraestructura de nodos interconectados que replican la información (a veces llamada infraestructura distribuida): el orden cronológico se construye mediante la conexión de los nodos que acuerdan entre sí (por las reglas de gobernanza) la secuencia de las entradas. Aquí es donde la tecnología de registro distribuido (DLT) entra en juego, no como una moda, sino como una forma concreta de lograr esa ordenación sin depender de un único punto. Cuando ese registro distribuido se presta con las garantías de un servicio cualificado de confianza, hablamos de qDLT: un registro distribuido cualificado.

Permítaseme aquí un apunte terminológico que vengo defendiendo desde hace tiempo. El Reglamento ha consagrado el término DLT (Distributed Ledger Technology, tecnología de registro distribuido), y a él me atengo por rigor normativo. Pero, puestos a bautizar la idea con precisión, yo preferiría hablar de RJT (Replicated Journal Technology). La razón es contable: en la partida doble, el orden cronológico de los hechos no se guarda en el ledger (el libro mayor, que agrupa los apuntes por cuenta), sino en el journal (el libro diario, que los anota uno tras otro según van ocurriendo). Y como lo que aquí estamos preservando es justamente la secuencia temporal, el nombre idóneo a adoptar para esta tecnología debería orientarse al diario replicado antes que al mayor distribuido. Es, seguramente, una batalla terminológica ya perdida frente al texto oficial, pero no por ello menos exacta.

Un buen ejemplo europeo de esta aproximación es EBSI, la infraestructura europea de servicios blockchain, hoy gobernada a través de la figura del Europeum-EDIC (un consorcio de infraestructura digital europea). EBSI muestra que el modelo distribuido no es incompatible con la confianza cualificada: los nodos pueden estar operados por administraciones y prestadores identificados, con anclas de confianza gubernamentales, de modo que el resultado combina la resiliencia de la distribución con la responsabilidad jurídica que exige el marco eIDAS.

Y vale la pena fijarse en un detalle del Reglamento de Ejecución (UE) 2025/2531, porque recoge con precisión esta dualidad. El acto de ejecución exige a todos los prestadores de registros electrónicos cualificados cumplir con la norma ETSI EN 319 401 (requisitos generales de política para prestadores de servicios de confianza) y añade requisitos específicos para la variante distribuida: cuando el registro se construye mediante nodos, el prestador debe cumplir además la ISO 23257:2022 (arquitectura de referencia de las tecnologías de registro distribuido) y la ISO/TS 23635:2022 (directrices de gobernanza). Dicho de otro modo, es el propio acto de ejecución el que reconoce las dos variantes y reserva las normas de consenso y gobernanza de DLT para el caso distribuido, que es cuando hablamos con propiedad de qDLT. La regulación, una vez más, no impone una tecnología: describe garantías y deja abierta la forma de alcanzarlas.

Merece la pena subrayar la continuidad normativa: de conservación (511) pasamos a archivado cualificado (18170) y de ahí a registro cronológico o qDLT (18264). No son tres mundos, sino tres capas de una misma idea que va ganando ambición: primero mantener con plenos efectos una firma electrónica, luego custodiar un documento (firmado o no) garantizando su recuperación futura, y finalmente ordenar y relacionar los hechos de forma verificable, cuando ese orden pueda producir efectos legales.

Lo que un registro cronológico permite hacer

La parte que más me interesa, y a la que dediqué buena parte de mi intervención, no es la tecnología del registro en sí, sino las funcionalidades que habilita cuando registramos no solo el documento, sino también su contexto: quién es su propietario, qué derechos incorpora y cómo evoluciona. Un registro cronológico bien diseñado abre la puerta a tres capacidades que hasta ahora eran difíciles de trasladar al mundo digital con plenas garantías.

La primera es la transferibilidad (o endosabilidad). Si el registro no anota únicamente que existe un documento, sino también quién es su titular, entonces puede anotar igualmente la transmisión de esa titularidad. Esto es lo que permite tratar un archivo electrónico como un bien que cambia de manos: pensemos en los efectos comerciales, en los títulos representativos de mercancías o en cualquier derecho que tradicionalmente se «endosaba» sobre un papel. El registro cronológico convierte la cadena de endosos en una secuencia verificable de entradas.

La segunda es la obliterabilidad (o cancelabilidad). Un derecho no solo se transmite: también se consume. Si un archivo representa una entrada de cine o el acceso a un espectáculo, necesitamos poder marcar que ese derecho ya se ha ejercido, de forma que no pueda usarse dos veces. El registro no borra la entrada (la evidencia permanece), pero anota de manera indeleble su cambio de estado: emitido, transferido, consumido. Es la diferencia entre tachar y tirar: el hecho de que un derecho se agotó es, en sí mismo, un hecho que merece quedar registrado. Es el caso del matasellos, por ejemplo.

La tercera es la completitud, que a mí me gusta describir como una grapa electrónica. Un documento raramente viaja solo. Un contrato lleva anexos; una escritura lleva anotaciones; un acuerdo evoluciona mediante versiones sucesivas. Pensemos en las novaciones contractuales, en las que las partes acuerdan modificar el clausulado: lo que importa jurídicamente no es solo el último texto, sino la relación completa entre el documento original, sus anexos y cada una de sus evoluciones. La completitud consiste en mantener unidos, de forma verificable, el documento y todo lo que le acompaña (anotaciones, anexos y sus propias versiones), de modo que el conjunto se conserve como una unidad indivisible y trazable. La grapa no solo junta papeles: registra en qué orden se fueron juntando.

Estas tres funcionalidades comparten un rasgo: solo son posibles si el registro guarda más que el documento. Guarda su titularidad, su estado y sus relaciones. Y solo son fiables si esa información está ordenada en el tiempo de forma que no pueda manipularse. Por eso el registro cronológico cualificado no es un capricho técnico, sino el sustrato sobre el que se pueden construir servicios que hasta ahora vivían atados al papel o a intermediarios de confianza cerrados.

Una base de datos con genealogía jurídica: las anotaciones en cuenta y el Cartulario de EADTrust

Para que estas tres funcionalidades sean algo más que una promesa, hace falta gestionar una base de datos asociada al servicio con unas propiedades muy concretas: que registre, para cada objeto archivado, quién es su titular, en qué estado se encuentra el derecho que incorpora (y donde o frente a quien se ejerce este derecho) y cómo se relaciona con otros documentos; y que lo haga de modo que cada cambio quede anotado en secuencia y resulte oponible frente a terceros. Quien conozca el Derecho del mercado de valores reconocerá el patrón de inmediato, porque es exactamente el que rige la representación de valores mediante anotaciones en cuenta: un registro contable en el que la titularidad, las transmisiones, los gravámenes y la extinción de los derechos no se documentan sobre un título físico, sino que se constituyen y se prueban por su inscripción. La transferibilidad es, en ese lenguaje, la transmisión de la anotación; la obliterabilidad, su cancelación; la completitud, el vínculo entre la anotación principal y sus accesorias. No es una coincidencia: el registro cronológico cualificado y el registro de anotaciones en cuenta resuelven el mismo problema —dar certeza sobre la titularidad y el estado de un derecho a lo largo del tiempo— con la misma herramienta: una base de datos fiable y ordenada.

En EADTrust llevamos tiempo trabajando sobre esta idea. Nuestro servicio Cartulario se diseñó hace ya bastantes años partiendo precisamente de esas premisas: tratar el archivo no como un simple depósito de ficheros, sino como un registro que anota titularidad, estado y relaciones, con la vista puesta en funcionalidades como la endosabilidad, la cancelabilidad y la completitud mucho antes de que el marco normativo europeo las recogiera de forma explícita.

Y ya que hablamos del nombre: un cartulario era, en la Edad Media, el códice en el que monasterios y cabildos copiaban y custodiaban sus escrituras, privilegios y donaciones para que no se perdieran (viene a ser el bisabuelo de la matriz notarial). Así que, bien mirado, en EADTrust llevamos en esto del archivo de orden cronológico desde varios siglos antes de que se inventara el PDF; la única diferencia es que hemos cambiado la vitela por un servidor digital y al monje amanuense por un sello de tiempo de precisión de milisegundo.

Y a esa base de partida Cartulario añade ahora un refinamiento que va justo al corazón de lo que discutíamos en Tallinn: sellos de tiempo de precisión de milisegundo (1 ms) asociados a cada solicitud de archivo. Cuando la prueba es la ordenación, la resolución temporal importa: disponer de una marca de tiempo con precisión de milisegundo en cada operación permite garantizar con mucha mayor finura el orden cronológico de las entradas, y resolver sin ambigüedad la secuencia incluso cuando varias solicitudes se acumulan en un intervalo muy breve. Es, en la práctica, la materialización de esa idea de «archivo de orden cronológico» de la que parte todo este razonamiento.

Por qué esto encaja con el resto del ecosistema

No quiero concluir el artículo sin conectar esta historia con la conversación más amplia sobre identidad digital europea. El ecosistema de la cartera europea (EUDI Wallet) y de las declaraciones electrónicas de atributos necesitan anclas de confianza sólidas: lugares donde asentar de forma verificable quién ha dicho qué, sobre quién y cuándo. Un registro cronológico cualificado (centralizado o en forma de qDLT) es precisamente uno de esos anclajes. Puede unir el mundo de la identidad con la responsabilidad jurídica del marco eIDAS.

Y todo ello sigue descansando sobre la primera piedra que mencionaba al principio: la capacidad de conservar la evidencia a largo plazo y de migrar de algoritmos cuando haga falta. La llegada de la criptografía postcuántica no invalida esta arquitectura; al contrario, la hace más necesaria. Un registro que ordena documentos en el tiempo debe ser, por diseño, un registro capaz de sobrevivir al paso del tiempo, incluido el tiempo en que los algoritmos de hoy dejen de protegernos o los formatos de codificación de documentos se sustituyan por otros..

Esa fue, en esencia, mi tesis en Tallinn: que las DLT y el qDLT no aparecen de la nada, sino que son el siguiente peldaño natural de una escalera que empezó conservando firmas, siguió archivando documentos y ahora aprende a ordenar los hechos. Verlo así ayuda mucho a no perderse: cada norma nueva no sustituye a la anterior, sino que le añade una capa de ambición.

Probar Cartulario

Si quieres experimentar con estas ideas sobre un servicio real, en EADTrust ponemos Cartulario a disposición de quienes deseen probarlo. Conviene precisar su naturaleza actual con total transparencia: hoy se ofrece como servicio de confianza no cualificado y está pendiente de auditoría para ser considerado servicio cualificado en el marco de eIDAS. Esa distinción no es un matiz menor (es, precisamente, la línea que separa un servicio de confianza de un servicio cualificado de confianza), y preferimos dejarla clara desde el principio.

Quien quiera conocerlo, plantear un proyecto piloto o comentar casos de uso (endosabilidad, cancelabilidad, completitud o el sellado de tiempo de precisión de milisegundo) puede escribirnos a info@eadtrust.com o llamarnos al 902 365 612 / 91 716 05 55. Más información en www.eadtrust.eu.

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


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ónObjetoIncidencia en el PID
(UE) 2024/2977Datos de identificación de la persona y declaraciones electrónicas de atributosDefine el PID (atributos y ciclo de vida)
(UE) 2024/2979Integridad y funcionalidades esenciales de la carteraIndirecta
(UE) 2024/2980Notificaciones a la Comisión sobre el ecosistemaIndirecta
(UE) 2024/2981Certificación de las carterasIndirecta
(UE) 2024/2982Protocolos e interfaces (estándares de referencia)Formatos de emisión y presentación
(UE) 2025/846Cotejo transfronterizo de identidadesRelevante: coteja nombre y apellidos
(UE) 2025/847Notificación de brechas de seguridadIndirecta
(UE) 2025/848Registro de las partes usuariasIndirecta
(UE) 2025/849Lista de carteras certificadasIndirecta
(UE) 2025/2162Acreditación de los organismos de evaluación de la conformidadIndirecta
(UE) 2026/1731Enmienda 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:

  1. Reversibilidad. codificar(decodificar(x)) == x. La estructura recuperada debe volver a producir exactamente la misma cadena, sin pérdida.
  2. 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.
  3. 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.
  4. 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»).
  5. 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.

ElementoValor
Nombre de pilaJosé María
Primer apellidoGarcía de la Torre
Segundo apellidoMartí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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

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


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íaEventoHorarioLugar
Lunes 14ETSI ESI CA Open Session13:00–18:00Kultuurikatel, Stalker Hall
Lunes 14CSC 10th Anniversary Celebration18:00–22:00F-Hoone, Telliskivi 60a/5
Martes 15ENISA Trust Services and eID Forum (12.ª ed.)jornada completaKultuurikatel
Miércoles 1618.º CA Day (D-Trust / TÜV NORD Cert)jornada completaKultuurikatel
Jueves 17 – viernes 18AHWG de ENISA sobre la EUDI Walletreunión de expertosKultuurikatel
Jueves 17PQC Migration Workshop (no asisto)09:00–12:50Kultuurikatel, 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:

  1. estándares y autoridades de certificación (ETSI ESI),
  2. interoperabilidad de firmas en la nube (CSC),
  3. el foro europeo de eIDAS y servicios de confianza (ENISA + CA Day),
  4. 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.

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


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

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, 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) 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. [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). [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. [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.

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/1943; 2025/1944; 2025/1946; 2025/2160; 2025/2531; 2025/2532; 2026/798).

Certificados cualificados

  • ETSI EN 319 411-1  -> Requisitos para PSC que emiten certificados; Parte 1, general (CIR (UE) 2025/1943; 2025/1942; 2025/1944; 2025/848).
  • ETSI EN 319 411-2  -> Parte 2, certificados cualificados de la UE (CIR (UE) 2025/1943; 2025/2527).
  • ETSI EN 319 412-1/-2/-3/-5  -> perfiles de certificados y QCStatements (CIR (UE) 2025/1943).
  • 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  -> perfil para certificados de autenticación web/TLS (CIR (UE) 2025/2527).
  • ETSI TS 119 495  -> perfil sectorial bancario PSD2 / finanzas abiertas (CIR (UE) 2025/2527).

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

  • ETSI EN 319 122-1  -> CAdES (CIR (UE) 2026/248; 2024/2979; 2025/2531).
  • ETSI EN 319 132-1  -> XAdES (CIR (UE) 2026/248; 2024/2979; 2025/2531).
  • ETSI EN 319 142-1  -> PAdES (CIR (UE) 2026/248; 2024/2979).
  • ETSI TS 119 182-1  -> JAdES (CIR (UE) 2026/248; 2024/2979; 2025/2531).
  • ETSI EN 319 162-1/-2  -> ASiC (contenedores de firma asociada) (CIR (UE) 2026/248; 2024/2979).
  • ETSI TS 103 171 / 172 / 173 / 174  -> perfiles heredados XAdES/PAdES/CAdES/ASiC, aún admitidos (CIR (UE) 2026/248 (Anexo II / Annex II)).

Sellos cualificados de tiempo

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

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).
  • ETSI TS 119 102-2  -> informe de validación de firma (CIR (UE) 2025/1942; 2025/1945).
  • ETSI TS 119 441  -> política de servicios de validación (CIR (UE) 2025/1942).
  • ETSI TS 119 172-1/-4  -> políticas de firma (CIR (UE) 2025/1942; 2025/1945; 2025/1946).
  • 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; CID 2025/2164 (versión de la norma de la plantilla / standard version of the template)).

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).

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; 2026/798).

Declaraciones electrónicas de atributos

  • ETSI TS 119 471  -> requisitos para prestadores de declaración de atributos (CIR (UE) 2026/1735 (modifica / amends 2025/1569)).
  • ETSI TS 119 478  -> perfiles de las declaraciones electrónicas de atributos (CIR (UE) 2026/1735 (modifica / amends 2025/1569)).

Entrega electrónica certificada (QERDS)

  • ETSI EN 319 521  -> requisitos de prestadores ERDS (CIR (UE) 2025/1944).
  • ETSI EN 319 522 (partes 1-4)  -> marco, contenidos, formatos e interfaces (CIR (UE) 2025/1944).

Preservación

  • ETSI TS 119 511  -> preservación a largo plazo de firmas y datos (CIR (UE) 2025/1946).

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).

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).

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 17xxx) (CIR (UE) 2024/2981).

Certificados de acceso de la parte usuaria

  • ETSI EN 319 411-1  -> política NCP para el certificado de acceso de la parte usuaria (CIR (UE) 2025/848).

Tabla-resumen: acto → normas ETSI/CEN

Acto de ejecuciónNormas 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 17xxx)
CIR (UE) 2025/848 [ES · EN]EN 319 411-1 (NCP)
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-4; TS 119 101; 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-4; TS 119 101; TS 119 612; EN 319 401
CIR (UE) 2025/2160 [ES · EN]EN 319 401
CIR (UE) 2025/2164 (Dec.) [ES · EN]TS 119 612
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
CIR (UE) 2025/2532 [ES · EN]EN 319 401; EN 319 421; CEN/TS 18170:2025
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/1735 [ES · EN]TS 119 471; TS 119 478

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, 2025/2162, 2025/2530 (paraguas), 2026/1730 y 2026/1731 (que actualiza los actos núcleo de la cartera al ARF v3.0.0).

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): [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.

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, quedan dos comprobaciones finas: si el CIR 2025/1567 cita además TS 119 431-2 / TS 119 432, y si el CIR 2025/1946 cita también TS 119 512 (protocolos de preservación); en la lectura realizada no aparecían. Tercero, los títulos exactos de ETSI TS 119 471 y TS 119 478 (introducidas por el CIR 2026/1735) conviene confirmarlos en el catálogo de ETSI, por ser de aparición reciente.

Como es habitual, iré actualizando esta información a medida que se publiquen nuevos actos 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

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, amends 2025/848), CIR (EU) 2026/1731 (aligns the four core wallet acts with ARF v3.0.0, superseding v2.8.0) 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. [ES · EN]
  • CIR (EU) 2025/2164 (Decisión)  -> 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). [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. [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.

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/1943; 2025/1944; 2025/1946; 2025/2160; 2025/2531; 2025/2532; 2026/798).

Qualified certificates

  • ETSI EN 319 411-1  -> Requirements for TSPs issuing certificates; Part 1, general (CIR (EU) 2025/1943; 2025/1942; 2025/1944; 2025/848).
  • ETSI EN 319 411-2  -> Part 2, EU qualified certificates (CIR (EU) 2025/1943; 2025/2527).
  • ETSI EN 319 412-1/-2/-3/-5  -> certificate profiles and QCStatements (CIR (EU) 2025/1943).
  • CEN/TS 419261:2015  -> trustworthy systems managing certificates and time stamps (CIR (EU) 2025/1943).

Website authentication certificates (QWAC)

  • ETSI TS 119 411-5  -> profile for web/TLS authentication certificates (CIR (EU) 2025/2527).
  • ETSI TS 119 495  -> PSD2 / open-finance sectoral profile (CIR (EU) 2025/2527).

Signature/seal formats (AdES) and containers

  • ETSI EN 319 122-1  -> CAdES (CIR (EU) 2026/248; 2024/2979; 2025/2531).
  • ETSI EN 319 132-1  -> XAdES (CIR (EU) 2026/248; 2024/2979; 2025/2531).
  • ETSI EN 319 142-1  -> PAdES (CIR (EU) 2026/248; 2024/2979).
  • ETSI TS 119 182-1  -> JAdES (CIR (EU) 2026/248; 2024/2979; 2025/2531).
  • ETSI EN 319 162-1/-2  -> ASiC (associated signature containers) (CIR (EU) 2026/248; 2024/2979).
  • ETSI TS 103 171 / 172 / 173 / 174  -> legacy XAdES/PAdES/CAdES/ASiC profiles, still accepted (CIR (EU) 2026/248 (Anexo II / Annex II)).

Qualified time stamps

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

Validation of signatures and seals

  • ETSI EN 319 102-1  -> AdES creation and validation; Part 1 (CIR (EU) 2025/1942; 2025/1945; 2025/1946).
  • ETSI TS 119 102-2  -> signature validation report (CIR (EU) 2025/1942; 2025/1945).
  • ETSI TS 119 441  -> validation service policy (CIR (EU) 2025/1942).
  • ETSI TS 119 172-1/-4  -> signature policies (CIR (EU) 2025/1942; 2025/1945; 2025/1946).
  • 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; CID 2025/2164 (versión de la norma de la plantilla / standard version of the template)).

Remote signature/seal device management

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

Identity verification and remote onboarding

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

Electronic attestations of attributes

  • ETSI TS 119 471  -> policy/security requirements for attribute attestation providers (CIR (EU) 2026/1735 (modifica / amends 2025/1569)).
  • ETSI TS 119 478  -> profiles for electronic attestations of attributes (CIR (EU) 2026/1735 (modifica / amends 2025/1569)).

Qualified electronic registered delivery (QERDS)

  • ETSI EN 319 521  -> ERDS provider requirements (CIR (EU) 2025/1944).
  • ETSI EN 319 522 (partes 1-4)  -> framework, contents, formats and interfaces (CIR (EU) 2025/1944).

Preservation

  • ETSI TS 119 511  -> long-term preservation of signatures and data (CIR (EU) 2025/1946).

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).

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).

Wallet and cybersecurity certification

  • CEN EN 17640  -> fixed-time cybersecurity evaluation methodology (with EN ISO/IEC 17xxx) (CIR (EU) 2024/2981).

Relying-party access certificates

  • ETSI EN 319 411-1  -> NCP policy for the relying-party access certificate (CIR (EU) 2025/848).

Summary table: act → ETSI/CEN standards

Implementing actETSI / 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 17xxx)
CIR (EU) 2025/848 [ES · EN]EN 319 411-1 (NCP)
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-4; TS 119 101; 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-4; TS 119 101; TS 119 612; EN 319 401
CIR (EU) 2025/2160 [ES · EN]EN 319 401
CIR (EU) 2025/2164 (Dec.) [ES · EN]TS 119 612
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
CIR (EU) 2025/2532 [ES · EN]EN 319 401; EN 319 421; CEN/TS 18170:2025
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 (legado)
CIR (EU) 2026/798 [ES · EN]TS 119 461; EN 319 401
CIR (EU) 2026/1735 [ES · EN]TS 119 471; TS 119 478

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, 2025/2162, 2025/2530 (umbrella), 2026/1730 and 2026/1731 (which aligns the core wallet acts with ARF v3.0.0).

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): [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. Three honest caveats: 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, two fine checks remain open: whether CIR 2025/1567 also cites TS 119 431-2 / TS 119 432, and whether CIR 2025/1946 also cites TS 119 512 (preservation protocols); they did not appear in the reading performed. Third, the exact titles of ETSI TS 119 471 and TS 119 478 (introduced by CIR 2026/1735) should be confirmed in the ETSI catalogue, as they are recent standards.

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.

Contact us by email at info@eadtrust.com or by phone at: [+34 917160555]. More información at eadtrust.com.

Obligación de aceptación de la Cartera de Identidad Digital Europea en el sector privado a partir de diciembre de 2027


El Artículo 5 septies del Reglamento (UE) 2024/1183, conocido como eIDAS 2, introduce una obligación directa para algunas empresas del sector privado: a más tardar en diciembre de 2027 (36 meses después de la entrada en vigor tras su publicación de los actos de ejecución correspondientes), las entidades obligadas deberán aceptar la Cartera de Identidad Digital de la Unión Europea (EUDI Wallet) como medio de identificación y autenticación reforzada del usuario.

Esta obligación afecta a todas las entidades que, por disposición legal o contractual, deban realizar una autenticación reforzada del cliente (SCA – Strong Customer Authentication) conforme al Reglamento (UE) 2016/679 (RGPD), la Directiva PSD2 o normativa sectorial específica.

Salvo microempresas y pequeñas empresas de los sectores aludidos.

La Cartera funciona mediante declaraciones electrónicas de atributos basadas en estándares abiertos (ISO/IEC 18013-5, OpenID4VCI y OpenID4VP), lo que permite la divulgación selectiva de atributos y la firma criptográfica de pruebas de posesión, sin que el prestador de servicios almacene datos biométricos ni documentos.

A continuación se detallan los casos de uso técnicos principales de onboarding (contratación inicial) y autenticación posterior por cada sector referenciado en el artículo 5 septies.

1. Banca y servicios financieros

  • Onboarding: El usuario presenta su Cartera a través de un flujo OpenID4VP. El banco recibe, en tiempo real los Datos de Identificación Personal (DIP) del titular de la Cartera (DNI/NIE, datos de residencia, fecha de nacimiento y, opcionalmente, mediante Declaraciones Electrónicas de Atributos complementarias, otros datos como nivel de ingresos o scoring crediticio). Se elimina la necesidad de videoidentificación o carga manual de documentos. La cartera puede gestionar la firma electrónica cualificada (QES, Qualified Electronic Signature) del contrato, por lo que todo el proceso podría completarse en uno o dos minutos.
  • Autenticación para acceder al servicio: Login en banca online o app móvil mediante protocolo OpenID Connect con presentación de credencial firmada. La Cartera actúa como segundo factor criptográfico (equivalente a un dispositivo seguro), cumpliendo los requisitos de SCA de PSD2 y sustituyendo o complementando OTP y contraseñas.

2. Suministros (empresas eléctricas, de gas y de agua)

  • Onboarding: Contratación de nuevo punto de suministro o cambio de comercializadora. La Cartera entrega atributos verificados de titularidad y domicilio, permitiendo la activación inmediata del contrato sin intervención manual. La cartera puede gestionar la firma electrónica cualificada a distancia del contrato,
  • Autenticación para acceder al servicio: Acceso al área de cliente para consulta de consumos, facturas o modificación de potencia contratada. La integridad criptográfica garantiza que solo el titular autorizado pueda modificar datos sensibles.

3. Telecomunicaciones

  • Onboarding: Alta de línea móvil, fibra óptica, servicios audiovisuales o paquete convergente. Verificación automática de identidad y titularidad sin videollamada ni envío de documentación. El operador recibe, en tiempo real los Datos de Identificación Personal (DIP) del titular de la Cartera (DNI/NIE, datos de residencia, fecha de nacimiento).
  • Autenticación para acceder al servicio: Login en la app del operador para gestión de la línea, portabilidades o contratación adicional de servicios complementarios. Ideal para procesos que requieren SCA (cambio de titular, eSIM, etc.).

4. Transporte

  • Onboarding: Compra de abonos de transporte, alquiler de vehículos o contratación de seguros de viaje. La Cartera puede entregar atributos verificados del carnet de conducir o pasaporte.
  • Autenticación para acceder al servicio: Validación de títulos de transporte digitales o acceso a plataformas de movilidad compartida. La credencial permite la verificación offline y online con firma de prueba de posesión. Podría controlar la interfaz NFC para que la propia cartera se pueda usar como título de transporte.

5. Sanidad

  • Onboarding: Alta en plataformas de telemedicina, contratación de seguros médicos privados o integración en sistemas de historial clínico compartido.
  • Autenticación para acceder al servicio: Login seguro para consulta de resultados, recetas electrónicas o citas. La divulgación selectiva protege datos de salud especialmente sensibles (art. 9 RGPD). Posible uso en farmacias para la dispensación de medicamentos.

6. Educación

  • Onboarding: Matrícula en universidades privadas, plataformas de formación continua o cursos de posgrado. Con posibilidad de aportar Declaraciones Electrónicas de Atributos de haber superado cierto nivel formativo cuando se exige para matricularse en otro superior.
  • Autenticación para acceder al servicio: Acceso a campus virtuales, entrega de exámenes o consulta de calificaciones, presentación de trabajos. La Cartera puede portar credenciales académicas verificadas (títulos, certificados de competencias).

7. Otros servicios básicos y plataformas en línea de muy gran tamaño (VLOPs)

  • Onboarding: Contratación de servicios postales premium, infraestructuras críticas o cualquier servicio que requiera SCA.
  • Autenticación para acceder al servicio: Gestión de envíos, seguimiento o acceso a portales de infraestructuras.

Caso específico de VLOPs (X, Google y Microsoft)

El párrafo 3 del artículo 5 septies impone una obligación específica a las plataformas definidas como Very Large Online Platforms (VLOPs) conforme al artículo 33 del Digital Services Act (Reglamento (UE) 2022/2065): cuando requieran autenticación del usuario para acceder a sus servicios en línea, deberán aceptar y facilitar el uso de la Cartera de Identidad Digital Europea (EUDI Wallet) para la autenticación, siempre bajo petición voluntaria del usuario y limitándose a los datos mínimos necesarios para el servicio concreto.

Esta obligación entra en vigor en el mismo plazo que para el resto del sector privado (diciembre de 2027) y busca reducir el fraude, mejorar la verificación de edad, combatir cuentas falsas y garantizar el cumplimiento del principio de minimización de datos del RGPD.

  • X: Autenticación reforzada para cuentas verificadas, funciones premium (X Premium) o publicación de contenido monetizado. La Cartera permite verificación de identidad real mediante divulgación selectiva y firma de prueba de posesión, reduciendo significativamente cuentas falsas y bots sin necesidad de vincular cuentas externas. Soporte técnico mediante OpenID4VP.
  • Google: Login en Gmail, YouTube, Google Workspace o Google Play Store mediante protocolo OpenID4VP. Ejemplos prácticos incluyen verificación de edad para contenido restringido (sin revelar la fecha de nacimiento), autenticación en Workspace para empresas o compras en Play Store. La Cartera actuaría como credencial única, eliminando la necesidad de contraseñas o factores adicionales y facilitando el cumplimiento de normativas de protección de menores.
  • Microsoft: Autenticación en Microsoft 365, Azure (Entra ID), Outlook o Xbox. Especialmente relevante en entornos B2B y educativos, donde la trazabilidad criptográfica y la Wallet Attestation garantizan el cumplimiento de políticas de seguridad corporativa y permiten single sign-on (SSO) con credenciales verificadas de forma nativa.

En todos los casos, las VLOPs deben implementar los flujos de presentación de credenciales (OpenID4VP) y respetar el principio de minimización de datos.

Cómo prepararse: hoja de ruta técnica para entidades obligadas

Se sugiere a las empresas obligadas que reserven presupuesto para llevar a cabo los trabajos de adaptación durante 2026 y 2027:

  1. Diagnóstico (Q3-Q4 2026): Mapear todos los procesos que requieren SCA y evaluar el impacto de la obligación.
  2. Integración técnica (2026-2027):
    • Implementar endpoints OpenID4VCI / OpenID4VP y soporte para Wallet Attestation.
    • Conectar con un servicio cualificado de archivo electrónico (conforme al Reglamento de Ejecución (UE) 2025/2532) para conservar las evidencias de presentación.
    • Adaptar sistemas de backend para procesar Verifiable Credentials y Selective Disclosure.
  3. Certificación y auditoría: Obtener certificación eIDAS como Qualified Trust Service Provider (QTSP) o contratar uno ya acreditado.
  4. Formación y gobernanza: Designar un Responsable de la Cartera Digital y actualizar políticas de privacidad y seguridad.
  5. Pruebas piloto: Participar en los entornos sandbox de la Comisión Europea o en los pilotos nacionales.

Las entidades que inicien la preparación en 2026 contarán con ventaja competitiva y evitarán sanciones por incumplimiento.

EADTrust, tu aliado para la transición

En EADTrust ya prestamos servicios cualificados de confianza (certificados para la firma electrónica cualificada y para el sello electrónico cualificado, sello de tiempo cualificado y archivo electrónico) y ya contamos con implementaciones de cartera que se adaptan a los proyectos.

Participamos en el CSC Interoperability Event 2026 en Bucarest con nuestra herramienta de Firma Remota que se puede invocar desde diferentes despliegues de Cartera.

Ofrecemos consultoría especializada para la integración de la EUDI Wallet.

Nuestro equipo de especialistas en Confianza Digital puede ayudarte a cumplir el artículo 5 septies de forma ágil y conforme a la normativa publicada.

Contacta con nosotros hoy mismo:

  • Teléfono: 917 160 555
  • Email: info@eadtrust.com
  • Formulario User-Centric-Id

¿Tu entidad está entre las obligadas? ¿Quieres que te ayudemos a evaluar tu grado de preparación?

Déjanos un comentario o ponte en contacto con nosotros directamente.

Estaremos encantados de acompañarte en este proceso estratégico.

Explicabilidad


Vamos a tratar el concepto de “explicabilidad” en el contexto de las evidencias electrónicas.

En el mundo digital, no basta con que algo esté “hecho”. Hace falta poder explicar cómo se ha hecho y cuándo se ha hecho y que esa explicación sea coherente con la forma de gestionar procesos internos digitales. A eso lo llamamos explicabilidad.

Es un concepto que cada vez aparece más en la normativa: desde la prueba electrónica hasta los sistemas regulados de inteligencia artificial. En EADTrust lo aplicamos de forma práctica con nuestros servicios de confianza cualificados, y especialmente con GoCertius, la app gratuita que permite generar evidencias digitales irrefutables.

¿Qué significa “explicabilidad” en una evidencia electrónica?

Imagina que estás grabando un vídeo, haciendo una foto o cerrando un acuerdo por chat. ¿Cómo demuestras después que ese archivo existía en ese momento exacto, que nadie lo ha modificado y que todo el proceso se ha seguido con diligencia?

La respuesta no es solo “tengo el archivo”. La respuesta es: tengo una cadena de sellos de tiempo cualificados que lo prueban paso a paso, más una explicación clara que cualquiera puede entender.

Eso es la explicabilidad: no solo la prueba técnica, sino la narrativa verificable que la acompaña.

El ejemplo práctico: GoCertius

GoCertius es la app gratuita de EADTrust (desarrollada junto con Garrigues) que millones de personas y empresas ya utilizan a diario. Con ella puedes certificar fotos, vídeos cortos, conversaciones de chat o cualquier documento digital en cuestión de segundos.

Cuando certificas algo con GoCertius, la app no solo guarda el archivo. Genera una certificación completa que incluye:

  • Las fotos o vídeos originales.
  • Pequeños bloques de código en formato Base64.

Esos bloques estandarizados en formato Base64 son la base del concepto de «simetría probatoria» ya que permiten que cualquier persona, incluso fuera de EADTrust, verifique la evidencia de forma independiente (hay muchos sitios web que permiten mostrar el significado de una secuencia Base64, incluyendo la firma electrónica) . Es como si la certificación llevara dentro su propio “manual de instrucciones” para que un juez, un perito o un auditor pueda comprobarlo sin depender de nosotros.

Todo ello está respaldado por sellos de tiempo cualificados de EADTrust, que tienen la mayor robustez criptográfica del mercado entre todos los Prestadores Cualificados de Servicios de Confianza de España y Europa.

Cómo funciona el proceso (paso a paso)

Los procesos digitales no son caóticos. Tienen momentos clave: “en este instante se tomó la foto”, “en este otro se firmó el contrato”, “aquí se envió el informe”, «en este proceso se manejaron ciertos datos, que se concatenaron para formar una evidencia» …En cada uno de esos momentos clave se hace lo siguiente:

  1. Se calcula un hash (una huella digital única e irrepetible del archivo, o de la secuencia de datos.
  2. Ese hash se envía a la autoridad de sellado de tiempo cualificado de EADTrust.
  3. Se genera un sello de tiempo cualificado (que va firmado electrónicamente por EADTrust) que certifica: “este hash existía exactamente en esta fecha y hora, y no ha sido modificado desde entonces”.

Al final del proceso, todas esas evidencias (todos los sellos de tiempo) se enlazan en una certificación única. Y aquí viene lo realmente innovador:

La certificación incluye un preámbulo claro y en lenguaje natural que explica:

  • Qué proceso se estaba siguiendo.
  • Cuáles eran los momentos clave.
  • Por qué cada sello de tiempo se generó en ese punto.

Ese preámbulo es la “explicabilidad” hecha realidad. No es solo un montón de datos técnicos: es una historia verificable que demuestra que se actuó con diligencia debida en un proceso que puede ser delicado.

¿Por qué esto es tan potente?

Porque cumple a la perfección dos principios clave de cualquier prueba electrónica:

  • Independencia: cualquiera puede verificar la evidencia sin depender de EADTrust.
  • Imparcialidad: el sello de tiempo lo pone una tercera parte de confianza cualificada (nosotros), no la propia empresa.

Gracias a la adopción creciente de GoCertius, ahora cualquier entidad que gestione procesos digitales puede demostrar fácilmente que su gestión es diligente y cumple el marco normativo. Ya no hace falta “confiar en mi palabra”. La cadena de sellos de tiempo y el preámbulo explicativo lo demuestran objetivamente.

Explicabilidad… también en la Inteligencia Artificial

Curiosamente, el mismo concepto está ganando terreno en otro ámbito: la Inteligencia Artificial. El Reglamento de IA de la Unión Europea exige que los sistemas de alto riesgo sean “explicables”. Es decir, que no solo tomen decisiones, sino que se pueda entender por qué las tomaron.

En EADTrust creemos que la explicabilidad no es solo un requisito legal. Es la base de la confianza digital del futuro. Ya sea para probar que un contrato se firmó correctamente o para explicar cómo una IA llegó a una conclusión, la combinación de tecnología criptográfica robusta + explicación clara es la fórmula ganadora.

Conclusión: un enfoque innovador que facilita la adopción

Con este modelo de certificación —hash + sello de tiempo + preámbulo explicativo— estamos consiguiendo que el sello de tiempo cualificado de EADTrust deje de ser “solo una firma técnica” para convertirse en una herramienta práctica y comprensible para cualquier empresa o profesional.

Es un enfoque innovador que estamos viendo que está facilitando enormemente su adopción en muchos contextos regulatorios. Porque, al final, la mejor prueba no es la más compleja… es la que cualquiera puede entender y verificar.

¿Quieres probarlo tú mismo? Descarga GoCertius (gratis) y certifica tu primera evidencia en menos de un minuto. O si gestionas procesos más complejos, contáctanos y te mostramos cómo integrar esta explicabilidad en los flujos diarios de tus aplicaciones informáticas. Llama al 917160555.

En EADTrust seguimos trabajando para que la confianza digital sea, sobre todo, explicable.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Este es el documento:

Adaptación de los organismos públicos a la Cartera IDUE: propuesta de hoja de ruta


1. ¿Cuándo debe tener servicios activables por la Cartera IDUE la Administración Pública?

Muchos organismos y ayuntamientos (los que al menos conocen que existirá una «Cartera IDUE») empiezan a inquietarse porque la fecha del 24 de diciembre de 2026 se acerca y no saben qué tienen que hacer ni si recibirán apoyo de organismos más especializados. Otros, los que ni siquiera saben que en 2024 se publicó el Reglamento UE 2024/1083 y que sus disposiciones son obligatorias en toda Europa, no son conscientes de que en Navidades estarán al margen de la Ley y no cumplirán sus obligaciones de dar servicios a sus ciudadanos y mantener los sistemas de interlocución telemática a la que están obligados (en aplicación de otras leyes que también rigen en este nuevo contexto: La Ley 39/2015 «LPACAP» y el RD 203/2021).

Es urgente la adaptación de los organismos públicos que prestan servicios electrónicos, desde los ayuntamientos más pequeños hasta los grandes ministerios, universidades y organismos reguladores.

En un artículo anterior analizaba la adaptación de las entidades financieras a la Cartera de Identidad Digital de la UE (Cartera IDUE o EUDI Wallet), centrándome en su papel como grandes consumidores y emisores de declaraciones de atributos de identidad, y otros específicos de su modelo de negocio. Tiene sentido trasladar ahora la pregunta al sector público:

¿Cómo deben prepararse los ayuntamientos y otros organismos públicos para aceptar la EUDI Wallet a tiempo, antes de finales de 2026, y cómo pueden aprovecharla en casos de uso concretos?

La buena noticia es que muchas administraciones ya cuentan con una base sólida de administración electrónica, Cl@ve, DNIe, sede electrónica y archivo electrónico, carpeta ciudadana que puede reutilizarse.
La mala noticia, vista la proximidad de los plazos, es que las entidades que aún no han iniciado la adaptación a la EUDI Wallet ya van tarde y corren un riesgo evidente de no llegar a tiempo si no actúan con rapidez.


2. Qué es la EUDI Wallet y por qué afecta tanto a ayuntamientos y organismos públicos

La EUDI Wallet, o Cartera IDUE es la Cartera de Identidad Digital de la Unión Europea prevista en el nuevo Reglamento de identidad digital europea y servicios cualificados de confianza digital que modifica Reglamento eIDAS (al nuevo Reglamento se le denomina eIDAS2).

Permitirá a ciudadanos y empresas:

  • Identificarse digitalmente ante servicios públicos y privados en toda la UE.
  • Presentar atributos verificables (edad, domicilio, titulaciones, licencias, calidad de representante, etc.) de forma segura y estandarizada.

Desde la perspectiva de un ayuntamiento o de cualquier organismo público, la EUDI Wallet no es simplemente un nuevo botón en la pantalla de acceso de la sede electrónica:

  • Es un canal europeo estandarizado para autenticación e intercambio seguro de datos y certificados.
  • Permite desplegar de forma real el principio de “solo una vez” (once‑only): dejar de pedir al ciudadano que aporte documentos que ya obran en poder de las administraciones.
  • Facilita trámites transfronterizos, algo cada vez más relevante en ciudades con alta movilidad de estudiantes, trabajadores y jubilados europeos.

En el contexto municipal y regional, algunos de los atributos que podrían gestionarse a través de la EUDI Wallet son:

  • Domicilio de empadronamiento (certificado de empadronamiento).
  • Condición de familia numerosa u otros títulos específicos autonómicos.
  • Titulaciones académicas emitidas por universidades públicas.
  • Licencias y autorizaciones (apertura, obras, terrazas, espectáculos, etc.).
  • Condición de representante de una empresa o entidad ante el ayuntamiento.

3. Marco normativo y plazos: qué debe estar listo para finales de 2026

El Reglamento EIDAS2 establece que todos los Estados miembros deben ofrecer al menos una EUDI Wallet interoperable y gratuita para ciudadanos y empresas el 24 de diciembre de 2026 (24 meses tras la entrada en vigor de los primeros «Reglamentos de ejecución» que se publicaron el 4 de diciembre de 2024).

En paralelo:

La consecuencia práctica es clara:

  • A finales de 2026 deberán existir EUDI Wallets operativas en los Estados miembros. La Cartera IDUE de España ya se presentó en el evento «EUDI Wallet launchpad» organizado por la Comisión Europea los días 10, 11 y 12 de diciembre de 2025 en Bruselas, Bélgica.
  • Se espera que las administraciones públicas estén en condiciones de aceptar la cartera como medio de identificación y de intercambio de atributos en ese mismo horizonte.

En este contexto, el mensaje ya no es “conviene empezar pronto”, sino mucho más contundente:

Las administraciones que deban adaptarse a la EUDI Wallet y no hayan iniciado ya el proceso de análisis y adaptación están, de facto, llegando tarde.

No se trata de generar alarma, pero sí de transmitir que el margen para “experimentar con calma” se está agotando.


4. Impacto en la prestación de servicios electrónicos públicos

La introducción de la EUDI Wallet impacta en varios niveles de la prestación de servicios electrónicos:

4.1. Identificación y acceso a la sede electrónica

La EUDI Wallet se convierte en un nuevo método de autenticación que deberá convivir con los ya existentes (DNIe, Cl@ve, certificados). En la práctica, implicará:

  • Añadir un botón de “Acceder con Cartera de Identidad Digital Europea / EUDI Wallet” en la sede electrónica.
  • Gestionar flujos de autenticación basados en los estándares europeos definidos en el ARF.

4.2. Aportación de documentos y datos

Muchos documentos hoy aportados como PDF escaneados (certificados, justificantes, etc.) pueden transformarse en declaraciones de atributos verificables suministrados por la EUDI Wallet, tras obtenerlos de una Fuente Auténtica a través de un Prestador de Declaraciones de Atributos.

  • El ciudadano ya no sube un PDF de un certificado, sino que autoriza a la cartera a compartir un atributo oficial y verificable con el organismo.

4.3. Automatización del back‑office y reducción de subsanaciones

Al recibir datos estructurados y verificados, los sistemas de gestión pueden:

  • Validar más campos de forma automática.
  • Reducir requerimientos de subsanación por documentación incorrecta o ilegible.
  • Disminuir tiempos de tramitación y cargas administrativas.

5. Casos de uso en ayuntamientos y otros organismos públicos

Para visualizar el impacto real, es útil aterrizar la EUDI Wallet en casos de uso concretos.

5.1. Empadronamiento y certificado de empadronamiento

Caso de uso 1: solicitud de alta en el padrón municipal

  • El ciudadano se identifica con su EUDI Wallet en la sede del ayuntamiento.
  • Autoriza la lectura de atributos de identidad y, eventualmente, de domicilio procedentes de otras administraciones.
  • El ayuntamiento utiliza esos datos para pre‑rellenar el formulario de empadronamiento y verificar la identidad.
  • Una vez completado el trámite (tras las verificaciones pertinentes), el ayuntamiento puede emitir una declaración electrónica de atributo “domicilio empadronado en el municipio X” que el ciudadano incorpora a su cartera.

Caso de uso 2: obtención del certificado de empadronamiento

  • En lugar de descargar un PDF desde la sede, el ciudadano podría:
    • Recuperar desde su EUDI Wallet un atributo de empadronamiento emitido previamente por el ayuntamiento.
    • Presentarlo en otros organismos sin necesidad de solicitar de nuevo el certificado.

5.2. Bonificaciones y ayudas municipales (familia numerosa, transporte, tasas)

Caso de uso 3: bonificación de tasas para familias numerosas

  • La comunidad autónoma emite una declaración de  atributos de “familia numerosa” que el ciudadano guarda en su EUDI Wallet.
  • Al solicitar una bonificación en el IBI, tasas escolares o actividades deportivas, el ciudadano:
    • Se identifica con la EUDI Wallet.
    • Autoriza la transmisión del atributo “familia numerosa”.
  • El sistema municipal valida automáticamente el requisito, sin PDFs ni copias en papel.

Caso de uso 4: ayudas al alquiler u otras ayudas sociales

  • Atributos como situación de desempleo o determinada información tributaria pueden presentarse desde la cartera.
  • El ayuntamiento reduce al mínimo la documentación aportada manualmente y los errores de cumplimentación.

5.3. Licencias urbanísticas y de actividad

Caso de uso 5: solicitud de licencia de obras o apertura de negocio

  • Personas físicas y representantes de empresas se identifican con la EUDI Wallet, presentando atributos de identidad y de representación.
  • Se consumen atributos relativos a:
    • Capacidad de representación de la empresa solicitante.
    • Situación censal o registral de la entidad.
  • El ayuntamiento realiza más rápido las verificaciones previas, reduciendo requerimientos posteriores.

Caso de uso 6: declaraciones responsables y comunicaciones previas

  • En procedimientos basados en declaración responsable, el solicitante puede firmarla electrónicamente a través de credenciales vinculadas a su cartera, reforzando la vinculación jurídica entre identidad, atributos y acto.

5.4. Educación y servicios universitarios en universidades públicas

Caso de uso 7: matrícula y servicios universitarios

  • Estudiantes se identifican con la EUDI Wallet para matricularse o acceder a servicios universitarios.
  • Aportan atributos como:
    • Titulaciones previas.
    • Reconocimiento de discapacidad para bonificaciones.
  • La universidad puede emitir credenciales académicas verificables (títulos, certificados de notas) que el estudiante incorpora a su cartera para trámites futuros, incluso en otros países de la UE.

5.5. Transporte público y servicios metropolitanos

Caso de uso 8: abonos de transporte y tarifas reducidas

  • La autoridad de transporte utiliza la EUDI Wallet para:
    • Identificar al usuario.
    • Verificar atributos como edad, condición de estudiante, familia numerosa o discapacidad.
  • La asignación de tarifas reducidas se automatiza y se evitan múltiples aportaciones de documentos a lo largo del tiempo.

5.6. Reserva de instalaciones deportivas municipales y acceso a las instalaciones

Caso de uso 9: reserva de frontones, piscinas pistas, pabellones y otros espacios deportivos

  • El ciudadano accede a la sede electrónica o al portal de reservas del ayuntamiento.
  • Se identifica con su EUDI Wallet, lo que permite al sistema:
    • Verificar la identidad y, si procede, atributos como edad (por ejemplo, horario o tarifa para menores), condición de estudiante o residente del municipio.
  • El ayuntamiento asocia automáticamente la reserva a la identidad verificada del usuario, reduciendo fraudes o usos de reserva de terceros.
  • En el pago de las tasas (si aplica), el ciudadano puede autorizar, desde la misma cartera, la presentación de atributos necesarios para bonificaciones (familia numerosa, estudiantes, etc.), sin necesidad de presentar documentos adicionales.

Caso de uso 10: autenticación en el acceso físico a las instalaciones

  • En el acceso a las instalaciones deportivas municipales (pabellón, polideportivo, pistas), el usuario puede:
    • Autenticarse mediante la EUDI Wallet en un terminal o punto de control electrónico (lectura de QR, NFC, o integración con sistemas de control de acceso).
    • El sistema valida la identidad y la reserva activa o el pase de uso almacenado en la cartera.
  • En entornos donde se requiera verificación de capacidad de representación (por ejemplo, menor acompañado por un adulto), el ayuntamiento puede validar también ese atributo procedente de la cartera, sin necesidad de presentar documentos en papel en el acceso.

Este doble flujo —reserva online con identidad verificada y acceso físico basado en la misma cartera— convierte a la EUDI Wallet en un elemento articulador entre la administración electrónica y los servicios presenciales, reforzando la seguridad, reduciendo fraudes y mejorando la experiencia de usuario.


6. Relación con Cl@ve, DNIe, Carpeta Ciudadana, certificados y otros medios actuales

España parte de una posición ventajosa gracias a sistemas como Cl@ve, el uso extendido del DNIe y los certificados electrónicos, que ya proporcionan una alta capilaridad de identificación electrónica en servicios públicos. Posiblemente la autenticación por EUDI Wallet se incorpore a las opciones de autenticación por Cl@ve simplificando la adopción de este sistema de autenticación

Pero también habrá organismos que den la opción de autenticación por EUDI Wallet en su propia página web de sede electrónica sin sustituir de un día para otro el resto de sistemas de autenticación:

  • Durante años, veremos un escenario de coexistencia: Cl@ve, certificados, DNIe y EUDI Wallet.
  • Muchas inversiones en infraestructura de administración electrónica, carpeta ciudadana, firma y sello electrónicos y archivo electrónico son directamente reutilizables en el nuevo modelo.

El foco de la transformación se desplaza desde el “cómo identifico al ciudadano” al “cómo gestiono, admito y genero declaraciones de atributos”, donde la EUDI Wallet se convierte en el articulador principal.


7. Hoja de ruta de adaptación para ayuntamientos y organismos públicos

Con los plazos ya tan próximos, la hoja de ruta deja de ser un ejercicio teórico y se convierte casi en un plan de choque para quienes aún no han empezado.

7.1. Gobernanza y planificación del proyecto

La integración de la EUDI Wallet no es un proyecto exclusivamente TIC. Requiere:

  • Un equipo de proyecto con: TIC, servicios jurídicos, administración electrónica/procedimientos, protección de datos y atención ciudadana.
  • Alinear la cartera con proyectos ya en marcha: carpeta ciudadana, archivo electrónico, cita previa, sistemas de gestión interna, etc.

7.2. Análisis de procedimientos y sedes electrónicas

Es imprescindible identificar con rapidez:

  • Procedimientos prioritarios por volumen e impacto (empadronamiento, ayudas, licencias, transporte, educación).
  • Puntos de fricción donde la EUDI Wallet pueda aportar más valor (mucha documentación, colas, subsanaciones reiteradas).

7.3. Integración técnica: ARF, APIs y proveedores

La integración se basará en:

  • Interfaces alineados con el Architectural Reference Framework (ARF) europeo.
  • APIs y SDKs de la solución de EUDI Wallet que despliegue el Estado miembro.
  • Colaboración con prestadores cualificados de servicios de confianza y proveedores especializados en identidad y firma.

7.4. Seguridad, eIDAS2, ENISA y esquemas nacionales de certificación (en España, Lince)

La EUDI Wallet estará sometida a esquemas de certificación de seguridad. Para los organismos públicos eso implica:

  • Tratar la integración con la cartera como una función crítica soportada por TIC, sujeta a análisis de riesgos, medidas de seguridad y continuidad.
  • Alinear las soluciones con marcos nacionales como el Esquema Nacional de Seguridad (a través de «Lince») y la normativa vinculada a NIS2, cuando resulte aplicable.

7.5. Comunicación y gestión del cambio con la ciudadanía

La adopción no será homogénea:

  • Es necesario diseñar campañas informativas explicando qué es la cartera, cómo se obtiene y en qué trámites locales ya aporta ventajas.
  • Deben mantenerse métodos alternativos de acceso, para no discriminar a quienes no usen la cartera.
  • Hay que formar al personal de atención presencial y telefónica para que ayude a los ciudadanos a utilizar la EUDI Wallet.

8. Oportunidades y riesgos de la inacción

La EUDI Wallet abre una ventana de oportunidad para:

  • Aplicar de forma real el principio once‑only.
  • Reducir cargas administrativas para ciudadanía y empresas.
  • Facilitar la movilidad europea en el ámbito local (estudiantes, trabajadores, jubilados, teletrabajadores).

Pero la inacción tiene costes claros:

  • Desfase tecnológico frente a otras administraciones y entidades privadas que ya aceptan la cartera.
  • Proyectos de última hora con sobrecostes y mayor riesgo operativo.
  • Percepción negativa de la ciudadanía, que puede ver a su administración local “a remolque” en identidad digital y servicios electrónicos.

9. Conclusiones: quien no haya empezado, ya llega tarde

Los plazos normativos nos sitúan ante una realidad difícil de ignorar:

  • La EUDI Wallet debe estar operativa a escala de la UE en el entorno de finales de 2026.
  • Las administraciones públicas deberán estar preparadas para aceptarla como medio de identificación y de generación o aceptación de declaraciones de atributos.

En este contexto, el mensaje para ayuntamientos, comunidades autónomas, universidades y otros organismos públicos es claro:

Las entidades que deban adaptarse a la EUDI Wallet y no estén ya trabajando activamente en ello, van tarde.

Eso no significa que sea imposible llegar, pero sí que el margen de maniobra se ha reducido drásticamente.


Los próximos meses deberían concentrarse en:

  • Acelerar la gobernanza y la planificación, sin dilaciones.
  • Priorizar casos de uso de alto impacto como los descritos.
  • Apoyarse en proveedores expertos en identidad digital y servicios de confianza, evitando comenzar desde cero.

La EUDI Wallet no es solo un tema de cumplimiento regulatorio: es una oportunidad estratégica para simplificar trámites, reducir cargas, mejorar la experiencia de la ciudadanía y posicionar a cada administración en el ecosistema europeo de identidad digital. Quien se mueva ahora con decisión aún puede llegar a tiempo; quien siga esperando, probablemente no.

EADTrust acompaña la adaptación a la EUDI Wallet

    Para las administraciones públicas y otros organismos que ya están descubriendo que la adaptación a la EUDI Wallet no es un “próximo proyecto”, sino una prioridad de año 2026, el reto no solo es técnico, sino también de gobernanza, integración y pruebas controladas.

    EADTrust ofrece servicios de consultoría especializada para:

    • Analizar y adaptar los sistemas existentes (sede electrónica, portales de reservas, sistemas de control de acceso, gestión de ayudas, etc.) a un entorno preparado para el uso de la EUDI Wallet.
    • Definir casos de uso prioritarios (empadronamiento, ayudas, licencias, reservas de instalaciones deportivas, educación, etc.) y alinearlos con la hoja de ruta de la entidad pública.
    • Implementar entornos de prueba a modo “sandbox”, donde los organismos públicos pueden:
      • Probar integraciones con la EUDI Wallet.
      • Validar flujos de autenticación y de atributos.
      • Formar a equipos de TIC y de atención ciudadana en un entorno realista pero sin riesgo para la producción.

    Las entidades interesadas en conocer cómo EADTrust puede ayudarles a adaptarse a la EUDI Wallet, a definir proyectos de integración o a acceder a un entorno de prueba, pueden solicitar más información en el sitio web:

    👉 usercentric.id (plataforma de EADTrust dedicada a soluciones de identidad digital y servicios de confianza).

    👉 O llamando al 917160555