How should security teams reduce blast radius in critical infrastructure environments that still rely on aging, unsupported systems?

Why blast radius is the right lens for aging critical systems

Unsupported systems in critical infrastructure are usually not the first point of failure so much as the point where a routine intrusion becomes a major outage. The security question is therefore less about eliminating every weakness and more about stopping one compromised node from becoming a site-wide event. That is why segmentation, constrained trust, and narrow administrative paths matter more than hoping a legacy platform will be made fully safe again. The CISA cyber threat advisories are useful here because they show how common intrusion patterns exploit exposed services, poor isolation, and weak boundary control rather than only unpatched software. In practice, many security teams discover their blast-radius problem only after a maintenance window, remote access path, or shared account has already widened the impact of a compromise.

How containment works when patching is no longer the main control

Reducing blast radius starts by treating the legacy asset as a constrained dependency, not as a general-purpose participant in the rest of the network. That means identifying which business functions truly depend on it, which upstream and downstream systems can be separated, and which access paths are unnecessary even if they are convenient. Once those paths are known, teams can place the legacy system behind tighter network boundaries, require explicit jump-host or brokered access, and remove implicit trust from adjacent segments.

In operational terms, the most effective containment measures tend to be the ones that reduce reachability before they try to detect compromise. Strong segmentation limits where an attacker can move; least privilege limits which operators, services, and accounts can touch the system; and narrowly scoped administrative workflows reduce the chance that a single stolen credential opens the entire environment. Where the system cannot be patched, hardening the surrounding controls often gives the biggest risk reduction per unit of effort.

• Map critical dependencies first so containment follows actual business pathways rather than the old network layout.
• Separate legacy control zones from user, office, and vendor-access networks wherever the architecture allows.
• Require brokered administration for sensitive systems instead of direct interactive access from broad internal ranges.
• Review authentication and authorisation paths together, because network isolation alone does not stop over-permissioned accounts.
• Monitor for unusual east-west movement, especially from systems that should never initiate broad internal connections.

The guidance breaks down when the legacy platform is so deeply embedded that segmentation is only nominal, because then the team is managing exposure rather than actually shrinking it.

Where the standard answer gets harder: shared dependencies, safety systems, and mixed trust zones

Tighter containment often increases operational overhead, requiring organisations to balance reduced attack surface against maintenance friction and recovery complexity. That trade-off becomes sharper in critical infrastructure, where availability and safety may override neat architectural boundaries. When a legacy system shares instrumentation, historians, engineering workstations, or vendor channels with newer platforms, the blast radius problem is really a trust-boundary problem. The ENISA Threat Landscape is relevant because it consistently frames exposure around interconnection, lateral movement, and operational dependency, not just initial compromise.

There is also a governance edge case: some systems are unsupported not because the owner ignored them, but because replacement is tied to procurement cycles, safety recertification, or site shutdown windows. In those cases, teams should be explicit about what risk is being accepted, what compensating controls are in place, and what dependency cannot yet be removed. The important distinction is between a temporary containment design and a permanent exception that slowly becomes normal.

If the environment also sits inside a regulated critical-services context, the security conversation should include resilience obligations and incident reporting expectations. The EU NIS2 Directive is a useful reference point for that governance layer, even though the technical answer still begins with segmentation and access limitation.

Risk and Threat Considerations

The main risk in unsupported critical infrastructure is not only exploitation of the old system itself, but the way a single foothold can expand into operational control of adjacent assets. Legacy environments often accumulate flat networking, shared administration, and weak trust assumptions, which makes lateral movement and privilege reuse the dominant failure mode.

Failure mechanism: An attacker or insider reaches the legacy system through exposed remote access, stolen credentials, or a trusted internal path, then uses permissive routing, shared accounts, or connected engineering tools to pivot into higher-value systems.

Impact: The result can be loss of control over multiple zones at once, disruption of operational technology or supporting IT, and a recovery problem that is larger than the original vulnerable host.

Practitioner Guidance

What to prioritise: Put the first effort into the connections that let one compromise spread, not into cosmetic hardening of the legacy host. The highest-value work is usually reducing trust between zones, tightening administrator reach, and removing unnecessary service-to-service paths.

What to verify: Teams should verify that segmentation is enforced at the points attackers can actually use, not just on paper. If a legacy asset can still reach broad internal ranges, or if operators can bypass controls through alternate management paths, the blast radius has not really changed.

What practitioners underestimate: Unsupported systems often fail as part of a system of systems, so the real exposure is frequently in shared dependencies, vendor access, and backup or monitoring channels. A narrow, well-understood exception is safer than a sprawling legacy trust zone that nobody fully owns.

Practitioner takeaway: In aging critical environments, the goal is not to make legacy technology modern, but to make compromise local, observable, and recoverable.

Related resources from NHI Mgmt Group

• How do security teams reduce the blast radius of malicious pull requests in cloud dev environments?
• How can security teams reduce the blast radius of document theft in HR and finance systems?
• How should security teams reduce blast radius when workflow automation platforms run with broad infrastructure access?
• How should security teams reduce blast radius when a popular npm package is compromised and used in CI/CD or developer environments?