From 11 September 2026, manufacturers must report certain actively exploited vulnerabilities and severe incidents involving products with digital elements. The operational problem is not completing a form. It is the moment before that: a support ticket, researcher disclosure or telemetry alert must be recognised as a potential CRA event, assigned to the right product and manufacturer, reliably timestamped and decided by authorised roles. If the organisation waits for a confirmed root cause before locating the reporting route, it has already mistaken the first 24 hours for a research project.
Note: General professional guidance; not legal advice or a certification or audit guarantee.
The clock is event-specific and role-specific
The CRA reporting obligations apply from 11 September 2026, while the Regulation's main obligations predominantly apply from 11 December 2027. According to the European Commission's official reporting page, the reporting role is the manufacturer, and there are two distinct event classes: an actively exploited vulnerability contained in a product with digital elements, and a severe incident having an impact on the security of such a product. That distinction belongs in triage because it determines the subsequent reporting path.
For both, the Commission states that an early warning is due within 24 hours of becoming aware, followed by a full notification within 72 hours. The deadlines therefore do not attach indiscriminately to every bug, CVE or service outage. Nor should a company design its internal clock to start only when engineering, legal and communications have reached complete certainty.
This is a governance problem. The process must establish when the organisation has defensible awareness, who may classify the event, which legal entity is the manufacturer and which products are affected. It must also distinguish confirmed facts from assumptions. These matters need to remain controlled under pressure without turning uncertainty into inaction.
The dry reality is that a “critical” severity field is not a legal role. Ticketing systems remain remarkably indifferent to corporate structures.
A hypothetical operating scenario shows how quickly these questions converge. At 16:20 on Friday, an enterprise customer reports that unknown parties appear to be exploiting a vulnerability in an older product version. Support opens a ticket. Engineering sees a plausible technical connection but has not confirmed the attack vector. The product is developed by the German parent, distributed through another legal entity and made available in several markets. At 17:00, the facts remain incomplete, but the timing question is already real.
The process now has to preserve the awareness time rather than negotiate it backwards through internal meetings. Product Security tests product relevance and exploitation; Compliance and the Product Owner determine the manufacturer role; the authorised role decides whether, and on what basis, to open the reporting path. Unknown facts are not guessed. They receive an owner and a next review time. The practical sequence is therefore to preserve the signal, identify the case, structure uncertainty and authorise a decision. Another meeting counts as a control only if someone can decide more at the end than at the beginning.
In the example, a shared case is opened at 17:10. The original customer disclosure is preserved unchanged as intake evidence. Alongside it, the team creates a working position in which every statement is marked as confirmed, assessed or unresolved. Support adds the customer contact and affected version; Engineering secures technical artefacts; Product Security states the provisional event hypothesis. The Product Owner supplies the product and distribution mapping instead of leaving technical teams to reconstruct the corporate structure. Compliance tests the role, not the exploit. This division of work prevents everyone from checking everything while nobody owns the decision.
At 18:00, active exploitation is still not conclusively established, but the escalation threshold has been met. The authorised role records which facts support the assessment, which alternative explanation remains under investigation and when the next decision will be made. At the same time, the sender begins drafting the early warning. That does not prejudge the outcome. It parallelises reversible work: a draft can be discarded; lost hours are less cooperative.
On Saturday morning, a second technical finding confirms the product connection, although the exact attack path remains open. The management issue has now widened. The question is no longer only whether a report can be submitted on time, but whether Engineering capacity, customer communication and potential remediation are aligned to the same case position. If a hotfix is prioritised, the affected versions and the relationship to the investigation and notification must remain clear. If external communication is held back, that choice also needs an owner and a defined review point. Time pressure does not suspend governance; it exposes missing connections.
24 and 72 hours require different work products
Within 24 hours: an early warning, not completed forensics
The 24-hour stage is an early warning. Operationally, the team needs a concise, controlled data set. It records the time and source of awareness, the affected manufacturer legal entity, and the product, versions and known distribution. It also captures the suspected event class with its rationale, currently confirmed effects, immediate measures in progress and named contact and decision roles. Open questions receive a next update point rather than an empty field.
The aim is not to hide uncertainty. It is to distinguish confirmed facts, reasoned assessment and unknowns. A deliberately incomplete but controlled early position is more defensible than a late “perfect” account.
Within 72 hours: a structured full notification
By the 72-hour stage, investigation and governance must converge. Product security, engineering, support, legal/compliance and management should operate one shared case rather than maintain competing truths across separate tools.
The 72-hour data set updates the technical description and affected product versions. It brings evidence of active exploitation or incident severity together with known effects on users, markets and security. The attack vector, indicators and suspected cause are included where available. Containment and corrective measures, the communication and update plan, and remaining uncertainty with its owner and next deadline all belong in the same case.
The two stages therefore need separate templates but the same identity. The 72-hour notification should not emerge as a new document with no provenance; it must carry the early warning's knowledge state forward in a traceable way. Corrected assumptions are marked, not silently replaced. Version control allows the organisation to explain what was known and decided at each point in time.
A practical case model separates four layers. Intake evidence remains faithful to its source. The current technical finding summarises reproducible observations. The decision record connects those findings to the event class, manufacturer role, approval and timestamp. The submitted version then represents exactly the position that was authorised. This is not documentation theatre. It prevents a technical assumption corrected on day three from appearing retrospectively as certainty on day one, or a management decision from changing silently whenever someone edits the underlying ticket.
The 72-hour effort also needs a defined update rhythm. Engineering can investigate continuously, but at agreed points the reportable position is frozen, checked for contradictions and approved. New indicators do not drift uncontrolled into a report that has already been reviewed. Conversely, a material finding does not wait for the next large status meeting. The mechanism combines technical speed with controlled release: continuous analysis, a defined cut-off, focused review and a traceable new version.
The Commission's CRA reporting page also identifies different final stages. For an actively exploited vulnerability, a final report is required no later than 14 days after a corrective measure becomes available. For a severe incident, it is due within one month. These downstream routes should not disappear into a generic “final report due” field.
One external reporting channel does not mean one internal role
According to the Commission, manufacturers use one reporting route through the CRA Single Reporting Platform (SRP) for the same reportable matter rather than submitting separately to multiple authorities. The notification goes to the CSIRT where the manufacturer has its main establishment and, except in particularly exceptional circumstances, is simultaneously available to ENISA. The receiving CSIRT shares it without delay with other CSIRTs where the product has been made available. As of 31 July 2026, functional and security testing is under way; the platform is due to be operational by 11 September 2026.
Internally, several handovers still matter. During intake, Support, the SOC, researchers, suppliers or telemetry receive a signal. Triage by Product Security tests product relevance, exploitation and security impact. During role determination, Compliance or Legal works with the Product Owner and corporate data to identify the manufacturer legal entity. An authorised role then decides classification and reporting, with uncertain cases following a time-boxed escalation. A named sender and deputy use the SRP and retain the receipt, version and timestamp. Engineering and Product Security continue the case while Communications and management maintain consistent statements.
One case identifier should link the signal, decision, receipt, evidence, actions and external communication. It also prevents the 24-hour warning from becoming an isolated PDF with no owner for what follows.
The organisational consequences extend beyond Product Security and Legal. Portfolio owners must be able to provide reliable product and version data; corporate functions must map manufacturer entities; Operations must preserve relevant telemetry; Procurement must enable timely supplier support. Communications needs an approved factual position without turning the technical investigation into its editorial system. Management must resolve conflicts over capacity and risk treatment. Where these connections are absent, the deadline is effectively delegated to the function with the least spare time: the investigation team.
A useful management view therefore shows more than the number of open cases. It identifies time since awareness, the next decision deadline, the responsible manufacturer entity, evidence status, blocking dependencies, and sender and deputy availability. That makes resource decisions concrete. A case whose classification remains open because a supplier has not provided artefacts requires a different escalation from a completed notification waiting only for approval. Labelling both “in progress” mainly improves the colour of the dashboard.
In a second hypothetical scene, the receipt arrives on time but is stored only in the sender's personal mailbox. Two days later, the deputy takes over and can find neither the submitted version nor the underlying classification decision. The report was technically sent, yet the organisational case has broken. A common identifier and controlled repository turn a personal act of submission into a process the company can continue. Personal mailboxes are useful for many things, but rarely make a convincing long-term archive of collective accountability.
Four common design failures before the deadline
Incident response alone leaves product signals outside the process
A product-security case need not be an incident in the manufacturer's environment. Active exploitation may surface through a researcher, customer or supplier. Intake must therefore cover external disclosures.
Complete certainty is not a workable process design
The two stages anticipate incomplete knowledge. Missing certainty needs an owner and review time, not a silent pause button.
Service providers do not replace manufacturer identification
The Commission names the manufacturer. Providers may assist, but manufacturer identification and report authorisation must not remain an implicit contractual assumption.
Non-binding guidance supports judgement but does not make the decision
On 27 July 2026, the Commission published practical CRA guidance with examples, flowcharts and explanations, including on reporting obligations. The Commission expressly describes this guidance as non-binding. It is useful implementation support, not a silent amendment to the Regulation or an individual legal determination.
Operationally, that means the guidance can sharpen internal questions, templates and exercise scenarios. The actual assessment of role and event still has to be anchored in the product, legal entity and facts. When a passage is used in the rationale, the decision record should identify which case facts fit it and where uncertainty remains. The guidance then supports judgement without becoming an outsourced decision-maker.
Management checklist for 11 September 2026
- Product portfolio, manufacturer entities and separate triage criteria for both event classes are documented.
- Awareness time, case identifier, evidence, decisions, reports and communications remain traceably connected.
- Support, SOC, Product Security, Engineering, Legal/Compliance and management know handovers, authority and deputies.
- The 24-hour, 72-hour and event-specific final stages use distinct templates and deadlines.
- SRP access, submission and receipts are tested, and supplier and researcher disclosures reach Product Security directly.
- A tabletop exercise with incomplete facts and an absent primary owner gives management a prioritised backlog.
Conclusion and A-R-C action prompt
CRA reporting is not a portal project. It is a time-critical decision process involving the product, event, manufacturer role, evidence and communication. Good preparation clarifies who may decide under uncertainty and how each statement is supported.
The next step: Run a 90-minute exercise with a Friday Support case suggesting but not proving active exploitation while the primary reporting owner is unavailable. Measure time to identify the manufacturer entity, record awareness, reach a classification decision and produce an approvable early warning. The gaps are the real implementation backlog.
Professional boundary
This article provides professional analysis of product security, governance and implementation practice. It is not legal advice, an authority ruling, a conformity assessment, certification or an independent audit. CRA applicability, manufacturer role, event classification and reporting duties must be assessed for the specific product, legal entity and facts. A-R-C does not guarantee legal compliance, certification or a particular audit outcome.
Primary sources
- European Commission, “Commission publishes new guidance to support timely Cyber Resilience Act implementation”, published 27 July 2026; the Commission expressly describes the guidance as non-binding; accessed 2 August 2026: https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
- European Commission, “Cyber Resilience Act – Reporting obligations”, accessed 2 August 2026: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- European Commission, “Cyber Resilience Act”, accessed 2 August 2026: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
About the author
Andreas Rühl supports organizations as an interim CISO and ISMS/GRC advisor. His focus is making information security manageable, auditable and fit for management decisions.