Who should be accountable for preventing IoT attacks when both manufacturers and users influence the outcome?

Why accountability has to be shared, not assumed

Preventing IoT attacks is a joint responsibility because the security outcome depends on decisions made before and after deployment. Manufacturers control the device’s built-in trust boundaries, firmware update path, default settings, and recovery options; users control where it is deployed, how it is segmented, who can reach it, and whether it stays patched and monitored.

That split matters because IoT compromise usually exploits a chain of weak points, not one isolated failure. A well-designed device can still be exposed by poor deployment, while a careful operator can still inherit risk from weak authentication, long-lived defaults, or unsupported firmware.

Accountability should therefore follow control: the party that can change the risk should own the risk. If a manufacturer ships insecure defaults or does not provide timely updates, the user cannot fully compensate. If the user ignores segmentation, credentials, or monitoring, the manufacturer cannot absorb that operational failure after delivery.

What each party must own across the device lifecycle

Manufacturer accountability begins with secure-by-design engineering. That includes hardening the device before sale, minimizing exposed services, providing authenticated updates, and documenting how the device should be deployed securely. The vendor also needs a support model that makes patching and vulnerability disclosure realistic over the product’s life.

User accountability begins at procurement and continues through operations. The operator should verify update support, reset or replace insecure defaults, place the device in the right network zone, and treat it like any other asset with exposure, logs, and ownership. If a device is internet-facing by design, the user must assume that configuration and monitoring are part of the control set, not optional extras.

These responsibilities are complementary, not interchangeable. The manufacturer supplies the secure baseline; the user decides whether that baseline is preserved, weakened, or ignored in production.

Why blurred ownership creates repeatable failure patterns

Shared accountability fails when each side believes the other has already handled the hard part. Manufacturers may assume customers will change defaults and segment the device. Users may assume the product was delivered in a hardened state and requires little oversight. That gap leaves exposures such as exposed management interfaces, stale credentials, unpatched firmware, and overbroad network reach.

This is especially dangerous in IoT because devices are often deployed at scale and then forgotten. Once a weak device is embedded in a home, factory, branch office, or facility network, it can become a durable foothold or a stepping stone to other systems. The 52 NHI Breaches Report shows how persistent credentials and weak operational ownership can turn a single exposed identity into broader compromise paths.

From a threat perspective, attackers look for the easy path: unchanged defaults, weak update mechanisms, exposed admin portals, and devices that can be used long after the owner has stopped watching them. That is why accountability cannot be implicit. It has to be assigned to the specific control owner for each stage of the lifecycle.

Risk and Threat Considerations

IoT risk is not just about the device itself, it is about the combined failure of design-time controls and runtime controls. When ownership is ambiguous, weak defaults survive, patching slows down, and exposed devices become easy targets for botnets, lateral movement, and long-term persistence.

Failure mechanism: The manufacturer ships a device that is hard to secure or hard to maintain, while the user deploys it without tightening configuration, monitoring, or network restrictions. Attackers then exploit the remaining default or operational weakness.

Impact: The result can be device takeover, unauthorized data access, abuse of the device as an internal pivot point, or inclusion in larger coordinated attacks. The longer the ownership gap persists, the more likely the exposure becomes systemic rather than isolated.

Practitioner Guidance

What to prioritise: Assign one accountable owner for secure design, patch support, deployment hardening, and ongoing operations, then document which side is responsible at each lifecycle stage. If that split is unclear, treat the device as high-risk until clarified.

What to verify: Check whether the product has authenticated updates, a supportable patch path, secure defaults, and a clear operator runbook. On the user side, verify segmentation, credential hygiene, and monitoring are actually in place, not just promised in policy.

Common mistake: Treating IoT as a one-time procurement decision. In practice, the security decision is continuous, because ownership of exposure shifts as the device moves from vendor control to customer control.

Practitioner takeaway: The safest operating model is explicit shared accountability with no control left ownerless, because every unanswered question about who secures the device becomes an attack surface.

Related resources from NHI Mgmt Group

• Why is NHI governance critical in the age of AI attacks?
• Why do Shai Hulud style attacks matter to NHI governance?
• Who is accountable for preventing social engineering that leads users to run attacker-supplied scripts during meetings or interviews?
• How should organisations assign responsibility for IoT device security across manufacturers and end users?