How should organisations assign responsibility for IoT device security across manufacturers and end users?

How responsibility should be split between manufacturers and end users

iot security works best when responsibility is assigned to the party that can actually control each risk. Manufacturers should own secure design, secure-by-default settings, vulnerability handling, and update support. End users should own deployment choices, configuration, monitoring, and local network discipline. The split should be written down before purchase and revisited for support windows, patching, and incident response.

The important distinction is between product capability and operational control. A manufacturer can remove or reduce insecure defaults, while an end user can decide whether devices are isolated, inventory is maintained, and credentials are changed. If either side assumes the other is handling a control, the device becomes harder to secure and harder to support.

In practice, the best assignment model is explicit shared accountability. Procurement, security, and operations should agree who handles patch release, who tests firmware, who approves exceptions, who disables unsupported devices, and who communicates when a flaw affects deployed equipment. That avoids the common failure mode where responsibility is only discussed after a defect, outage, or compromise.

What manufacturers should own in the IoT security lifecycle

Manufacturers are responsible for security properties that must be built into the device before it reaches the customer. That includes secure development, safe defaults, strong authentication support, signed updates, vulnerability disclosure handling, and a clear end-of-support policy. If the product cannot be patched or secured in practice, the manufacturer has not met the minimum expectation of supportability.

This obligation matters because many IoT risks are not created by user error alone. Hard-coded credentials, weak onboarding flows, exposed management interfaces, and unsupported firmware create conditions that end users cannot fully fix. Manufacturers should therefore document what is protected by design, what still requires customer action, and what the support model covers over the life of the device.

A ISO/IEC 27002:2022 Information Security Controls approach is useful here because it reinforces secure configuration, vulnerability handling, and supplier control as part of an information security programme. Where devices are connected to regulated environments, the same baseline also aligns well with EU NIS2 Directive expectations around supply chain risk and incident readiness.

What end users should own after deployment

End users own the security conditions created by how devices are introduced into the environment. That means safe installation, network segmentation, credential changes, access restriction, logging where available, and timely removal of devices that are no longer supported. The same device can be materially safer or riskier depending on how it is deployed and maintained.

End users also need operational discipline, because many IoT failures come from neglected basics rather than sophisticated attacks. Devices should be inventoried, monitored, and reviewed for patch status, remote access exposure, and unusual communications. If the product requires the customer to turn on security features, the customer must treat those steps as mandatory controls, not optional hardening.

CIS Benchmarks are helpful for the surrounding infrastructure that hosts or manages IoT devices, even when there is no device-specific benchmark. For organisations that want a control-catalog view of the operating model, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful way to map ownership for configuration management, access control, and system integrity.

Risk and Threat Considerations

The main risk is the ownership gap: each party assumes the other side has handled a control, so insecure defaults, unsupported firmware, and exposed interfaces remain in production. That creates avoidable exposure, especially when the device is internet-facing, hard to patch, or embedded in critical operations.

Failure mechanism: Weak assignment of responsibility leaves patching, hardening, and decommissioning unfinished, while attackers or ordinary failures exploit the resulting persistence of vulnerable devices.

Impact: The outcome can be device compromise, lateral movement into the broader network, operational outage, or an inability to prove who was accountable when the failure occurred.

Practitioner Guidance

What to verify: Before purchase, confirm who owns secure boot, update delivery, vulnerability notification, end-of-support handling, and incident coordination. If the answer is vague, treat that as a sourcing risk, not a documentation issue.

Decision rule: If the manufacturer cannot commit to patch support and removal of known flaws, do not rely on the end user to compensate later. If the end user cannot isolate or monitor the device, treat deployment as incomplete until those controls exist.

Practitioner takeaway: The safest IoT operating model is explicit shared responsibility with no ambiguous controls, because the most dangerous failures occur when security tasks are assumed rather than assigned.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• How should organisations govern AI use when responsibility is split across security, legal, HR, and compliance?
• How do organisations keep IoT trust visible across large device fleets?
• Why do organisations struggle to prove endpoint security controls are effective across every device?