-
Dos wallets con el mismo código quedan en regímenes distintos según la CRA europea.
-
La Ley de Ciberresiliencia de la UE no mide la seguridad de las wallets.
Una ley de ciberseguridad puede exigir que un producto reporte sus fallas en cuestión de horas sin aplicar esa obligación a la mitad del mercado. El motivo es que el criterio no mide qué tan expuesto está un sistema, sino quién responde legalmente por él. Ese es el criterio que empezó a regir en la Unión Europea para las wallets de criptomonedas.
Desde el 11 de septiembre de 2026, la Ley de Ciberresiliencia (CRA, por su sigla en inglés) exige en su artículo 14 a los fabricantes de «productos con elementos digitales» avisar a las autoridades europeas dentro de las 24 horas si detectan una vulnerabilidad explotada o un incidente grave. Una notificación más completa debe llegar antes de las 72 horas siguientes.
Esos fabricantes, entre los que caen quienes desarrollan wallets de criptoactivos, presentan ambos avisos a través de la plataforma única de notificación de ENISA, la agencia europea de ciberseguridad, operativa desde el mismo 11 de septiembre.
«Las fallas en los productos digitales suelen ser explotadas por actores maliciosos para vulnerar o entorpecer servicios críticos, como la salud, la energía, el transporte o las telecomunicaciones», explicó Juhan Lepassaar, director ejecutivo de ENISA, al presentar la herramienta.
El filtro no es la seguridad, es el negocio
El plazo de 24 y 72 horas no depende de la robustez del código ni del número de auditorías que respaldan a una wallet de criptomonedas. Depende de si detrás del producto existe un fabricante, definido como quien lo desarrolla y lo monetiza bajo su propio nombre o marca.
Esta definición del fabricante divide en dos a wallets, sean dispositivos físicos o aplicaciones, que pueden compartir el mismo código. Una wallet de código abierto, mantenida por una comunidad sin estructura comercial detrás, no genera esa figura de fabricante y queda, hoy, fuera del plazo de 24 horas. La misma wallet, distribuida y monetizada por una empresa bajo su marca, sí la genera y sí queda obligada a reportar.
Esa diferencia legal empuja a los proyectos de código abierto a una decisión que antes no tenían que tomar, mantenerse puramente comunitarios y quedar fuera del radar de la CRA, o formalizar una estructura comercial para ganar la misma garantía regulatoria que hoy solo exhiben los fabricantes. Formalizar tiene un costo, introducir una empresa donde antes solo había una comunidad.
La guía oficial de la Comisión Europea sobre software libre lo confirma, el software no monetizado por quien lo desarrolla no cuenta como actividad comercial. Cobrar por el producto, ofrecer versiones pagas o monetizar servicios asociados sí cuenta. Aceptar donaciones voluntarias o recibir financiamiento público no lo convierte en comercial, mientras el software siga siendo de acceso libre.
La CRA prevé, además, una figura intermedia, el steward de código abierto (una organización que sostiene sin monetizarlo un proyecto pensado para uso comercial de terceros), con obligaciones más livianas que las de un fabricante. Esa figura, sin embargo, recién entra en vigor el 11 de diciembre de 2027, conforme al propio reglamento, de modo que hoy no atenúa la disyuntiva entre formalizarse o quedar fuera.
Y aun cuando ese régimen rija, dejará sin ninguna obligación al proyecto que no tenga detrás ninguna organización, ni comercial ni de sostén. La línea que separa a quien responde ante la ley de quien no, seguirá siendo la existencia de una entidad organizada, no la seguridad del código.
Una asimetría que no depende del código
Un fabricante comercial que reporta un incidente en 24 horas deja una constancia pública y verificable de que alguien resolvió el problema.
Un proyecto de código abierto, sin esa obligación, puede corregir la misma falla igual de rápido, pero no cuenta con ningún trámite oficial equivalente para demostrarlo. Por eso puede leerse como menos responsable, no por su desempeño real, sino por la ausencia de ese registro.
La Comisión Europea no impuso ninguna jerarquía de confianza entre fabricantes y proyectos comunitarios de forma deliberada. Es un efecto secundario del propio mecanismo de reporte, que separa a quien puede mostrar una respuesta institucional de quien no tiene esa vía disponible.
Para un usuario sin conocimiento técnico, esa constancia pública puede pesar más que cualquier auditoría independiente a la hora de elegir una wallet. Si una empresa exhibe su cumplimiento con la CRA como garantía de seguridad, puede ganar usuarios frente a un proyecto comunitario que en los hechos audita su código con la misma o mayor frecuencia, pero no tiene ningún sello regulatorio que mostrar.
El contraste puede ser más agudo todavía. Una wallet de código abierto con miles de revisiones públicas y años de uso puede ser, en la práctica, más segura que una wallet comercial reciente con menos escrutinio. Aun así, solo la segunda enfrenta la obligación de reportar, haciéndola «más fiable» a los ojos de quienes no quisiera indagar en el funcionamiento, porque la ley CRA regula la relación entre el producto y su responsable legal, no la calidad del código en sí.
La Ley de Ciberresiliencia no mide, en los hechos, qué wallet resiste mejor un ataque. Mide qué wallet tiene, detrás, una estructura capaz de responder legalmente cuando ese ataque ocurre. Esa distinción, comercial antes que técnica, es la que empieza a repartir de forma desigual la confianza dentro del ecosistema de wallets.
