CRA reporting is now mandatory: are you ready?

Why does CRA readiness matter now?

Reporting obligations for actively exploited vulnerabilities and severe incidents affecting product security have applied since September 11, 2026. Reporting requires an operational capability now, while organizations continue preparing for the wider product cybersecurity obligations that apply in 2027.

Non-compliance carries real financial weight, as it can attract maximum penalties of EUR 15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. The applicable penalty depends on the infringement and enforcement decision. That exposure sits alongside the reputational and customer-trust cost of a missed or mishandled report.

The timing collides with a shift in how code gets written. AI-assisted development is increasing the volume of code entering production. The CRA does not create an exception for AI-generated code: the manufacturer remains accountable for the security of the product. More code, produced faster, means more change to inventory, verify, and assess, with the same reporting clock and manufacturer accountability.

What must you report under the CRA?

The CRA reporting obligation covers actively exploited vulnerabilities contained in in-scope products and severe incidents having an impact on the security of those products. Each follows a staged reporting process once the manufacturer becomes aware of a qualifying event.

The staged reporting timelines

For an actively exploited vulnerability:

• Early warning: Submitted without undue delay and within 24 hours of becoming aware of the actively exploited vulnerability.
• Vulnerability notification: Submitted without undue delay and within 72 hours, unless the relevant information has already been provided, with available information about the product, the vulnerability and exploitation, and corrective or mitigating measures.
• Final report: Submitted no later than 14 days after a corrective or mitigating measure becomes available.

For a severe incident having an impact on product security:

• Early warning: Submitted without undue delay and within 24 hours of becoming aware of the severe incident.
• Incident notification: Submitted without undue delay and within 72 hours, with an initial assessment of the incident, including its severity and impact and, where available, indicators of compromise.
• Final report: Submitted no later than one month after the 72-hour incident notification. If the incident is still ongoing, the CRA provides for a progress report followed by a final report after the incident has been handled.

Manufacturers submit notifications once through ENISA's CRA Single Reporting Platform. The notification is addressed to the CSIRT for the Member State of the manufacturer's main establishment and, unless exceptional circumstances apply, is made available simultaneously to ENISA. The compressed windows mean that gathering facts, assessing scope, and preparing the notification must happen while the event is still live.

What each report needs to contain

Each phase asks for more than a checkbox.

The required information develops across the reporting sequence, from the affected product and the nature and likely impact of the event to the available corrective or mitigating measures, severity, root cause, and remediation. The precise content differs between vulnerability and incident notifications. A reliable link between the reported event and the underlying product, code, dependency, or configuration helps teams substantiate their assessment under the deadline.

Manufacturers must also be prepared to inform affected users without undue delay about qualifying incidents or actively exploited vulnerabilities and, where appropriate, the corrective or mitigating measures users can take.

Where do CRA readiness gaps usually appear?

The blockers that stop organizations from reporting on time are rarely limited to a missing tool. They are often gaps in the operational process that should be decided in advance, so nobody has to invent it while a vulnerability is being exploited or an incident is underway.

Asset and product inventory

You cannot assess or report on a product you cannot locate. Many organizations lack a current inventory of which products with digital elements they place on the EU market, which components and dependencies those products contain, and who is responsible for each. An SBOM can support component-level visibility, while a product catalog establishes the product, version, market, and ownership context needed for reporting.

Detection and intake

A report starts with awareness, and awareness depends on detection and intake. Gaps here take two forms: no reliable operational monitoring or external intelligence for identifying potential exploitation or incidents affecting deployed products, and no defined intake channel for reports arriving from researchers, customers, or vulnerability scanning. If a disclosure lands in an unmonitored inbox, the 24-hour clock may already be running before the right team sees it.

Triage capacity and named ownership

Detection without triage is noise. Teams need separate, documented decision criteria for determining whether there is reliable evidence of an actively exploited vulnerability and whether an event qualifies as a severe incident affecting product security. They also need a named owner authorized to make or escalate that determination. When accountability is diffuse, the reporting decision can stall in exactly the window the CRA gives teams least room to spare.

Legal, communications, and escalation

Reporting is a cross-functional act. Legal has to confirm how the obligation applies, engineering has to supply the technical facts, and communications has to support required user notifications. Without a pre-agreed escalation path that names who is involved and when, coordination overhead consumes the deadline. The failure mode is not one team dropping the ball; it is no team knowing it holds the ball.

How does secure development support CRA readiness?

Reporting is the most immediate obligation, but the CRA also requires, where applicable based on the cybersecurity risk assessment, that in-scope products are made available without known exploitable vulnerabilities and are maintained securely across their lifecycle. Reporting readiness is easier when engineering teams reduce preventable risk and maintain usable technical information about their products.

This is where secure software development practice pays back directly. Catching injection flaws, hard-coded secrets, and vulnerable dependencies before code reaches production reduces the likelihood that those issues will later be exploited. Generating an SBOM and maintaining remediation records means that, when a report is required, useful technical inputs already exist rather than needing to be reconstructed under a deadline.

The connection runs both ways. A codebase with continuous vulnerability management and current dependency visibility narrows the scope of investigation and can shorten the time needed to assemble technical reporting inputs. Compliance readiness becomes part of how teams build and maintain software, rather than a separate scramble before an audit or reporting deadline.

How can SonarQube help you strengthen CRA readiness?

SonarQube provides independent code analysis that applies consistent quality and security standards regardless of whether code was written by a developer or generated with an AI tool. For teams working toward CRA readiness, it supports prevention, code-level vulnerability identification, dependency visibility, remediation, and the technical inputs used in assessment and reporting.

SonarQube capabilities support the code-level side of CRA readiness:

• Vulnerability detection at the source. Static application security testing identifies potential vulnerabilities and security weaknesses, including injection-related issues, early in development. Secrets detection scans for hard-coded credentials and access tokens in analyzed source code.
• Dependency and supply chain visibility. Software composition analysis in SonarQube Advanced Security identifies known vulnerabilities in third-party open-source dependencies and potential conflicts with organizational license policies. Continual analysis helps teams identify newly disclosed dependency risks. 
• SBOM capabilities support the machine-readable component inventory required by the CRA, which must cover at least top-level dependencies.
• Standards enforcement and supporting evidence. Quality gates define automated release conditions and can be integrated with repository and CI/CD controls to prevent non-conforming code from progressing. 
• The EU Cyber Resilience Act security report maps detected findings to relevant CRA requirements to support assessment and triage; it is not a compliance attestation. 
• Audit logs record supported administrative, access, and security-configuration events, providing governance context.

Different controls operate at different stages of development, from IDE and pull-request feedback to CI/CD analysis and release enforcement. This allows verification to keep pace with AI-assisted development while preserving the same standards for human- and AI-generated code. 

To get started, connect SonarQube to the relevant repositories, define suitable quality profiles and quality gates, enable the required Advanced Security capabilities, and establish SBOM coverage for in-scope products.

Your 30-day CRA reporting-readiness action plan

The reporting obligation is already in force. This plan is not a grace period: any qualifying event must be reported within the applicable Article 14 timeline while operational gaps are being closed. The goal for the next 30 days is to establish and test a process that can move on a 24-hour clock.

• Days 1–7: Establish access and intake. Confirm access to ENISA's CRA Single Reporting Platform and identify the CSIRT associated with the manufacturer's main establishment. Define a single monitored channel for vulnerability disclosures and incident reports from researchers, customers, and internal detection. Publish a coordinated disclosure contact so external reporters know where to go.
• Days 8–14: Set reporting criteria. Establish separate decision tests for actively exploited vulnerabilities and severe incidents affecting product security, and document who is authorized to confirm or escalate each determination.
• Days 15–21: Define escalation and user-notification paths. Name the owner authorized to initiate reporting, and map the escalation to legal, communications, and engineering, including responsibility for required notifications to affected users.
• Days 22–30: Build and test reporting templates. Prepare separate templates for vulnerability and incident early warnings, 72-hour notifications, and final reports, reflecting their different content and deadlines. Run a tabletop exercise against a mock exploited vulnerability and a severe incident to test the chain end to end.

Evaluate your current CRA reporting readiness against this plan, and treat any step you cannot complete today as an operational gap requiring immediate attention.

Next steps

Cyber Resilience Act by industry: who is affected and who is exempt — clarify whether your products fall in scope before you build your reporting process.

Cyber Resilience Act compliance for AI-generated code — apply analysis, quality gates, SCA, and supporting evidence workflows to code whatever its origin.

SonarQube compliance and reporting — see how standards enforcement and supporting evidence work inside the development workflow.

Software bill of materials explained — understand the component inventory required by the CRA and how an SBOM supports it.

The Cyber Resilience Act: why AI velocity demands automated verification — read how SonarQube capabilities map to specific CRA requirements.