Accountability sits with the manufacturer of the product as placed on the EU market, but the operational filing path may involve assigned representatives, importers, distributors, or open source stewards in limited cases. Organisations need a documented internal owner so the legal obligation and the filing action line up before an incident occurs.
Why CRA reporting becomes a governance problem in multi-entity groups
The Cyber Resilience Act creates a reporting obligation that follows the economic operator responsible for the product as placed on the EU market, so the first question is legal accountability, not who happens to notice the issue first. In a multi-entity organisation, that distinction matters because product ownership, market placement, and incident knowledge are often split across business units, subsidiaries, and regional teams. The internal owner must be explicit before an incident, or reporting can stall at the exact moment speed matters. For the legal basis and reporting context, the EU Cyber Resilience Act is the most direct authority.
Practically, the accountable entity should be the one that can make filing decisions, coordinate evidence, and speak for the product without needing to negotiate ownership during a live event. In practice, many organisations discover that reporting accountability is unclear only after an incident has already forced a cross-border coordination effort.
How the filing chain should work in practice
In a group structure, accountability and execution should be separated but linked. The manufacturer remains the accountable party, while operational tasks can be delegated to a legal entity, compliance function, product security team, incident response team, or appointed representative where the CRA permits that arrangement. The key control is not who drafts the report, but whether the draft, review, approval, and submission path are documented and rehearsed. Without that, the organisation may know there is an incident but still miss the filing window.
A workable operating model usually includes:
- one named accountable owner for CRA reporting decisions;
- one documented backup for absence, escalation, or regional handoff;
- a clear trigger for when an incident becomes reportable;
- a preserved evidence path from detection to filing.
This is especially important where distributors, importers, or open source stewards sit close to the product but do not control the legal obligation themselves. They may provide evidence, support triage, or pass notifications upstream, yet the filing authority still has to be unambiguous. The EU CRA policy page is useful here because it anchors the accountability model to the product’s market placement rather than to whichever entity receives the alert first. These controls tend to break down when the product is shipped through several subsidiaries and no single entity has authority over the final report.
Common variations and edge cases in group structures
Tighter legal accountability often increases coordination overhead, so organisations have to balance local responsiveness against central control. The hard part is that the “right” reporting owner is not always the same as the team that has the best technical visibility.
Common edge cases include contract manufacturing, white-label products, shared platforms, and open source components embedded into a commercial product. In those situations, the organisation should avoid assuming that whoever maintains the code also owns the CRA obligation. If multiple entities contribute to a product, the group needs a single designated reporting authority, plus a documented internal escalation path for shared evidence and cross-entity sign-off.
Where a group uses regional subsidiaries, the reporting line should be tested against the real incident path, not the org chart. The best practice is to define one accountable entity, one operational reporter, and one escalation timetable, then verify that all three survive a weekend incident, a holiday, or a legal review delay. The same EU CRA source is the relevant reference point because it ties reporting duty to the market-facing manufacturer relationship, which is exactly where multi-entity confusion tends to arise.
Risk and Threat Considerations
The main risk is not just non-compliance, it is missed or delayed reporting caused by fragmented ownership. When accountability is split across entities, incident response can become a handoff problem, and the filing obligation may sit with a different legal entity than the one that first sees the issue.
Failure mechanism: Teams detect an incident in one subsidiary, but legal responsibility sits elsewhere, so evidence, approval, and submission all wait on internal clarification. That delay can be worsened by distributed product ownership, outsourced operations, or a misunderstanding of who qualifies as the manufacturer.
Impact: The organisation risks late reporting, inconsistent statements, and weak auditability, and it may lose the ability to demonstrate that the correct entity made the required filing decision on time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU Cyber Resilience Act | Manufacturer accountability and incident reporting | The question is about who holds CRA reporting accountability in a multi-entity group. |
| Recommendation — Assign reporting ownership to the manufacturer entity placed on the EU market. | ||
| NIST CSF 2.0 | GV.RM-01 — Organizational Risk Management Strategy | Multi-entity CRA reporting needs a clear internal owner and escalation governance. |
| Recommendation — Define a governance owner for regulatory incident reporting across the group. | ||
| CIS Controls v8 | 12.4 — Establish and Maintain an Incident Response Process | CRA reporting depends on a documented incident-to-filing workflow and escalation path. |
| Recommendation — Document and test the incident reporting workflow before a reportable event occurs. | ||
Practitioner Guidance
What to prioritise: Name the reporting owner at the same time you assign product ownership, then document which entity is allowed to submit, approve, and escalate the CRA report. If those roles differ, the handoff must be explicit and testable.
What to verify: Check that the accountable entity matches the product as placed on the EU market, not just the group’s technical operator or incident team. Also verify that backup approvers, contact details, and evidence retention are current enough to survive an after-hours incident.
Decision rule: If more than one entity could plausibly think it owns the report, treat that as a governance defect and resolve it before the next release, because the ambiguity itself is the operational risk.
Practitioner takeaway: CRA reporting fails most often when legal obligation and operational visibility live in different places, so the control objective is to make one entity accountable while keeping the filing path fast, rehearsed, and provable.
Related resources from NHI Mgmt Group
- Who is accountable when a supplier compromise disrupts a multi-organisation event?
- Who is accountable when a product fails CRA conformity or reporting expectations?
- Who is accountable when a CRA reporting deadline is missed?
- Who is accountable when a product shipped into the EU lacks required security updates or reporting controls under the CRA?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
