CRA from 11 September 2026: 24/72-hour reporting

Article 14 of the Cyber Resilience Act, Regulation (EU) 2024/2847, applies from 11 September 2026. Manufacturers of products with digital elements within CRA scope must report actively exploited vulnerabilities and severe incidents affecting the security of their products. ENISA launched the initial operating capability of the Single Reporting Platform (SRP) that day.

The main product cybersecurity and conformity-assessment requirements apply from 11 December 2027. For a software company’s leadership, the immediate decision is who assesses an event, prepares the information and can submit a notification in time. This article was verified on 13 September 2026.

The CRA covers hardware and software products with digital elements made available on the EU market, subject to the regulation’s conditions and exclusions. Relevant readers include manufacturers of distributed applications, connected equipment and separately marketed components. Article 14 reporting also covers in-scope products placed on the market before 11 December 2027.

SaaS is not automatically in scope: assess whether it constitutes remote data processing necessary for a product’s functionality and meets the legal definition. Using an open-source library does not make a company an open-source software steward. The specific Article 24(3) duties for that category start on 11 December 2027.

Assess scope by product and manufacturer entity. Operating in a NIS2 sector is not a CRA scope test. For an organisation that only buys software, the practical lesson is to request a security contact and a clear communication process from the supplier.

An actively exploited vulnerability requires reliable evidence of exploitation by a malicious actor without the system owner’s permission. A CVE, high CVSS score or good-faith security test alone is not enough. EPSS estimates exploitation probability; it does not prove an attack occurred.

For incidents, Article 14(5) includes actual or potential effects on protection of sensitive or important data or functions, as well as the introduction or execution of malicious code in the product or a user’s systems. You do not need an already-confirmed data leak to assess this threshold.

An alert about a third-party component requires checking the version and how it is used in the product. The Commission FAQ explains that a vulnerability that cannot be exploited in that product is not subject to this mandatory reporting. Document the reasoning and reassess it when new evidence arrives.

The 72 hours are not added to the 24 hours. The 14-day deadline is not a general allowance for developing a patch. Retain separate timestamps for the initial signal, awareness, submissions and availability of measures.

Do not wait for the investigation to finish before issuing the early warning. The stages allow information to be completed. Alongside authority reporting, Article 14(8) requires informing affected users and, where appropriate, all users, including relevant measures.

• Early warning: without undue delay and no later than 24 hours after becoming aware.
• Notification: without undue delay and no later than 72 hours after the same awareness point, with available information and relevant measures.
• Final vulnerability report: no later than 14 days after a corrective or mitigating measure becomes available.
• Final severe-incident report: within one month after submission of the 72-hour-stage notification.

Submit through the SRP to the designated coordinating CSIRT; the notification is normally accessible to ENISA simultaneously. Jurisdiction primarily depends on where product cybersecurity decisions are predominantly taken, with further rules for manufacturers without a main EU establishment. ENISA’s official list identifies DNSC for Romania.

The reporting representative needs a personal EU Login account with MFA. According to ENISA’s 12 September FAQ, SRP registration and association validation are recommended when a notification must be submitted; association verification can run alongside reporting. Prepare the account and responsibilities before an incident.

At launch, the SRP has no API for automated notification submission. If the platform is temporarily unavailable, ENISA advises submitting when service resumes and contacting the CSIRT directly if immediate communication is needed; the notification must still be entered in the SRP afterwards.

Our recommendation is a shared workflow for security, development, support and management. The component inventory, supplier contacts and evidence should be accessible to whoever is on duty, rather than depending on one developer. Independent reporting by ITPro on 11 September highlights the difficulty of reconstructing a software inventory during an incident.

For an internal exercise, start with a fictional signal about a library: who confirms deployed versions, assesses exploitability, receives customer reports and retains the decision rationale? Repeat the scenario for a severe incident without a public CVE. Do not submit test notifications to the SRP.

• An owner and deputy for assessment, escalation, submission and user communication.
• A product and version inventory, tracked components, public sources and channels for private reports.
• A timeline with dates, times, time zones, evidence and reasoned decisions.
• A case record connecting notifications, actions, communications and verification of measures.

Monitor’s published capabilities include scheduled two-hour aggregation from NVD, CISA KEV, EUVD and GitHub Advisories, CVSS + EPSS prioritisation, watchlists, assignment, notes and evidence exports. Pro adds version-aware inventory from SBOM, package.json or requirements.txt and team workflow integrations.

These capabilities can support investigation of public signals and documentation of actions. The team must map inventory to marketed products and assess exploitation information in context. The two-hour cycle is a described service feature, not a CRA-mandated scanning deadline.

Monitor does not replace channels for incidents and unpublished vulnerabilities, legal assessment or the SRP. We do not describe internal exports as official notifications or promise CRA compliance through use of the application.

The AWARELY checklist turns these decisions into 12 steps, from scope and access to notification, the final report and rehearsal. It is available in full on the website in Romanian and English for teams to work through together. Ticking steps tracks work progress; it does not certify scope or compliance.