Who is accountable for CRA reporting when multiple entities sell the same product?

What “manufacturer of record” means in CRA reporting

CRA reporting should follow the entity that is legally treated as the manufacturer for the product, not whichever party happens to notice the issue first. That distinction matters because the reporting duty is tied to the entity responsible for placing the product on the market, maintaining conformity, and coordinating the post-market security obligations that come with the digital product lifecycle.

The practical question is therefore not “who found the problem?” but “who holds the regulatory role for this product version and market entry?” In a multi-entity chain, that role may sit with the original manufacturer, an importer, or another party that has effectively assumed manufacturer duties under the CRA’s allocation rules.

For teams managing products through resellers, distributors, or open-source contribution chains, the first task is to map the regulatory role to the release artifact. The same product can have several commercial actors, but only one entity should own the reporting path for a given obligation instance. That owner then coordinates the evidence, decision record, and submission.

How shared product chains should assign internal accountability

Internal accountability should be explicit even when external reporting is singular. A clean model separates legal reporting authority from operational responsibility: one team owns the submission decision, another owns technical investigation, and supporting parties supply facts, timelines, and remediation status. Without that separation, organisations either duplicate filings or miss the deadline while they debate ownership.

In practice, the most useful control is a standing decision tree that answers four questions: who is manufacturer of record, who can submit on behalf of the entity, who validates whether the issue is reportable, and who signs off on the final content. That model should cover subsidiaries, contract manufacturers, importers, distributors, and cases where open-source components are bundled into a commercial product.

Where product governance is weak, the risk is not only delay. Teams often discover that incident handling, product security, legal review, and regulatory filing are split across different systems and owners. That creates gaps in evidence, inconsistent wording, and confusion over whether a vulnerability is a product defect, a deployment issue, or a reportable security event.

Who should act when the chain includes importers, distributors, or open source stewards

The best way to handle shared chains is to assign one accountable entity for each product line and document how downstream parties escalate to it. Importers and distributors may have duties to preserve traceability and forward information quickly, but they should not improvise parallel reporting unless the manufacturer role is absent or contractually transferred under the CRA framework.

Open-source stewards and maintainers introduce a different problem: they may influence the software supply chain without being the commercial manufacturer of the finished product. In those cases, the commercial entity shipping the product still needs a clear intake path for upstream security notices, because the reporting obligation attaches to the sold product and its responsible legal entity, not to every contributor in the dependency graph.

For practitioners, the operational test is simple: if multiple parties can change the product, only one party should own the reporting decision, and every other party should know how to hand over facts without creating a second filing stream. That is especially important where products are sold under private label, rebranded, or assembled from external components.

Practitioner Guidance

What to prioritise: Create a named manufacturer-of-record register for every product family and tie it to the regulatory filing owner, not to the engineering team that discovered the issue. That register should be reviewed whenever commercial ownership, branding, import status, or release responsibility changes.

What to verify: Before trusting a CRA submission path, verify that the entity named in the reporting process is the one that actually owns the market placement decision for that product and jurisdiction. If that cannot be shown quickly, treat the reporting model as unresolved.

Decision rule: If more than one entity sells the product, route all reporting through the legally responsible manufacturer path unless a documented legal transfer of responsibility says otherwise. Do not let distributors, resellers, or internal product teams file independently unless the governance model explicitly permits it.

Practitioner takeaway: The hard part is not writing the report, it is proving which entity is entitled and obligated to make it. The organisations that avoid CRA reporting confusion are the ones that pre-assign authority before an incident, then make every upstream party feed into that single path.

Related resources from NHI Mgmt Group

• Who is accountable when a product fails CRA conformity or reporting expectations?
• Who is accountable when a product shipped into the EU lacks required security updates or reporting controls under the CRA?
• What makes GenAI usage part of the same secrets problem?
• Who should be accountable for AI overspend when multiple teams share the same model?