# Crypto wallets and the Cyber Resilience Act: what the 24-hour rule assumes > The Regulation never mentions crypto wallets. It applies to products with digital elements. From December 2027, it also requires effective and regular tests and reviews of the security of the product. In our reading, that duty bears on whether a maker finds a flaw before an attacker does. This note explains the scope, the reporting deadlines and the role of an independent review. Source: https://counterproof.io/cyber-resilience-act-crypto-wallets/ · Published 28 September 2026 · CounterProof is a practice of Clavestra Capital Limited (Malta, C 113987). **Since 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in a product it has placed on the EU market must send an early warning within 24 hours.** Yet the Cyber Resilience Act, Regulation (EU) 2024/2847, never mentions crypto wallets. Article 14's clock starts when the manufacturer becomes aware. From 11 December 2027, manufacturers must also apply effective and regular tests and reviews of their product's security (Annex I Part II(3)); for a product placed on the market before that date, it applies only if the product is substantially modified from that date (Article 69(2)). In our reading, that duty bears on whether awareness comes from your own testing or from someone else's exploit. See [*The Machines Are Reading the Code*](https://counterproof.io/notes/the-machines-are-reading-the-code/). This note is for makers of hardware wallets, wallet software, custody software and payment devices. It explains the test for scope, what the 24 hours assume, what December 2027 adds, and where an independent adversarial review fits. It is not legal advice and does not determine whether your product is in scope. ## Is a wallet in scope? The starting point is the Regulation's definition of a *product with digital elements*: "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately" (Article 3(1)). The next question is whether that product is *made available on the market*. The definition is "the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge" (Article 3(22)). Article 2(1) adds a condition: the Regulation applies to such products "the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network". In our reading, a hardware wallet that connects to a phone or computer, and wallet software that reaches a network, will usually meet it. An air-gapped device that exchanges data only by QR code or memory card may still meet it: Article 3(9) defines a physical connection as one made by physical means, "including through electrical, optical or mechanical interfaces", and Article 3(10) covers an indirect connection made "as part of a larger system that is directly connectable to such device or network". Whether a given device meets it is a question for counsel. For wallet makers, these definitions raise several questions. The discussion below gives our reading; applying it to a particular product requires counsel. ### Hardware wallets A hardware wallet sold in the EU will often fit the description of a hardware product containing software, supplied in the course of a commercial activity. Whether your device meets the legal test still needs to be established. Its firmware is usually part of the product. A companion app raises a further question: is it part of the same product, or a product in its own right? ### Wallet software and commercial activity For wallet software, the question turns on whether it is made available in the course of a commercial activity (Article 3(22)). Recital 18 says that the provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity. Identifying the manufacturer is a separate step. Article 3(13) names the person who develops or manufactures the product, or has that work done, and markets it under its own name or trademark, "whether for payment, monetisation or free of charge". Recital 15 says supply in the course of a commercial activity might be characterised not only by charging for the product itself, but also by: - charging a price for technical support services where this does not serve only the recuperation of actual costs; - having "an intention to monetise, for instance by providing a software platform through which the manufacturer monetises other services"; - making use of the product conditional on processing personal data for reasons other than exclusively improving the software's security, compatibility or interoperability; - accepting donations that exceed the costs of designing, developing and providing the product. It also states: "Accepting donations without the intention of making a profit should not be considered to be a commercial activity." In our reading, a wallet that earns from fees, swaps or a paid tier sits close to these examples and may count as "monetised" under recital 18. The Regulation does not define that word, and we do not determine its application to a particular product. ### Free and open-source wallets Recital 18 describes a carve-out: "the provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity". A company that monetises its open-source wallet does not obtain that carve-out merely by publishing the source. The recital also addresses not-for-profit organisations. Their development of products with digital elements qualifying as free and open-source software should not be considered to be a commercial activity, provided the organisation is set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives. It further states that the Regulation does not apply to natural or legal persons who contribute source code to free and open-source products that are not under their responsibility. ### Custodial back ends A custodial back end can fall into different categories. If the back end is itself supplied on the Union market as a product, it can be a product with digital elements in its own right (Article 3(1)). If it processes data remotely for another product, Article 3(2) counts it as remote data processing only where both conditions hold: the software is designed and developed by or under the responsibility of that product's manufacturer, and the product could not perform one of its functions without it. Recital 12 says that Directive (EU) 2022/2555 applies to cloud computing services and cloud service models. Which description fits a given custody system is a question for counsel. ### Important and critical products The Regulation also distinguishes *critical* and *important* products. These classifications affect conformity assessment, so the distinction matters separately from the question of scope. Annex IV lists three categories of critical products: "Hardware Devices with Security Boxes"; smart meter gateways "and other devices for advanced security purposes, including for secure cryptoprocessing"; and "Smartcards or similar devices, including secure elements". Being listed affects which conformity assessment procedures a product may use (Articles 8 and 32). Annex III lists important products in two classes, with nineteen entries in class I and four in class II. Class I includes "Password managers", "Microprocessors with security-related functionalities" and "Microcontrollers with security-related functionalities". Class II includes "Tamper-resistant microprocessors" and "Tamper-resistant microcontrollers". A product with the core functionality of an Annex III category is an important product. The corresponding conformity assessment procedures are in Article 32(2) for class I and Article 32(3) for class II. Integrating such a product into another does not, by itself, subject the containing product to those procedures (Article 7(1)). Article 32(5) provides a route for products that qualify as free and open-source software and fall under an Annex III category. Their manufacturers shall be able to demonstrate conformity using one of the procedures in Article 32(1), provided the technical documentation referred to in Article 31 is made public when the product is placed on the market. Whether any Annex III or Annex IV entry describes a particular device or app requires a legal classification. We do not make that determination. ## What the 24 hours assume Article 14 sets out three reporting steps for an actively exploited vulnerability. Each report goes to the CSIRT designated as coordinator and to ENISA through the single reporting platform: - **Early warning:** "without undue delay and in any event within 24 hours of the manufacturer becoming aware of it". - **Vulnerability notification:** without undue delay and in any event within 72 hours of becoming aware of the actively exploited vulnerability. - **Final report:** "no later than 14 days after a corrective or mitigating measure is available". The relevant CSIRT depends on the manufacturer's main establishment in the Union. Where there is none, Article 14(7) sets out the sequence of criteria for identifying it. There is also a separate duty to inform users. After becoming aware, the manufacturer must inform impacted users (and, where appropriate, all users) of the vulnerability or incident. Where necessary, it must also tell them what measures they can take (Article 14(8)). This duty is distinct from the 24-hour early warning. The clock starts when the manufacturer *becomes aware*. In our reading, for most products awareness comes through a report from a user or researcher; for a wallet, the first sign of an exploited flaw is often the exploit itself: funds moving that the owner did not move. ### What each report contains The 24-hour step is an early warning rather than a description of the flaw. Article 14(2)(a) specifies that, where applicable, it must indicate the Member States on the territory of which the manufacturer is aware that the product has been made available. The 72-hour notification must provide general information, as available. This includes the general nature of the exploit and of the vulnerability, any corrective or mitigating measures taken, and corrective or mitigating measures that users can take. The final report must describe the vulnerability, including its severity and impact. It must also give details of the security update or other corrective measures made available to remedy it. Where available, it must include information about any malicious actor that has exploited or is exploiting the vulnerability. In our reading, the Regulation's other duties bear on the time before this reporting clock starts. ### Severe incidents have a separate track Severe incidents follow a parallel reporting track with the same first two deadlines. Under Article 14(5), an incident is severe if it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. An incident also qualifies if it has led, or is capable of leading, to the introduction or execution of malicious code. The final report on a severe incident is due within one month of the incident notification (Article 14(4)(c)). The 14-day deadline after a corrective or mitigating measure becomes available belongs to the vulnerability track. Our [vulnerability management note](https://counterproof.io/vulnerability-management/) explains both reporting tracks. ## What December 2027 adds The Regulation applies in full from 11 December 2027, when the essential cybersecurity requirements in Annex I take effect. Wallets placed on the market before that date are subject to the Regulation's requirements "only if, from that date, those products are subject to a substantial modification" (Article 69(2)); the Article 14 reporting obligations apply to them regardless of that modification where they fall within the scope of the Regulation (Article 69(3)). Our note [The standards may slip. The reporting date does not.](https://counterproof.io/notes/the-standards-slipped-the-deadline-did-not/) explains the timetable. Three duties bear directly on whether an Article 14 case is rare or routine. Two come from Annex I and one from Article 13. **Ship without known exploitable flaws.** On the basis of the risk assessment and where applicable, a product must "be made available on the market without known exploitable vulnerabilities" (Annex I Part I(2)(a)). **Test and review the product's security.** The manufacturer must "apply effective and regular tests and reviews of the security of the product with digital elements" (Annex I Part II(3)). The technical documentation must contain "reports of the tests carried out to verify the conformity of the product with digital elements and of the vulnerability handling processes with the applicable essential cybersecurity requirements" (Annex VII, point 6). See [CRA test report](https://counterproof.io/glossary/#cra-test-report). **Exercise due diligence on what you did not write.** Manufacturers must "exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements" (Article 13(5)). This includes open-source components. For a wallet, it means the cryptographic libraries, derivation code and transaction builder on which it depends. These are only part of the requirements. Annex I also covers, among other things, the confidentiality and integrity of data and commands, the identification of vulnerabilities and components including an SBOM, a coordinated-vulnerability-disclosure policy, and timely security updates. Non-compliance with the essential cybersecurity requirements in Annex I and the obligations in Articles 13 and 14 is subject to administrative fines of up to EUR 15 000 000. If the offender is an undertaking, the maximum is that amount or 2.5% of its total worldwide annual turnover for the preceding financial year, whichever is higher (Article 64(2)). None of these duties turns on whether a person or a model wrote the code. If a model wrote part of your signing path, the duty to have tested and reviewed it is still yours. See [*Is vibe coding safe? What a benchmark of 186 real tasks found*](https://counterproof.io/notes/is-vibe-coding-safe/). Our explanation of [adversarial code review](https://counterproof.io/adversarial-code-review/) discusses why a second model is not automatically a second witness. ## Where wallet code breaks A review has to start somewhere. In wallet code, the places where a defect can cost money are well known. We begin with: - key generation and the entropy behind it; - seed backup and restore, and the derivation of keys and addresses; - signing, including how nonces are produced and whether any can repeat; - transaction construction, including whether what the device shows is what it signs; - the update path for firmware and apps: the Regulation asks for "mechanisms to securely distribute updates" (Annex I Part II(7)); - the third-party components on which all of these depend (Article 13(5)). These are sources of wallet failures in general. Listing them does not assert that any particular product contains a flaw. ## What we offer a wallet maker A first engagement covers one component: the one where a flaw would cost your users most. Usually, that means signing, key derivation or the update path. We review a [specified, fixed revision](https://counterproof.io/glossary/#pinned-revision) of the code adversarially and deliver a signed finding record. Each [confirmed finding](https://counterproof.io/glossary/#candidate-finding-vs-confirmed-finding) is labelled by [how it was established](https://counterproof.io/glossary/#evidence-rung): *reproduced* through a test run against the unmodified code, or *read* from that code without running it. The record never presents a finding as more than its evidence supports. It also identifies every [surface examined without a finding](https://counterproof.io/glossary/#recorded-negative) and the method used to examine it. The reviewers are [independent of your code's author](https://counterproof.io/glossary/#independence), and a named person is accountable for the record. A finding closes when the reviewer who raised it withdraws it or when it is demonstrated against the code. See [*A finding is not a verdict*](https://counterproof.io/notes/a-finding-is-not-a-verdict/) and [*What settles a finding*](https://counterproof.io/notes/what-settles-a-finding/). The record documents the test and review of the component examined. It contributes evidence towards the effective and regular tests and reviews required by Annex I Part II(3). That duty covers the whole product and requires recurring work, so one engagement cannot discharge it. Nor does the record, by itself, constitute the test reports that Annex VII, point 6 requires the technical documentation to contain. The same review method can then be applied to the rest of the product. A component review does not make your product compliant or determine whether it is in scope, important or critical. It does not set up your Article 14 reporting or replace a notified body where one is required. Our [five refusals](https://counterproof.io/refusals/) set further limits on what we claim. Among them: agreement between AI models is not proof, and a review that finds nothing does not establish that nothing is there. ## Questions this page answers **Does the Cyber Resilience Act apply to crypto wallets?** The Regulation does not name them. It applies to products with digital elements made available on the Union market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network (Article 2(1)). Making available means supply in the course of a commercial activity, whether in return for payment or free of charge (Article 3(22)). A hardware wallet sold in the EU, or wallet software its maker monetises, will often meet that test. Recital 18 says that the provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity. Whether that recital describes your product is a question for counsel. **If a wallet is in scope, what does Article 14 require within 24 hours of awareness?** The manufacturer must send an early warning of an actively exploited vulnerability in its product without undue delay, and in any event within 24 hours of becoming aware of it. The warning goes to the CSIRT designated as coordinator and to ENISA through the single reporting platform. A vulnerability notification follows without undue delay, and in any event within 72 hours of awareness. A final report is due no later than 14 days after a corrective or mitigating measure is available (Article 14(2)). Severe incidents have a separate reporting track. **Is a hardware wallet a critical product under the CRA?** Annex IV lists three critical product categories: "Hardware Devices with Security Boxes"; smart meter gateways "and other devices for advanced security purposes, including for secure cryptoprocessing"; and "Smartcards or similar devices, including secure elements". Being listed affects which conformity assessment procedures a product may use (Articles 8 and 32). Annex III separately lists important products in two classes, including "Tamper-resistant microcontrollers" in class II. Building such an Annex III component into a product does not, by itself, subject that product to the conformity assessment procedures in Article 32(2) and (3) (Article 7(1)). Whether a particular device, or a secure element inside it, falls under any of these entries requires a legal classification. We do not make that determination. **Does a security review make a wallet CRA-compliant?** No. The manufacturer remains responsible for meeting every requirement of Annex I, and for the risk assessment and the technical documentation. A component review contributes evidence towards the effective and regular tests and reviews required by Annex I Part II(3). That duty covers the whole product and requires recurring work, so one review cannot discharge it. Nor is the review, by itself, the test reports that Annex VII, point 6 requires the technical documentation to contain. **What does CounterProof deliver for a wallet maker?** An independent adversarial review of the wallet's highest-risk component, delivered as a signed finding record. Each finding is labelled by how it was established. The record also identifies every surface examined without a finding and the method used to examine it.