Accountability should sit with the manufacturer or product owner, because they control the device lifecycle and the trust boundary around customer and operational data. That role must set policy for data collection, partner access, update integrity, and security standards across suppliers. Shared ecosystems still need a clear owner, or responsibility becomes diluted and controls fail in practice.
Why accountability belongs with the manufacturer or product owner
For connected devices, accountability has to follow the party that can actually change the product, not the party that merely buys or deploys it. The manufacturer or product owner controls firmware, update channels, embedded credentials, telemetry choices, and the trust boundary around the device. That is why they are the only practical owner for device security, data-handling policy, and lifecycle decisions.
This matters because connected devices rarely operate as isolated endpoints. They sit inside a service ecosystem that may include mobile apps, cloud back ends, installers, distributors, support partners, and analytics providers. If no single owner is accountable, security decisions get split across functions and suppliers, and gaps appear at handoff points such as onboarding, patching, decommissioning, or third-party access.
Accountability also needs to be explicit about data, not just hardware. The same organisation that defines what data is collected should define who can access it, how long it is retained, where it is processed, and what happens when a supplier or integration changes. In practice, the owner has to set the policy for collection minimisation, partner access, update integrity, and security requirements across the supply chain.
What breaks when responsibility is shared too loosely
Shared ecosystems create real failure modes when no one is clearly in charge. A common pattern is that the device vendor assumes the cloud provider will secure the data, while the cloud provider assumes the device vendor controls the firmware, and the customer assumes both parties have already done the necessary hardening. The result is diluted responsibility, inconsistent controls, and weak escalation when something goes wrong.
Another common breakdown is lifecycle drift. Devices are sold, installed, resold, transferred, or retired, but the accountability model does not keep up. That can leave stale credentials, unsupported firmware, unmanaged partner integrations, or orphaned data flows in place long after the original deployment decision. The manufacturer or product owner is the only party positioned to define and enforce the lifecycle rules that prevent that drift.
Update integrity is especially important because a connected device is only as trustworthy as its update path. If integrity checks, signing, rollback protection, or release governance are weak, the device can become a persistent compromise point. The owner must treat update security as part of product governance, not as a later operational fix.
What “accountable” means in practice for connected-device security
Being accountable means owning the decisions that affect risk across the full product lifecycle, from design to retirement. That includes setting security baselines, approving supplier access, defining data categories, requiring secure update mechanisms, and establishing how incidents are triaged and disclosed. It also means the owner can be measured against those decisions, rather than relying on informal coordination.
For practitioners, the useful test is simple: if the control requires changing the product, the vendor or product owner should own it. If the control only changes how a customer uses the product, the customer may contribute, but cannot replace the owner’s obligation to ship a secure design. This is where product governance and operational security meet.
A clear ownership model also supports downstream assurance. If a device fleet depends on the EU Cyber Resilience Act style secure-by-design expectations, the accountable party must be the one that can prove conformity through build, update, and vulnerability processes. Without a named owner, assurance becomes a paperwork exercise instead of a security control.
Risk and Threat Considerations
When connected devices have diffuse ownership, the main risk is not just weak security, but unowned security. Attackers look for exactly those gaps: stale update paths, third-party access that was never reviewed, exposed telemetry, reused credentials, and unclear incident response responsibility. A fragmented ecosystem makes it easier for compromise to persist and harder for anyone to contain it quickly.
Failure mechanism: Responsibility is split across manufacturer, product owner, cloud provider, and customer, so no single party enforces secure lifecycle controls, partner access rules, or update integrity end to end.
Impact: The device can become a durable compromise path, customer or operational data may be exposed or mishandled, and remediation slows because every party can point to another as the owner.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while EU Cyber Resilience Act and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU Cyber Resilience Act | Cyber Resilience Act | Covers secure-by-design obligations for connected products with digital elements. |
| Recommendation — Assign a responsible product owner for security, updates, vulnerability handling, and lifecycle assurance. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Applies because third-party suppliers and lifecycle dependencies shape connected-device trust. |
| Recommendation — Require supply-chain controls for firmware, components, and partner access paths. | ||
| ISO/IEC 27001:2022 | A.5.23 — Information security for use of cloud services | Relevant where connected devices rely on cloud platforms and shared service providers. |
| Recommendation — Define cloud-security responsibilities and evidence requirements across the product ecosystem. | ||
| CIS Controls v8 | CIS-17 — Incident Response Management | Relevant because clear ownership is essential when device or data compromise occurs. |
| Recommendation — Document who leads response, escalation, and recovery for connected-device incidents. | ||
Practitioner Guidance
What to prioritise: Name one accountable owner for the product lifecycle, then make every supplier and operational dependency report into that owner’s control model. If a control spans firmware, cloud, and data handling, it needs a single decision-maker even if execution is distributed.
What to verify: Check that the owner can produce evidence for update signing, vulnerability handling, partner access approval, data retention rules, and decommissioning. If any of those are only “understood verbally,” the accountability model is not real enough to trust.
Common mistake: Treating customer deployment responsibility as a substitute for product accountability. Customers can harden their own environments, but they cannot compensate for weak product design, unsafe defaults, or opaque supplier access.
Practitioner takeaway: The right accountability model is the one that can actually change the device, the data path, and the update path, because that is where durable risk is created and removed.
Related resources from NHI Mgmt Group
- What do manufacturers get wrong when they rely on legacy systems and connected devices for data-heavy operations?
- How should organisations structure privacy notices when they collect highly sensitive personal data through apps and connected devices?
- Why is it important to integrate identity and data governance?
- What is the difference between protecting applications and protecting access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
