Obligación de notificación para los fabricantes de monederos: qué se aplica desde el 11 de septiembre de 2026

Desde el 11 de septiembre de 2026 se aplica en toda la UE una obligación que antes no existía en esta forma: quien comercialice en el mercado europeo un producto con elementos digitales debe notificar a los organismos competentes, en un plazo de 24 horas, toda vulnerabilidad activamente explotada, e informar a los usuarios afectados sobre esa vulnerabilidad y sobre las contramedidas que ellos mismos pueden adoptar.

Para ti, como tenedor de criptomonedas, la segunda parte es la más importante. Está en el artículo 14, apartado 8, del Reglamento europeo de ciberresiliencia y desplaza la cuestión de quién debe procurar que te enteres de un problema en tu monedero. Hasta ahora era un asunto de cultura empresarial. A partir de ahora es una obligación jurídica con un régimen de multas detrás.

Este texto explica qué se aplica exactamente, desde cuándo, a quién, y dónde discurre la frontera entre la situación jurídica acreditada y la sobreinterpretación. Porque el reglamento no menciona ni una sola marca de monedero, y quien deduzca de él una lista de fabricantes afectados escribe más de lo que allí figura.

Qué se aplica desde el 11 de septiembre de 2026: el artículo 14 del Reglamento de ciberresiliencia

El Reglamento de ciberresiliencia es el Reglamento (UE) 2024/2847, conocido en la jerga como Cyber Resilience Act o, abreviado, CRA. El CRA entró en vigor el 10 de diciembre de 2024, pero no se aplica en su totalidad hasta el 11 de diciembre de 2027. El artículo 71, apartado 2, contiene al respecto una frase que trastoca todo el calendario: «El presente Reglamento será aplicable a partir del 11 de diciembre de 2027. No obstante, el artículo 14 será aplicable a partir del 11 de septiembre de 2026, y el capítulo IV (artículos 35 a 51) será aplicable a partir del 11 de junio de 2026.»

El artículo 14 lleva el título «Obligaciones de notificación de los fabricantes» y es, por tanto, la parte del reglamento que se activó primero. Todo lo demás —la evaluación de la conformidad, el marcado CE, los requisitos esenciales de ciberseguridad del anexo I— no llega hasta 2027. Así que quien lea ahora que el CRA se aplica se refiere a ese único artículo.

La esencia en una frase: un fabricante debe notificar toda vulnerabilidad activamente explotada en su producto y todo incidente grave de seguridad simultáneamente al CSIRT designado como coordinador y a la Agencia de la Unión Europea para la Ciberseguridad, ENISA, a través de una plataforma única de notificación.

¿Qué es un CSIRT? Un Computer Security Incident Response Team es el organismo designado por un Estado miembro que recibe, evalúa y transmite los incidentes de seguridad. En Alemania, el CERT-Bund, dentro de la Oficina Federal de Seguridad de la Información, es el CSIRT coordinador, y el BSI asume al mismo tiempo la vigilancia del mercado.

¿Qué es una vulnerabilidad activamente explotada? Un fallo de seguridad del que el fabricante sabe que los atacantes ya lo están utilizando. Una brecha teórica que alguien ha encontrado en el laboratorio no pone en marcha el reloj de las 24 horas. El abuso en la práctica, sí.

Por qué un reglamento de productos afecta a tu monedero de criptomonedas

El CRA no es derecho financiero ni derecho de los criptoactivos. Es derecho horizontal de productos y no se interesa por los valores que gestiona un aparato, sino únicamente por si se trata de un producto con elementos digitales y por si se comercializa en el mercado de la Unión. Precisamente eso lo hace relevante para la custodia de criptomonedas.

Un monedero de hardware es un aparato físico con firmware que se comunica con un programa acompañante por USB, Bluetooth o código QR. Una aplicación de monedero es software que un proveedor pone a disposición para su descarga. Por su arquitectura, ambos son lo que el artículo 3, punto 1, describe como «un producto de software o de hardware y sus soluciones de tratamiento de datos a distancia». El artículo 2, apartado 1, traza el límite a través de la conexión: el reglamento se aplica a los productos cuya finalidad prevista o uso razonablemente previsible incluya «una conexión de datos lógica o física, directa o indirecta, a un dispositivo o red».

Para la custodia de criptomonedas, ese es el punto en el que algo cambia. Si custodias tus fondos tú mismo, tu seguridad depende exactamente de dos cosas: de la calidad del aparato o del software, y de que te enteres a tiempo cuando algo no funciona. Sobre lo primero, la obligación de notificación todavía no dice nada; los requisitos correspondientes no se aplican hasta 2027. Sobre lo segundo, dice algo desde ya. Qué aparatos hay disponibles y en qué se diferencian lo encuentras en nuestra comparativa de carteras de hardware; para las soluciones puramente de software valen las mismas consideraciones con otra superficie de ataque.

Producto con elementos digitales: quién es fabricante según el test jurídico

Que un aparato o una aplicación concretos estén cubiertos lo deciden tres pasos de comprobación. No existe una lista de productos afectados. Primero: ¿se comercializa el producto en el mercado de la Unión, es decir, se suministra para su distribución o uso en el marco de una actividad comercial? Segundo: ¿es un producto de software o de hardware en el sentido del artículo 3? Tercero: ¿incluye su finalidad prevista o su uso razonablemente previsible una conexión de datos directa o indirecta?

Un monedero de hardware conectado y distribuido comercialmente y una aplicación de monedero ofrecida por una empresa pueden cumplir esas tres preguntas. Se trata de una aplicación del test jurídico y no de una constatación oficial para un producto determinado. Quien de ello concluya que tal o cual proveedor debe ahora hacer tal o cual cosa afirma algo que no respaldan ni el reglamento ni las directrices de la Comisión.

Importa además dónde tiene su sede el fabricante. El artículo 14, apartado 7, lo regula con detalle: es determinante el CSIRT del Estado miembro en el que el fabricante tiene su establecimiento principal en la Unión, es decir, allí donde se adoptan mayoritariamente las decisiones sobre la ciberseguridad de sus productos. Si no tiene ningún establecimiento en la Unión, se aplica un orden: primero el Estado miembro del representante autorizado, después el del importador, después el del distribuidor y, por último, el Estado miembro en el que se encuentra el mayor número de usuarios. Un proveedor de fuera de Europa no queda, por tanto, automáticamente al margen desde el momento en que atiende al mercado europeo.

24 horas, 72 horas, 14 días: la cadena de plazos del artículo 14, apartado 2

El reglamento exige tres informes que se apoyan uno en otro. Todos los plazos comienzan en el momento en que el fabricante tiene conocimiento.

1. Alerta temprana, a más tardar 24 horas después de tener conocimiento. La alerta temprana debe indicar en qué Estados miembros se ha comercializado el producto afectado, según el conocimiento del fabricante. El reglamento no exige más en este punto, y es deliberado: la alerta temprana debe ser rápida, no completa.
2. Notificación de la vulnerabilidad, a más tardar 72 horas después de tener conocimiento. Se añaden entonces datos generales sobre el producto afectado, sobre la naturaleza de la explotación y de la vulnerabilidad, sobre las medidas correctoras o de mitigación ya adoptadas y, expresamente, también sobre las «medidas correctoras o de mitigación que los usuarios pueden adoptar».
3. Informe final, a más tardar 14 días después de que esté disponible una medida de mitigación. Contiene una descripción de la vulnerabilidad, con su gravedad y sus efectos, cuando esté disponible información sobre los atacantes, e información sobre la actualización de seguridad u otra medida correctora.

Para el incidente grave de seguridad del artículo 14, apartado 3, vale la misma división entre 24 y 72 horas, pero allí el informe final debe presentarse un mes después de la notificación de las 72 horas. Cuándo un incidente se considera grave lo define el apartado 5: cuando afecta a la capacidad del producto de proteger la disponibilidad, la autenticidad, la integridad o la confidencialidad de datos o funciones sensibles, o cuando ha dado lugar o puede dar lugar a la ejecución de código malicioso.

La notificación se cursa a través de la CRA Single Reporting Platform que gestiona la ENISA. El fabricante transmite una sola vez, y la notificación se pone a disposición del CSIRT coordinador competente y de la ENISA al mismo tiempo. Tras el informe final, la persona notificante ya no puede, por regla general, editar la comunicación.

Artículo 14, apartado 8: cuándo debe informarte el fabricante a ti

Los plazos frente al CSIRT y a la ENISA son la parte sobre la que escribe la prensa del sector. Para ti, como usuario, la frase decisiva está en otro sitio, concretamente en el artículo 14, apartado 8. Ligeramente abreviada, dispone que, después de que el fabricante haya tenido conocimiento de una vulnerabilidad activamente explotada o de un incidente grave de seguridad, «informará a los usuarios afectados del producto con elementos digitales y, en su caso, a todos los usuarios sobre esa vulnerabilidad o ese incidente grave y, cuando sea necesario, sobre cualquier medida de mitigación del riesgo y medida correctora que los usuarios puedan aplicar».

Tres puntos de ello merecen una lectura atenta.

Primero: la obligación se engancha al mismo conocimiento que la notificación a las autoridades. El desencadenante es el mismo momento. El reglamento, sin embargo, no fija ninguna cifra de horas para la información a los usuarios. Lo que se exige es una información vinculada a la toma de conocimiento, y en otro lugar el texto atiende al carácter oportuno. Quien convierte las 24 horas previstas para la autoridad en un plazo de 24 horas frente a los clientes lee mal el precepto.

Segundo: hay que informar sobre las contramedidas que tú mismo puedes adoptar. Ese es el núcleo práctico. Una comunicación que solo dice que hubo un problema no cumple la letra del precepto si existen medidas que los usuarios pueden adoptar por su cuenta. En un monedero, esas medidas son precisamente las relevantes: actualizar el firmware, no usar temporalmente una función determinada, mover fondos a una dirección nueva, comprobar manualmente una firma antes de confirmarla.

Tercero: el reglamento desea un formato legible por máquina. El texto habla de un formato estructurado y legible por máquina, fácil de procesar automáticamente, y lo matiza con «en su caso». Para los investigadores de seguridad y para los portales que agregan avisos, esa es la formulación más interesante de todo el apartado.

¿Qué ocurre si el fabricante calla? El papel del CERT-Bund

La segunda frase del apartado 8 es la palanca verdaderamente nueva: «Cuando el fabricante no informe oportunamente a los usuarios del producto con elementos digitales, los CSIRT designados como coordinadores podrán facilitar dicha información a los usuarios cuando lo consideren proporcionado y necesario para prevenir o mitigar los efectos de esas vulnerabilidades o incidentes.»

Con ello consta en el derecho europeo que una autoridad puede informar al público sobre una vulnerabilidad de un producto cuando el fabricante no lo hace a tiempo. Para Alemania esto significa, concretamente: el CERT-Bund del BSI recibe la notificación como CSIRT coordinador, y el BSI puede actuar como autoridad de vigilancia del mercado. No es una obligación de advertir: la formulación es «podrán» y atiende a la proporcionalidad y a la necesidad. Para ti significa, no obstante, que a partir de ahora existe un segundo lugar en el que confluye la información sobre un producto que utilizas.

Que esta vía hace falta lo muestra una mirada a los casos de las últimas semanas. Cuando en agosto se hizo pública una vulnerabilidad en una implementación de la red Lightning de Bitcoin, la información para los operadores dependía de una nota de versión y de los medios especializados. Tratamos el caso en nuestro artículo sobre el fallo de seguridad de Core Lightning y la cuestión de cuándo hay que poner un nodo fuera de línea. Cómo puede comprobarse técnicamente un aviso sobre un monedero está en nuestro artículo sobre el blind signing y cómo desactivarlo en tu monedero de hardware.

Lo que la norma expresamente no dice: ninguna lista de marcas de monederos

Aquí está la salvedad que debe figurar en todo texto honesto sobre este tema. Ni el reglamento ni las directrices de la Comisión Europea mencionan una sola marca de monedero, un solo tipo de aparato del entorno cripto o un proveedor determinado. El CRA trabaja con categorías de productos abstractas y con un test jurídico que cada operador económico debe realizar por sí mismo.

De ahí se siguen dos cosas. Por un lado, del reglamento no puedes deducir si un aparato determinado que posees está cubierto. Eso depende de cómo esté organizado el fabricante, de dónde tenga su sede, de cómo distribuya y de cómo apliquen las autoridades competentes el test jurídico en el caso concreto. Por otro lado, en los próximos meses leerás textos que llenarán ese vacío con nombres. Quien escribe que un proveedor concreto «tiene ahora que» hacer esto o aquello formula una valoración jurídica para la que no existe ni una resolución administrativa ni una sentencia.

Lo único fiable en este punto es el procedimiento. Si una afirmación así te interesa, comprueba dos cosas: ¿hay detrás una declaración propia del fabricante o una manifestación de una autoridad? ¿Y se refiere al artículo 14, que se aplica desde el 11 de septiembre, o a las obligaciones de conformidad que no se aplican hasta el 11 de diciembre de 2027? Ambas cosas se mezclan con frecuencia en estos momentos.

Software libre y de código abierto: la excepción que afecta a muchos proyectos cripto

Una gran parte de la infraestructura cripto es de código abierto y la mantienen personas físicas, asociaciones o fundaciones. Para esa constelación el CRA contiene un tratamiento propio, y eso importa para lo que cabe esperar.

El software libre y de código abierto es, según el considerando 18, software cuyo código fuente se comparte abiertamente y en cuya licencia se prevén todos los derechos para hacerlo libremente accesible, utilizable, modificable y redistribuible. Determinante para el ámbito de aplicación es el carácter comercial del suministro: según el mismo considerando, solo entra en el ámbito de aplicación el software libre y de código abierto que se comercializa y, por tanto, se suministra para su distribución o uso en el marco de una actividad comercial. Las meras circunstancias del desarrollo y el tipo de financiación expresamente no deben desempeñar ningún papel.

A ello se añade el artículo 64, apartado 10, letra b). Conforme a él, las multas allí reguladas no se aplican a los administradores de software de código abierto, y ello para cualquier infracción del reglamento. Es uno de los privilegios más claros de todo el acto jurídico.

Para ti, como usuario, eso significa: en un monedero que nace como proyecto abierto sin suministro comercial, no deberías contar con que alguien esté jurídicamente obligado a avisarte. En un aparato o una aplicación que una empresa ofrece comercialmente la situación es otra, aunque el código fuente esté abierto. La pregunta de quién está detrás de un producto y cómo se distribuye ya era antes una buena pregunta de selección. Desde el 11 de septiembre de 2026, esa pregunta tiene además una vertiente jurídica.

Multas de hasta 15 millones de euros: lo que cuesta infringir el artículo 14

Una obligación sin consecuencia se queda en apelación. El artículo 64, apartado 2, fija el marco: las infracciones de las obligaciones establecidas en los artículos 13 y 14 se sancionan con multas de hasta 15 millones de euros o, en el caso de las empresas, de hasta el 2,5 % del volumen de negocios anual mundial total del ejercicio financiero anterior, si esta cifra fuese superior. La obligación de notificación se sitúa, por tanto, en el más alto de los tres tramos de multas que conoce el reglamento.

Para su fijación en el caso concreto, el apartado 5 exige tener en cuenta la naturaleza, la gravedad y la duración de la infracción, las multas anteriores impuestas al mismo operador económico y el tamaño de la empresa, incluida su cuota de mercado. Las microempresas y las pequeñas empresas se mencionan expresamente.

Para ellas hay además un alivio. El artículo 64, apartado 10, letra a), exime a los fabricantes que sean microempresas o pequeñas empresas de las multas reguladas en los apartados 3 a 9, en la medida en que se trate del incumplimiento del plazo de 24 horas del artículo 14, apartado 2, letra a), o del artículo 14, apartado 4, letra a). La obligación de notificación misma no desaparece por ello: solo cae la sanción por incumplir ese plazo concreto. Para una pequeña empresa emergente de monederos con tres desarrolladores y sin servicio de guardia, esa es la diferencia entre un precepto exigente y uno que amenaza su existencia.

La ejecución corresponde a las autoridades de vigilancia del mercado de los Estados miembros. En Alemania está previsto que sea el BSI. Una multa impuesta debe comunicarla la autoridad a las autoridades de vigilancia del mercado de los demás Estados miembros a través del sistema de información previsto en el Reglamento de vigilancia del mercado.

Anexos III y IV: por qué los monederos de hardware volverán a estar en el orden del día en 2027

El artículo 14 se aplica a todos los fabricantes de productos con elementos digitales, con independencia de cualquier clase de riesgo. El reglamento conoce además dos anexos que enumeran productos especialmente sensibles, y sus efectos jurídicos no se despliegan hasta la plena aplicación, el 11 de diciembre de 2027. Vale la pena echarles un vistazo de todos modos, porque muestra cómo piensa el legislador sobre este tipo de aparatos.

El anexo IV enumera, bajo el título «Productos críticos con elementos digitales», tres entradas: dispositivos de hardware con cajas de seguridad; pasarelas de contadores inteligentes, así como «otros dispositivos con fines de seguridad avanzada, incluido el tratamiento criptográfico seguro»; y tarjetas inteligentes o dispositivos similares, incluidos los elementos de seguridad. El anexo III menciona, en la clase I, entre otras cosas, los microprocesadores y microcontroladores con funcionalidades relacionadas con la seguridad y, en la clase II, los microcontroladores resistentes a la manipulación.

Esos son exactamente los componentes de los que está hecho un monedero de hardware: un elemento seguro, un microcontrolador resistente a la manipulación, un entorno aislado para las operaciones criptográficas. Si un aparato determinado encaja en una de esas entradas se decide, de nuevo, caso por caso. La dirección, sin embargo, es reconocible, y para los fabricantes de tales aparatos implica, a partir de finales de 2027, una evaluación de la conformidad más estricta, en la que puede participar un organismo notificado.

Qué puedes comprobar concretamente como usuario de monedero

El reglamento se dirige a los fabricantes. No tienes que actuar por ello. Pero hay cuatro cosas que a partir de ahora son más elocuentes que antes.

• Comprueba si tu proveedor tiene un canal de seguridad al que puedas suscribirte. Una página de seguridad, una lista de correo, un canal en la aplicación. Un fabricante que quiera cumplir el artículo 14, apartado 8, necesita algo así. Quien no lo tenga querrá llegar a ti, en caso de necesidad, mediante una nota de prensa.
• Comprueba dónde tiene su sede el proveedor. Según el artículo 14, apartado 7, el establecimiento principal en la Unión determina qué CSIRT es competente. En proveedores sin establecimiento en la Unión se aplica el orden supletorio a través de representante autorizado, importador, distribuidor y número de usuarios.
• Distingue entre producto comercial y proyecto abierto. En un proyecto abierto sin suministro comercial, la obligación de notificación no se aplica por regla general, y los administradores de software de código abierto están exentos de las multas. Eso no hace peor a ese software, pero cambia aquello en lo que puedes confiar.
• En los avisos, fíjate en la fuente. A partir de ahora hay, junto al fabricante, un segundo remitente posible: el CSIRT coordinador. En Alemania es el CERT-Bund del BSI. Un aviso que venga de allí no es una comunicación de marketing.

El texto oficial del reglamento lo encuentras en el Diario Oficial de la UE como Reglamento (UE) 2024/2847, versión en alemán; el artículo 14 está en el capítulo II y el inicio de aplicación en el artículo 71, apartado 2. La vía de notificación alemana, con su tabla de plazos, la describe el BSI en su página sobre la CRA Single Reporting Platform.

Comprobar la obligación de notificación de los monederos: qué te llevas de aquí

1. La obligación de informar recae desde ahora en el fabricante, y no solo en ti. Cuando un proveedor se entera de una brecha activamente explotada, debe informarte sobre ella y sobre las medidas que tú mismo puedes adoptar. Tómalo como criterio de selección: un proveedor con un canal de seguridad que funciona es la mejor elección. Qué aparatos entran en consideración lo muestra la comparativa de carteras de hardware.
2. Comprueba bajo qué constelación se ofrece tu monedero. Producto comercial, proyecto abierto, proveedor con o sin establecimiento en la Unión: de ello depende si la obligación de notificación se aplica y quién es competente en caso de necesidad. Para soluciones puramente de aplicación vale la pena mirar la comparativa de monederos de software, porque allí la estructura del proveedor y la vía de actualización se separan.
3. Si no custodias tú mismo, la pregunta se desplaza al custodio. Entonces tu acceso depende de la supervisión sobre el proveedor y de su práctica de custodia. Qué plataformas pueden acreditar una licencia en la UE está en el panorama de los exchanges de criptomonedas regulados.

(13 de septiembre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)