The CRA’s First Deadline Is an Operations Test

The European Union’s Cyber Resilience Act’s (CRA) first reporting requirements take effect September 11, 2026. After that date, if a manufacturer becomes aware of a qualifying cybersecurity issue, it has 24 hours to submit an early warning, putting response processes, product information, and internal coordination to the test.

---

CRA Deadline Takeaways

• Reporting begins September 11, 2026. Manufacturers must report actively exploited vulnerabilities and severe security incidents affecting products with digital elements.
• The first reporting window is 24 hours. Once a manufacturer becomes aware of a qualifying event, it has 24 hours to submit an early warning through the CRA Single Reporting Platform.
• Product traceability supports faster assessment. Configuration, software, firmware, revision, and third-party component information can help determine which products may be affected.
• Reporting readiness depends on more than having a process. Clear responsibilities, monitored reporting channels, accessible product information, and coordination across functions can influence how effectively an organization responds once the reporting clock starts.

---

The Cyber Resilience Act (CRA) reaches its first major compliance deadline on September 11, 2026, more than a year before most CRA obligations take effect.

For manufacturers of products with digital elements, the first deadline raises operational questions. How quickly can an organization receive and evaluate a cybersecurity report? Can it determine what is affected, involve the appropriate people, and respond within the required 24-hour timeline?

With the deadline approaching, manufacturers have an opportunity to consider how their existing processes would perform if a reportable cybersecurity issue arises and the 24-hour clock starts.

Cyber Resilience Act Reporting Requirements

What CRA Reporting Requirements Take Effect?

Beginning September 11, manufacturers will be required to report actively exploited vulnerabilities and severe security incidents affecting products with digital elements, which include connected hardware, software, and their associated components. These reporting obligations arrive ahead of the CRA’s broader requirements, which take effect on December 11, 2027.

Reporting will take place through the CRA Single Reporting Platform (SRP), developed and operated by the European Union Agency for Cybersecurity (ENISA). The platform provides a single entry point for manufacturers to meet the CRA reporting requirements.

The process begins with an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe security incident. A full notification follows within 72 hours. Additional reporting occurs on timelines that vary depending on the type of event.

What Does the CRA’s 24-Hour Reporting Window Require?

The short reporting window puts added importance on how cybersecurity information enters and moves through an organization. A finding could originate internally or come from a customer or other party. Manufacturers can consider whether they have an accessible, monitored channel for receiving these reports, such as a dedicated email address on the company website.

“That email can't just go to a general bucket that will get sat on for two weeks,” said Martin Bowman, Software Engineer Team Leader at Sealevel Systems.

A product security incident response team (PSIRT) can provide a defined process for receiving, evaluating, and routing cybersecurity reports. The exact approach will vary by organization, but the short reporting window depends on getting information to the people who can act on it quickly.

Once information enters the organization, appropriate contacts need access to what is known at that stage. Internal routing and escalation then shape how quickly the event can be evaluated and addressed within the applicable reporting window.

Product Traceability and CRA Vulnerability Reporting

Identifying Affected Products and Configurations

Once a security issue is identified, determining its scope can quickly become a product-information problem.

A product name alone may not provide enough context. Different configurations can contain varying software or firmware versions, hardware revisions, or third-party components. Understanding potential exposure may require tracing the affected technology through those variations.

Third-party components highlight the challenge. A security flaw in a communications module, for example, may first surface in one product but exist in others built with the same module. Component records and revision histories can help connect the issue to other potentially affected configurations.

Bowman pointed to this broader exposure when discussing a component shared across a product line.

 “If we find a vulnerability in a module that we get from a supplier, it could potentially affect other products,” he said. “It’s not just the unit that gets the bug reported against it. It’s a broader impact.”

Traceability, therefore, helps establish more than the identity of the product initially associated with an event. It can also help determine whether the same cybersecurity concern extends elsewhere in a manufacturer's portfolio.

At Sealevel, traceability extends from engineering design through production. Controlled bills of materials (BOMs), software bills of materials (SBOMs), product and component revisions, engineering changes, and manufacturing records help connect what was programmed with what was ultimately built. That information can also provide a path back through the product when an issue arises. For CRA reporting, those established quality-control practices can provide useful information for assessing the potential scope of an issue.

What Product Information Supports CRA Reporting?

CRA reporting can draw on information maintained across different systems and functions. Configuration records can establish how a product was built. Software and component records can identify versions and third-party technologies associated with it. A threat analysis and risk assessment (TARA) can document potential threat scenarios and associated mitigations. Security and incident records document what is known about the event.

The information required also develops as reporting progresses. The first reporting step includes product identification and information available at that stage. Later notifications add further details, including an initial assessment and information about corrective or mitigating measures.

Connecting these records can make it easier to assemble the relevant information as the reporting process advances.

Cross-Functional Coordination for CRA Vulnerability Reporting

From Detection to Cybersecurity Response

A technical finding can quickly involve responsibilities beyond the person or team that discovers it.

Technical assessment helps establish what happened and which products may be affected. The issue may then move through internal escalation and a determination of whether it meets the CRA reporting threshold. Preparing and authorizing a notification introduces additional responsibilities before it is submitted through the SRP.

Work may continue on several tracks after submission. Technical teams could be evaluating mitigation or updates while other teams manage records or customer communication. Coordination becomes especially relevant when each activity depends on information coming from the same cybersecurity event.

Who Is Involved in CRA Vulnerability Reporting?

The functions involved will vary by organization, but a short reporting timeline can expose whether responsibilities are clearly defined.

One consideration is responsibility for evaluating technical information and determining whether an event meets the CRA reporting threshold. Another is authority to submit notifications through the SRP. ENISA’s process provides for primary and secondary assigned representatives, providing continuity if the primary reporting contact is unavailable.

Information also has to move among the functions involved. Connecting technical findings, reporting decisions, submissions, mitigation activity, and other actions to the incident record can provide a common reference as the response progresses. An internal dashboard can provide additional visibility, including an incident clock that tracks the time remaining within the reporting window.

CRA Reporting Readiness: Questions to Consider Before September 11

How Would Your CRA Reporting Process Perform?

The approaching deadline provides an opportunity to look at reporting readiness in terms of performance and clarity rather than simply whether a process exists.

That starts with the accessibility and monitoring of the cybersecurity reporting channel. It also includes how quickly potentially affected products and configurations can be identified and whether software, firmware, and third-party component information is readily available.

Responsibility is another consideration. Organizations can examine how clearly roles are defined for evaluating an event, determining whether it meets the reporting threshold, and submitting the 24-hour and 72-hour notifications. Primary and backup SRP responsibilities can be considered alongside the information available at each stage.

The same review can look at how mitigation, updates, and customer communication connect to the broader response.

What Could a CRA Reporting Readiness Review Reveal?

Looking at the process from beginning to end can uncover gaps that may be difficult to see when each activity is considered separately.

A security report may not reach the appropriate people quickly enough. Product or configuration information may be incomplete. Documentation may be fragmented, ownership unclear, or internal handoffs slower than expected. Limited information about third-party components can make the scope of an issue harder to determine.

The review may also expose gaps in primary and backup reporting responsibilities or disconnects between the technical response and other functions. Identifying those friction points before September 11 gives manufacturers a clearer picture of how their existing process could perform when the CRA reporting clock is actually running.

Frequently Asked Questions

When do the Cyber Resilience Act reporting requirements take effect?

The CRA’s mandatory reporting requirements take effect September 11, 2026. Manufacturers must report actively exploited vulnerabilities and severe security incidents affecting products with digital elements. The CRA’s broader requirements apply from December 11, 2027.

What is the CRA’s 24-hour reporting requirement?

Once a manufacturer becomes aware of an actively exploited vulnerability or severe security incident, it has 24 hours to submit an early warning. A full notification follows within 72 hours, with additional reporting depending on the type of event.

Where do manufacturers submit CRA cybersecurity reports?

Manufacturers submit CRA reports through the CRA Single Reporting Platform (SRP), developed and operated by the European Union Agency for Cybersecurity (ENISA). The SRP provides a single-entry point for meeting the CRA reporting requirements.

Why is product traceability relevant to CRA vulnerability reporting?

A reported security issue may affect more than one product or configuration, particularly when software, firmware, or third-party components are shared across products. Configuration and component records can help manufacturers identify the potential scope of an issue.

What can manufacturers consider before the September 11 CRA reporting deadline?

Manufacturers can consider how security reports are received and monitored, how quickly affected products can be identified, whether relevant technical information is readily available, and how clearly reporting responsibilities are defined. Reviewing these areas can help reveal potential gaps before a reportable event occurs.