CRA reporting starts 11 September 2026: what a small software vendor should do this week

Summary

From 11 September 2026 you must report actively exploited vulnerabilities within 24 hours — including for products you already sell. You don't yet need documentation or CE marking (those apply from 11 December 2027), but you do need a process in place: a reporting channel, an SBOM and an account on ENISA's platform. Do the five things this week that won't change.

The Cyber Resilience Act (Regulation (EU) 2024/2847) has two dates, and most small software companies remember only half of each. The second one — 11 December 2027, full conformity and CE marking — is still far away. The first one is this week: from 11 September 2026, Article 14 applies, meaning the obligation to report actively exploited vulnerabilities and severe incidents. And it applies to software and devices you placed on the market years ago.

Who is affected

Anyone who commercially places a "product with digital elements" on the EU market — software the customer installs or runs (desktop or mobile app, on-prem server, library, plugin, firmware), or a device with software or a network connection. Company size does not matter: the regulation has no exemption for micro-enterprises, only simplified documentation.

Pure SaaS is mostly out of scope (NIS2 covers it). But if you ship a client app, an agent or a device alongside your cloud service, that piece is a product. If you are not sure, our scope-checker gives you an answer in two minutes.

What exactly must be reported

Two events: an actively exploited vulnerability in your product (someone is really using it, not merely "a CVE exists") and a severe incident affecting the product's security. In both cases a cascade of deadlines starts the moment you become aware:

  1. Within 24 hours — early warning: who you are, which product, what it is about.
  2. Within 72 hours — full notification: nature of the issue, severity, corrective measures, affected Member States.
  3. Within 14 days (vulnerability) or one month (incident) — final report.

Reports are submitted through ENISA's Single Reporting Platform, which forwards them to your national CSIRT (in Slovakia, SK-CERT). The platform has no API — reports are filed manually through an EU Login account.

Scope-checker

Find out whether the CRA applies to you

Six questions, two minutes, no account. Get your product class and first steps.

Start the scope-checker

Why this is a problem even if you have no incident

Because 24 hours is not enough time to improvise. Who in your company hears about a vulnerability first? From where — do you even have a channel someone can report it through? Do you know which components and versions are in your product, so you can judge whether a new vulnerability affects you? Do you have an account on the platform? If any answer is "no", your first incident will arrive with a deadline you cannot meet.

Five things to do this week

  1. Register on ENISA's platform. You need an EU Login (which can be created in advance); after your first sign-in, your national CSIRT verifies the account. Do it before you need it — verification differs by country.
  2. Set up a vulnerability-reporting channel. A public e-mail address (typically security@your-domain) and a /.well-known/security.txt file on your website. This is also an Annex I obligation — you will need it in 2027 anyway.
  3. Build a component inventory (SBOM). A list of libraries and dependencies with versions, at least at the top level. Without it you cannot say within 24 hours whether a new vulnerability affects you. Tools like Syft or Trivy generate one from your build in minutes.
  4. Name one person and a deputy. Who monitors vulnerabilities (OSV, NVD, CISA KEV), who decides, who files the report. Write it on one page and keep it next to the platform login.
  5. Prepare a report template. The fields for the 24-hour, 72-hour and final reports are known. Pre-fill what does not change (manufacturer, contact, products) so that during an incident you only add the facts.

What can wait

Technical documentation, the Declaration of Conformity, CE marking and the Annex I security properties are fully required only for products placed on the market (or substantially modified) after 11 December 2027. The harmonised standards that self-assessment will be based on are not out yet — the first are expected at the end of October 2026. There is no point writing documentation today that you will rewrite in a few months. There is every point in having the processes from steps 1–5 — those will not change.

How CRAguard helps

This monitoring and paperwork is exactly what we want to take off small companies' hands: an SBOM from your build, daily comparison against vulnerability sources with one plain-language verdict, a hosted reporting channel, and a 24/72/14 deadline guide with pre-filled fields for ENISA's platform. Find out whether the CRA applies to you, or join the waitlist — we'll let you know at launch.

This article is informational and not legal advice. It is based on Regulation (EU) 2024/2847 and the European Commission's guidance of 27 July 2026.

Scope-checker

Find out whether the CRA applies to you

Six questions, two minutes, no account. Get your product class and first steps.

Start the scope-checker

Sources