Who is accountable for CRA compliance across the product supply chain?

Why This Matters for Security Teams

CRA accountability is not a legal footnote; it shapes how software, firmware, and connected products are built, verified, and handed off across the commercial chain. The manufacturer is usually the primary duty holder, but importers and distributors are not passive transport layers. They need enough evidence to know the product meets security expectations before placing it on the EU market, and that evidence has to survive audits, incident response, and product changes.

Security teams often underestimate how quickly CRA obligations become a supply chain problem. A component can be secure in source control and still fail compliance if the support terms, vulnerability handling, technical documentation, or conformity records are missing downstream. That is why NHI governance lessons matter here: accountability follows the identity and authority that can change the product state, not just the team that wrote the code. The EU Cyber Resilience Act makes that distinction operational, and NHIMG’s Ultimate Guide to NHIs shows why evidence trails matter across delegated trust boundaries.

In practice, many security teams discover CRA gaps only after a partner asks for conformity evidence that was never assembled in the first place.

How Accountability Is Shared Across the Supply Chain

Under the CRA, accountability is layered. Manufacturers own product security by design, the vulnerability handling process, and the declarations or technical records that support conformity. Importers must check that the manufacturer has done the required work before putting the product on the market, while distributors need to avoid moving products that obviously lack the necessary compliance posture. Current guidance suggests treating this as a chain of evidence, not a single sign-off.

That means each party should be able to answer a practical set of questions: who produced the security documentation, who validated the support commitment, who can change the shipped artifact, and who is responsible if a vulnerability disclosure lands after release? This is where supply chain identity becomes important. If a build pipeline, package publisher, or release automation account can ship a product, then the organisation must know which human or non-human identity is accountable for that action. OWASP’s Non-Human Identity Top 10 is useful here because CRA failures often begin with unmanaged machine access rather than with policy language.

NHIMG research on the 52 NHI Breaches Analysis shows how often delegated credentials, automation tokens, and third-party integrations become the weak link in accountability chains. For a concrete supply-chain example, the Reviewdog GitHub Action supply chain attack illustrates how trust in an upstream component can turn into downstream exposure when verification is thin.

• Manufacturers should own technical compliance evidence, support periods, and vulnerability handling records.
• Importers should verify documentation, conformity claims, and obvious security gaps before market placement.
• Distributors should check packaging, labelling, and whether the product appears non-compliant or altered.
• All parties should retain traceable evidence for version, provenance, and security obligations.

These controls tend to break down when release authority is fragmented across vendors, resellers, and automation pipelines because no single party can prove end-to-end custody of the product state.

Common Variations and Edge Cases

Tighter CRA compliance often increases operational overhead, requiring organisations to balance faster distribution against deeper verification and recordkeeping. That tradeoff is especially visible in open-source distribution, white-label products, and multi-vendor SaaS ecosystems where the legal role is less obvious than the technical one. There is no universal standard for this yet on how every open-source steward, marketplace operator, or downstream integrator should document accountability, so current guidance suggests preserving the strongest available evidence and making role boundaries explicit in contracts.

One common edge case is commercial software assembled from multiple upstream components. The entity that assembles and places the final product on the market typically cannot outsource accountability just because upstream packages were open source. Another edge case is a distributor that modifies packaging, firmware, or documentation. That can shift the compliance burden materially, because the product is no longer identical to the original manufacturer’s release. A third case is when the organisation relies on cloud-delivered updates: the update channel, signing keys, and rollback process may become part of the compliance story.

For teams mapping this to governance frameworks, NIST Cybersecurity Framework 2.0 helps structure accountability, while the Klue OAuth Supply Chain Breach is a reminder that downstream reliance on third-party trust often fails during hidden integration points, not at the final delivery step.

Related resources from NHI Mgmt Group

• Who is accountable for enforcing supply chain security across repositories and teams?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• Why do non-human identities create compliance risk even when policies exist?