What the crypto wallet headlines mean for your own app

Crypto wallet makers are in the headlines today, and the angle is the 24-hour reporting duty.

I have no stable link for that coverage, so I will stay on the text of the regulation and leave the reporting to the outlets that did it.

The stories talk about wallets. The text behind them never mentions wallets once.

Why wallet makers showed up first

A wallet is software a user installs and runs. A desktop build, a mobile app, a browser extension. That puts it inside the definition of a product with digital elements, Article 3(1).

The people who ship it are manufacturers under Article 3(13) if they develop the product and place it on the market under their own name or trademark. Paid, free, or monetised, all three are in the definition. Article 3(22) adds that it happens in the course of a commercial activity.

Nothing in those two lines is specific to crypto. The press picked wallets because the incident story writes itself. The articles apply the same way to a backup tool, a WordPress plugin, or a CLI you publish under your own name.

Three questions that decide for you

First question. Does the user run your code on their machine, or does everything stay on your servers? A browser-only service is outside the scope under recital 12. NIS2 can still reach you, but only past its sector and size thresholds. If you also ship an installable client, that client is a product with digital elements. Remote data processing has its own definition in Article 3(2), and that is the line to read if you run a backend next to a client.

Second question. Is your name on it, and is there commercial activity around it? Open source supplied outside a commercial activity sits outside, under recital 18. A paid tier, a support contract, or a company behind the repository changes the answer. Open source stewards get the lighter regime of Article 24.

Third question. Would you find out if someone exploited a flaw in your product? Article 3(42) defines actively exploited as reliable evidence that a malicious actor exploited the vulnerability in a system without the owner's authorisation. Your answer depends on whether you have an address people can write to.

A two-person example

Take a team of two shipping a browser extension that reads invoices and pushes them into an accounting tool. The extension is free. A paid tier adds bulk export. There is also a small hosted dashboard for the paid accounts.

They are a manufacturer for the extension. Their names are on the store listing, money changes hands, Article 3(13) fits. The dashboard raises its own question, and Article 3(2) on remote data processing is the definition to read before they answer it.

A user writes in. Their security team saw the extension posting invoice data to a domain the team does not own, and they attach the request log. That message is the moment of knowledge. The clock starts when you know, not when an authority writes to you.

From that message, the two of them have 24 hours for the early warning and 72 hours for the notification, under Article 14. Both go to the CSIRT designated as coordinator in their member state and to ENISA. Then Article 14(8): they tell affected users about the vulnerability and about the mitigation they can apply, without undue delay.

The final report comes 14 days after a corrective or mitigating measure is available.

What applies now, what waits

Article 14 has applied since 11 September 2026, and ENISA's single reporting platform exists under Article 16. That is the part in the headlines.

The rest waits until 11 December 2027 under Article 71. Annex I essential requirements, the SBOM covering at least top-level dependencies, technical documentation under Annex VII, conformity assessment, the EU declaration of conformity under Annex V, CE marking, the support period. Penalties under Article 64 apply from 11 December 2027 as well, not before.

Products already on the market before that date are covered by Article 69: Article 14 applies to them, the rest only after a substantial modification. Security updates and bug fixes are not a substantial modification, per recital 39.

What I would do this week

Read Article 14 once, in the text, not in a summary. Write down which CSIRT covers your member state. Put a contact address in a security.txt file so that first message reaches you at all.

If you are unsure whether any of this reaches your product, the free scope test walks through the borderline cases with the article references: https://crakit.eu/scope/. It gives you a written, indicative reading. It does not give you a verdict.

I build tools around this regulation and I have read it closely, but I have no legal training, so take everything above as a starting point for your own reading.

Not legal advice.

This is not legal advice.