Cyber Resilience Act: reporting vulnerabilities and incidents to ENISA

A credible report of exploitation reaches support on Friday evening. The affected library is part of a product your company sells. Engineering needs to determine which versions are exposed; someone also needs to decide whether the manufacturer must report.

Under Article 14 of the Cyber Resilience Act, or CRA, the first warning may be due within 24 hours of awareness. The reporting obligation has applied since 11 September 2026. It is already operational, even though most of the CRA’s wider product obligations apply from 11 December 2027.

Reports go through ENISA’s Single Reporting Platform, or SRP. This is an EU-wide product-security process, not a reporting duty limited to Polish companies. The account, escalation route and supplier cooperation need to work before a serious event arrives.

Law and platform guidance checked as at 1 October 2026, including ENISA’s FAQ update of 30 September 2026.

What you will learn

In brief

• Manufacturers report actively exploited vulnerabilities and severe incidents affecting in-scope products.
• A CVE or scanner finding does not automatically establish active exploitation.
• The 24-hour and 72-hour deadlines both run from awareness, with reporting required without undue delay.
• Vulnerability and incident final reports have different starting points.
• Reporting to the authorities does not replace informing affected users.
• A contract can allocate supporting tasks without changing the statutory manufacturer’s responsibility.

First establish the manufacturer and product

The manufacturer generally develops a product, or has it developed, and makes it available on the market under its own name or trademark. Writing code for a customer does not by itself make a software development company the manufacturer.

Check who markets the product, under whose brand, and on whose responsibility it was designed. Other statutory rules can also impose manufacturer duties, including particular substantial modifications. The contract should reflect the actual model and identify who supplies the evidence needed for reporting.

The product’s architecture matters too. Standalone SaaS is not automatically a CRA product. Software downloaded to a device can fall within scope; remote data processing designed or developed under the manufacturer’s responsibility can be included where its absence would prevent the product from performing a function.

Assess the actual product rather than relying on the “SaaS” label. Our CRA security-updates guide explains the wider lifecycle and maintenance questions. A supplier can have important contractual cooperation duties even where the customer is the statutory manufacturer.

Two distinct reporting triggers

An actively exploited vulnerability

There must be reliable evidence that a malicious actor has exploited the vulnerability in a system without the system owner’s permission. Publishing a CVE, finding a weakness in code or receiving a scanner alert does not automatically satisfy that definition.

Assess whether the vulnerability is contained in the manufacturer’s product and whether the evidence concerns exploitation relevant to that product. Record the basis for the assessment rather than treating every vulnerability entry as a mandatory notification.

A severe incident affecting product security

Article 14(5) has two alternative severity criteria. An incident is severe where it:

• 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; or
• Has led, or is capable of leading, to the introduction or execution of malicious code in the product or a user’s network and information systems.

Not every service interruption meets these conditions. Conversely, an incident affecting the release channel can matter because it enables malicious code to reach users, even before all customer impact is known.

Older products and third-party components still matter

Article 14 reporting covers in-scope products placed on the market before 11 December 2027. Waiting for the main CRA application date is therefore not an answer to a reportable event today.

Commission guidance distinguishes awareness from the age of the vulnerability. A manufacturer does not have to retrospectively report active exploitation it already knew about before 11 September 2026. Awareness acquired after that date can trigger reporting even where the flaw existed earlier.

An external component does not automatically transfer the final product manufacturer’s reporting responsibility to the component supplier. The manufacturer must assess the vulnerability in its own product. A component manufacturer may have its own duty where the component was itself placed on the market.

Coordinate information, versions and mitigation with the supplier. Do not assume that the supplier’s report necessarily satisfies your own obligation.

Deadlines: record awareness, not just ticket creation

The manufacturer must act without undue delay. The maximum periods are not an invitation to wait until the last hour.

Stage	Deadline	Information
Early warning	Without undue delay, within 24 hours of awareness	Initial information about the vulnerability or severe incident, including applicable affected Member States
Notification	Without undue delay, within 72 hours of awareness	Available general information, initial assessment and corrective or mitigating measures
Vulnerability final report	No later than 14 days after a corrective or mitigating measure becomes available	Severity, impact, available exploitation information and the remedy
Severe-incident final report	Within one month after the 72-hour incident notification	Detailed incident description, severity, impact, likely cause and applied or ongoing mitigation

The two final-report clocks are different. Do not reduce them to a generic “one month to report” in the incident procedure. The coordinating CSIRT may also request an intermediate status report under Article 14(6).

Record when credible information reached the organisation, who assessed it and what was known. A later management meeting or ticket reassignment should not be assumed to restart the awareness clock.

The current platform counter is not the legal deadline

ENISA’s current FAQ explains that the SRP’s 72-hour counter is displayed as 48 hours after submission of the early warning. An early warning submitted before the 24-hour limit can therefore produce an earlier displayed due time. ENISA says this counter will be adjusted.

Keep a separate record of the statutory deadline, which runs from awareness. The vulnerability final-report stage currently has no automated deadline counter. These interface details are procedural guidance as at the review date and can change.

Inform users alongside the authority report

Article 14(8) requires the manufacturer to inform users affected by the actively exploited vulnerability or severe incident, and all users where appropriate. Include available corrective or mitigating actions they can take where necessary.

Prepare that communication alongside the SRP notification. Identify affected versions, what users should do, what is still uncertain and where updates will appear. An authority report does not itself deliver a usable warning to customers.

Use the correct SRP endpoint

The live portal is portal.cra-srp.enisa.europa.eu. The manufacturer selects a CSIRT designated as coordinator. For an EU establishment, Article 14(7) generally looks first to where product-cybersecurity decisions are predominantly taken, with the statutory fallback where that cannot be determined. Non-EU manufacturers follow a separate statutory sequence.

Confirm the endpoint rather than choosing the country of a convenient sales office. ENISA warns that a wrongly selected coordinating CSIRT can invalidate a notification and require resubmission.

The notification is simultaneously available to ENISA. The coordinating CSIRT distributes it to other relevant CSIRTs and, where applicable, market-surveillance authorities.

Access, representatives and current platform limits

Representatives use personal EU Login accounts with MFA. Do not make the reporting process depend on a shared password or one person’s availability.

The current FAQ provides for one Primary Assigned Representative and up to 20 Secondary Representatives. The primary representative needs a verified manufacturer association before inviting secondary representatives. Association verification runs alongside reporting: an unverified association can submit up to 20 notifications before verification becomes mandatory.

ENISA advises initiating SRP registration and verification when a notification is needed; an active EU Login account can be prepared earlier. Plan that distinction and the handover process. Do not assume that appointing a backup internally has already granted them platform access.

Associated representatives can continue submitted reports according to their permissions. Drafts remain local to the individual representative’s account, so an unfinished draft needs a separate operational handover plan.

At this stage the platform does not offer an API. Use the interface and current ENISA instructions, including the SRP glossary. Mandatory fields differ between an early warning, notification and final report.

Restricted dissemination does not remove reporting

Exceptional cybersecurity grounds can justify delayed dissemination to other CSIRTs. A narrower mechanism can restrict which information ENISA initially receives from a 72-hour actively exploited vulnerability notification in particular exceptional circumstances.

The coordinating CSIRT decides on these mechanisms. Neither allows a manufacturer simply to omit its report. The relevant framework includes Article 16 and Commission Delegated Regulation (EU) 2026/881.

Limit submitted material to what is required or needed for assessment. Platform confidentiality measures do not make unnecessary personal data, secrets or complete customer records appropriate attachments.

A hypothetical case: exploitation in a library

Support receives a credible exploitation signal about a library included in a sold application. It immediately escalates to security and the person responsible for the reporting decision.

The team identifies affected versions, checks how the application uses the library and records when the relevant knowledge was obtained. If the in-scope product contains the actively exploited vulnerability and it can be exploited there, the manufacturer reports despite the flaw originating in an external library. It also prepares the affected-user communication.

If the architecture prevents exploitation of that flaw in the product, the team records the evidence supporting its no-report decision. A general statement that “the supplier owns the library” is not that evidence.

The supplier contract should provide rapid information, impact analysis, patch cooperation and support with reports and communications. Contractual response periods need to leave the manufacturer time within the statutory 24 hours.

Test the process before the next alert

The platform currently supports mandatory Article 14 reporting. ENISA says voluntary Article 15 reporting will be added later. Open-source software stewards’ corresponding Article 24(3) duties apply from 11 December 2027; do not treat every maintainer as already subject to the manufacturer’s September 2026 reporting timetable.

For contract design, connect this process with secure-by-design acceptance and the separate NIS2 and Polish KSC supplier-contract framework. The regimes have different triggers and responsibilities. Our technology legal services cover supplier cooperation, maintenance and product responsibility; contact us with the actual product and delivery model.

Primary sources

• Cyber Resilience Act, Regulation (EU) 2024/2847, particularly Articles 3, 14, 16, 24, 69 and 71.
• ENISA SRP FAQs, updated 30 September 2026.
• European Commission CRA implementation FAQs, version 1.4 of 4 September 2026.
• European Commission: CRA reporting.
• ENISA SRP glossary.
• ENISA representative registration guidance and interface guidance.
• Commission Delegated Regulation (EU) 2026/881, delayed dissemination framework.