Who is accountable when a product shipped into the EU lacks required security updates or reporting controls under the CRA?

Why This Matters for Security Teams

For products placed on the EU market, the CRA changes cybersecurity from a best-effort engineering concern into a formal accountability problem. The organisation that places the product on the market must be able to prove that security updates, vulnerability handling, and incident reporting are built into the lifecycle, not improvised after release. That means legal, product, engineering, and security functions all need a shared record of obligations, decisions, and release evidence. The European Commission’s EU Cyber Resilience Act sets the direction clearly, even though implementation details still vary by product class and market role.

Practitioners often miss that accountability is not diluted by outsourcing, rebranding, or distribution partnerships. If the EU-facing product ships without update pathways or reporting controls, the gap is usually visible first in governance artefacts, not in a vulnerability scan. In practice, many security teams encounter CRA exposure only after a release decision has already been made without defensible evidence trails, rather than through intentional compliance design.

How It Works in Practice

The CRA accountability model is best understood as a chain of obligations anchored to the manufacturer, with supporting duties spread across product, security, and compliance teams. The practical question is not only who owns the code, but who can demonstrate that the product can be maintained securely after shipment. That includes secure-by-design requirements, known vulnerability handling, coordinated disclosure intake, and a reporting process for serious incidents or exploited weaknesses.

Operationally, mature teams treat CRA readiness as a release control problem. They define who approves a release, who can issue a security update, who validates whether reporting thresholds were met, and who retains the evidence. Useful artefacts typically include:

• a product security policy with named owners for update, patch, and disclosure decisions;
• a vulnerability intake and triage workflow with timestamps and escalation paths;
• release records showing security checks completed before shipment;
• incident and notification procedures that link product events to legal and regulatory reporting;
• supplier and distributor agreements that preserve the manufacturer’s accountability instead of obscuring it.

Where organisations already use control libraries such as NIST SP 800-53 Rev 5 Security and Privacy Controls, the relevant mapping usually sits across configuration management, system and information integrity, incident response, and audit evidence. That does not make the CRA a NIST exercise, but it gives teams a disciplined way to operationalise update governance and reporting discipline. These controls tend to break down when products are white-labelled across multiple legal entities because ownership of patching and notification becomes ambiguous.

Common Variations and Edge Cases

Tighter product governance often increases release overhead, requiring organisations to balance speed to market against evidence quality and reporting discipline. That tradeoff becomes sharper for software components embedded in hardware, cloud-connected services, and products sold through resellers, where the legal manufacturer may not be the operational maintainer. Current guidance suggests the accountability remains with the manufacturer, but best practice is evolving on how much obligation can be contracted to suppliers without weakening regulatory responsibility.

There is also a practical distinction between being able to ship an update and being able to prove that update authority, testing, and notification procedures existed before an issue arose. For multi-jurisdiction products, teams should not assume that global support processes satisfy EU obligations automatically. They need jurisdiction-specific traceability for vulnerability handling, incident thresholds, and market surveillance response. In higher-risk environments, organisations should align the product security programme with the CRA and related lifecycle controls in a way that preserves ownership, timestamps, and decision records.

Where the product contains connected identity features, device credentials, or automated update agents, the accountability scope can widen into NHI governance as well, because unmanaged service identities often become the weakest link in patch delivery and reporting workflows. For authoritative context on the regulation itself, the EU Cyber Resilience Act remains the starting point, but there is no universal standard for this yet on how suppliers should evidence shared operational duties across every distribution model.

Related resources from NHI Mgmt Group

• Who is accountable when a product cannot prove secure design under the CRA?
• Who is accountable when a regulated product ships with weak security controls?
• When does product security become an identity governance issue under the CRA?
• Who is accountable when a product fails CRA conformity or reporting expectations?