How should organisations secure legacy OT that cannot be patched quickly?

Start by separating unpatchable systems from standard enterprise assets and treating them as a distinct risk class. Then restrict who can reach them, record privileged activity, and add compensating controls where patching is not possible. The goal is not perfect hardening. It is reducing the number of identities and sessions that can create operational impact.

Why This Matters for Security Teams

Legacy OT that cannot be patched quickly is not just a vulnerability management problem. It is an identity and access problem, because unpatchable controllers, engineering workstations, and protocol gateways often remain exposed for years while attackers target the weakest reachable session. A risk-based answer starts with the premise that these systems will not become safe through patching alone, so the organisation must reduce who can connect, what they can do, and how long access survives.

This is where identity controls become the main compensating measure. NHI Management Group notes that 97% of NHIs carry excessive privileges, which broadens the attack surface in environments already constrained by uptime and vendor support limits. That makes least privilege, session isolation, and strict secrets handling critical, not optional. The control model should align to a broader resilience program such as the NIST Cybersecurity Framework 2.0, but OT execution has to account for fragile assets and maintenance windows.

In practice, many security teams discover the exposure only after a vendor laptop, remote access broker, or shared service account has already been used to reach an unpatchable controller.

How It Works in Practice

The first step is to separate legacy OT from standard enterprise trust zones and then treat every connection as privileged. That means removing broad routing paths, placing systems behind industrial jump hosts, and requiring authenticated access through tightly controlled gateways. Where possible, access should be user- and workload-specific rather than shared, with short-lived credentials issued only for the maintenance task. For identity governance, the operational model should mirror the basics in the Ultimate Guide to Non-Human Identities: visibility, rotation, and revocation are not nice-to-have features, they are the only scalable defenses when patching lags.

Compensating controls should be layered rather than substituted for one another:

• Use network segmentation and allowlisting so only approved hosts, protocols, and destination ports can reach the asset.
• Require PAM for interactive access, with separate admin credentials and session recording for operator review.
• Store secrets in a managed vault and rotate them on a fixed schedule, even when the underlying OT device cannot be patched.
• Apply JIT access for maintenance, so privileged sessions expire when the work order ends.
• Log command execution and configuration changes centrally, then alert on out-of-window activity.

The best practice is evolving toward identity-centric access decisions at the control point, not just perimeter filtering, because legacy OT is frequently reached through vendor support paths, remote engineering tools, or shared automation accounts. NHI Mgmt Group’s research on the Schneider Electric credentials breach underscores the operational reality that compromised credentials can create impact even when the device itself is not modified. These controls tend to break down when third-party maintenance requires persistent vendor connectivity, because shared exceptions quickly become standing privilege.

Common Variations and Edge Cases

Tighter access control often increases operational friction, requiring organisations to balance availability against incident containment. That tradeoff is especially sharp in plants with 24/7 production, safety systems, or unsupported vendor hardware. There is no universal standard for this yet, but current guidance suggests setting different control tiers for safety-critical assets, business-critical assets, and low-consequence legacy devices so the same policy does not overconstrain every environment.

One common exception is a vendor-managed system that cannot accept modern agents, MFA, or endpoint telemetry. In that case, compensating controls should move outward: isolate the session jump point, enforce time-bound vendor access, and require dual approval for emergency changes. Another edge case is an OT environment that shares credentials across multiple controllers. That is a high-risk pattern because it defeats accountability and makes revocation slow, so the better control is to replace shared access with individually attributed sessions where possible, even if the device itself remains unpatched.

For organisations building a broader operating model, the NIST Cybersecurity Framework 2.0 provides the governance spine, while NHI-specific practices from NHI Management Group fill the access, rotation, and session-control gaps that OT teams face daily.

Related resources from NHI Mgmt Group

• How should organisations handle websites that still show a browser not secure warning?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How should teams secure non-human identities across cloud and SaaS?
• How can organisations reduce secret leakage in ServiceNow at scale?