At 09:12, a security alert lands in the team channel.
A third-party component inside a live product is being actively exploited.
The first questions are obvious. Are we affected? Which versions are exposed? Which customers use them? Is there a mitigation? How quickly can we release an update?
Another question is becoming just as urgent:
When did the reporting clock start?
From 11 September 2026, reporting obligations under the Cyber Resilience Act begin to apply. Manufacturers of covered products with digital elements will need to report actively exploited vulnerabilities and severe security incidents within clearly defined time windows.
The first deadline is twenty-four hours.
Not twenty-four hours after the investigation is complete.
Twenty-four hours after awareness.
The Cyber Resilience Act does not require every software bug to be reported.
The clock starts when a manufacturer becomes aware of an actively exploited vulnerability, meaning there is reliable evidence that a malicious actor has exploited it without permission, or a severe incident that meets the Act’s security-impact criteria.
For qualifying events, the reporting sequence is clear:
These deadlines are confirmed in the latest ENISA guidance for the CRA Single Reporting Platform.
Nobody expects a complete root-cause analysis in the first twenty-four hours. That is not what the early warning is designed to provide.
But the deadline does assume that the organisation can identify the affected product, recognise the nature of the event and begin coordinating a response.
In practice, the twenty-four-hour rule is not only a reporting deadline.
It is a product visibility test.
The difficult questions are usually internal
A vulnerability alert rarely arrives with all the answers attached.
The affected component may be used in several products. Different versions may be running in different environments. One team may own the application, another the infrastructure and a third the deployment pipeline.
Before anyone can report clearly, someone needs to establish:
The reporting form may be submitted by one person, but the information usually belongs to several teams.
Engineering understands the dependencies. Operations can see what is deployed. Product knows which users and workflows are affected. Security assesses the threat. Leadership decides how the organisation responds.
When these responsibilities are unclear before an incident, the first hours are spent locating information rather than acting on it.
Modern software is assembled from internal code, open-source libraries, cloud services, frameworks and third-party components.
That makes component visibility central to vulnerability response.
An up-to-date software bill of materials can help a team identify where a vulnerable dependency is used. But an inventory alone is not enough. It needs to connect to real product versions, deployments and ownership.
A list that says a library exists somewhere in the codebase does not answer whether the vulnerable version is currently running in production.
The Cyber Resilience Act reflects this wider supply-chain reality. Its scope includes both final products and components made available separately on the EU market, while manufacturers are expected to handle vulnerabilities affecting their products throughout the support period. The Commission’s current guidance for manufacturers places cybersecurity across design, development, market placement and ongoing product maintenance.
This does not mean every third-party vulnerability automatically becomes a reportable event for every company using the component.
It does mean that teams need a reliable way to trace a component from discovery to product impact.
Notifications will be submitted through the CRA Single Reporting Platform, which is being established and managed by ENISA.
The platform is designed as a single entry point. Manufacturers submit once, selecting the relevant national CSIRT based on their main establishment. The information is then routed to the appropriate authorities and, except in specific exceptional circumstances, made available to ENISA.
As of August 2026, ENISA says the platform is scheduled to become operational by 11 September 2026. It has also published updated guidance covering registration, notification submission and the information required at each stage.
A single platform simplifies external reporting.
It does not simplify the internal work required to produce an accurate notification.
That still depends on product records, dependency data, version tracking, monitoring, escalation paths and people who know what they are responsible for.
The wider Cyber Resilience Act obligations apply from 11 December 2027, but the reporting obligations arrive more than a year earlier. The European Commission’s latest implementation guidance, published in July 2026, covers scope, support periods, risk assessments and reporting requirements.
For product teams, preparation should begin with a few practical questions.
The CRA broadly covers hardware and software products with digital elements made available on the EU market, but the scope is not identical for every service, component or open-source arrangement.
Teams should establish which organisation acts as the manufacturer and which products require assessment rather than assuming that the regulation either covers everything or nothing.
Maintain a component inventory that can answer where a dependency is used, which version is running and who owns the affected area.
A static spreadsheet that is updated once a year will not be very useful during hour one.
The legal clock begins when the manufacturer becomes aware of a qualifying event.
Internally, teams need to know how security alerts are received, who evaluates them and when an issue is escalated into the formal response process.
Technical assessment, reporting, mitigation, release management and user communication should have clear owners.
The middle of an incident is a poor time to decide who has authority to submit a notification or approve an emergency update.
A short tabletop exercise can reveal missing information quickly.
Start with a hypothetical exploited dependency. Give the team twenty-four hours. Then ask whether they can identify the affected products, versions, markets, owners and first mitigation steps.
The gaps that appear are the real preparation plan.
At Galeyo, we see operational readiness as part of product engineering, not as a separate layer added after launch.
System evaluation, solution architecture, environment setup, custom development, monitoring and continuous iteration all shape how understandable a product remains as it grows. Those disciplines matter when teams need to trace an issue, assess its impact and move a change safely from code to users.
That is why our product development approach continues beyond implementation. A product should not only work when conditions are normal. The teams responsible for it should also be able to understand and change it when conditions are not.
The Cyber Resilience Act does not give teams twenty-four hours to learn how their own product works.
It gives them twenty-four hours to begin reporting what they already know.
The clock starts with awareness.
Readiness starts much earlier, in the architecture, the workflow and the everyday decisions behind the product.
Could your team trace a vulnerability from component to impact before the clock runs out?
This article provides a product and engineering perspective on the Cyber Resilience Act and does not constitute legal advice. Organisations should assess their specific scope and obligations with qualified legal and cybersecurity professionals.