What changes on 11 September 2026 for small software vendors

Not legal advice. Every claim below points to the article of Regulation (EU) 2024/2847 it comes from, so you can check it. Corrections welcome.

The short version

From 11 September 2026, anyone who sells software, firmware or a connected device into the EU must report actively exploited vulnerabilities in their product and severe incidents affecting it. That includes a one-person company, and it includes companies outside the EU. The deadlines run from the moment you become aware: an early warning within 24 hours, a notification within 72 hours, both through ENISA's single reporting platform (Articles 14 and 16).

Everything else in the Cyber Resilience Act applies from 11 December 2027 (Article 71): secure-by-design requirements, SBOM, technical documentation, EU declaration of conformity, CE marking, five years of security support. Fines exist (Article 64: up to €15M or 2.5 % of worldwide turnover, whichever is higher, which for a one-person company makes the €15M figure theoretical). They also apply from December 2027.

So September is not the deadline for being compliant. It is the date from which your reporting process must exist. The clock starts when you become aware, not when a regulator writes to you.

Are you a "manufacturer"?

The regulation applies to "products with digital elements": software or hardware products, and their remote data processing solutions, whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Article 3(1)). A "manufacturer" is whoever develops or manufactures such a product, or has it developed, and markets it under their own name or trademark, whether for payment, monetisation or free of charge (Article 3(13)). The condition is that the product is made available on the EU market in the course of a commercial activity (Article 3(22)).

In practice:

Sector exceptions: medical devices (MDR/IVDR), vehicles with type-approval, civil aviation, marine equipment and products developed only for defence or national security have their own regimes (Article 2). A free test walks through these questions and returns a written, indicative assessment with the article references: crakit.eu/scope.

What must exist on 11 September

Article 14 asks a manufacturer to notify any actively exploited vulnerability contained in the product (paragraph 1) and any severe incident having an impact on the security of the product (paragraph 3). Not every CVE. Not bugs.

"Actively exploited" means there is reliable evidence that a malicious actor has exploited the vulnerability in a system without the permission of the system owner (Article 3(42)).

"Severe incident" means an incident that 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. It also covers an incident that has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of a user (Article 14(5)).

The timeline, from the moment you become aware:

• 24 h: early warning. That the vulnerability is exploited (or that an incident occurred), and the Member States where the product is available. Very little detail is required at this stage.
• 72 h: notification. General information, nature of the exploit, corrective or mitigating measures taken and those users can take. For incidents: nature, severity, impact, indicators of compromise.
• Final report: for a vulnerability, 14 days after a corrective or mitigating measure is available. For an incident, 1 month after the notification.

Recipients: the CSIRT designated as coordinator in your Member State (or the one determined by your representative if you are outside the EU) and ENISA, through the single reporting platform (Article 16). You must also inform the users of the product without undue delay, and tell them about mitigating measures where needed (Article 14(8)).

So the minimum set-up for a small vendor on 11 September is short:

1. A reachable security contact. A security@ address that a human reads every working day, a /.well-known/security.txt (RFC 9116), and a public coordinated vulnerability disclosure (CVD) policy that says how to report and what happens next. Annex I, Part II, points 5 and 6 make the policy and the contact address mandatory in 2027 anyway. security.txt is the practical way to publish the address.
2. Knowing what is in your product. A software bill of materials of your dependencies. Not because the SBOM is due (that's 2027), but because "actively exploited" almost always arrives as a library you depend on landing on an exploited-vulnerabilities list. If you don't know you ship it, you can't be "aware" in time.
3. A one-page procedure. Who decides "this is actively exploited" or "this is a severe incident", who has the ENISA platform account, what goes in the 24 h message, what goes in the 72 h one, and how users are told.
4. The templates ready, so that at 2 a.m. nobody starts from a blank page.

What waits until 11 December 2027

• The essential requirements of Annex I, Part I: security by design, secure defaults, no known exploitable vulnerabilities at release, security updates, access control, encryption, integrity, data minimisation, resilience, attack-surface reduction, logging, secure deletion.
• The vulnerability-handling requirements of Annex I, Part II: SBOM (top-level dependencies at least), remediation without delay, regular testing, public disclosure of fixed vulnerabilities, CVD policy, contact address, secure update distribution, free security patches.
• Technical documentation (Annex VII), the conformity assessment, the EU declaration of conformity (Annex V), CE marking, and the user information of Annex II. On the assessment: self-assessment for most products. For "important" class I products of Annex III, self-assessment is only possible if harmonised standards or common specifications are applied in full (Article 32(2)); otherwise a notified body. Third-party assessment for class II and for the "critical" products of Annex IV.
• A security support period of at least five years, unless the product is expected to be used for less (Article 13(8)). Each security update stays available for at least ten years after it has been issued, or for the rest of the support period, whichever is longer (Article 13(9)).
• Fines: up to €15M or 2.5 % for Annex I and Articles 13/14 breaches; €10M or 2 % for other obligations; €5M or 1 % for incorrect information (Article 64). Micro and small enterprises cannot be fined for merely missing the 24-hour early-warning deadline, and open-source stewards cannot be fined at all (Article 64(10)).

Fifteen months is enough to do this calmly, in order: write down what you already do, put the SBOM in CI, run a risk assessment against Annex I, then draft the declaration.

Free things that help

• ENISA publishes guidance and the reporting platform documentation. OpenSSF and the Eclipse Foundation's ORC working group publish guidance and specifications aimed at open source. All free.
• I built two free tools for the small-vendor case. A scope test (8 questions, indicative assessment with article references). And an in-browser SBOM + vulnerability scanner that reads your lockfile, produces a CycloneDX SBOM, queries OSV.dev and flags entries from CISA's Known Exploited Vulnerabilities catalogue, the closest public proxy for "actively exploited". Nothing is uploaded except the package identifiers sent to OSV. Same thing as a CLI and GitHub Action: npx crakit (MIT). crakit.eu/scan
• The same site sells a €79 document kit (CVD policy, security.txt, vulnerability-handling and reporting procedures with templates, support statement, Annex I/II/V/VII drafts) generated from your answers, in English or French. You can preview it before paying, and you don't need it to use the free tools. I mention it because it pays for the free part.

Three honest caveats

1. CISA KEV is a US list, not an EU legal definition. It is a strong signal that something is actively exploited, not the whole answer. Vendor advisories and your own logs count too.
2. "Actively exploited" is a judgement call for the manufacturer. Write down how you make it. Over-reporting is provided for (Article 15 organises voluntary reporting). Under-reporting is what the penalty regime will target from December 2027.
3. The Commission's guidance is still moving (delegated acts on product categories, the technical descriptions of Annexes III/IV, standards under development). Article references are stable; interpretations may move. Check again before December 2027.

Regulation (EU) 2024/2847 of 23 October 2024, OJ L, 20.11.2024. Article numbers refer to that text.