Desde el 11 de septiembre de 2026, un fabricante que tenga conocimiento de una vulnerabilidad aprovechada activamente en un producto que ha introducido en el mercado de la UE debe enviar una alerta temprana en un plazo de 24 horas. Sin embargo, el Cyber Resilience Act, el Reglamento (UE) 2024/2847, nunca menciona los monederos cripto.
El reloj del artículo 14 empieza a correr cuando el fabricante tiene conocimiento. Desde el 11 de diciembre de 2027, los fabricantes deben además llevar a cabo exámenes y pruebas eficaces y periódicos de la seguridad de su producto (anexo I, parte II, punto 3); para un producto introducido en el mercado antes de esa fecha, se aplica únicamente si el producto se somete a una modificación sustancial a partir de esa fecha (artículo 69, apartado 2). Según nuestra lectura, ese deber incide en si el conocimiento le llega de sus propias pruebas o de que otro explote el fallo. Véase Las máquinas están leyendo el código.
Esta nota está dirigida a fabricantes de monederos físicos, software de monedero, software de custodia y dispositivos de pago. Explica el criterio del ámbito de aplicación, lo que presuponen las 24 horas, lo que añade diciembre de 2027 y dónde encaja una revisión adversarial independiente. No es asesoramiento jurídico y no determina si su producto entra en el ámbito de aplicación.
¿Entra un monedero en el ámbito de aplicación?
El punto de partida es la definición de producto con elementos digitales del Reglamento: «producto consistente en programas informáticos o equipos informáticos y sus soluciones de procesamiento de datos remoto, incluidos los componentes consistentes en programas informáticos o equipos informáticos que se introduzcan en el mercado por separado» (artículo 3, punto 1).
La siguiente pregunta es si ese producto es objeto de comercialización. La definición es «el suministro, ya sea remunerado o gratuito, de un producto con elementos digitales para su distribución o utilización en el mercado de la Unión en el curso de una actividad comercial» (artículo 3, punto 22). El artículo 2, apartado 1, añade una condición: el Reglamento se aplica a esos productos «cuya finalidad prevista o uso razonablemente previsible incluya una conexión de datos directa o indirecta, lógica o física, a un dispositivo o red». Según nuestra lectura, un monedero físico que se conecta a un teléfono o a un ordenador, y un software de monedero que accede a una red, normalmente cumplirán esa condición. Un dispositivo aislado (air-gapped) que solo intercambia datos mediante código QR o tarjeta de memoria puede cumplirla aun así: el artículo 3, punto 9, define la conexión física como la realizada por medios físicos, «también mediante interfaces eléctricas, ópticas o mecánicas», y el artículo 3, punto 10, abarca la conexión indirecta, la que se establece «como parte de un sistema más amplio que puede conectarse directamente a dicho dispositivo o red». Si un dispositivo concreto la cumple es una cuestión para su asesor jurídico.
Para los fabricantes de monederos, estas definiciones plantean varias preguntas. Lo que sigue expone nuestra lectura; aplicarla a un producto concreto requiere asesoramiento jurídico.
Monederos físicos
Un monedero físico vendido en la UE encajará a menudo en la descripción de un producto de hardware que contiene software, suministrado en el transcurso de una actividad comercial. Queda por establecer si su dispositivo cumple el criterio jurídico.
Su firmware suele formar parte del producto. Una aplicación complementaria plantea otra pregunta: ¿forma parte del mismo producto o es un producto por sí misma?
Software de monedero y actividad comercial
En el software de monedero, la cuestión depende de si se suministra en el transcurso de una actividad comercial (artículo 3, punto 22). El considerando 18 dice que el suministro de productos con elementos digitales que se consideren programas informáticos libres y de código abierto que no sean monetizados por sus fabricantes no debe considerarse una actividad comercial.
Identificar al fabricante es un paso aparte. El artículo 3, punto 13, designa como tal a la persona que desarrolla o fabrica el producto, o encarga ese trabajo, y lo comercializa con su propio nombre o marca comercial, «ya sea de manera remunerada, monetizada o gratuita».
El considerando 15 dice que el suministro en el transcurso de una actividad comercial puede caracterizarse no solo por cobrar un precio por el propio producto, sino también por:
- cobrar un precio por servicios de asistencia técnica cuando esto no sirva únicamente para la recuperación de costes efectivos;
- tener «la intención de monetizar, por ejemplo por el suministro de una plataforma de software a través de la cual el fabricante monetiza otros servicios»;
- supeditar el uso del producto al procesamiento de datos personales por razones distintas de las relacionadas exclusivamente con la mejora de la seguridad, la compatibilidad o la interoperabilidad del software;
- aceptar donaciones que excedan los costes de diseño, desarrollo y suministro del producto.
También afirma: «La aceptación de donaciones sin la intención de obtener un beneficio no debe considerarse una actividad comercial».
Según nuestra lectura, un monedero que obtiene ingresos de comisiones, intercambios (swaps) o un plan de pago se sitúa cerca de estos ejemplos y puede contar como «monetizado» a efectos del considerando 18. El Reglamento no define esa palabra, y no determinamos su aplicación a un producto concreto.
Monederos libres y de código abierto
El considerando 18 describe una exclusión: «el suministro de productos con elementos digitales que se consideren programas informáticos libres y de código abierto que no sean monetizados por sus fabricantes no debe considerarse una actividad comercial». Una empresa que monetiza su monedero de código abierto no obtiene esa exclusión por el mero hecho de publicar el código fuente.
El considerando se ocupa también de las organizaciones sin ánimo de lucro. El desarrollo, por parte de estas, de productos con elementos digitales que se consideren programas informáticos libres y de código abierto no debe considerarse una actividad comercial, siempre que la organización se haya establecido de tal manera que se garantice que todos los ingresos después de los costes se utilicen para alcanzar objetivos sin ánimo de lucro.
Añade que el Reglamento no se aplica a las personas físicas o jurídicas que contribuyan con código fuente a productos libres y de código abierto que no estén bajo su responsabilidad.
Backends de custodia
Un backend de custodia puede corresponder a categorías distintas. Si el propio backend se suministra como producto en el mercado de la Unión, puede ser por sí mismo un producto con elementos digitales (artículo 3, punto 1).
Si trata datos a distancia para otro producto, el artículo 3, punto 2, lo considera tratamiento de datos a distancia solo cuando se cumplen ambas condiciones: el software ha sido diseñado y desarrollado por el fabricante de ese producto o bajo su responsabilidad, y el producto no podría cumplir alguna de sus funciones sin él.
El considerando 12 dice que la Directiva (UE) 2022/2555 se aplica a los servicios de computación en la nube y a los modelos de servicios en nube. Qué descripción corresponde a un sistema de custodia concreto es una cuestión para su asesor jurídico.
Productos importantes y críticos
El Reglamento distingue además entre productos críticos e importantes. Estas clasificaciones afectan a la evaluación de la conformidad, así que la distinción importa con independencia de la cuestión del ámbito de aplicación.
El anexo IV enumera tres categorías de productos críticos: «Dispositivos de equipos informáticos con cajas de seguridad»; pasarelas de contadores inteligentes «y otros dispositivos con fines de seguridad avanzada, incluido el procesamiento seguro de criptoactivos»; y «Tarjetas inteligentes o dispositivos similares, que incluyan elementos seguros». Figurar en la lista afecta a qué procedimientos de evaluación de la conformidad puede utilizar un producto (artículos 8 y 32).
Nota de traducción: en esta entrada, la versión española oficial dice «procesamiento seguro de criptoactivos», mientras que las versiones inglesa, alemana, francesa e italiana se refieren al procesamiento criptográfico seguro.
El anexo III enumera productos importantes en dos clases, con diecinueve entradas en la clase I y cuatro en la clase II. La clase I incluye «Gestores de contraseñas», «Microprocesadores con funcionalidades relacionadas con la seguridad» y «Microcontroladores con funcionalidades relacionadas con la seguridad». La clase II incluye «Microprocesadores resistentes a las manipulaciones» y «Microcontroladores resistentes a las manipulaciones».
Un producto cuya funcionalidad principal sea la de una categoría del anexo III es un producto importante. Los procedimientos de evaluación de la conformidad correspondientes están en el artículo 32, apartado 2, para la clase I y en el artículo 32, apartado 3, para la clase II. Integrar un producto así en otro no somete, por sí solo, al producto que lo contiene a esos procedimientos (artículo 7, apartado 1).
El artículo 32, apartado 5, ofrece una vía para los productos que se consideren programas informáticos libres y de código abierto y entren en una categoría del anexo III. Sus fabricantes podrán demostrar la conformidad utilizando uno de los procedimientos del artículo 32, apartado 1, siempre que la documentación técnica a que se refiere el artículo 31 se ponga a disposición del público en el momento de la introducción del producto en el mercado.
Determinar si alguna entrada del anexo III o del anexo IV describe un dispositivo o una aplicación concretos requiere una clasificación jurídica. No hacemos esa determinación.
Lo que presuponen las 24 horas
El artículo 14 establece tres pasos de notificación para una vulnerabilidad aprovechada activamente. Cada comunicación se dirige al CSIRT designado como coordinador y a ENISA a través de la plataforma única de notificación:
- Alerta temprana: «sin demora indebida y, en todo caso, en un plazo de veinticuatro horas desde que el fabricante haya tenido conocimiento de ella».
- Notificación de la vulnerabilidad: sin demora indebida y, en todo caso, en un plazo de 72 horas desde que se tuvo conocimiento de la vulnerabilidad aprovechada activamente.
- Informe final: «a más tardar catorce días después de que se disponga de una medida correctora o paliativa».
El CSIRT competente depende del establecimiento principal del fabricante en la Unión. Cuando no lo hay, el artículo 14, apartado 7, establece el orden de criterios para identificarlo.
Existe además un deber distinto de informar a los usuarios. Una vez tenga conocimiento, el fabricante debe informar a los usuarios afectados (y, cuando proceda, a todos los usuarios) sobre la vulnerabilidad o el incidente. Cuando sea necesario, debe indicarles también qué medidas pueden adoptar (artículo 14, apartado 8). Este deber es distinto de la alerta temprana de 24 horas.
El reloj empieza a correr cuando el fabricante tiene conocimiento. Según nuestra lectura, en la mayoría de los productos el conocimiento llega a través del aviso de un usuario o de un investigador; en un monedero, la primera señal de un fallo explotado es a menudo la propia explotación: fondos que se mueven sin que su propietario los haya movido.
Qué contiene cada comunicación
El paso de las 24 horas es una alerta temprana, no una descripción del fallo. El artículo 14, apartado 2, letra a), especifica que, cuando proceda, debe indicar los Estados miembros en cuyo territorio el fabricante tenga conocimiento de que se ha comercializado el producto.
La notificación de 72 horas debe proporcionar la información general disponible. Esto incluye la naturaleza general de la vulnerabilidad y el modo en que es aprovechada, las medidas correctoras o paliativas adoptadas y las medidas correctoras o paliativas que pueden adoptar los usuarios.
El informe final debe describir la vulnerabilidad, incluidas su gravedad y sus repercusiones. Debe dar también detalles sobre la actualización de seguridad u otras medidas correctoras puestas a disposición para subsanarla. Cuando se disponga de ella, debe incluir información sobre cualquier agente malintencionado que haya explotado o esté explotando la vulnerabilidad.
Según nuestra lectura, las demás obligaciones del Reglamento inciden en el tiempo anterior a que empiece a correr este reloj de notificación.
Los incidentes graves tienen una vía propia
Los incidentes graves siguen una vía de notificación paralela con los mismos dos primeros plazos. Conforme al artículo 14, apartado 5, un incidente es grave si afecta o puede afectar negativamente a la capacidad del producto para proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes. Un incidente también lo es si ha llevado o puede llevar a la introducción o ejecución de código malicioso.
El informe final sobre un incidente grave debe presentarse en el plazo de un mes desde la notificación del incidente (artículo 14, apartado 4, letra c)). El plazo de 14 días desde que se disponga de una medida correctora o paliativa pertenece a la vía de las vulnerabilidades. Nuestra nota sobre gestión de vulnerabilidades explica ambas vías de notificación.
Lo que añade diciembre de 2027
El Reglamento se aplica íntegramente desde el 11 de diciembre de 2027, cuando surten efecto los requisitos esenciales de ciberseguridad del anexo I. Los monederos introducidos en el mercado antes de esa fecha están sujetos a los requisitos del Reglamento «únicamente si, a partir de dicha fecha, los productos mencionados se ven sometidos a una modificación sustancial» (artículo 69, apartado 2); las obligaciones de notificación del artículo 14 se les aplican con independencia de dicha modificación, siempre que entren en el ámbito de aplicación del Reglamento (artículo 69, apartado 3). Nuestra nota Las normas pueden deslizarse. La fecha de notificación, no. explica el calendario.
Tres deberes inciden directamente en que un caso del artículo 14 sea raro o rutinario. Dos proceden del anexo I y uno del artículo 13.
Comercializar sin fallos aprovechables conocidos. Sobre la base de la evaluación de riesgos y cuando proceda, los productos «se comercializarán sin vulnerabilidades aprovechables conocidas» (anexo I, parte I, punto 2, letra a)).
Examinar y probar la seguridad del producto. Los fabricantes «llevarán a cabo exámenes y pruebas eficaces y periódicos de la seguridad del producto con elementos digitales» (anexo I, parte II, punto 3). La documentación técnica debe contener «informes de las pruebas realizadas para verificar la conformidad del producto con elementos digitales y de los procesos de gestión de las vulnerabilidades con los requisitos esenciales de ciberseguridad aplicables» (anexo VII, punto 6). Véase informe de pruebas del CRA.
Ejercer la diligencia debida sobre lo que usted no escribió. Los fabricantes «ejercerán la diligencia debida al integrar componentes procedentes de terceros de modo que estos componentes no comprometan la seguridad del producto con elementos digitales» (artículo 13, apartado 5). Esto incluye los componentes de código abierto. En un monedero, significa las bibliotecas criptográficas, el código de derivación y el constructor de transacciones de los que depende.
Estos son solo parte de los requisitos. El anexo I abarca también, entre otras cosas, la confidencialidad y la integridad de los datos y los comandos, la identificación de vulnerabilidades y componentes, incluida una nomenclatura de materiales de los programas informáticos (SBOM), una política de divulgación coordinada de vulnerabilidades y actualizaciones de seguridad oportunas.
El incumplimiento de los requisitos esenciales de ciberseguridad del anexo I y de las obligaciones de los artículos 13 y 14 está sujeto a multas administrativas de hasta 15 000 000 EUR. Si el infractor es una empresa, el máximo es esa cuantía o el 2,5 % de su volumen de negocio total anual mundial del ejercicio financiero anterior, la cantidad que sea mayor (artículo 64, apartado 2).
Ninguno de estos deberes depende de que el código lo escribiera una persona o un modelo. Si un modelo escribió parte de su camino de firma, el deber de haberlo probado y examinado sigue siendo suyo. Véase ¿Es seguro el vibe coding? Lo que encontró un banco de pruebas de 186 tareas reales. Nuestra explicación de la revisión de código adversarial analiza por qué un segundo modelo no es automáticamente un segundo testigo.
Dónde se rompe el código de un monedero
Una revisión tiene que empezar por algún sitio. En el código de un monedero, los puntos donde un defecto puede costar dinero son bien conocidos. Empezamos por:
- la generación de claves y la entropía en la que se basa;
- la copia de seguridad y la restauración de la semilla, y la derivación de claves y direcciones;
- la firma, incluido cómo se producen los nonces y si alguno puede repetirse;
- la construcción de transacciones, incluido si lo que muestra el dispositivo es lo que firma;
- la vía de actualización del firmware y de las aplicaciones: el Reglamento pide «mecanismos para distribuir de manera segura las actualizaciones» (anexo I, parte II, punto 7);
- los componentes de terceros de los que depende todo lo anterior (artículo 13, apartado 5).
Estas son fuentes de fallos de monederos en general. Enumerarlas no afirma que un producto concreto contenga un fallo.
Lo que ofrecemos a un fabricante de monederos
Un primer encargo abarca un componente: aquel en el que un fallo costaría más a sus usuarios. Normalmente, eso significa la firma, la derivación de claves o la vía de actualización. Revisamos de forma adversarial una versión especificada y fijada del código y entregamos un expediente de hallazgos firmado.
Cada hallazgo confirmado se etiqueta según cómo se estableció: reproducido mediante un test ejecutado contra el código sin modificar, o leído en ese código sin ejecutarlo. El expediente nunca presenta un hallazgo como más de lo que su evidencia sostiene. También identifica cada superficie examinada sin hallazgo y el método con que se examinó.
Los revisores son independientes del autor de su código, y una persona con nombre responde del expediente. Un hallazgo se cierra cuando el revisor que lo planteó lo retira o cuando se demuestra contra el código. Véanse Un hallazgo no es un veredicto y What settles a finding (en inglés).
El expediente documenta la prueba y el examen del componente revisado. Aporta evidencia para los exámenes y pruebas eficaces y periódicos que exige el anexo I, parte II, punto 3. Ese deber abarca todo el producto y exige un trabajo recurrente, así que un solo encargo no puede darlo por cumplido. Tampoco constituye el expediente, por sí solo, los informes de pruebas que, según el anexo VII, punto 6, debe contener la documentación técnica. El mismo método de revisión puede aplicarse después al resto del producto.
Una revisión de un componente no hace que su producto sea conforme ni determina si entra en el ámbito de aplicación o si es importante o crítico. No pone en marcha su notificación conforme al artículo 14 ni sustituye a un organismo notificado allí donde se exija uno.
Nuestras cinco negativas (en inglés) fijan más límites a lo que afirmamos. Entre ellas: la coincidencia entre modelos de IA no es una prueba, y una revisión que no encuentra nada no establece que no haya nada.
Las disposiciones del CRA citadas remiten al Reglamento (UE) 2024/2847 y se han verificado contra la versión lingüística española oficial; las citas entre comillas reproducen esa versión. Esta página es una traducción del original inglés; en caso de divergencia, prevalece el original. Si algo aquí es erróneo, lo corregiremos por escrito en esta página.