The Cyber Resilience Act (CRA) is about to turn cybersecurity incidents into a race against the clock.

From 11 September 2026, all manufacturers of products with digital elements, and open-source software stewards will have mandatory reporting obligations for actively exploited vulnerabilities and severe incidents that affect the security of their products. The CRA’s main provisions apply later, in December 2027, but the reporting requirements arrive much sooner.

For security teams, that creates a practical challenge.

An attacker does not wait for an incident report to be complete. A vulnerability may be exploited, suspicious activity may appear across multiple systems, and the SOC may need to investigate what happened while the reporting clock is already running.

The question is therefore not simply whether or not your organization can detect an incident. It is whether you can detect it, establish what happened, determine whether it is reportable, and preserve enough evidence to support that conclusion in time.

What Does the EU Cyber Resilience Act Require?

The CRA establishes cybersecurity requirements for hardware and software products with digital elements made available on the EU market. Among its requirements are obligations for manufacturers to handle vulnerabilities throughout the product’s support period and to report certain security events once they become aware of them. You can access and read the official policy post by the Commission. Also, feel free to inform the official guidance by the European Commission from the official download link.

From 11 September 2026, two types of events are particularly important for reporting:

• Actively exploited vulnerabilities: vulnerabilities for which there is reliable evidence that a malicious actor has exploited them.
• Severe incidents: incidents having -or that are capable of having- a severe impact on the security of a product with digital elements, including impacts relating to availability, authenticity, integrity or confidentiality.

The reporting process is handled through the CRA Single Reporting Platform (SRP) operated by ENISA. A manufacturer submits the notification through the platform, which routes it to the relevant national CSIRT (Computer Security Incident Response Team) and ENISA.

For a SOC, this changes the way incident response ought to connect with compliance.

The security team may be the first part of the organization to see the technical evidence that an event has occurred. Logs, alerts, endpoint telemetry, vulnerability intelligence and analyst investigations can all contribute to establishing what happened and when the organization became aware of it. Thus, the quality and availability of the investigation record is critical.

The CRA 24/72-Hour Reporting Window

The CRA reporting clock starts when the manufacturer becomes aware of the actively exploited vulnerability or severe incident.

From this point, the reporting process regards the following phases:

Within 24 hours: Early warning

The first notification must be submitted without undue delay and, in any case, within 24 hours of becoming aware of the vulnerability or incident. At this stage, the organization is not expected to have completed its entire investigation. The purpose is to provide an early warning to the designated CSIRT as the coordinator and ENISA while the investigation continues.

Within 72 hours: Main notification

The next deadline is 72 hours from becoming aware.

The main notification provides more information, including general information about the vulnerability or incident and an initial assessment. Thus, the CRA reporting workflow requires organizations to move from initial detection toward a more informed understanding of what happened while the clock is still running.

After the initial notifications: Final report

The process does not necessarily end at 72 hours.

For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective measure becomes available. For a severe incident, the final report is due within one month after the initial notification.

This is where the SOC’s evidence trail becomes essential. Using the right tool for telemetry ensures compliance and trust.

ENISA’s reporting template includes information such as the time an incident was detected, the time it occurred, the initial assessment, corrective or mitigating measures, the nature and impact of the incident, and — as the investigation develops — more detailed information about severity, impact and likely root cause.

In other words, the reporting process is not simply about sending a notification quickly. It requires an organization to build and maintain an accurate picture of the incident as the investigation progresses.

For a SOC, that means being able to answer questions such as:

• When was the suspicious activity first detected?
• When did the organization become aware of the incident?
• What evidence indicates that exploitation occurred?
• Which products, systems or environments were affected?
• How did the incident impact security?
• What was the initial assessment?
• What actions were taken to contain or mitigate it?
• Can the investigation reconstruct the sequence of events later?

The faster the SOC can answer those questions — and the more reliably it can preserve the underlying evidence — the easier it becomes to support the CRA reporting process under a deadline.

Therefore, there is a new demand for organizations to establish strong detection and investigation tools.

 

Investigate incidents with Logstail SOAR

When performing incident evaluation, analysts ought to be wary of the scope of this incident. Thus, estimate the risk appetite of the network/organization as well as the particular device and context that is creating this alert or log. Keeping note of the scope, analysts then should evaluate the severity of the potential incident by commencing an investigation. Sequentially, evaluating the severity of the potential incident comes next, as this will queue the investigation against other incoming events. If a more serious event transpires, it is likely to take precedence to resolve.

Example
Let’s go over an example of this process using Logstail SOAR, starting from the beginning:

Detection

During the operational security of an organization, analysts get notified by Logstail SOAR that new alerts have been triggered. The analyst team can review these alerts stemming from behavioral analysis. In this example, analysts go over a malicious alert of Potential Access Token Abuse:

Alert triage

Analysts proceed to review the details of the alert. Logstail SOAR has forwarded important details regarding this event, that will help analysts evaluate severity and legitimacy of the alert. Thus, judging from the executable processes being obfuscated, target usernames, and SIDs used, as well as the time of the alert being outside working hours, analysts decide to flag this alert under current investigation.

Of course, triage is not where this workflow ends. It’s as important to provide a timely and precise documentation.

Incident Documentation

Analysts need to confirm compromise and severity. They will continue to evaluate a second deeper investigation by utilizing the Logstail SIEM to search for the maximum amount of available logged data. After noting down all points of interest, analysts integrate the alert into an incident case. The case note should document the relevant malicious artifacts and evidence supporting the determination of true Access Token Abuse, assess the incident’s scope, severity, and potential impact, identify affected users, systems, and resources, and summarize the containment, remediation, and follow-up actions taken or recommended.

Notification
Later on, by utilizing this case the organization can then escalate this documented incident to the CRA Single Reporting Platform (SRP), and establish a timeframe that aligns with the official established timings. This will ensure the organization a trusted workflow that aligns with the goals of the Cyber Resilience Act.

Each sequence of this process is audited and logged in Logstail SOAR. In case of legal obligations, organizations have absolute control and access of the audit trail of each operation against alerts, case creation and clearing of tracks.

Incident Response Training with Logstail Academy

You can further train on this topic with hands-on courses on Logstail Academy. Particularly take the courses on Incident Response management and Leveraging SIEM for Investigations & Cyber Forensics. These will provide hands-on courses on the Logstail SIEM & SOAR as well as recommended workflows for managing incidents, evaluating incoming alert and rule-based traffic as well as responsible notifying of security gaps.

 

Conclusion

New developments from the European Cyber Resilience Act require companies to be proactive and prepared for quick and analytical triage & investigation. By adhering to recommendations from official sources as well as our supporting material, your organization can build a strong foundation and be prepared to effectively combat potential security incidents with accurate supporting analysis. Logstail SOAR platform, as well as academy resources provide crucial help for organizations dealing with the new Cyber Resilience Act requirements, through efficient incident management and detailed sourcing.

Contact Our Experts or Sign Up for Free