The Cyber Resilience Act: The first reporting obligations will apply from September 2026

Why 11 September 2026 is a critical date for companies

The Cyber Resilience Act (CRA) is often associated with the year 2027. That is when the comprehensive requirements for the security of digital products begin to apply. One important obligation, however, starts significantly earlier.

From 11 September 2026, manufacturers of products with digital elements must report certain security events. These include:

• actively exploited vulnerabilities in products
• severe security incidents affecting product security

These reporting obligations are particularly relevant for manufacturers and product owners in industrial and software companies. Roles such as the CISO, product security teams, PSIRT, legal, compliance, and product management are also directly involved.

The challenge is that the reporting deadlines are very short and concern products already in operation. Companies therefore need to be operationally prepared, not just legally prepared.

Which security events must be reported

Not every vulnerability automatically triggers a reporting obligation. What matters is the actual security relevance.

Actively exploited vulnerabilities

A vulnerability is regarded as actively exploited where there are reliable indications that attackers are using it in practice. This may, for example, be the case in the event of:

• confirmed attacks
• observed exploits
• threat intelligence indicating exploitation in the wild

A simple rule of thumb is therefore:

Not every vulnerability is reportable. It only becomes reportable once its exploitation can be identified in the real world.

Severe security incidents

Certain security incidents must also be reported where they significantly impair the security of a product. Examples may include:

• unauthorized access to security-relevant functions
• manipulation of core product functions
• compromised update mechanisms
• a large number of affected systems or users

Whether an incident is considered severe typically depends on three factors:

• impact (the effects of the incident)
• scope (how many systems or users are affected)
• exploitability (how easily the attack can be carried out)

How the reporting process must work

Reporting takes place via a central European platform, the so-called Single Reporting Platform (SRP). From there, the information is forwarded to the competent authorities.

The reporting process is structured in several stages and follows clearly defined timeframes.

Stage 1: Early warning (maximum 24 hours)

An initial notification must be submitted within 24 hours of awareness. It contains a brief indication that a relevant security event has occurred, together with initial basic information.

Stage 2: Full notification (maximum 72 hours)

A more detailed notification must be submitted no later than 72 hours after awareness. It includes, among other things:

• affected products and versions
• an initial assessment of the incident
• current mitigation measures
• guidance for customers or users

Stage 3: final report

The final report follows later and depends on the type of event:

• in the case of actively exploited vulnerabilities: no later than 14 days after a remedy becomes available
• in the case of severe incidents: no later than one month after the notification

Which information companies must be able to provide at short notice

In order to submit a report, structured information must be available within a very short period of time. In practice, this means that companies must be able to compile a minimum information package quickly.

This will typically include:

• the product or product line
• affected versions and release dates
• the type of event (vulnerability or incident)
• an initial assessment of the potential impact
• the affected installed base or customer groups
• the current status of workarounds or patches
• a central contact person for follow-up questions

The problem is that this information is often spread across different functions, such as engineering, support, security, or suppliers.

The critical factor: A functioning triage process

The real bottleneck in relation to the CRA reporting obligation is rarely the technology itself. What matters far more is a clearly defined triage process.

Triage describes the path from the first indication of a problem to the decision as to whether an event is reportable.

A typical process may look like this:

• receipt of a signal (for example via support, the SOC, threat intelligence, or a bug bounty programme)
• initial review by product security or PSIRT
• classification of the event (vulnerability or incident)
• assessment: actively exploited or severe?
• collection of the relevant facts by engineering, product, and support
• approval by legal or communications leads
• submission via the reporting platform
• communication to customers and users
• final report and internal lessons learned

Without clearly defined roles, decision-making paths, and approval processes, this workflow can quickly stall.

What risks arise in the event of non-compliance

The CRA requirements are backed by significant sanctions.

Possible consequences include, among other things:

• fines of up to EUR 15 million or 2.5% of worldwide annual turnover
• regulatory measures such as sales bans
• product recalls or restrictions on product availability

In addition to financial risks, companies often also face reputational damage and a loss of customer trust.

How companies should prepare now

In order to comply with the reporting obligations from September 2026 onwards, companies must put several organisational foundations in place.

1. Define the reporting scope and responsibilities

Companies should first clarify:

• which products are relevant under the CRA
• which versions may be affected
• who is responsible for each product
• which contact chains apply in the event of an incident

2. Establish decision rules and approval processes

A central step is to define clear rules, such as:

• when “awareness” arises internally
• when a vulnerability is considered actively exploited
• when an incident is to be classified as severe
• who drafts and approves reports

Templates for the various reporting phases should also be prepared in advance.

3. Make facts and product data quickly available

In order for reports to be submitted within the deadlines, key product information must be centrally available. This includes, for example:

• versioning and release information
• update mechanisms
• support and patch cycles
• key components or dependencies

4. Involve the supply chain

Many security incidents are linked to third-party components or suppliers. Companies should therefore ensure that their partners can also provide relevant information quickly.

Important elements include, for example:

• clear escalation contacts
• defined response times
• obligations to pass on security-related information

5. Test processes realistically

Before the reporting obligation takes effect, it is advisable to conduct a trial run. For example, two typical scenarios may be simulated:

• an actively exploited vulnerability
• a severe security incident affecting customers

Such exercises help identify process gaps, missing data, or unclear responsibilities at an early stage.

Why reporting is hardly possible without vulnerability management

Formally, the CRA initially introduces a reporting obligation from September 2026 onwards. In practice, however, this obligation can hardly be met without basic processes for vulnerability management.

Companies therefore need at least a functioning structure for:

• intake channels for security reports
• assessment and prioritisation of vulnerabilities
• review of possible exploits
• coordination of fixes or workarounds
• communication with customers and authorities

In other words, functioning vulnerability management effectively becomes a prerequisite for legally compliant reporting.

Conclusion

The first mandatory requirement under the Cyber Resilience Act applies earlier than many companies expect: from 11 September 2026, actively exploited vulnerabilities and severe security incidents must already be reported.

The greatest challenge lies not in the reporting itself, but in the organisation behind it. Without clear triage processes, rapid access to data, and coordinated responsibilities, the short deadlines will be difficult to meet.

Companies should therefore review their reporting processes, responsibilities, and information flows at an early stage and ideally carry out realistic test runs before the deadline.