The EU Cyber Resilience Act has been on most SaaS roadmaps as a 2027 problem, because its main cybersecurity requirements apply from December 11, 2027. One part arrived earlier. Since September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of their products with digital elements, and ENISA launched the CRA Single Reporting Platform on the same day to receive those reports. The deadlines are short. According to the European Commission, manufacturers must submit an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for an actively exploited vulnerability, or within a month of the 72-hour notification for a severe incident.
Is your SaaS company a manufacturer?
The CRA covers products with digital elements, which means hardware and software placed on the EU market. Standalone SaaS that is designed and developed outside the responsibility of a product manufacturer is generally outside the regulation, according to the Commission's guidance and FAQ. Browser-only web apps are not products in themselves. Cloud processing enters scope as a remote data processing solution only when it is necessary for a covered product to perform one of its functions and is developed under the manufacturer's responsibility. Here is the catch for SaaS founders: very few SaaS companies ship only a website. Look at what customers download or install from you: iOS and Android apps, desktop clients, browser extensions, on-premises connectors or agents, command-line tools, SDKs and client libraries, and firmware for any hardware you sell. Each of those may be a product with digital elements, and the backend that makes it work may count as its remote data processing solution.
What counts as reportable
Two things trigger the obligation: an actively exploited vulnerability in your product, and a severe incident having an impact on its security. A vulnerability someone reports through your bug bounty is not automatically reportable; one you have evidence is being exploited in the wild is. Write down how your team decides, with examples, before you need to make that call at two in the morning. The 24-hour clock starts when you become aware, so the decision process has to be fast and documented.
Build the reporting path now
Reports go through ENISA's Single Reporting Platform. A notification is addressed to the CSIRT where your company has its main establishment, which shares it with CSIRTs in other member states where the product is available, while ENISA receives it at the same time. ENISA has published user manuals, an FAQ, and a glossary, and runs a help desk. Do the setup work in a quiet week: identify who in your company will hold platform access, confirm your main establishment, and do a dry run with a fictional incident so the first real report is not also the first time anyone logs in.
CRA reporting runbook (manufacturer, from 2026-09-11)
T+0 Aware of actively exploited vuln / severe incident
T+24h Early warning via ENISA Single Reporting Platform
T+72h Full notification (impact, affected products, mitigations)
Fix+14d Final report for actively exploited vulnerability
T72h+1mo Final report for severe incident
Also: inform impacted users and share mitigation guidanceConnect it to incident response
Most SaaS companies already have an incident process for outages and data breaches, often built around SOC 2 controls and GDPR's 72-hour breach notification. Extend that process rather than creating a parallel one. Add a CRA decision step to your incident template: does this involve a product with digital elements, is a vulnerability actively exploited, does the incident affect product security. Assign a named owner for CRA reporting, and make sure legal, security, and engineering leads can reach each other on short notice. Remember that the obligation covers vulnerabilities in components you ship. If a library inside your mobile app or desktop agent is actively exploited, you may have a report to file even though the bug is not in your code. That makes a software bill of materials for every shipped artifact far more useful: when an exploited dependency appears in the news, you can answer within hours whether you ship it.
Prepare for December 2027 at the same time
Reporting is the first CRA obligation, not the last. From December 11, 2027, the main requirements apply, including secure-by-design obligations, vulnerability handling processes, security updates for the support period, and conformity assessment. The work you do now, such as product inventory, SBOMs, coordinated vulnerability disclosure, and an incident decision tree, is the foundation for that larger effort. Enterprise buyers in the EU are already adding CRA questions to procurement, so readiness is also a sales asset.
Tell your users, not only regulators
Reporting to authorities is only half of the job. The CRA also expects manufacturers to inform impacted users about actively exploited vulnerabilities and severe incidents, and to share corrective or mitigating measures they can take. Prepare templates for customer notices, a status-page format for security advisories, and a channel for enterprise security contacts. The faster a customer's security team hears from you directly, the less likely they are to learn about the issue from a scanner or the news.
Founder takeaway
List everything you ship that runs outside your cloud and decide, with counsel where needed, which items are products with digital elements. For those, the reporting clock is already running: set up access to ENISA's Single Reporting Platform, add a CRA step and owner to your incident process, generate SBOMs for every shipped artifact, and rehearse a 24-hour early warning. It is a small amount of work now compared with learning the process during a live exploit.
