Reporting Duty for Wallet Makers: What Has Applied Since September 11, 2026

Since September 11, 2026 a duty applies across the whole of the EU that did not exist in this form before: anyone who makes a product with digital elements available commercially on the European market must report an actively exploited vulnerability to the competent bodies within 24 hours and inform affected users about the vulnerability and about the countermeasures they can take themselves.

For you as a holder of cryptocurrencies, the second part is the more important one. It sits in Article 14(8) of the EU Cyber Resilience Act and shifts the question of who has to make sure you learn about a problem with your wallet. Until now that was a matter of company culture. From now on it is a legal duty with a fining framework behind it.

This article explains what exactly applies, from when, to whom, and where the line runs between the documented legal position and over-interpretation. Because the regulation does not name a single wallet brand, and anyone who derives a list of affected manufacturers from it is writing more than what is there.

What has applied since September 11, 2026: Article 14 of the EU Cyber Resilience Act

The Cyber Resilience Act is Regulation (EU) 2024/2847, usually called the Cyber Resilience Act or CRA for short. The CRA entered into force on December 10, 2024, but only applies in full from December 11, 2027. Article 71(2) contains one sentence that upends the whole timetable: "This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026, and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026."

Article 14 is headed "Reporting obligations of manufacturers" and is thus the part of the regulation that was switched on first. Everything else — the conformity assessment, the CE marking, the essential cybersecurity requirements in Annex I — only arrives in 2027. So anyone reading right now that the CRA applies means this one article.

The core in one sentence: a manufacturer must report every actively exploited vulnerability in its product and every severe security incident simultaneously to the CSIRT designated as coordinator and to the EU Agency for Cybersecurity, ENISA, through a single reporting platform.

What is a CSIRT? A Computer Security Incident Response Team is the body designated by a member state that receives, assesses and passes on security incidents. In Germany, CERT-Bund within the Federal Office for Information Security is the coordinating CSIRT, and the BSI also handles market surveillance.

What is an actively exploited vulnerability? A security flaw the manufacturer knows attackers are already using. A theoretical gap someone found in a laboratory does not start the 24-hour clock. Abuse in practice does.

Why a product regulation concerns your crypto wallet at all

The CRA is not financial law and not crypto law. It is horizontal product law and takes no interest in which assets a device manages, only in whether it is a product with digital elements and whether it is made available commercially on the EU market. That is precisely what makes it relevant for crypto custody.

A hardware wallet is a physical device with firmware that talks to companion software over USB, Bluetooth or QR code. A wallet app is software a provider makes available for download. By their design, both are what Article 3(1) describes as "a software or hardware product and its remote data processing solutions". Article 2(1) draws the boundary via the connection: the regulation applies to products whose intended purpose or reasonably foreseeable use includes "a direct or indirect logical or physical data connection to a device or network".

For the custody of cryptocurrencies, that is the point at which something changes. If you hold your balance yourself, your security hangs on exactly two things: on the quality of the device or the software, and on whether you find out in time when something is wrong with it. On the first, the reporting duty still says nothing; the corresponding requirements only bite in 2027. On the second, it says something with immediate effect. Which devices are available at all and how they differ is in our hardware wallet comparison; for purely software solutions the same considerations apply with a different attack surface.

Product with digital elements: who counts as a manufacturer under the legal test

Whether a specific device or a specific app is covered is decided by three test steps. There is no list of affected products. First: is the product made available on the EU market, that is, supplied for distribution or use in the course of a commercial activity? Second: is it a software or hardware product within the meaning of Article 3? Third: does its intended or reasonably foreseeable use include a direct or indirect data connection?

A commercially distributed, connected hardware wallet and a wallet app offered by a company can satisfy these three questions. That is an application of the legal test and not an official finding for any particular product. Anyone who turns it into a claim that this or that provider must now do this or that is asserting something that neither the regulation nor the Commission's guidelines supports.

Where the manufacturer is based also matters. Article 14(7) regulates this in detail: what governs is the CSIRT of the member state in which the manufacturer has its main establishment in the Union, that is, where the decisions on the cybersecurity of its products are predominantly taken. If it has no establishment in the EU at all, an order of precedence applies: first the member state of the authorised representative, then that of the importer, then that of the distributor, and finally the member state in which the largest number of users is located. A provider outside Europe is therefore not automatically out of scope once it serves the European market.

24 hours, 72 hours, 14 days: the chain of deadlines under Article 14(2)

The regulation requires three reports that build on one another. All deadlines start at the moment the manufacturer becomes aware.

1. Early warning, no later than 24 hours after becoming aware. The early warning must state in which member states the affected product has been made available, to the manufacturer's knowledge. The regulation asks for no more at this stage, and that is deliberate: the early warning is meant to be fast, not complete.
2. Vulnerability notification, no later than 72 hours after becoming aware. Now general information about the affected product is added, about the nature of the exploit and of the vulnerability, about any corrective or mitigating measures already taken, and expressly also about the "corrective or mitigating measures that users can take".
3. Final report, no later than 14 days after a mitigating measure is available. It contains a description of the vulnerability including its severity and impact, where available information on the attackers, and information on the security update or other corrective measure.

For a severe security incident under Article 14(3) the same split into 24 and 72 hours applies, but there the final report is due one month after the 72-hour notification. When an incident counts as severe is defined in paragraph 5: when it affects the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive data or functions, or when it has led or can lead to the execution of malicious code.

Reporting runs through the CRA Single Reporting Platform operated by ENISA. The manufacturer submits once, and the report is made available to the competent coordinating CSIRT and to ENISA at the same time. After the final report, the reporting person can as a rule no longer edit the submission.

Article 14(8): when the manufacturer has to inform you directly

The deadlines towards the CSIRT and ENISA are the part the industry press writes about. For you as a user, the decisive sentence sits elsewhere, namely in Article 14(8). Slightly abridged, it reads: after the manufacturer has become aware of an actively exploited vulnerability or a severe security incident, "it shall inform the affected users of the product with digital elements, and where necessary all users, about that vulnerability or incident and, where necessary, about any risk mitigation and corrective measures that the users can deploy".

Three points in this are worth reading closely.

First: the duty attaches to the same awareness as the report to the authorities. The trigger is the same moment. For informing users, however, the regulation names no fixed number of hours. What is required is information in connection with becoming aware, and elsewhere the text turns on timeliness. Anyone who turns the 24 hours for the authority into a 24-hour deadline towards customers is reading the provision wrongly.

Second: users must be informed about the countermeasures they can take themselves. That is the practical core. A notice that merely says there was a problem does not satisfy the wording if there are measures users can take themselves. With a wallet, those measures are precisely the relevant ones: update the firmware, temporarily stop using a particular function, move a balance to a new address, check a signature manually before confirming it.

Third: the regulation would like a machine-readable format. The text speaks of a structured, machine-readable format that is easy to process automatically, and qualifies this with "where appropriate". For security researchers and for portals that aggregate warnings, that is the most interesting wording in the whole paragraph.

What happens if the manufacturer stays silent? The role of CERT-Bund

The second sentence of paragraph 8 is the genuinely new lever: "Where the manufacturer fails to inform the users of the product with digital elements in a timely manner, the CSIRTs designated as coordinators may provide such information to the users when they consider it to be proportionate and necessary for preventing or mitigating the impact of those vulnerabilities or incidents."

European law thereby states that an authority may inform the public about a product vulnerability if the manufacturer does not do so in time. For Germany that means, concretely: CERT-Bund at the BSI receives the report as coordinating CSIRT, and the BSI can act as market surveillance authority. That is not an obligation to warn; the wording is "may" and turns on proportionality and necessity. For you it nevertheless means that from now on there is a second place at which information about a product you use comes together.

A look at the cases of recent weeks shows that this route is needed. When a vulnerability in a Bitcoin Lightning implementation became public in August, the information for operators hung on a release note and on trade media. We worked through that case in our article on the Core Lightning vulnerability and the question of when a node has to go offline. How a wallet warning can be technically verified at all is in our article on blind signing and how to switch it off on your hardware wallet.

What the rule expressly does not say: no list of wallet brands

Here is the qualification that belongs in every honest text on this subject. Neither the regulation nor the European Commission's guidelines names a single wallet brand, a single device type from the crypto world, or any particular provider. The CRA works with abstract product categories and a legal test that every economic operator has to carry out for itself.

Two things follow from that. For one, you cannot read from the regulation whether a particular device you own is covered. That depends on how the manufacturer is organised, where it is based, how it distributes, and how the competent authorities apply the legal test in the individual case. For another, over the coming months you will read texts that fill this gap with names. Anyone writing that a specific provider "now has to" do this or that is formulating a legal assessment for which there is neither an administrative decision nor a court ruling.

The only reliable thing at this point is the procedure. If such a statement interests you, check two things. Is there a manufacturer's own declaration behind it, or a statement by an authority? And does it refer to Article 14, which has applied since September 11, or to the conformity duties that only bite from December 11, 2027? The two are frequently conflated at the moment.

Free and open source software: the exception that concerns many crypto projects

A large part of crypto infrastructure is open source and maintained by individuals, associations or foundations. For this constellation the CRA contains its own treatment, and that matters for what you can expect.

Free and open source software is, under recital 18, software whose source code is openly shared and whose licence provides for all rights to make it freely accessible, usable, modifiable and redistributable. What is decisive for the scope is the commercial character of the supply: according to the same recital, only free and open source software that is made available on the market, and thus supplied for distribution or use in the course of a commercial activity, falls within the scope. The mere circumstances of development and the type of funding are expressly not meant to play a role.

On top of that comes Article 64(10)(b). Under it, the fines regulated there do not apply to stewards of open source software, and that holds for every infringement of the regulation. It is one of the clearest privileges in the entire legal act.

For you as a user that means: with a wallet that arises as an open project without commercial supply, you should not count on anyone being legally obliged to notify you. With a device or an app a company offers commercially, the position is a different one, even if the source code is open. The question of who stands behind a product and how it is distributed was a good selection question before. From September 11, 2026 that question additionally has a legal side.

Fines up to 15 million euros: what an infringement of Article 14 costs

A duty without consequence remains an appeal. Article 64(2) sets the framework: infringements of the obligations laid down in Articles 13 and 14 are subject to fines of up to 15 million euros or, in the case of undertakings, up to 2.5 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. The reporting duty therefore sits in the highest of the three fining bands the regulation knows.

When setting the amount in the individual case, paragraph 5 requires the nature, gravity and duration of the infringement to be taken into account, along with previous fines against the same economic operator and the size of the undertaking including its market share. Microenterprises and small enterprises are expressly mentioned.

For them there is an additional relief. Article 64(10)(a) exempts manufacturers that qualify as micro or small enterprises from the fines regulated in paragraphs 3 to 9, insofar as the missed 24-hour deadline under Article 14(2)(a) or Article 14(4)(a) is concerned. The reporting duty itself does not fall away as a result, only the sanction for missing that one deadline. For a small wallet startup with three developers and no on-call rota, that is the difference between a demanding provision and an existential one.

Enforcement lies with the market surveillance authorities of the member states. In Germany, the BSI is designated for that. A fine imposed must be communicated by the authority to the market surveillance authorities of the other member states through the information system under the Market Surveillance Regulation.

Annex III and Annex IV: why hardware wallets come up again in 2027

Article 14 applies to all manufacturers of products with digital elements, irrespective of a risk class. Beyond that, the regulation knows two annexes that list particularly sensitive products, and their legal consequences only bite with the full start of application on December 11, 2027. A look at them is worthwhile all the same, because it shows how the legislator thinks about this type of device.

Annex IV lists three entries under the heading "Critical products with digital elements": hardware devices with security boxes; smart meter gateways as well as "other devices for advanced security purposes, including secure cryptoprocessing"; and smartcards or similar devices, including secure elements. Annex III names, in class I, among other things microprocessors and microcontrollers with security-related functionalities, and in class II tamper-resistant microcontrollers.

Those are exactly the components a hardware wallet is built from: a secure element, a tamper-resistant microcontroller, a shielded environment for cryptographic operations. Whether a particular device falls under one of these entries is again decided case by case. The direction is recognisable, though, and for manufacturers of such devices it means a stricter conformity assessment from the end of 2027, one in which a notified body can be involved.

What you as a wallet user can actually check now

The regulation addresses manufacturers. You do not have to act because of it. But there are four things that are more informative from now on than they were before.

• Check whether your provider has a security channel you can subscribe to. A security page, a mailing list, a channel in the app. A manufacturer that wants to satisfy Article 14(8) needs something of the kind. One that has none will want to reach you through a press release when it matters.
• Check where the provider is based. Under Article 14(7), the main establishment in the Union determines which CSIRT is competent. For providers with no EU establishment, the fallback order runs via authorised representative, importer, distributor and number of users.
• Distinguish between a commercial product and an open project. With an open project without commercial supply, the reporting duty regularly does not apply, and stewards of open source software are exempt from the fines. That does not make such software worse, but it changes what you can rely on.
• With warnings, pay attention to the source. From now on there is a second possible sender alongside the manufacturer, namely the coordinating CSIRT. In Germany that is CERT-Bund at the BSI. A warning coming from there is not a marketing announcement.

You will find the official wording of the regulation in the Official Journal of the EU as Regulation (EU) 2024/2847, German-language text; Article 14 sits in Chapter II, the start of application in Article 71(2). The German reporting route including a table of deadlines is described by the BSI on its page about the CRA Single Reporting Platform.

Checking the wallet reporting duty: what to take away

1. The duty to inform now lies with the manufacturer, no longer only with you. When a provider learns of an actively exploited vulnerability, it has to inform you about the gap and about the measures you can take yourself. Take that as a selection criterion: a provider with a functioning security channel is the better choice. Which devices are candidates at all is shown by the hardware wallet comparison.
2. Check the constellation under which your wallet is offered. Commercial product, open project, provider with or without an EU establishment: on that depends whether the reporting duty applies at all and who is competent when it matters. For pure app solutions it is worth a look at the software wallet comparison, because there the provider structure and the update route diverge.
3. If you do not hold your own keys, the question shifts to the custodian. Then your access hangs on the supervision of the provider and on its custody practice. Which platforms can show a licence in the EU is in our overview of regulated crypto exchanges.

(As of September 13, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)