What breaks when ICS environments are secured like ordinary IT networks?

Why IT-style security assumptions break down in ICS

ICS is not just another network segment. Many control loops, safety functions and operator workflows depend on deterministic timing, device-specific protocols and a valid state transition, so a control that is normal in IT can be disruptive here. A “safe” change in an office environment may become a process interruption when it delays commands, blocks telemetry or forces devices into an undefined state.

That is why segmentation, filtering and hardening have to be evaluated against process impact, not only against attack surface reduction. In practice, the question is whether the control preserves the ability to monitor, command and recover the physical process without introducing new failure modes.

What continuity means in an industrial environment

Continuity in ICS is about keeping the physical process stable, observable and recoverable. Operators need valid telemetry, predictable command delivery and a recovery path that does not make the plant less safe than the original fault. If a security change prevents a controller from talking to a historian, HMI or engineering workstation, the consequence can be more than inconvenience, it can be loss of situational awareness or inability to execute a required action.

Legacy devices make this harder because they often cannot support modern authentication, encryption or rapid patch cycles. Security teams therefore have to work around protocol constraints, vendor support limits and fragile restart behaviour, instead of assuming they can apply the same control set used for standard enterprise endpoints.

Published guidance from NIST SP 800-82 Rev 3, OT Security Guide is useful here because it frames industrial security around availability, segmentation and control-system baselines rather than ordinary office-network defaults.

What a safe recovery posture looks like when something goes wrong

Recovery in ICS must be validated, not assumed. Restoring from a backup or re-imaging a device can be unsafe if the restored configuration is stale, incompatible or missing process-specific settings. A rollback that is fine for IT may reintroduce a bad logic version, break time-sensitive dependencies or trigger an unintended state change when the controller comes back online.

The better model is to treat recovery as part of the control system itself: test the restore path, confirm which devices can be restarted safely in what order, and verify that the rebuilt state is still aligned with the physical process. Guidance for industrial operators from CISA Industrial Control Systems reinforces the need to plan for incident response and recovery in ways that match the operational environment.

Risk and Threat Considerations

When ICS is secured like ordinary IT, the main risk is that defensive controls interfere with the process itself. A blocked protocol, delayed command or aggressive restore can create safety exposure, production loss or equipment damage even when no attacker is present.

Failure mechanism: Generic enterprise controls can break timing, availability or device interoperability, which means the security layer becomes a cause of operational failure rather than a protection against it.

Impact: The result can be lost control visibility, interrupted production, unsafe state transitions or a recovery action that worsens the original incident.

Practitioner Guidance

What to prioritise: Start with process continuity, command reliability and validated recovery paths before you tighten policy, deploy filtering or enforce protocol restrictions. If a control can delay a command or suppress telemetry, it needs operational testing, not just policy approval.

What to verify: Confirm that every security change has been tested against the real device mix, protocol set and restart sequence in the target environment. The key question is whether the plant can still monitor, operate and recover safely after the control is applied.

Common mistake: Treating ICS hardening as a direct copy of IT hardening. That shortcut often ignores legacy constraints, vendor dependencies and the fact that “secure” can be unsafe if it breaks the process at the wrong moment.

Practitioner takeaway: In ICS, the correct security outcome is not maximal restriction, it is controlled change that preserves safe operation, predictable command flow and a recovery path that has already been proven in context.

Related resources from NHI Mgmt Group

• What breaks when GenAI systems are secured like ordinary applications?
• What breaks when AI gateway controls are treated like ordinary API security?
• What breaks when AI agents are managed like ordinary machine identities?
• What breaks when autonomous agents are managed like ordinary NHIs?