Los fabricantes de billeteras cripto y otros productos con elementos digitales deben comenzar a reportar vulnerabilidades explotadas activamente e incidentes graves de seguridad que afecten a productos comercializados en la Unión Europea a partir del 11 de septiembre. El reporte inicial debe enviarse mediante la Plataforma Única de Reportes operada por ENISA al CSIRT del Estado miembro donde el fabricante tiene su establecimiento principal y, en circunstancias normales, a ENISA.

El requisito previsto en el Artículo 14 de la Ley de Resiliencia Cibernética de la Unión Europea (CRA) comienza antes que la mayor parte de la regulación. El marco general de la CRA, incluidos los requisitos relacionados con el diseño de productos, la documentación y la conformidad, se aplica principalmente a partir del 11 de diciembre de 2027. Sin embargo, la disposición de reporte anticipada significa que una empresa de billeteras ya puede enfrentar un plazo legal cuando un exploit se encuentra activo.

La regla también cubre productos dentro del alcance que hayan sido comercializados en la UE antes de diciembre de 2027, en lugar de aplicarse únicamente a futuros dispositivos y lanzamientos de software. La Comisión Europea publicó además orientaciones sobre el reporte de vulnerabilidades e incidentes conforme a la CRA.

Las billeteras de hardware y software podrían estar dentro del alcance

La CRA se aplica a productos de hardware y software comercializados en la UE cuando su uso previsto o razonablemente previsible incluye una conexión lógica o física, directa o indirecta, con un dispositivo o una red. Por lo tanto, las billeteras de hardware comerciales, junto con las aplicaciones de billetera para computadoras de escritorio y dispositivos móviles, podrían estar cubiertas.

La obligación legal recae en el fabricante: la persona o empresa que desarrolla un producto, encarga su desarrollo y lo comercializa bajo su propio nombre o marca registrada. Una empresa que vende un dispositivo de hardware o distribuye software de billetera en la UE es un ejemplo más claro que una persona que contribuye a un proyecto de código abierto no relacionado.

Como las billeteras cripto no se mencionan específicamente en la CRA, determinar si un producto particular está sujeto a la ley todavía podría requerir una evaluación legal.

El primer reporte debe presentarse dentro de 24 horas

La primera presentación es una alerta temprana, no una investigación técnica completa. Una vez que un fabricante toma conocimiento de una vulnerabilidad explotada activamente, debe notificar a las autoridades sin demora indebida y a más tardar 24 horas después. Cuando corresponda, la alerta temprana debe identificar los Estados miembros en los que la empresa sabe que el producto afectado fue comercializado.

El mismo plazo se aplica a un incidente grave que afecte la seguridad del producto. En esa situación, la alerta temprana debe indicar al menos si el fabricante sospecha que una actividad ilegal o maliciosa causó el incidente e identificar los mercados relevantes donde está disponible el producto.

Una notificación más detallada debe presentarse dentro de 72 horas. Según las orientaciones de la Comisión Europea, debe incluir la información disponible sobre el producto y la naturaleza general del exploit y de la vulnerabilidad. La presentación también debe describir las medidas correctivas o de mitigación ya adoptadas, los pasos que pueden seguir los usuarios y, cuando corresponda, el nivel de sensibilidad que el fabricante atribuye a la información.

La explotación activa activa el plazo

El período de 24 horas no comienza cada vez que un investigador reporta un error de forma privada. Se aplica cuando el fabricante toma conocimiento de que una vulnerabilidad está siendo explotada activamente contra el producto, o cuando toma conocimiento de un incidente grave que afecta la seguridad del producto.

Una empresa puede recibir un reporte de vulnerabilidad, investigarlo y preparar un parche sin entrar automáticamente en el proceso de reporte del Artículo 14. El plazo regulatorio comienza cuando la empresa se entera de que los atacantes están explotando la falla antes de que se complete la corrección.

La cobertura reciente sobre Coldcard demuestra por qué esta distinción es importante. En una advertencia de julio relacionada con una generación de semillas potencialmente débil, el riesgo práctico iba más allá de identificar la vulnerabilidad. Los usuarios afectados debían determinar si su semilla había quedado expuesta y mover sus fondos si era necesario. La cobertura fue publicada por Coindoo.

Los reportes se envían a las autoridades, no automáticamente al público

El requisito de 24 horas no significa que un fabricante deba publicar de inmediato los detalles de una vulnerabilidad de billetera que aún no ha sido corregida. El reporte inicial se envía al CSIRT correspondiente y a ENISA mediante la Plataforma Única de Reportes. No constituye automáticamente un aviso público ni una publicación obligatoria en un blog con información técnica sobre el exploit.

La CRA exige que las autoridades y las demás partes involucradas en la aplicación de la regulación protejan la información confidencial, incluido el código fuente, los secretos comerciales y la información que podría perjudicar una investigación. En casos de divulgación coordinada de vulnerabilidades, un CSIRT puede retrasar la distribución de una notificación sobre una vulnerabilidad explotada a otros CSIRT cuando existan motivos justificados de ciberseguridad.

La divulgación pública sigue siendo posible cuando sea necesaria para prevenir o mitigar un incidente grave, abordar un incidente en curso o atender el interés público. Después de consultar al fabricante, un CSIRT puede informar al público o exigir que el fabricante lo haga. Los fabricantes de billeteras deben proporcionar a las autoridades información suficiente para evaluar el riesgo y, al mismo tiempo, explicar a los usuarios cómo protegerse sin divulgar detalles que puedan ayudar a un atacante.

Las billeteras de código abierto no están exentas automáticamente

La CRA no se aplica al software gratuito y de código abierto que no se comercializa en el marco de una actividad comercial. Tampoco se aplica a las personas que simplemente contribuyen con código a software de código abierto que no está bajo su responsabilidad.

Estas disposiciones no crean una exención general para los proyectos de billeteras de código abierto. Las orientaciones de la Comisión Europea sobre el software de código abierto conforme a la CRA establecen que un fabricante que comercializa un producto gratuito y de código abierto sigue sujeto a las obligaciones del fabricante. Que un producto sea gratuito no significa necesariamente que su suministro no sea comercial.

La CRA también establece una categoría separada para los administradores de software de código abierto: entidades jurídicas que brindan apoyo continuo a un producto específico de código abierto destinado a una actividad comercial. Estos administradores no están sujetos a multas administrativas de la CRA, pero el Artículo 14 todavía puede exigir reportes cuando participan en el desarrollo del producto o cuando incidentes graves afectan los sistemas de desarrollo que proporcionan.

Un parche podría no eliminar los riesgos existentes para los usuarios de billeteras

En el caso de las billeteras cripto, el fin de un incidente técnico no necesariamente coincide con la publicación de una actualización de seguridad. Una actualización puede evitar una nueva exposición y, al mismo tiempo, dejar en riesgo las claves, frases semilla o configuraciones de billetera creadas con el software afectado.

Esta distinción quedó clara cuando Coldcard publicó una actualización de seguridad para un problema anterior de generación de semillas. Actualizar el dispositivo no hizo seguras las semillas afectadas que ya habían sido generadas; los usuarios todavía debían crear claves nuevas y mover sus fondos. El aviso de Coldcard también fue cubierto por Coindoo.

Conforme a la regla de reporte de la CRA, esa respuesta operativa ahora puede llevarse a cabo junto con una notificación obligatoria a las autoridades cuando se identifica una explotación activa. Por ello, los fabricantes de billeteras necesitan un proceso documentado para determinar si la explotación está activa, notificar a las autoridades dentro de 24 horas, preparar medidas de mitigación y advertir a los usuarios afectados mientras continúan la investigación del incidente y la elaboración del plan completo de corrección. Ese proceso también debe conectar los registros técnicos del incidente con la información sobre qué productos fueron comercializados en cuáles mercados de la UE, ya que la alerta temprana puede exigir que los fabricantes identifiquen esos Estados miembros.

El reporte original, “EU Crypto Wallet Makers Now Have 24 Hours to Report Exploits”, fue publicado por Coindoo.