What Software Startups Must Report Under the EU CRA

The EU Cyber Resilience Act’s manufacturer reporting obligations already apply, having started on 11 September 2026. If your startup manufactures an in-scope software product supplied on the EU market, it must report actively exploited vulnerabilities and severe incidents affecting product security. The early warning is due within 24 hours of awareness; the follow-up notification is due within 72 hours. Most other CRA obligations apply from 11 December 2027, but the reporting duty does not wait until then. European Commission reporting overview

For a small engineering team, the immediate task is to establish whether the product is covered, identify the reporting trigger and assign someone who can submit while others investigate and mitigate.

Select the event your team has identified to see the reporting track and deadlines.

Software Coverage Depends on the Product and Commercial Model

The CRA generally covers software and hardware products with an intended or reasonably foreseeable direct or indirect data connection to a device or network. Separately marketed components can qualify. A manufacturer includes a company that develops software—or has it developed—and markets it under its own name or trademark. This is not a hardware-only category.

For software founders, three distinctions determine where to focus the scope assessment:

Product Model	Scope Consideration
Distributed software	A commercial desktop application, developer tool or self-hosted package supplied to EU users warrants assessment, even if the company is headquartered outside the EU.
SaaS or cloud backend	Cloud hosting alone does not establish coverage. Required remote processing can be part of a covered product.
Open-source software	An open-source licence is not a blanket exemption; the commercial model and the company’s role matter.

Remote processing is included when its software is designed and developed by or under the manufacturer’s responsibility and its absence would prevent the product from performing a function. A manufacturer-developed service providing an API required by its mobile application is the regulation’s example. Standalone cloud services are not automatically covered merely because they are software.

For open source, whether supply is commercial matters, and monetisation can extend beyond charging for a download. Conversely, development funding or regular releases alone do not make open-source supply commercial. A qualifying open-source software steward is a distinct role, not a label every open-source startup can adopt. These scope distinctions come from CRA Articles 2–3 and recitals 11–19. Stewards’ reporting obligations begin on 11 December 2027, rather than the manufacturer reporting start date, as the Commission reporting overview explains.

Document your distributed artifacts, required remote services, EU distribution and commercial model. Have counsel resolve borderline classifications against that architecture, rather than the marketing label “SaaS.” The Commission’s July 2026 non-binding guidance addresses remote processing, open source and reporting.

Existing releases are not grandfathered out of reporting. Article 69(3) expressly applies Article 14 to in-scope products placed on the market before 11 December 2027. CRA transitional provisions

Two Independent Events Trigger Mandatory Reporting

Reliable Evidence of Active Exploitation

The first trigger is an actively exploited vulnerability contained in your product. The legal definition requires reliable evidence that a malicious actor exploited the vulnerability in a system without the owner’s permission.

A scanner finding, high severity score or proof-of-concept alone does not establish this trigger. Conversely, do not limit triage to attacks against your own infrastructure: the definition is not confined to your systems.

A Severe Incident Affecting Product Security

The second trigger is a severe incident affecting product security. An incident qualifies if 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.

It also qualifies if it has led, or could lead, to malicious code being introduced or executed in the product or a user’s network and information systems. Actual data loss is therefore not required.

Assess the two triggers independently. A finding that does not establish active exploitation still needs assessment against the severe-incident test. The definitions and reporting triggers are set out in CRA Article 3(42) and Article 14(1) and (5).

The First Two Deadlines Run From Awareness

The 24- and 72-hour requirements are “without undue delay” obligations with outer limits, not permission to wait. Both run from awareness, not from completion of the investigation.

Stage	Exploited Vulnerability	Severe Incident
Early warning	Within 24 hours of awareness	Within 24 hours of awareness
Follow-up notification	Within 72 hours of awareness	Within 72 hours of awareness
Final report	No later than 14 days after a corrective or mitigating measure becomes available	Within one month after submitting the incident notification

The early warning identifies the affected EU Member States where applicable. For an incident, it must also state whether unlawful or malicious acts are suspected.

The 72-hour notification supplies available information about the exploit or incident and mitigation, including measures users can take. An unfinished investigation does not move that deadline: the notification uses the information available.

The final vulnerability report describes severity, impact and remediation. The final incident report adds the likely threat or root cause and applied or ongoing mitigation. Follow-up notifications and final reports are required unless the relevant information has already been provided. The coordinating CSIRT may also request an intermediate status report. CRA Article 14(2)–(6)

Submit Through ENISA and Select the Correct CSIRT

Manufacturers submit through ENISA’s Single Reporting Platform (SRP). Use ENISA’s SRP resource page for access, registration guidance, the user manual and field definitions. Arrange access before an incident so registration is not part of the first 24 hours of response.

The coordinating national CSIRT is normally selected by your main EU establishment: where product-cybersecurity decisions are predominantly taken or, if that cannot be determined, your EU establishment with the most employees.

Without an EU main establishment, Article 14(7) sets an ordered route:

1. The Member State of the authorised representative handling the most of your products.
2. If that route does not apply, the Member State of the importer placing the most of your products on the market.
3. Next, the Member State of the distributor making the most of your products available.
4. Finally, the Member State with the most users of your products.

Do not pick a country merely because it is convenient. Record the basis for your selection under CRA Article 14(7).

Give Reporting Its Own Owner and Evidence Record

Assign Submission Authority Before an Incident

Name a reporting owner and backup, arrange platform access and define who can approve submission outside business hours. Separate that responsibility from the investigation: the engineer diagnosing an exploited dependency should not also be the only person able to file the early warning.

Preserve Awareness and Trigger Evidence

Record awareness timestamps, affected versions, exploitation evidence, product impact and the trigger decision. Keep known facts distinct from open questions so the team can submit available information without presenting a hypothesis as an established cause.

Prepare notification templates with product identifiers, EU availability and user mitigations. Those details should not have to be reconstructed during the reporting window.

Track the Two Final-Report Clocks Separately

For an exploited vulnerability, record when a corrective or mitigating measure becomes available. For a severe incident, record when the incident notification is submitted. Those are different anchors for the final-report deadline; neither should be replaced by the original awareness timestamp.

Communicate With Users as Well as Regulators

Article 14(8) separately requires informing impacted users—and, where appropriate, all users—about the vulnerability or incident and, where necessary, mitigation and corrective measures they can deploy. An SRP submission does not replace that communication. CRA user-information duty

Rehearse the workflow with a hypothetical exploited dependency or compromised update channel. The test is whether the team can classify the event, submit available facts and give users actionable mitigation within the first 24 hours—not whether it can finish the postmortem that quickly.