Who is accountable when a connected device remains vulnerable after sale?

Accountability should sit with both the manufacturer and the operator, but the proposed EU Cyber Resilience Act shifts more responsibility to the manufacturer for lifecycle security, updates, and vulnerability handling. Operators still need procurement and monitoring controls, but they should demand evidence of support, disclosure, and update commitments before deployment.

Why This Matters for Security Teams

When a connected device stays vulnerable after sale, the problem is no longer just a product flaw. It becomes a lifecycle security and accountability issue that affects procurement, patching, monitoring, incident response, and contract enforcement. For security teams, the key question is whether the organisation can prove who owns remediation, how updates will be delivered, and what happens if the vendor fails. That is where governance, not just engineering, determines risk exposure.

Current guidance suggests that manufacturers should not treat security as complete at shipment, while operators cannot assume the device will self-secure in production. Controls around asset inventory, vulnerability tracking, and supplier assurance matter because connected devices often remain online for years after purchase. The NIST SP 800-53 Rev 5 Security and Privacy Controls framework is useful here because it ties ongoing monitoring, configuration management, and supply chain oversight to operational accountability.

In practice, many security teams encounter this only after exploitation has already occurred, rather than through intentional procurement and lifecycle governance.

How It Works in Practice

Accountability is usually split across the lifecycle. The manufacturer is expected to design for secure operation, publish vulnerability handling processes, and provide updates or remediation paths. The operator is expected to configure the device safely, keep it inventoried, monitor exposure, and retire it when support ends. In mature programmes, that split is made explicit in contracts, security requirements, and acceptance criteria before deployment.

For this question, the practical controls usually include:

• Security requirements in procurement, including minimum patch support periods and disclosure obligations.
• Asset inventory that records model, firmware version, support status, and business owner.
• Monitoring for known vulnerabilities, exposed services, and end-of-support notices.
• Change control for firmware updates, especially where devices support safety, building, or industrial functions.
• Escalation rules for unsupported devices, including isolation, compensating controls, or replacement.

The EU Cyber Resilience Act is important because it shifts stronger baseline responsibility onto manufacturers for products with digital elements, especially around secure design, vulnerability handling, and update delivery. Operators still retain responsibility for local control implementation, but they should not be forced to compensate for vague vendor commitments. For broader supplier governance, many teams also map their process to NIST guidance on cyber supply chain risk management so that ownership, reporting, and remediation expectations are documented upfront.

Where devices support credentials, remote administration, or API-based control, this quickly becomes an identity and privilege issue as well. A vulnerable device with standing administrative access can become a persistence point, so access scope, secrets handling, and remote support channels need to be reviewed alongside patch status. These controls tend to break down when the device is embedded in operational technology or safety-critical environments because patch windows are narrow and replacement cycles are long.

Common Variations and Edge Cases

Tighter product-security expectations often increase procurement effort and operational overhead, requiring organisations to balance faster deployment against stronger assurance. The accountability answer also changes depending on context. In consumer environments, users may have little practical ability to patch or verify support claims, so market regulation and vendor disclosure become more important. In enterprise and regulated environments, the operator usually has stronger duties to enforce asset control and retire unsupported equipment.

Best practice is evolving for connected devices that rely on cloud services, mobile apps, or managed firmware channels. There is no universal standard for this yet, but security teams should treat the vendor update service itself as part of the product. If that service disappears, the device may effectively become unsupported even if the hardware still functions. Where devices process personal data or financial transactions, accountability may also intersect with privacy and payment obligations, especially if device insecurity creates exposure to breach notification or fraud.

For governance, this means the most defensible approach is shared accountability with clear division of duties: the manufacturer for secure product lifecycle obligations, and the operator for deployment, monitoring, and risk acceptance. Where either side is vague, security debt accumulates until the device becomes an incident rather than an asset.

Related resources from NHI Mgmt Group

• Who is accountable if a vulnerable domain controller remains online after disclosure?
• Who is accountable when a workload secret remains active after compromise?
• Who is accountable when vendor access remains active after a banking engagement ends?
• Who is accountable when a user remains active after directory removal?