Who should be accountable for keeping legacy devices out of the critical infrastructure attack surface?

Who should own legacy-device removal from critical infrastructure?

Accountability works best when it is not left with a single “cleanup” team. The teams that control asset inventory, network segmentation, and operational technology reliability need shared ownership, with executive sponsorship when retirement requires capital or outage planning. Legacy devices persist when no one is explicitly responsible for finding them, isolating them, or funding their replacement.

Why ownership has to follow the control surface

Legacy devices create risk because they are often hard to see, hard to patch, and hard to replace without operational disruption. The right owner is usually the function that can actually act on the device’s presence: inventory teams can identify it, network teams can contain it, and infrastructure or OT teams can decide whether it remains justified in service.

In practice, this is a governance problem as much as a technical one. If the owner of the device, the owner of the network path, and the owner of the business service are different people, then the accountability model must define who makes the final call on retirement, exception handling, and compensating controls.

When executive backing is missing, outdated equipment can remain on the network simply because replacement competes with uptime, budget, or scheduling constraints. A durable answer assigns responsibility to the team that can verify exposure and drive action, not just to the team that can write a policy.

What the accountability model should cover

A workable model separates three tasks: discovering legacy assets, deciding whether they are still acceptable, and removing or constraining them when they are not. Asset inventory owns discovery, network security owns containment and isolation, and OT or infrastructure reliability owns operational feasibility and retirement sequencing.

That division matters because no single team usually has all the information needed to make the decision safely. The team that understands production dependencies may not know where the device sits on the network, and the team that sees the network may not know whether the device is still tied to a life-safety or uptime function.

The most useful accountability statement is therefore specific: who inventories the device, who approves the exception, who applies compensating controls, and who signs off on removal. If those four questions are unanswered, the device is effectively outside governance even if it is formally listed in a register.

Risk and Threat Considerations

Legacy devices expand the attack surface when ownership is unclear, because they are more likely to be forgotten, exposed to flat network paths, or left with default and unsupported configurations. In critical infrastructure, that creates a durable entry point that can outlast a single patch cycle or staff change.

Failure mechanism: A device stays online because no named owner is responsible for finding it, restricting it, or funding its replacement, so compensating controls weaken over time and the asset becomes a permanent exception.

Impact: The result can be unauthorized access, lateral movement, service disruption, or an avoidable interruption to an operational process that should have been retired or isolated much earlier.

Practitioner Guidance

What to prioritise: Put legacy-device accountability into the asset lifecycle, not the incident response plan. The first control point should be inventory ownership, because you cannot retire or isolate what you cannot reliably identify.

Decision rule: If a device cannot be patched, monitored, or segmented to an acceptable level, it should move into a formal retirement or exception path with a named approver and a review date. If nobody can name the approver, the exception is already unmanaged.

What to verify: Confirm that every legacy device has an owner, a business justification, a containment measure, and a disposition date. If any of those fields are missing, treat the device as an unresolved exposure rather than an approved exception.

Practitioner takeaway: Accountability should sit where action is possible and consequences are understood, which usually means shared operational ownership with executive authority for the hard replacement decisions.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• Who should be accountable for coordinating response when a critical infrastructure attack affects public services?
• How should critical infrastructure teams implement identity and access controls as cloud adoption expands their attack surface?
• How should organisations adapt Zero Trust when nation-state groups target legacy network devices and critical infrastructure?