Who is accountable for product security across the IoT lifecycle?

Shared accountability across the IoT product chain

Accountability for IoT product security is distributed because the risks are distributed. A component manufacturer controls secure design choices, the integrator controls how parts are combined, the operator controls how devices are deployed and maintained, and regulators set the accountability baseline. That division matters because a secure component can still become a weak product if it is integrated poorly or left unsupported in the field.

For security teams, the practical question is not whether one party is “the owner,” but whether every party can show what it is responsible for, what it can influence, and what evidence proves that responsibility is being met. The EU Cyber Resilience Act gives a useful example of how product obligations are increasingly formalised around lifecycle responsibility, not just shipping a device and moving on. In practice, many teams discover accountability gaps only after integration, update, or decommissioning has already created exposure.

How lifecycle accountability is assigned in practice

IoT product security follows the lifecycle of the product, so accountability changes shape as the product moves from design to deployment to operation. The manufacturer is typically accountable for secure-by-design choices, vulnerability handling, update capability, and the security properties of the shipped product. The integrator becomes accountable when it combines components, connects the product to other systems, or alters the trust boundary through configuration and deployment decisions. The operator or end customer owns the day-to-day reality of patching, access control, monitoring, and retirement of the device.

This is why “secure product” and “secure deployment” are not interchangeable. A manufacturer may provide secure firmware, but the product can still be exposed if the integrator enables unnecessary services or if the operator leaves credentials unchanged. Likewise, an operator may run a device in a safe environment, but if the manufacturer provides no update path, the device becomes a residual risk. The best accountability model therefore links each party to a concrete set of decisions, evidence, and escalation paths.

Regulators do not usually operate the product, but they define the conditions under which accountability becomes enforceable. That can include disclosure duties, baseline security requirements, and market access expectations. For practitioners, the useful test is whether each lifecycle owner can answer three questions clearly: what controls they own, what dependencies they rely on, and what happens when a vulnerability cannot be fixed immediately.

• Map responsibility by lifecycle stage, not only by vendor relationship.
• Document who can patch, who can configure, and who can retire the product.
• Require evidence of update support, logging, and vulnerability response before deployment.

For a broader control baseline, NIST’s security control catalogue remains useful when teams need to translate lifecycle responsibility into measurable safeguards, especially for access, configuration, monitoring, and recovery. The guidance breaks down when responsibility is contractual but not operational, because written ownership without actual authority does not reduce exposure.

Where lifecycle ownership gets disputed or blurred

Tighter lifecycle accountability often increases coordination overhead, requiring organisations to balance clearer ownership against slower procurement, integration, and support decisions.

The hardest cases are the ones with shared influence but no single operational owner. A contract may say the manufacturer supports updates, while the integrator controls the deployment pattern and the operator controls uptime expectations. In that situation, responsibility can become fragmented enough that nobody acts quickly when a flaw is found. Guidance versus consensus also matters here: there is broad agreement that lifecycle accountability should be explicit, but there is less consensus on how far contractual responsibility should extend once a product is embedded in a larger solution.

Edge cases appear in managed services, white-label products, and heavily customised deployments. In those models, the party that appears to be the “seller” may not be the party that can actually change the security posture. The more the product depends on remote management, cloud connectivity, or third-party software supply chains, the more important it becomes to separate legal responsibility from operational control. That distinction is often missed until a vulnerability, unsupported component, or update failure forces a decision.

For lifecycle questions, the useful practitioner habit is to treat ambiguity itself as a security issue. If no party can demonstrate who owns secure updates, response timelines, and end-of-life handling, then accountability has not been assigned in a way that is strong enough to protect the product.

Practitioner Guidance

What to prioritise: Define accountability by lifecycle phase and control point, not by organisational chart. If a party cannot change the outcome of a security decision, it should not be treated as the accountable operator for that decision.

What to verify: Confirm that the manufacturer, integrator, and operator each have evidence for their part of the lifecycle, including update support, configuration responsibility, and retirement or replacement planning.

Practitioner takeaway: IoT accountability works only when responsibility is paired with practical authority; if ownership is written down but no one can patch, configure, or decommission the device, the lifecycle remains exposed.

Related resources from NHI Mgmt Group

• How should security teams centralise certificate lifecycle management across TLS, enterprise PKI, and IoT environments?
• Who should be accountable for payment fraud reduction across security, product, and operations teams?
• Who should be accountable for preparing for the Cyber Resilience Act across product, security, and SOC teams?
• Who is accountable when identity security controls fail across team boundaries?