Identity-First Remote Access for OT Networks: Replacing Flat VPNs Without Stopping the Plant

Operational technology networks were built for availability, not for adversarial conditions. Remote access was bolted on later, usually as a VPN concentrator that terminates somewhere near the control network and trusts whatever authenticates successfully. That design is now the weakest link in many industrial environments.

Why the reader needs this

Remote maintenance is not optional. Vendors need access to diagnose faults, engineers need to reach HMIs after hours, and staff work from home. The question is not whether to allow remote access but how to grant it without handing an authenticated session the same reach as a workstation on the plant floor. Ransomware crews have repeatedly entered industrial networks through exactly this path, and the entry step rarely involves a novel exploit.

Technical context: what flat access actually grants

A conventional VPN gives an authenticated user an IP address inside a network and routes to whatever that network permits. In an OT environment that typically means:

• Direct reachability to engineering workstations and HMIs, often with default or shared credentials.
• Protocols with no authentication at all. Modbus TCP, for example, has no native authentication or authorization, so network reachability is equivalent to control.
• A single authentication event that produces a long-lived session with broad routing.
• Limited logging of what the session did after it connected, because the VPN logs the connection rather than the operations. The practical consequence is that the VPN authenticates a person once and then stops making decisions. Everything after that is network policy, and OT network policy is usually permissive because segmentation was designed for reliability rather than least privilege. ## A concrete failure chain This chain reflects publicly documented incident patterns in industrial environments, presented as a reasoning model rather than a specific case study.
• An attacker obtains credentials for a remote access portal, through phishing, credential reuse or a purchased credential dump.
• The portal has no second factor, or the second factor is push-based and the attacker can fatigue the user into approving.
• The session lands on a jump host that is dual-homed between IT and OT.
• From the jump host, the attacker enumerates the OT segment, finds an engineering workstation, and uses credentials found in a project file or a cached session.
• With access to the engineering workstation, the attacker can modify control logic or deploy ransomware to the historian and HMI fleet. Each step is a configuration weakness rather than a software vulnerability. That is what makes the pattern durable. ## Defensive implications Put identity in front of the session, not just at the door. A broker that authenticates the user, checks device posture, and then issues a short-lived, per-session credential to a specific target changes the model. The user never receives network-level access; they receive a session to one asset. Require phishing-resistant authentication. Hardware security keys or certificate-based authentication remove the push-fatigue path. For vendor access, this is the control that most directly breaks step two above. Make every session individually authorized. A vendor who needs to read a controller's diagnostics should not receive a session that can also write logic. Enforce this at the broker, not in a policy document. Log operations, not connections. Record which commands, registers or files were touched. Connection logs answer "who connected"; operation logs answer "what changed", which is the question that matters during an incident. Assume the jump host will be compromised. Segment it, keep it free of cached OT credentials, and treat any lateral movement from it as a detection signal rather than a surprise. Keep a manual fallback. Availability matters. Any access control change should be tested against the scenario where the broker is unavailable and the plant still needs to run. ## Limits of this analysis Identity-based access brokers add a dependency: if the broker is down, so is remote access. They also require asset inventory that many OT environments do not have, because you cannot scope a session to an asset you have not identified. Modbus and similar protocols remain unauthenticated at the protocol level, so the broker protects the path to the device rather than the device itself. These are real constraints, and they argue for a staged migration rather than a flag day. ## References
• CISA, "Guide to Operational Technology (OT) Security" (SP 800-82 Rev. 3 co-publication): https://www.cisa.gov/resources-tools/resources/guide-operational-technology-ot-security
• NIST SP 800-82 Rev. 3, Guide to Operational Technology Security: https://csrc.nist.gov/pubs/sp/800/82/r3/final
• NIST SP 800-207, Zero Trust Architecture: https://csrc.nist.gov/pubs/sp/800/207/final
• CISA advisories on internet-exposed OT and industrial control systems: https://www.cisa.gov/news-events/cybersecurity-advisories