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

Deja un comentario

En el PID se incluye un campo de nombre y otro de apellido, pero no se contempla un tratamiento de nombres compuestos españoles y de dos apellidos, que pueden ser tambien 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,

El problema de fondo

El modelo de datos de identificación de persona —el 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 ultima versión en este momento es la 3.0) desarrolla lo anterior en varias piezas: el documento principal; el Annex 1 (Definiciones); el Annex 2 (High-Level Requirements), con requisitos técnicos, algunos específicos del PID; y, sobre todo, el Annex 3.01 – PID Rulebook, que es donde se define el esquema de atributos y sus dos codificaciones, mdoc (ISO/IEC 18013-5) y SD-JWT VC. Como referencia paralela está el Annex 3.02 (mDL Rulebook), y para el ciclo completo, el Annex 4 (emisión y presentación) y el Annex 6 (certificación). Cuando en este artículo se habla de «evolucionar la descripción del PID», el objeto concreto es el Annex 3.01 y el anexo del Reglamento 2024/2977.

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

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

Qué exige el Reglamento sobre estos campos

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

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

Qué le pedimos a una solución provisional

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

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

La solución provisional: la barra inclinada

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

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

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

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

		

Casos límite, resueltos

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

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

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

Ejemplo completo

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

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

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

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

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

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

		

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

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

		

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

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

		

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

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

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

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

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

		

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

		

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

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

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

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

		

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

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

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

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

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

Conclusión

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

Referencias normativas y técnicas

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

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

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

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

Te ayudamos

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

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

Deja un comentario

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

Qué es la European Business Wallet

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

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

Qué ha ocurrido en septiembre

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

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

El recorrido legislativo, en fechas

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

Las dos posiciones que llegan a la mesa

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

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

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

Aspectos clave de la negociación

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

Perspectiva

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

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

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

Candidatura de Ismael Arribas a la Presidencia del Subcomité CTN71/SC307 «Blockchain y tecnologías de registro distribuido»

Deja un comentario

Se ha abierto el plazo para votar las candidaturas a la Presidencia del Subcomité CTN 71/SC 307 «Blockchain y tecnologías de registro distribuido» de UNE. Ismael Arribas es uno de los candidatos a la presidencia.

Cuando Ismael me llamó, me dijo: “sería un honor, si prospera la candidatura, que estés a mi lado como Vicepresidente”. Como Presidente de la Comisión de Blockchain de AMETIC, este ofrecimiento resulta un refuerzo que con gusto estoy dispuesto a compartir con su candidatura.

El subcomité ha funcionado porque ha sabido articular expertos de administraciones, empresas, asociaciones, universidad y prestadores de servicios. Esa es la cultura que conviene preservar.

Gracias a César Pérez-Chirinos

Cualquier relevo que no comience con el agradecimiento sería injusto. César Pérez-Chirinos ha presidido el CTN 71/SC 307 desde su constitución, en marzo de 2017, y lo ha hecho con la discreción, el rigor y la constancia que exige un órgano de normalización.

Bajo su presidencia, España no se limitó a seguir el trabajo internacional: contribuyó a definirlo. El subcomité se alineó con ISO/TC 307 y con CEN/CLC JTC 19, y dio cauce a un hito que todavía hoy se cita como referencia: la UNE 71307-1, primer estándar mundial sobre gestión de identidades digitales descentralizadas basada en blockchain y otras DLT, después elevado al ámbito europeo.

César ha sostenido durante años una posición española coherente en foros donde es fácil fragmentarse. Ha representado al subcomité con la mirada de quien conoce tanto la tecnología como las exigencias de un entorno regulado (su trayectoria en el Banco de España no es un detalle menor) y ha permitido que el trabajo técnico primara sobre las adscripciones de cada uno. Esa es una deuda colectiva. Gracias, César, por el tiempo, por la paciencia institucional y por haber dejado el listón alto.

Ismael Arribas: el candidato que ha estado en todos los frentes de trabajo

Si hay un rasgo que distingue a Ismael Arribas no es la visibilidad puntual, sino la continuidad en los grupos de trabajo. Quienes participan en el ámbito de la normalización saben que el valor no está en la reunión plenaria, sino en las horas de redacción, de comentarios, de «liaisons», de conciliación de textos y de seguimiento de ítems que avanzan a un ritmo distinto en ISO, en CEN-CENELEC, en ETSI o en UIT.

Ismael no ha sido un observador periférico. Ha sido, y es, vicepresidente del propio CTN-UNE 71/SC 307. A escala internacional es convenor del ISO/TC 307/WG 3, Smart contracts and their applications, el grupo que trabaja la taxonomía, la clasificación y el encaje de los contratos inteligentes en sistemas DLT.

Esa responsabilidad no es aislada. Su actividad se ha extendido, de forma sostenida, por varios de los espacios en los que se decide de verdad la agenda:

Convenor del PNE 71308 en UNE, sobre el uso de blockchain y DLT para la gestión de evidencias digitales.
Participación y liaison entre CEN/CLC JTC 19 y ETSI ISG PDL, además de rapporteur en este último.
Cofundador de INATBA y copresidente de su Comité de Estándares.
Enlace entre ISO/TC 307 y ISO/TC 292 (seguridad y resiliencia).
Presencia en ITU-T, incluida la vicepresidencia del grupo de aplicaciones y servicios del Focus Group sobre el metaverso.
Asesoría en normalización para LACChain y el BID Lab.

También ayudó a la gobernanza de Alastria y fue el lider de su comisión de estándares.

Ese mapa no es un currículum ornamental. Es la prueba de que ha invertido esfuerzo en todos los grupos de trabajo relevantes, nacionales e internacionales, no solo en el que le resultaba más cómodo. Quien ha coordinado el WG3 de contratos inteligentes, ha impulsado normas nacionales de evidencias digitales y ha mantenido los puentes con ETSI, CEN-CENELEC, INATBA e ITU entiende la interdependencia real del programa de trabajo: identidad, gobernanza, sostenibilidad, smart contracts, interoperabilidad y usos.

Hay un dato reciente que resume bien esa capacidad de ejecución: Ismael fue el convenor del ISO/TC 307/WG 3 que impulsó la reunión internacional del comité en Valladolid, en junio de 2024, con el apoyo de UNE, del Ayuntamiento y de la Agencia de Innovación de la ciudad. Convertir a España en sede de la plenaria mundial no es un gesto protocolario; es el resultado de años de presencia técnica y de credibilidad ante secretarías y delegaciones.

Por eso su candidatura a la Presidencia es la evolución natural de quien ya ha hecho el trabajo menos vistoso: estar, aportar, convenir y sostener el hilo entre el subcomité español y los foros en los que se escriben las normas que después adoptamos.

Una propuesta para la nueva etapa del CTN 71/SC 307

La candidatura parte de la continuidad con el trabajo realizado desde 2017 y propone reforzar al CTN 71/SC 307 como punto español de referencia para la normalización de blockchain y las tecnologías de registro distribuido. La prioridad será anticipar los ámbitos en los que la normalización pueda aportar interoperabilidad, seguridad jurídica, confianza y capacidad de adopción industrial.

Esto requiere mantener una participación española activa en ISO/TC 307 y CEN/CLC JTC 19, reforzar la coordinación con otros organismos como ETSI e ITU-T y favorecer la participación de administraciones públicas, empresas, pymes, universidades, centros de investigación, prestadores de servicios de confianza y otras organizaciones relevantes.

Especial atención deberán recibir la interoperabilidad, los contratos inteligentes, la gestión de evidencias digitales, la identidad y las credenciales cuando resulte pertinente el uso de DLT, la tokenización, la gobernanza, la sostenibilidad y la relación entre estas tecnologías y los nuevos marcos regulatorios europeos.

La Presidencia supone la coordinación y servicio al Subcomité: facilitar consensos, promover nuevas iniciativas normativas, mejorar la conexión entre los trabajos nacionales e internacionales y favorecer que España mantenga una presencia relevante en la construcción de los estándares que definirán la próxima generación de infraestructuras digitales de confianza.

Animo a las vocalías a ejercer el voto con conocimiento de causa. Y, sea cual sea el resultado, el subcomité seguirá necesitando lo que César practicó durante años: rigor, paciencia y sentido de país.

He sido nominado a los Premios ISACA Madrid 2026 en la categoría Influencer en Seguridad

Deja un comentario

La Junta Directiva de ISACA Madrid ha seleccionado a los finalistas de los Premios ISACA Madrid 2026. Es un honor haber sido incluido en la categoría Influencer en Seguridad, junto a Marta Barrio Marcos y Mónica Valle.

Estos premios reconocen a profesionales que, con su trabajo, su visión y su compromiso, han dejado huella en la ciberseguridad, la auditoría y el gobierno de las tecnologías de la información. En el caso de la categoría de Influencer en Seguridad, se trata de quienes contribuyen a que la seguridad importe más allá del ámbito estrictamente técnico y la acercan a públicos más amplios.

Agradezco a ISACA Madrid la nominación y a quienes hayan propuesto o apoyado la candidatura. El reconocimiento de los compañeros de profesión siempre tiene un valor especial.

En este blog, Todo es electrónico, llevo años insistiendo en una idea sencilla y exigente a la vez: la transformación digital solo es real si no se pierde el valor probatorio. No basta con firmar, identificar o archivar; hay que conservar la finalidad jurídica del acto a lo largo del tiempo. De ahí la atención a la identidad digital centrada en el usuario, a eIDAS 2 y a la Cartera IDUE, a los servicios de confianza cualificados, a la custodia digital, a la factura electrónica, a la prueba en el ámbito judicial y, más recientemente, a la criptoagilidad y a la transición postcuántica. La seguridad, en este enfoque, no es un añadido técnico: es la condición para que lo digital produzca los mismos efectos jurídicos que el papel, o mejores.

Cómo votar

La votación corresponde en exclusiva a los asociados de ISACA Madrid. Se puede votar en una, en dos o en las tres categorías.

Plazo: hasta el 4 de octubre de 2026.
Formulario de votación: (cada miembro de ISACA recibe su enlace)

Los premios se entregarán el jueves 29 de octubre de 2026 durante la XIV edición del Congreso CiberTodos, en El Beatriz (Calle José Ortega y Gasset, 29, Madrid), en el marco del Mes Europeo de la Ciberseguridad.

Si eres asociado de ISACA Madrid y consideras que esta línea de divulgación —identidad digital, servicios de confianza, documento electrónico y seguridad jurídica preventiva— merece tu voto en la categoría Influencer en Seguridad, te lo agradezco de antemano.

En cualquier caso, enhorabuena a todos los finalistas. El nivel de las tres categorías es muy alto y eso habla bien de la comunidad.

Más información en la publicación en LinkedIn de ISACA Madrid:
https://www.linkedin.com/posts/premiosisacamadrid-share-7503787710906626049-GU4S

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

Deja un comentario

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

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

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

Calendario de la semana

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

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

Lunes 14 — ETSI ESI CA Open Session

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

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

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

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

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

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

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

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

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

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

Kultuurikatel – Tallinn Creative Hub

Página del evento

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

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

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

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

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

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

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

Por qué esta semana importa

En cuatro días se encadenan:

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

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

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

Criptocalipsis, criptoagilidad y transición postcuántica: preparando el marco legal

Deja un comentario

La amenaza cuántica a la criptografía ha dejado de ser un debate académico para convertirse en un problema de gobierno, de cumplimiento y de responsabilidad de los administradores. Y ya empiezan a confirmarse movimientos regulatorios. Y esos movimientos no son solo nacionales: mientras España perfila su plan de migración, la Unión Europea prepara su propio Quantum Act y el Parlamento Europeo debate cómo convertir su liderazgo científico en liderazgo industrial y en soberanía tecnológica.

Durante años, la computación cuántica se consideró una promesa lejana y los riesgos para la criptografía serían una amenaza remota. Ese relato ha cambiado. Uno de los aspectos, el riesgo relevante para la seguridad de la información no es que exista mañana un ordenador cuántico capaz de romper la criptografía asimétrica actual con el Algoritmo de Shor (RSA, curva elíptica), sino un fenómeno que ya está ocurriendo hoy: el «recolecta ahora, descifra después» (harvest now, decrypt later). Un adversario puede capturar y almacenar hoy tráfico y datos cifrados para descifrarlos cuando disponga de esa capacidad. Todo dato con vida útil larga —historias clínicas, expedientes, secretos industriales, información clasificada— está, en la práctica, ya expuesto. De ahí que una palabra clave que representa la preparación para resistir los ataques es criptoagilidad: la capacidad de una organización de inventariar, sustituir y actualizar sus mecanismos criptográficos con rapidez y sin traumas.

1. El CCN marca el paso, con foco en el sector público

El Centro Criptológico Nacional (CCN) ha actualizado estos días su doctrina criptográfica para orientar la adopción de la criptografía postcuántica, con especial atención al sector público. La guía de buenas prácticas CCN-TEC 009, «Recomendaciones para una transición postcuántica segura» (julio de 2026), se suma a la CCN-STIC 221 de mecanismos criptográficos autorizados (noviembre de 2025) y al aviso expreso del CCN-CERT sobre los graves riesgos que la amenaza cuántica supone para la seguridad de la información y la llamada a prepararse frente a ella. El mensaje institucional es inequívoco: la migración no admite demoras y debe planificarse ya, empezando por inventariar qué se protege, con qué algoritmos y durante cuánto tiempo.

En el plano técnico, el destino está razonablemente definido: los estándares de criptografía postcuántica del NIST ya publicados: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) y el FIPS 206 (FN-DSA) pendiente de publicar, fijan los algoritmos de referencia, y organismos como ENISA y ETSI vienen empujando la migración. Lo difícil no es elegir el algoritmo, sino gobernar la transición en organizaciones con miles de sistemas y dependencias.

2. Hacia una cobertura legal: norma y sentido de urgencia

Lo relevante de este momento es que la iniciativa técnica está recibiendo cobertura legal. Se prepara una norma —previsiblemente un real decreto— que dé amparo jurídico a la transición postcuántica y, sobre todo, transmita sentido de urgencia a administraciones y operadores. No es un gesto aislado: en el 40.º Encuentro de la Economía Digital y las Telecomunicaciones de AMETIC, en Santander, el Gobierno anunció un plan de migración a criptografía postcuántica con horizonte de inicio en torno a 2030-2031 para los sistemas más críticos, articulado en cuatro ejes: inventario de sistemas a migrar (empezando por la Administración General del Estado), calendario de transición por criticidad de los datos, impulso de un ecosistema empresarial español y regulación y apoyo al desarrollo tecnológico propio, con el CCN como interlocutor técnico. Que se hable de calendario y de norma es la señal de que la criptoagilidad pasa de recomendación a obligación gestionada.

3. Las Cortes también analizan el riesgo

El impulso no es solo del Ejecutivo. En sede parlamentaria, la Comisión Mixta de Seguridad Nacional (Congreso-Senado) constituyó una Ponencia de análisis de las amenazas en el ciberespacio, en la era de la Inteligencia Artificial y la Computación Cuántica —creada el 19 de septiembre de 2024—, cuyo informe de riesgos y recomendaciones se aprobó el 24 de marzo de 2026. Que las Cortes hayan analizado formalmente estos riesgos —incluidos, de forma destacada, los que la computación cuántica proyecta sobre la criptografía— y hayan emitido recomendaciones es una señal potente: el asunto ha dejado de ser un tecnicismo del CISO para convertirse en materia de política pública y, potencialmente, de futura legislación.

4. Banca y DORA: la criptoagilidad como deber de buena administración

En el sector financiero, el marco ya existe y se llama DORA (Reglamento (UE) 2022/2554 de resiliencia operativa digital, aplicable desde el 17 de enero de 2025). DORA obliga a las entidades a una gestión rigurosa del riesgo TIC —incluidos el cifrado y la protección de datos— y crea el terreno natural para desarrollar iniciativas de criptoagilidad ante la inminencia del riesgo cuántico. Y lo hace con una lectura que interesa subrayar: la preparación frente a estos riesgos forma parte del deber de diligencia de los administradores, de lo que cabe llamar una «buena administración» digital. No anticipar un riesgo conocido, documentado por los organismos técnicos y con estándares ya disponibles, es difícilmente defendible desde el punto de vista de la responsabilidad de administradores y directivos. El énfasis, además, está en la protección de los usuarios bancarios, cuyos datos y operaciones no pueden quedar expuestos a la ventana del «recolecta ahora, descifra después».

5. El ecosistema español y AMETIC

La otra cara de la moneda es industrial: el sector de la computación cuántica se está desarrollando en España, y sus principales empresas se agrupan en torno al grupo de trabajo de Tecnologías Cuánticas de AMETIC. En el 40.º Encuentro de la Economía Digital y las Telecomunicaciones (Santander, #SANTANDER40, septiembre de 2026), AMETIC entregó sus Premios de Tecnologías Cuánticas 2026 —con reconocimientos a Kilimanjaro Quantum Tech y GMV— y concedió una mención especial a Garrigues por su coautoría de un informe pionero a nivel internacional sobre regulación, ética y gobernanza de las tecnologías cuánticas, acompañado del lanzamiento de un observatorio digital de acceso libre. Es un reconocimiento significativo, porque subraya algo que a veces se pasa por alto: la transición postcuántica no es solo un reto criptográfico, sino también jurídico y ético —gobernanza del riesgo, responsabilidad, protección de derechos— y ese marco hay que construirlo con rigor.

6. La dimensión europea: el Parlamento Europeo y el futuro Quantum Act

El movimiento no se limita a España. A comienzos de septiembre de 2026, el Parlamento Europeo acogió el encuentro de alto nivel «Europe’s Quantum Moment: From Lab to Leadership», organizado por el eurodiputado Sergey Lagodinsky, que reunió a representantes de la Comisión, el Consejo y el propio Parlamento con investigadores, líderes empresariales e inversores del ámbito cuántico. El diagnóstico compartido fue nítido: Europa es líder indiscutible en ciencia cuántica (aporta en torno al 80 % de los componentes que se emplean en los ordenadores cuánticos europeos), pero corre el riesgo de no traducir esa excelencia en tejido industrial. Tommaso Calarco, secretario del Consejo Asesor de Alto Nivel sobre Tecnologías Cuánticas, lo resumió en tres palabras: «dinero, velocidad y hacer las cosas juntos» y en una advertencia: «este es el último tren que pasa para Europa».

Sobre esa urgencia se proyecta el futuro Quantum Act, la norma europea que la Comisión prevé presentar hacia finales de 2026, con posible deslizamiento a 2027. No se concibe como una regulación restrictiva, sino como un «marco habilitador» que se apoya en la Estrategia Cuántica Europea y complementa iniciativas como el Chips Act, EuroHPC o IRIS². Persigue tres objetivos: impulsar la investigación y la innovación, escalar la capacidad industrial (líneas piloto e instalaciones de diseño y fabricación) y reforzar la resiliencia de la cadena de suministro y su gobernanza. Su consulta pública previa (la call for evidence) invitó expresamente a contribuir, entre otros, a los expertos en ciberseguridad y a los organismos de normalización, lo que enlaza directamente con el hilo de este artículo: la soberanía cuántica europea no es solo cuestión de fabricar hardware, sino también de gobernar la criptografía que protege los datos europeos.

Ahí es donde ambas caras de la moneda se encuentran. La cara industrial (consolidar un ecosistema hoy fragmentado en unas 78 startups sin campeones europeos comparables a Microsoft, Google o IBM, como reconoció Thomas Skordas de la DG CNECT) y la cara defensiva (la criptoagilidad y la transición postcuántica) forman parte del mismo objetivo de autonomía estratégica: «Europa puede liderar; podemos abastecernos a nosotros mismos; podemos decidir por nosotros mismos», en palabras de Cecile Perrault del «European Quantum Industry Consortium». El reto, además del capital (unos 2.000 millones de euros invertidos por la UE entre 2020 y 2025, más cerca de 9.000 millones de los Estados miembros), es de coordinación y de talento: como advirtió la profesora Eleni Diamanti, «el talento va donde están los líderes globales, no solo donde está el dinero». Para las organizaciones españolas, el mensaje es doble: el marco de referencia de la transición postcuántica ya no es únicamente el CCN o DORA, sino también un futuro Quantum Act que situará la seguridad, la resiliencia y la gobernanza cuánticas en el centro de la política industrial europea.

7. De la doctrina a la práctica: formación y acompañamiento

Garrigues es el principal accionista de EADTrust, y esa combinación —firma jurídica de referencia y agencia especializada en confianza digital— es exactamente la que hace falta para traducir todo lo anterior en acción. Desde EADTrust desarrollamos formación «In Company» que describe el marco legal que impulsa la adopción de la criptoagilidad: qué exige el CCN, qué implica DORA, qué responsabilidad recae en los administradores y cómo se convierte todo eso en un plan de inventario, priorización y migración criptográfica realista. Porque el obstáculo, en la mayoría de las organizaciones, no es la falta de algoritmos, sino la falta de gobernanza: quién es responsable, con qué calendario, con qué evidencias y bajo qué obligaciones.

Formación y Servicios Profesionales de EADTrust

La criptoagilidad y la transición postcuántica ya no son un ejercicio de futuro: el CCN marca el paso, se prepara cobertura normativa, el Senado analiza la necesidad de regular y DORA convierte la preparación en un deber de buena administración. En EADTrust (European Agency of Digital Trust) participada mayoritariamente por Garrigues, distinguida con una mención especial en los Premios de Tecnologías Cuánticas 2026 de AMETIC por su informe sobre regulación, ética y gobernanza de las tecnologías cuánticas, ayudamos a empresas y organismos a anticiparse.

Ofrecemos:

Formación «In Company» sobre computación cuántica y el marco legal que impulsa la criptoagilidad, con dos ponentes complementarios:
- Jorge Christen, creador de la metodología ENSAR (Experience-Name-Speak-Apply-Repeat), lleva a los asistentes desde no saber nada de física cuántica hasta programar programas sencillos en el simulador de computación cuántica de IBM, sin requerir conocimientos previos.
- Ainhoa Inza aborda el marco legal, la estandarización del NIST, la descripción de los algoritmos criptográficos (clásicos y postcuánticos) y el marco de criptoagilidad (CCN, DORA, responsabilidad de los administradores y hoja de ruta postcuántica).
Servicios profesionales de acompañamiento: análisis de impacto normativo, inventario de activos criptográficos, plan de criptoagilidad y priorización de la migración por criticidad.

Si tu organización puede verse impactada por la computación cuántica —sector público, banca y finanzas, sanidad, infraestructuras críticas o cualquier tratamiento de datos con vida útil larga—, hablemos. Contacta por correo electrónico en info@eadtrust.com o por teléfono en el 917 160 555 (también 902 365 612). Más información en eadtrust.com.

Fuentes

CCN-TEC 009 — Recomendaciones para una transición postcuántica segura (julio 2026)
CCN-STIC 221 — Mecanismos criptográficos autorizados por el CCN (nov. 2025)
CCN-CERT — Advertencia sobre la amenaza cuántica
España prepara un calendario de migración a criptografía postcuántica (AMETIC Santander)
Ponencia sobre amenazas en el ciberespacio (IA y computación cuántica) — Comisión Mixta de Seguridad Nacional (Senado)
Informe de la Ponencia (Cortes Generales, PDF) · Diario de Sesiones de la Comisión Mixta de Seguridad Nacional
Garrigues recibe una mención especial de AMETIC en tecnologías cuánticas · AMETIC — Premios de Tecnologías Cuánticas 2026
Reglamento (UE) 2022/2554 (DORA)
NIST FIPS 203 (ML-KEM) · FIPS 204 (ML-DSA) · FIPS 205 (SLH-DSA)
The Quantum Insider :»Europe Looks to Quantum Act to Turn Research Strength Into Industry»: https://thequantuminsider.com/2026/09/04/europe-looks-to-quantum-act-to-turn-research-strength-into-industry/
Silicon Republic: «Quantum funding only a part of the solution, EU experts say»: https://www.siliconrepublic.com/innovation/quantum-technology-european-union-commission-funding
Comisión Europea: «Commission invites contributions to shape the future EU Quantum Act»: https://digital-strategy.ec.europa.eu/en/news/commission-invites-contributions-shape-future-eu-quantum-act

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

Deja un comentario

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

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

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

Qué es la European Business Wallet

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

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

Encaje en eIDAS2

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

Recorrido legislativo

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

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

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

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

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

Puntos de debate

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

Calendario de aplicación previsible

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

Qué aspectos requerirán nuestra atención

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

Servicios Profesionales de EADTrust

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

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

Fuentes

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

Deja un comentario

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ón	Normas ETSI / CEN citadas
CIR (UE) 2024/2979 [ES · EN]	EN 319 122-1; EN 319 132-1; EN 319 142-1; TS 119 182-1; EN 319 162-1/-2
CIR (UE) 2024/2981 [ES · EN]	CEN EN 17640 (+ EN ISO/IEC 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 act	ETSI / CEN standards cited
CIR (EU) 2024/2979 [ES · EN]	EN 319 122-1; EN 319 132-1; EN 319 142-1; TS 119 182-1; EN 319 162-1/-2
CIR (EU) 2024/2981 [ES · EN]	CEN EN 17640 (+ EN ISO/IEC 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.

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

Deja un comentario

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

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

1. Legislación

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

2. Terminología

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

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

3. Organismos

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

4. URLs y recursos

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

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

Documento de Propuesta de Cambios

@firma_tabla_cambios_actualizacion_2026

Afirma_tabla_cambios_actualizacion_2026 Descarga

Documento actualizado incorporando los cambios

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

Afirma_procedimiento_actualizado-2026 Descarga

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

Se acaban de publicar tres nuevos actos de ejecución del Reglamento eIDAS 2 que actualizan aspectos de la gestión de Carteras IDUE

1 respuesta

Ayer, 22 de julio de 2026 el Diario Oficial de la Unión Europea publicó tres nuevos reglamentos de ejecución de la Comisión, todos ellos adoptados el 15 de julio de 2026, que continúan tejiendo el andamiaje normativo del Reglamento (UE) 2024/1183 (eIDAS 2) y de la Cartera Europea de Identidad Digital (Cartera IDUE / EUDI Wallet).

Los tres comparten un mismo hilo conductor —y un mismo título revelador: «en lo que respecta a las normas y especificaciones aplicables»—. No introducen figuras nuevas, sino que modifican actos de ejecución ya vigentes para alinear sus especificaciones técnicas con la evolución de la Arquitectura y el Marco de Referencia (ARF), que acaba de actualizarse a la versión 3.0.0. Dicho de otro modo: la Comisión está poniendo al día las remisiones a normas ETSI, perfiles y procedimientos para que el texto reglamentario no se quede atrás respecto de la ingeniería de la cartera.

El momento no es casual. Con el plazo del 24 de diciembre de 2026 —fecha en la que los Estados miembros deben poner al menos una cartera a disposición de la ciudadanía— cada vez más cerca, esta tanda de normas afina tres piezas sensibles del ecosistema: el registro de las partes usuarias (relying parties), el núcleo funcional de la propia cartera y las declaraciones electrónicas de atributos. A continuación, la lista con lo esencial de cada uno.

Para quien siga el hilo de este blog, estos tres textos no son una sorpresa: ya los comenté cuando se publicaron como borradores, en Nuevos borradores de actos de ejecución en relación con #eIDAS2 y la EUDI Wallet (febrero de 2026). Desde entonces he seguido cubriendo los desarrollos normativos —el último acto que reseñé fue el Reglamento de Ejecución (UE) 2026/798, sobre la incorporación a distancia de usuarios a la Cartera IDUE— y mantengo al día la lista completa de actos de ejecución que acompañan a #eIDAS2 que publiqué el 2 de febrero de 2026 en la que iré incorporando estas tres novedades.

Los 3 Reglamentos de Ejecución

1. Reglamento de Ejecución (UE) 2026/1730

Fecha: adoptado el 15 de julio de 2026; publicado en el DOUE el 22 de julio de 2026.
Qué modifica: el Reglamento de Ejecución (UE) 2025/848, de 6 de mayo de 2025, sobre el registro de las partes usuarias de las carteras (wallet-relying parties).
En breve: actualiza las normas y especificaciones aplicables al registro de las partes usuarias. Entre los ajustes destaca el reforzamiento de la información de transparencia —por ejemplo, que las partes usuarias faciliten una URL a su política de privacidad en relación con el uso previsto de la cartera—.
Entrada en vigor: a los veinte días de su publicación (11 de agosto de 2026).
Texto completo: Español · English.

2. Reglamento de Ejecución (UE) 2026/1731

Fecha: adoptado el 15 de julio de 2026; publicado en el DOUE el 22 de julio de 2026.
Qué modifica: de una sola vez, los cuatro reglamentos del núcleo normativo de la cartera adoptados el 28 de noviembre de 2024:
- (UE) 2024/2977 — datos de identificación de la persona (DIP / PID) y declaraciones electrónicas de atributos expedidas a las carteras;
- (UE) 2024/2979 — integridad y funcionalidades básicas de las carteras;
- (UE) 2024/2980 — notificaciones a la Comisión relativas al ecosistema de la cartera;
- (UE) 2024/2982 — protocolos e interfaces que admitirá el marco europeo de identidad digital.
En breve: es la modificación de mayor alcance de la tanda. Pone al día las normas y especificaciones técnicas del corazón de la cartera para reflejar la nueva versión del ARF, garantizando la interoperabilidad transfronteriza.
Entrada en vigor: a los veinte días de su publicación.
Texto completo: Español · English.

3. Reglamento de Ejecución (UE) 2026/1735

Fecha: adoptado el 15 de julio de 2026; publicado en el DOUE el 22 de julio de 2026.
Qué modifica: el Reglamento de Ejecución (UE) 2025/1569, de 29 de julio de 2025, sobre las declaraciones electrónicas cualificadas de atributos (DECA / QEAA) y las declaraciones electrónicas de atributos expedidas por un organismo del sector público responsable de una fuente auténtica (o en su nombre).
En breve: actualiza los requisitos de expedición y revocación de estas declaraciones y —novedad relevante— introduce la firma o sellado de los resultados de la verificación frente a fuentes auténticas, exigiendo al menos una firma electrónica avanzada basada en certificado cualificado (o un sello electrónico avanzado basado en certificado cualificado). Incorpora remisiones a normas ETSI (TS 119 471 y TS 119 478) y contó con dictamen del Supervisor Europeo de Protección de Datos (SEPD) de 17 de abril de 2026.
Entrada en vigor: a los veinte días de su publicación (11 de agosto de 2026), con una salvedad: el artículo 1.3 se aplica desde el 1 de enero de 2027.
Texto completo: Español · English.

La velocidad en la generación de normas conlleva que pueda ser necesaria su modificación

Vistos en conjunto, estos tres reglamentos confirman la tendencia de los últimos meses: el marco de eIDAS 2 ya no crece tanto en nuevas piezas como en mantenimiento fino de las existentes, sincronizándolas con un ARF vivo. Para quienes desarrollan carteras, actúan como partes usuarias o emiten declaraciones de atributos, el mensaje operativo es claro: conviene revisar las referencias normativas actualizadas antes del hito de nochebuena, con especial atención a la transparencia hacia el usuario (2026/1730) y a la firma/sellado de las verificaciones frente a fuentes auténticas (2026/1735).

Referencias

Reglamento de Ejecución (UE) 2026/1730 — DOUE 22/07/2026 · BOE/DOUE · ELI
Reglamento de Ejecución (UE) 2026/1731 — DOUE 22/07/2026 · BOE/DOUE · ELI
Reglamento de Ejecución (UE) 2026/1735 — DOUE 22/07/2026 · BOE/DOUE · ELI
Actos base modificados: 2025/848 (registro de partes usuarias) · 2024/2977 · 2024/2979 · 2024/2980 · 2024/2982 · 2025/1569

Antecedentes en este blog:

Nuevos borradores de actos de ejecución en relación con #eIDAS2 y la EUDI Wallet (20/02/2026) — estos tres reglamentos en fase de borrador.
Publicado el nuevo Reglamento de Ejecución (UE) 2026/798 para el desarrollo de la Cartera IDUE (09/04/2026) — último acto reseñado hasta ahora.
Lista completa de actos de ejecución que acompañan a #eIDAS2 / Complete list of implementing acts accompanying #eIDAS2 (02/02/2026) — catálogo completo.