Manufacturers of crypto wallets and other products with digital elements must begin reporting actively exploited vulnerabilities and severe security incidents affecting products made available in the European Union from September 11. The initial report must be submitted through the Single Reporting Platform operated by ENISA to the CSIRT in the Member State where the manufacturer has its main establishment and, under normal circumstances, to ENISA.

The requirement under Article 14 of the EU Cyber Resilience Act (CRA) begins before most of the regulation. The broader CRA framework, including requirements concerning product design, documentation and conformity, applies mainly from December 11, 2027. However, the earlier reporting provision means a wallet company may already face a statutory deadline when an exploit is active.

The rule also covers in-scope products made available in the EU before December 2027, rather than applying only to future devices and software releases. The European Commission has published additional guidance on CRA vulnerability and incident reporting.

Hardware and software wallets may fall within scope

The CRA applies to hardware and software products made available commercially in the EU when their intended or reasonably foreseeable use includes a direct or indirect logical or physical connection to a device or network. Commercial hardware wallets, along with desktop and mobile wallet applications, could therefore be covered.

The legal obligation rests with the manufacturer: the person or company that develops a product, has it developed, and markets it under its own name or trademark. A business selling a hardware device or distributing wallet software in the EU is a clearer example than an individual contributing to an unrelated open-source project.

Crypto wallets are not specifically named in the CRA, so determining whether a particular product falls within the law may still require a legal assessment.

The first report is due within 24 hours

The first submission is an early warning, not a completed technical investigation. Once a manufacturer becomes aware of an actively exploited vulnerability, it must notify the authorities without undue delay and no later than 24 hours afterward. Where applicable, the early warning must identify the Member States in which the company knows the affected product has been made available.

The same deadline applies to a severe incident affecting product security. In that situation, the early warning must at least state whether the manufacturer suspects that unlawful or malicious activity caused the incident and identify the relevant markets where the product is available.

A more detailed notification is due within 72 hours. According to the European Commission’s guidance, it must include available information about the product and the general nature of the exploit and vulnerability. The submission must also describe corrective or mitigating measures already taken, steps users can take, and, where applicable, how sensitive the manufacturer considers the information to be.

Active exploitation triggers the clock

The 24-hour period does not begin whenever a researcher privately reports a bug. It applies when the manufacturer becomes aware that a vulnerability is being actively exploited against the product, or when it becomes aware of a severe incident affecting product security.

A company can receive a vulnerability report, investigate it and prepare a patch without automatically entering the Article 14 reporting process. The regulated deadline begins once the company learns that attackers are exploiting the flaw before the fix is complete.

Recent Coldcard coverage illustrates why this distinction matters. In a July warning involving potentially weak seed generation, the practical risk extended beyond identifying the vulnerability. Affected users needed to determine whether their seed had been exposed and move funds if necessary. The coverage was reported by Coindoo.

Reports go to authorities, not automatically to the public

The 24-hour requirement does not mean that a manufacturer must immediately publish details of an unpatched wallet vulnerability. The initial report is sent to the relevant CSIRT and ENISA through the Single Reporting Platform. It is not automatically a public advisory or a mandatory blog post containing technical exploit information.

The CRA requires authorities and other parties involved in applying the regulation to protect confidential information, including source code, trade secrets and information that could undermine an investigation. In coordinated vulnerability disclosure cases, a CSIRT may delay distributing an exploited-vulnerability notification to other CSIRTs when justified cybersecurity grounds exist.

Public disclosure remains possible when it is necessary to prevent or mitigate a severe incident, address an ongoing incident or serve the public interest. After consulting the manufacturer, a CSIRT may inform the public or require the manufacturer to do so. Wallet makers must provide authorities with enough information to assess the risk while explaining to users how to protect themselves without releasing details that could help an attacker.

Open-source wallets are not automatically exempt

The CRA does not apply to free and open-source software that is not made available on the market through commercial activity. It also does not apply to people who merely contribute code to open-source software that is not under their responsibility.

Those provisions do not create a blanket exemption for open-source wallet projects. The European Commission’s guidance on open-source software under the CRA states that a manufacturer placing a free and open-source product on the market remains subject to manufacturer obligations. A product’s being free does not necessarily mean that its supply is non-commercial.

The CRA also establishes a separate category for open-source software stewards: legal entities that provide sustained support for a specific open-source product intended for commercial activity. These stewards are not subject to CRA administrative fines, but Article 14 can still require reporting when they are involved in the product’s development or when severe incidents affect the development systems they provide.

A patch may not eliminate existing wallet risks

For crypto wallets, the end of a technical incident does not necessarily coincide with the release of a security update. An update can prevent new exposure while leaving keys, seed phrases or wallet configurations created with affected software at risk.

That distinction was evident when Coldcard released a security update for an earlier seed-generation issue. Updating the device did not make previously generated affected seeds safe; users still needed to create fresh keys and move their funds. Coldcard’s notice was also covered by Coindoo.

Under the CRA’s reporting rule, that operational response may now take place alongside a mandatory notification to authorities when active exploitation is identified. Wallet makers therefore need a documented process for determining whether exploitation is active, notifying authorities within 24 hours, preparing mitigation and warning affected users while the incident investigation and full remediation plan are still in progress. That process also needs to connect technical incident records with information about which products were made available in which EU markets, since the early warning can require manufacturers to identify those Member States.

The original report, “EU Crypto Wallet Makers Now Have 24 Hours to Report Exploits,” was published by Coindoo.