CRA Vulnerability Reporting: The 24-Hour Rule

CRA vulnerability reporting becomes mandatory on 11 September 2026. From that date, every software manufacturer selling into the EU has to report an actively exploited vulnerability within 24 hours of becoming aware of it. Not 24 business hours. Twenty-four hours.

That deadline is weeks away, not months, and whether an engineering team can meet the window depends almost entirely on work that should have started months ago. For a large share of organisations it did not. A 2026 OpenSSF survey found that 72% of North American organisations still know little or nothing about their CRA legal exposure, and although the European picture is better, it is not better by much.

Below we set out what CRA vulnerability reporting in September 2026 actually requires, who it applies to, which technical infrastructure makes compliance possible, and where the common gaps are.

The Cyber Resilience Act and its phased deadlines

The Cyber Resilience Act, formally Regulation (EU) 2024/2847, is the first EU-wide regulation to place mandatory cybersecurity requirements on digital products across the whole lifecycle, from design and development through deployment and end of support. It entered into force on 10 December 2024, but the obligations arrive in phases, so most teams have been planning against the December 2027 date.

Article 14 is the exception, because the reporting duty starts on 11 September 2026. Everything else follows on 11 December 2027: conformity assessments, CE marking, technical documentation and the Software Bill of Materials requirement. Teams that worked through the EU AI Act August 2026 deadline will recognise the pattern, since the reporting and transparency duties land first and the heavier conformity machinery follows later.

Which products CRA vulnerability reporting covers

All of them. The duty applies to every in-scope product already made available on the EU market, not only to releases that appear after the date. A product shipped in 2019 and still sold or supported today carries the same 24-hour obligation as one launching next month. Because legacy products rarely have a current dependency inventory, that is exactly where most of the exposure sits.

Who counts as a manufacturer under the CRA

Most organisations get this wrong, because the definition reaches further than the everyday sense of the word. A manufacturer is any natural or legal person who develops or manufactures a product with digital elements, or has one developed or manufactured, and markets it under their own name or trademark.

Distributors who rebrand. If you take a product with digital elements and resell it into the EU under your own brand, you are the manufacturer. The obligation follows the commercial relationship with the European market, not whoever wrote the code.

Anyone bundling open source. If your product ships open source libraries, frameworks or operating system components, those are part of its digital elements. The obligations apply to the product as a whole, including the parts your team did not write.

Importers and authorised representatives. Where the manufacturer sits outside the EU, duties attach to the authorised representative or the importer. So the reporting path has to be settled contractually before an incident, not during one.

Where SaaS and cloud services sit

The blunt answer that circulates in most compliance summaries is wrong. Pure cloud services delivered as SaaS, PaaS or IaaS are not products with digital elements, since Recital 12 leaves them to NIS2. What the regulation does capture is a remote data processing solution: data processing at a distance, designed by or under the responsibility of the manufacturer, whose absence would stop the product performing one of its functions. A smart device's cloud control backend is therefore in scope. A general-purpose SaaS tool that your product happens to call is not.

CRA vulnerability reporting in September 2026: the exact cascade

The obligation runs on a defined clock, and the three stages are cumulative rather than alternative.

The Article 14 clock for an actively exploited vulnerability

24 hours: early warning

Notify that an actively exploited vulnerability exists. No full technical analysis required

›

72 hours: notification

Description, affected versions, initial impact assessment, corrective measures taken

›

14 days: final report

Due once a corrective measure exists: root cause, remediation, researcher credit

The same 24 and 72-hour rhythm applies to severe incidents, where the final report is due within one month rather than 14 days.

The cascade does not cover every disclosed CVE. It covers vulnerabilities that have been weaponised and are being used in real attacks, which is a far narrower set. Still, the narrowness cuts both ways, because knowing that a CVE has crossed from disclosed to exploited takes threat intelligence rather than a monthly dependency review. The clock starts when the manufacturer becomes aware, so a monitoring gap does not pause it.

The 24-hour clock starts when you become aware. It does not wait for the next sprint review.

Where CRA vulnerability reporting is filed

Reports go through one channel: the CRA Single Reporting Platform, which ENISA builds and runs under Article 16. A manufacturer files once, and the submission is routed at the same time to the CSIRT designated as coordinator for its main establishment and to ENISA. That replaces separate notifications to every national authority.

Two practical points follow. First, as of mid-2026 the platform was still pre-operational, and the initial rollout is expected to be manual entry through a portal without APIs, so system-to-system reporting is not available on day one. Second, a late platform is not a reason to wait, because identifying your coordinating CSIRT, agreeing who submits and drafting the early-warning template are all work that happens off-platform. Onboarding details appear on the Commission's CRA reporting page and on ENISA's Single Reporting Platform page.

End-of-life dependencies, from technical debt to legal liability

This is the part that will cause the most immediate disruption for teams that have not looked at it. Many enterprise products ship open source frameworks that have reached end of life, which means no security patches are coming from anyone.

EOL 31 Dec 2021

AngularJS

Still present in a surprising number of internal admin interfaces and customer portals that nobody has budget to rewrite.

EOL 31 Dec 2023

Moving to Vue 3 is a breaking change, so the upgrade tends to be deferred one quarter at a time.

EOL 30 Apr 2025

Node.js 18

A runtime out of support pulls every transitive dependency out of support along with it.

OSS support ended 31 Dec 2024

Spring Framework 5.3

Commercial support continues, which turns an unpatched deployment into a purchasing decision rather than an engineering one.

These are examples, not a complete list. For each product the question is simpler: does anything in the dependency tree no longer receive security patches from anyone?

Before 11 September, keeping these components in production was a risk management decision, so teams weighed migration cost against exposure. Afterwards it becomes a compliance question with a defined consequence. If a new CVE lands in an end-of-life component and that CVE is actively exploited, the manufacturer has 24 hours to notify. No patch exists, by definition, so the organisation has to report a vulnerability it cannot remediate. That problem cannot be solved after the date. Either the migration happens first, or the exposure is accepted with open eyes.

Concerned about end-of-life dependencies in your product stack? Our team can assess your exposure and build a remediation plan.

Talk to our team →

What the SBOM has to do for CRA vulnerability reporting in September 2026

A Software Bill of Materials is a complete inventory of the components in a software product. The formal SBOM requirement belongs to the December 2027 deadline rather than to September, although in practice that distinction is misleading. The 24-hour window is only achievable if the team already knows exactly what is in the product, down to every dependency and version. Without a live inventory, notification begins with manual discovery, and manual discovery does not finish inside a day.

Not enough

SBOM as compliance artifact

A document produced at a point in time, listing the components present in that snapshot. It satisfies the letter of the documentation requirement. During an incident it is already out of date, so it contributes nothing to the 24-hour clock.

What works

SBOM as operational tool

An inventory regenerated automatically with every build, connected to CVE databases and wired into alerting, so the security team learns within minutes that a component running in production is affected. This is what makes the window achievable.

Organisations that are ahead of the deadline have the second kind. They also have a defined path from alert to notification, which is the part usually left until an incident forces the question.

The infrastructure behind CRA vulnerability reporting in September 2026

Beyond the inventory itself, four capabilities have to exist.

Automated dependency monitoring. No security team tracks CVE databases by hand across every dependency in every product. Scanning belongs in the CI/CD pipeline, connected to the NVD, the GitHub Advisory Database and vendor feeds, with alerting tuned for high-severity findings in production components.

Active exploitation intelligence. Since the clock runs from awareness of active exploitation, monitoring has to separate a disclosed CVE from one confirmed in use. Known-exploited catalogues and commercial threat feeds do that work.

A defined reporting workflow. Who submits? Through which account on the Single Reporting Platform? To which CSIRT? What goes into the early warning as opposed to the 72-hour notification? A 24-hour window leaves no room to decide any of this while it is running.

Current registration details. Manufacturers have to identify themselves to their CSIRT and to ENISA. Check that the legal entity details are accurate and that the security contact on file is not someone who left two years ago.

CRA vulnerability reporting and open source: what maintainers owe

Open source developed and supplied outside a commercial activity falls outside the manufacturer obligations. The regulation recognises the ecosystem explicitly, so it creates a lighter category for open source software stewards, meaning the foundations and organisations that provide sustained support for components used in commercial products. Stewards document their security policy and disclosure practice. They do not face conformity assessment or the SBOM duty.

What maintainers will feel instead is demand pressure. Once enforcement begins, manufacturers carrying vulnerabilities in unmaintained components will turn upstream with urgent requests, although volunteer projects have no obligation to answer them. Planning on an upstream fix arriving in time is therefore not a compliance strategy. Our wider view of where European engineering teams stand sits in our cyber resilience outlook for 2026.

A readiness checklist for CRA vulnerability reporting September 2026

Five questions, in the order worth answering.

Are we a manufacturer, and for which products? List everything sold or supported in the EU under your brand, including legacy releases and rebranded third-party products.

Do we know our coordinating CSIRT? It follows your main establishment in the EU, or your authorised representative if the company is established outside it.

Do we have a live component inventory? One that regenerates with every build, not a spreadsheet from the last audit.

Can we tell disclosed from exploited within hours? If the answer depends on someone reading a newsletter on Monday morning, the window is not covered.

Who writes and submits the early warning at 2am on a Sunday? Name the role, write the template, and rehearse it once before it matters.

What Caixa Mágica brings to this

We have built software for the Portuguese public sector and for European enterprise clients for more than 20 years, and our security credentials include certification at Secreto level by Portugal's National Security Office. Linux Caixa Mágica, our open source operating system, is itself a product with digital elements under the regulation. The questions in this article are ones we had to answer for our own product before advising anyone else on them.

If you need help with SBOM implementation, vulnerability monitoring infrastructure or a CRA vulnerability reporting readiness assessment across your product stack, our software development and nearshore teams can work alongside yours.

Frequently asked questions

CRA vulnerability reporting September 2026: scope and deadlines

Who is considered a manufacturer under the EU Cyber Resilience Act?

A manufacturer is any organisation that develops or has developed a product with digital elements and markets it in the EU under its own name or trademark. That includes distributors who rebrand, organisations that bundle open source components into commercial products, and, where the manufacturer sits outside the EU, the authorised representative or importer. You do not need to have written the code.

What does the CRA September 2026 reporting obligation require?

From 11 September 2026, manufacturers must submit an early warning to their coordinating national CSIRT and ENISA within 24 hours of becoming aware of an actively exploited vulnerability, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure becoming available. Severe incidents follow the same 24 and 72-hour rhythm with a final report within one month. Reports are filed once through ENISA's Single Reporting Platform, and the duty covers products already on the EU market.

Does the CRA apply to SaaS products?

Not by default. Cloud services delivered purely as SaaS, PaaS or IaaS fall under NIS2 rather than the CRA. A cloud component is in scope only as a remote data processing solution, meaning it is designed by or under the responsibility of the manufacturer and the product would fail to perform one of its functions without it.

SBOMs, dependencies and open source

What is an SBOM and why does it matter for CRA compliance?

A Software Bill of Materials is a complete inventory of the components in a software product. The formal requirement applies from December 2027, but an operational SBOM, regenerated with each build and connected to CVE databases, is what makes 24-hour reporting achievable from September 2026. Without one, notification starts with manual discovery that cannot be completed in the time available.

Are end-of-life open source dependencies a CRA liability?

Yes. If your product ships components that no longer receive security patches, any new actively exploited CVE in those components creates a reporting obligation you cannot close with a patch. That moves end-of-life dependencies out of the technical debt column and into regulatory compliance.

Do open source maintainers face CRA obligations?

Not directly, for projects developed and supplied outside a commercial activity. Open source software stewards face lighter duties around security policy and disclosure documentation. The practical risk for maintainers is demand pressure from manufacturers seeking urgent fixes once enforcement begins.

Caixa Mágica Team

Caixa Mágica Software is a Portuguese software company with 20+ years of experience delivering custom software, AI solutions and nearshore development teams for European businesses.

Software Development · Caixa Mágica Software

Get your software supply chain ready before 11 September

Operational SBOMs. Vulnerability monitoring wired into your pipeline. Migration plans for end-of-life dependencies. Built by a team that has shipped secure software for public sector and enterprise clients for over 20 years.

See how we build Start a conversation