Who is accountable when a connected product cannot be patched or retired securely?

Why This Matters for Security Teams

When a connected product cannot be patched or retired securely, the issue is not just technical debt. It becomes a lifecycle accountability problem that spans product security, operations, supply chain management, and legal exposure. The organisation must be able to show who owns revocation, containment, customer notification, and end-of-life handling. Under the NIST Cybersecurity Framework 2.0, that accountability maps directly to governance and risk ownership, not only engineering fixes.

This is especially important for connected products because unpatchable devices often continue to hold credentials, maintain trust relationships, or expose unsupported services long after the original team has moved on. NHIMG research shows the scale of this problem: the Ultimate Guide to NHIs — The NHI Market notes that only 20% of organisations have formal offboarding and revocation processes for API keys, and 71% of NHIs are not rotated within recommended time frames. In practice, many security teams encounter the failure only after a product is already embedded in production, rather than through intentional retirement planning.

How It Works in Practice

Accountability should be assigned across the full product lifecycle, starting at design and continuing through deployment, support, and retirement. For secure patchability, the manufacturer is responsible for designing update paths, signed firmware, and safe rollback mechanisms. The operating team is responsible for asset inventory, change control, credential revocation, and enforcing retirement timelines. If patching is not possible, there must be an approved containment plan that reduces exposure while preserving business continuity.

Operationally, that means the organisation should know three things at all times: which products are still supported, which identities or secrets those products use, and what compensating controls exist if a vulnerability cannot be fixed. That inventory work is consistent with the Ultimate Guide to NHIs, which emphasises lifecycle visibility as a prerequisite for revocation and offboarding. Where a patch cannot be delivered, teams should evaluate whether the device can be isolated, its privileges reduced, or its trust relationships removed.

• Track ownership for secure update, emergency revocation, and end-of-life decisions.
• Maintain a complete inventory of product instances, embedded secrets, and external dependencies.
• Use compensating controls such as network segmentation, allowlisting, or JIT access where supported.
• Document the retirement trigger, customer communication path, and evidence of deletion or decommissioning.

For implementation detail, current guidance from the NIST Cybersecurity Framework 2.0 supports assigning governance, protective, and recovery responsibilities rather than treating remediation as a one-time engineering event. These controls tend to break down when connected products depend on third-party firmware, embedded OEM credentials, or field devices that cannot be accessed without disrupting essential operations.

Common Variations and Edge Cases

Tighter retirement and revocation control often increases operational overhead, requiring organisations to balance uptime against the cost of maintaining unsupported products. That tradeoff is real, especially in industrial, medical, or safety-critical environments where immediate removal is not practical. Best practice is evolving, and there is no universal standard for every exception path yet.

Some products cannot be patched because the vendor no longer exists, the hardware is end-of-life, or the device was deployed without remote update capability. In those cases, accountability does not disappear. The manufacturer may still bear product security obligations, but the operator owns the residual risk once the device remains in service. The right response is a documented exception, compensating controls, and a retirement deadline tied to business risk.

This is also where lifecycle accountability intersects with breach response. NHIMG’s Schneider Electric credentials breach illustrates how credential exposure can outlive a product decision if revocation and containment are not enforced quickly. The practical question is not whether a patch exists in theory, but whether the organisation can prove safe cessation or constrained operation when no patch is available.

Related resources from NHI Mgmt Group

• Who is accountable when certificate transparency monitoring misses a retired log?
• Who is accountable for certificate and key lifecycle failures in modern identity programmes?
• Who should be accountable for privileged access on CICS systems?
• Who is accountable when cryptographic credentials are left active too long?