Should OT teams prioritise identity-driven controls over another firewall redesign?

When should OT teams fund identity-driven control improvements first?

OT teams should prioritise identity-driven controls when the environment spans legacy controllers, modern platforms, vendor access, and shared operational users. In that setting, another firewall redesign can improve segmentation, but it still leaves trust anchored to location and subnet assumptions. Identity-driven controls change who can act, not just which path traffic takes.

Why a firewall redesign often misses the real control gap

A firewall is a boundary control. It can reduce exposure, constrain routes, and make lateral movement harder, but it does not solve the underlying question of whether a device, service, or operator should be trusted at all. If access decisions are still based mainly on where traffic originates, the control plane remains fragile when systems move, vendors rotate, or hybrid access paths appear.

Identity-driven controls matter because OT environments increasingly mix physical process assets with remotely managed infrastructure, engineering workstations, jump hosts, and integrated IT services. In that mix, network segmentation alone is rarely enough to express least privilege. The more useful question is whether a given identity, device, or workload is allowed to perform a specific action at a specific time.

That is why operational teams often find more value in tightening authentication, access approval, privileged session handling, and machine-to-machine authorization than in another round of perimeter tuning. The control objective shifts from “keep traffic in the right zone” to “permit only the right actor to perform the right function.”

What identity-driven controls change in mixed OT environments

Identity-driven controls give OT teams a way to govern access across zones without assuming that every trusted network is equally trusted. They are especially useful where shared accounts, vendor remote support, service credentials, or engineering tools create broad implicit access. OT and ICS Identity and Access Guide is a useful reference for how shared accounts, vendor remote access, and segmentation intersect in operational technology.

They also improve auditability. When access is bound to identity and privilege rather than only to network path, teams can trace who approved a change, who opened a session, and which machine or service executed a command. That matters in OT because operational continuity depends on knowing not only that a system was reached, but whether the access was expected, authorised, and bounded.

In practice, the strongest pattern is layered control. Network segmentation still matters, but it becomes a supporting control rather than the main trust decision. Identity, device posture, session approval, and privileged action limits become the deciding factors for access into critical segments and for remote support across plant and enterprise boundaries.

Risk and Threat Considerations

When OT trust is inferred from network location, a compromise inside one zone can become a fast path to deeper access. Shared accounts, vendor tunnels, and reused credentials make that risk worse because an attacker does not need to defeat every firewall rule if they can inherit an already-trusted identity or session.

Failure mechanism: A flat or over-reliant network design treats “inside the right subnet” as evidence of legitimacy, which lets stolen credentials, remote access tools, or misused privileged accounts operate with too much authority once they are inside the environment.

Impact: The result can be unauthorised configuration change, loss of process integrity, broader lateral movement, and slower detection because the activity looks like normal authorised traffic rather than a trust failure.

Practitioner Guidance

What to prioritise: If the environment still depends on shared OT credentials, broad vendor access, or long-lived privileged sessions, fund identity controls before another firewall redesign. The redesign may still be worthwhile, but it should not be the primary answer to a trust problem.

What to verify: Check whether access decisions are tied to named identities, approved devices, and specific operational actions. If you cannot answer who is allowed to do what from where, and for how long, the network design is carrying too much of the trust burden.

What good looks like: Operators, vendors, and automation are individually attributable; privileged access is time-bounded and reviewable; and a network boundary only narrows exposure, it does not become the control that grants legitimacy.

Practitioner takeaway: In hybrid OT environments, identity-driven control is usually the better first investment because it reduces trust at the point of action, which is where firewall redesign alone cannot help.

Related resources from NHI Mgmt Group

• When should teams prioritise a firewall rollout over adding more application-level controls on a new Ubuntu server?
• When should teams prioritise firewall allowlisting over reverse tunnels for identity traffic?
• How should security teams prioritise NHI remediation in cloud environments?
• Should teams prioritise runtime controls over more vulnerability scanning?