Starting September 11 2026, you have just 24 hours to report on-device vulnerabilities.

A security researcher emails your support address on a Tuesday in October. The desktop agent you shipped back in 2024, so customers could sync files into your product, has a path traversal bug, and attached is a log showing somebody has already used it against a live install. Nobody has touched that repository in eighteen months.

You do the normal things: wake up whoever owns that repository, cut a patch, start drafting a note to the customers you think are affected.

But starting 11 September 2026, there's a new clock running. Once you become aware that someone is exploiting a vulnerability in software you placed on the EU market, you have only 24 hours to file an early warning with a national incident response team and with ENISA, the EU's cybersecurity agency 1. Not 24 hours to fix it. 24 hours to report it.

That duty is Article 14 of the Cyber Resilience Act. Most of the companies it now covers have filed the whole regulation under "rules for people who make routers", and the duty they are filing away lands on software they have already shipped.

So: if you ship software into the EU that other people run on their own machines, you need to settle before 11 September which national team receives that report and who at your company can file it, or you will be working both out during an incident with the clock already running.

Does the Cyber Resilience Act apply to us?

The Cyber Resilience Act attaches to what you put on the market, whoever you are.

Article 2(1) covers products with digital elements made available on the EU market, meaning anything whose expected use involves a data connection to a device or network, and Article 3(1) defines a product with digital elements as a software or hardware product together with its remote data processing solutions 1. Software counts on its own. There is no hardware requirement in it.

Two conditions then decide whether it is yours. Article 3(13) makes you the manufacturer if you develop something, or have it developed, and market it under your own name, "whether for payment, monetisation or free of charge". Article 3(22) adds that software is made available on the market when supplied "in the course of a commercial activity", again whether or not anyone pays. Commercial purpose is the gate, not price. A free tool that exists to sell the paid product around it is in. Open-source software that its maker does not monetise is out, which comes from recital 18, and recitals are the explanatory paragraphs opening an EU regulation that steer how the binding articles are read without binding by themselves. Whoever maintains that open-source software gets a lighter set of duties under Article 24 instead.

A hosted product escapes for a more specific reason than being a service. The Commission's guidance of 27 July 2026 sets the test as where the software runs: a product with digital elements has to be "provided to a user, obtained by that user and operated on, or as part of, an electronic information system on the user's side", and software that executes remotely and is merely accessed by the user does not qualify on that basis alone, which it says is typical of web applications reached through a browser 3.

So the question worth asking is whether you hand people in the EU software that runs on their side:

• a desktop application
• a mobile app
• a browser extension
• a command line tool, an SDK or a library, where you publish it commercially
• a self-hosted or on-premise deployment
• an agent customers install in their own infrastructure
• firmware, if you ship any hardware at all

Almost every B2B software company I can think of has at least one of these, usually built when a big customer asked and owned by nobody in particular today.

Does our backend count, or only what customers download?

Part of it can, but only the part your shipped product cannot work without.

Article 3(2) defines remote data processing as processing at a distance where the software "is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions" 1. Recital 11 gives the EU's own example: a mobile app that needs an API or database provided by a service the manufacturer developed pulls that service into scope. Both conditions have to hold, so a third-party service you merely integrate fails the second one, though where it touches your product's security the guidance expects you to treat it as a component and do due diligence on it 3.

What exactly starts on 11 September 2026?

Only Article 14. Nothing else that a software manufacturer has to do arrives before December next year.

Article 71(2) is short enough to quote in full: "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" 1. Chapter IV is the machinery for notifying the bodies that will run conformity assessments, so it already applies and asks nothing of you.

So on 11 September you do not need CE marking, a conformity assessment, a software bill of materials, or a declared support period. What you need is the ability to file a report.

Software already shipped gets no pass, and that is what catches people. Article 69(2) reads like a grandfather clause, exempting products placed on the market before 11 December 2027 unless they are substantially modified after that date. Article 69(3) then puts the reporting duty straight back, applying it "to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027".

I read Article 69(3) twice before I accepted it, because it takes back what the paragraph above just gave. A desktop client you shipped in 2024 and have barely touched is inside Article 14 from the first day. One limit worth knowing: the guidance says exploitation you were already aware of before 11 September 2026 need not be reported, while a vulnerability you knew about but had not seen exploited becomes reportable once exploitation starts or you learn of it 3.

What has to be reported, and how fast?

Two triggers, each with three deadlines 1, 2.

The first is an actively exploited vulnerability, which Article 3(42) defines as one "for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner". What matters is the evidence, not who brought it to you: a researcher's mail counts if it shows exploitation, and a bug you found yourself does not until somebody uses it.

• 24 hours from becoming aware: an early warning, flagging where applicable which Member States you know the product has been made available in.
• 72 hours: a notification covering the product, the general nature of the vulnerability and the exploit, what measures you have taken, and what users can do.
• 14 days after a corrective or mitigating measure is available: a final report with severity and impact, anything you know about who exploited it, and details of the update.

The second trigger is a severe incident affecting the product's security. Article 14(5) makes one severe if it affects, or could affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or if it has led, or could lead, to malicious code running in the product or in a user's own systems. Same 24 hours and 72 hours, then a final report within one month of the 72-hour notification. Article 14(8) adds one more duty: tell the impacted users too, with any mitigation they can apply.

Article 64(2) sets the ceiling for non-compliance with Articles 13 and 14 at EUR 15 000 000 or, where the offender is an undertaking, 2.5% of worldwide annual turnover for the preceding financial year, whichever is higher. If you are a micro or small company, that number is probably not yours: Article 64(10)(a) lifts administrative fines for exactly this failure to hit the 24-hour early warning. I would not lean on it. The wording granting it does not sit cleanly against the paragraph setting the Article 14 fine, and Article 71(2) starts the duty in September while leaving Article 64 to arrive in December 2027, so the interval is untested either way. Report on time and none of it matters.

Which incident response team is ours, and how do we file?

You report to a Computer Security Incident Response Team, or CSIRT, the national body that handles reports like this one. Which country's CSIRT is yours depends on where your cybersecurity decisions are predominantly taken, and everything goes through a single platform run by ENISA.

Article 14(7) routes the notification to the CSIRT designated as coordinator in the Member State of your main establishment in the Union, and requires it to be simultaneously accessible to ENISA 1. Main establishment has its own definition here, turning on decision-making rather than where your head office sits: the Member State where decisions about the cybersecurity of your products are predominantly taken. If that cannot be determined, it is where you have the most employees in the EU. If you have no EU establishment at all, Article 14(7) works down an order: whoever you formally appointed to act for you in the EU, then whoever brings the product in, then whoever sells it on, then the country with the most of your users.

The practical part comes from ENISA 4, 5. The Single Reporting Platform is the channel for mandatory reporting from 11 September 2026, and whoever files needs an EU Login account, created in advance. There are no APIs at this stage, so a first filing is a person typing into a portal. ENISA says the coordinating CSIRT validates your registration in parallel with the reporting process and that this does not hold up your ability to submit, so what to sort out ahead of time is the login.

What should we do before 11 September?

Most of this is listing what you already have rather than building anything.

1. Write down every artefact you place on the EU market that runs on somebody else's machine. Mobile apps, desktop apps, browser extensions, commercially published SDKs and command line tools, self-hosted deployments, installed agents, firmware. Free ones count when they serve a commercial purpose, and so do the ones shipped for one customer and forgotten.
2. For each one, mark the backend services it cannot function without and that you built yourself. Those are in scope alongside it; third-party services you only integrate are not.
3. If the list is empty, write down why, and date it. You are outside Article 14 today. That is a conclusion with a shelf life.
4. If it is not empty, settle which Member State's CSIRT is yours, and get an EU Login account created now for whoever will file.
5. Put the 24, 72 and 14 sequence in your incident runbook, next to the step where somebody decides a vulnerability is being exploited rather than reported.

The list is where this decays. Scope here is a function of what you ship, so it changes on an ordinary Tuesday when somebody merges an installer or publishes a package, and nothing about that pull request looks like a compliance event to the person who opened it. We build Lawcel to watch that: it reads product changes as they land and flags the ones that move a legal obligation. You do not need us for this particular one, though. You need one named person who owns the question and gets asked it again after each release.

The alternative to writing that list down now is assembling it on the day a researcher emails you, with 24 hours on the clock and nobody sure who the report goes to.