Who is accountable when a digitally connected product fails CRA expectations?

Why This Matters for Security Teams

The EU Cyber Resilience Act raises a simple but difficult question for connected products: who owns security when the product ships, changes, and is used in the field? Accountability is not limited to the legal manufacturer. It can extend to importers, distributors, and the internal teams that can still reach the product through privileged access, remote support, update channels, or cloud-connected management planes. The hard part is proving that vulnerability handling, patch delivery, and access revocation are assigned to specific owners rather than spread across functions.

That matters because CRA expectations are operational, not aspirational. A product can look secure in design reviews and still fail when no one can prove who closes a vulnerability, who signs off a fix, or who removes obsolete administrative access after a service relationship ends. The most common breakdown is not a missing control, but a missing owner. In practice, many security teams encounter CRA exposure only after a product incident forces them to reconstruct responsibility from tickets, vendor emails, and expired support agreements.

For baseline control expectations, NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful reference point, while NHIMG’s Ultimate Guide to NHIs — The NHI Market shows how quickly ownership gaps emerge when machine identities and privileged access are not governed as first-class assets.

How It Works in Practice

Accountability under CRA should be treated as a chain of obligations, not a single name on a policy. The manufacturer is typically responsible for secure design, vulnerability handling, and delivering updates. Importers and distributors need to verify that the product entering and moving through the market still has current security information, support terms, and update paths. Operational teams with privileged access must also be accountable for how they authenticate, approve, use, and revoke that access.

In practice, organisations need a traceable map from control to owner to evidence. That usually means:

• named owners for vulnerability intake, triage, patching, and disclosure decisions
• documented update delivery paths, including who can sign, publish, and revoke firmware or software packages
• inventory of privileged access into products, support portals, and cloud management planes
• revocation procedures for contractors, distributors, service desks, and legacy support accounts
• proof that support windows, update promises, and end-of-life dates are visible and enforced

This is where NHI governance becomes relevant. Connected products increasingly depend on secrets, certificates, API keys, and service accounts that outlive human role changes. NHIMG’s The State of Secrets in AppSec highlights the operational cost of weak secrets handling, and the same pattern applies to product support access: if credentials are not rotated, scoped, and revoked, accountability becomes theoretical. For threat context, CI/CD pipeline exploitation case study is a useful reminder that the path from build systems to deployed products is often where control ownership gets blurred.

The practical test is whether a security team can answer three questions without debate: who receives the issue, who is authorised to fix it, and who proves it was fixed. These controls tend to break down when a product is sold through multiple channels and the support chain spans third-party service partners, because each party assumes another party owns the last mile of remediation.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance clarity against commercial complexity. That tradeoff is real in reseller models, white-label products, and ecosystems where one company manufactures the device while another operates the service layer. There is no universal standard for this yet, so current guidance suggests making responsibility explicit in contracts, service terms, and technical runbooks rather than relying on informal operating assumptions.

Edge cases usually appear when access is shared across organisational boundaries. A distributor may never patch the product, but still hold credentials for staging or diagnostic access. A managed service provider may not be the legal manufacturer, but may control the update pipeline. In those cases, accountability should follow actual authority over the control, not just the logo on the box.

That is why the CRA conversation should be paired with EU Cyber Resilience Act obligations and product support evidence. NHIMG’s Millions of Misconfigured Git Servers Leaking Secrets also reinforces a practical lesson: when secrets, build artifacts, and admin access are spread across teams, accountability fails fastest at the seams. The safest assumption is that any unassigned access path will become a compliance gap.

Related resources from NHI Mgmt Group

• Who should be accountable for CRA readiness in a connected device programme?
• Who is accountable when a connected product cannot be patched or retired securely?
• Who is accountable when age assurance fails to protect privacy expectations?
• Who is accountable when a product cannot prove secure design under the CRA?