Remote Access, Authentication, and Wireless

The Cursor Nobody Authorized

On February 5, 2021, a water treatment operator in Oldsmar, Florida watched his mouse cursor move on its own. A setpoint for sodium hydroxide dosing changed from 111 parts per million to 11,100 -- one hundred times the normal level. He reversed it within thirty seconds. Four months of FBI investigation failed to confirm whether the cursor was moved by an external attacker or by an internal accidental action. No outside actor was ever identified or charged. The current evidence, including statements from the former city manager in 2023 and the Water Information Sharing and Analysis Center, points toward an internal inadvertent event. The reason the question was never definitively answered is the actual lesson. No session log showed who connected. No MFA token confirmed an authorized user. No IP whitelist confirmed the source address. The monitoring system that should have caught an anomalous connection did not exist. The absence of those controls made it impossible to distinguish an attack from an accident -- and that inability is itself the security failure. This chapter covers the access controls that would have answered that question: VPN architecture, jump servers, MFA options that work in OT field conditions, vendor access management, default credential exposure, and the wireless paths that bypass every network boundary an organization believes it has.

VPN: What It Does and What It Doesn't

A VPN secures the connection to the control network, not the network itself. That distinction matters more in OT than in IT because the consequence of misunderstanding it is an open control zone. A VPN creates an encrypted tunnel between two endpoints across an untrusted network. Traffic in transit is protected from eavesdropping and tampering. Once the tunnel opens and the remote device is inside, the VPN has done its job. What the connected user can reach, what they can change, and whether anyone is watching are not VPN questions. They are architecture questions. In site-to-site VPN, the two endpoints are VPN gateways installed at each facility boundary. Devices on both sides communicate as if they share a private network. The SCADA server and the PLCs have no awareness that a VPN exists -- the gateways handle everything transparently. A company connecting multiple plant control networks to a head office uses this model. In remote access service VPN, one endpoint is the user's device running a VPN client. The other is the VPN gateway at the plant boundary, which sits in the Industrial DMZ. Once the vendor's laptop authenticates and the tunnel opens, that laptop is a node on the control network -- the same as any HMI or engineering workstation. Everything the laptop can reach, an attacker who has compromised the laptop can also reach. OT-positioned VPN appliances from vendors like Fortinet FortiGate Rugged and Moxa EDR add controls that basic VPN cannot: authentication enforced before traffic is passed, access control lists that restrict each remote user to specific device groups, and low-latency processing that does not disrupt supervisory control loops. SSL VPN -- also called clientless VPN, delivered through standard HTTPS without installing a client -- matters when a vendor arrives with an unmanaged laptop that cannot have software installed. VPN is necessary. On its own, it is not sufficient. The controls that make it sufficient are covered in the rest of this chapter.

The Jump Server: One Controlled Entry Point

The jump server -- sometimes called a bastion host -- is a hardened, monitored system placed in the OT DMZ between the enterprise zone and the control network. Its purpose is architectural: it is the only routed path from outside into the OT zone. All remote access sessions terminate at the jump server first. From there, the user initiates a second connection to the specific OT device they need. No direct connections from outside to Level 2 and below are permitted. A vendor's laptop cannot reach a PLC directly. It reaches the jump server. The jump server reaches the PLC. Every keystroke, every command, and every session is captured at the jump server. If a vendor's laptop is compromised, the attacker reaches the jump server and stops -- the devices behind it are still one authenticated hop away, and the jump server's session log records every command attempted. The jump server serves three distinct security objectives simultaneously. Network segmentation: the OT zone has no direct external access path; the jump server is the only door. Audit trail: the session record is authoritative, not dependent on individual device logging, which many legacy OT devices cannot provide. Access control: jump server credentials are maintained separately from individual OT device credentials, so a compromised remote credential does not automatically yield control of what the credential can reach. The jump server itself is the highest-value target on the OT boundary. It must be hardened, kept patched, monitored continuously, and backed up with the same priority as a SCADA server.

MFA in OT Field Conditions

Multi-factor authentication adds a second verification step beyond a password: something you know plus something you have or are. CISA's primary OT security mitigations require MFA on all accounts accessed remotely, including vendor accounts. The implementation challenge in OT is that the conditions that make software MFA straightforward in an office -- smartphones, reliable mobile coverage, individual workstations -- are often absent in the field. Cellular signal is unavailable at remote RTU sites. Smartphones are banned in control rooms with explosion risk classifications. Shared workstations across shifts mean no personal device is always present. Hardware tokens address all three constraints. A YubiKey uses challenge-response cryptography that works offline with no battery, no mobile connection, and no smartphone app. It generates the second factor from a private key stored on the physical token, validated by a server that holds the corresponding public key -- the handshake is complete without any network call to a mobile carrier. An RSA SecurID hardware token generates time-based one-time passwords on a standalone device synchronized to a server clock, requiring no app or phone signal. Both options allow individual user authentication in environments where smartphone-based TOTP apps cannot function. For environments where hardware tokens cannot be deployed immediately, CISA's guidance is explicit: if MFA cannot be implemented on a remote access path, that path's security exposure must be compensated through additional network segmentation steps, tighter credential management, and priority assignment for MFA deployment. The guidance does not treat MFA as optional -- it treats it as a requirement with a timeline.

Vendor Access: Time-Bounded, Audited, and Revocable

The most common vendor access failure pattern is a permanent VPN credential with standing access to the control network. The vendor has credentials that work at any time, connect to a broad network segment, and expire only if someone remembers to revoke them. When that vendor relationship ends, or when the vendor's laptop is compromised, the credential remains active. The correct architecture issues a time-limited credential, valid only for the duration of the maintenance window -- often four hours or less. The credential is restricted to the specific devices the vendor needs to access during that window, not to the segment or zone as a whole. Every session is recorded at the jump server, and the credential expires automatically when the window closes without any manual action. Platform-specific vendor access management tools implement this model with additional controls. CyberArk Vendor PAM provides just-in-time access provisioning, where vendor credentials are created at the start of a session and destroyed at the end; it adds biometric MFA and agentless connectivity that does not require the vendor to install a VPN client. Claroty xDome Secure Access provides session recording with over-the-shoulder monitoring capabilities, allowing an OT security analyst to observe a vendor session in real time and terminate it if the activity deviates from the stated maintenance purpose. Secomea is an OT-specific remote access gateway with IEC 62443-certified access controls designed for field device support scenarios. The common principle across all three is that vendor access is never a permanent relationship -- it is a controlled, time-bounded, fully audited event with a defined scope and an automatic end.

Default Credentials: The Key Left in the Lock

In November 2023, a threat group affiliated with Iran's Islamic Revolutionary Guard Corps scanned the internet for Unitronics Vision Series PLCs and logged in using the factory default password: 1111. The password had not been changed since the devices shipped. Multiple US water utilities were affected. CISA issued an emergency advisory. The FBI opened investigations. No zero-day exploit, no advanced persistent threat, no custom malware -- just the credential published in the vendor's public documentation, used against devices the vendor shipped with that credential set. Vendors ship devices with factory defaults because the device must function on first power-up: admin/admin, admin/1234, root/root, and 1111 appear across thousands of PLC and HMI models and are documented in publicly available installation manuals. Three patterns cause them to persist after commissioning. The configuration tool used to manage the device requires the factory password to connect, and changing it breaks the tool's ability to reconnect; the change gets deferred and never made. A third-party application -- a historian, a monitoring platform, a legacy SCADA interface -- has the default credential hard-coded and breaks if the device password changes; changing the password breaks more than it fixes. Or the vendor's documentation discourages changing the password to avoid configuration errors, and the operator follows the documentation. The device works perfectly and gives no sign the password was never changed. The scale of exposure from default credentials is not theoretical. A Forescout analysis found 4,407 internet-facing controllers with their EtherNet/IP port visible on Shodan, the device search engine that indexes internet-accessible systems. A broader survey found close to 110,000 internet-facing ICS devices overall. Researchers have authenticated into live HMI systems from the public internet using admin:admin. When an attacker uses the default password and it works, the system records a successful login. It has no mechanism to distinguish that login from a legitimate one.

Shared Accounts and Individual Authentication

The most widespread authentication failure in OT environments is not default credentials -- it is shared accounts. One SCADA username, one password, used by every shift worker who needs access to the supervisory system. The audit log records that the account named "operator" logged in at 2 AM and changed a pump setpoint. It cannot tell you which of the twelve shift workers assigned to that account was at the keyboard. When a security incident occurs, no log entry points to an individual. When an employee leaves under difficult circumstances and their access must be revoked, revoking it means changing the password for every person who uses that account -- a process disruptive enough that it gets deferred indefinitely. IEC 62443-3-3 Security Requirement SR 1.1 (Identification and Authentication for Human Users) and SR 1.2 (Authenticator Management) address this directly. SR 1.1 requires that every human user be uniquely identified before being granted access to the IACS. A shared account makes that requirement impossible to meet by design -- the system cannot distinguish which human is behind the shared credential. Individual accounts require technology support that some legacy OT platforms cannot provide. Where individual accounts cannot be implemented immediately, IEC 62443 allows compensating controls: supervisor verification for parameter changes, sign-in sheets that tie a name to an action, and shift records that provide the individual traceability that the authentication system cannot. These are compensating measures, not permanent solutions. The standard's position is that individual authentication is the requirement and the timeline for achieving it must be documented.

Wireless in OT: What Belongs and What Doesn't

Not all wireless in OT is a security problem. WirelessHART, standardized as IEC 62591, is the dominant wireless standard for OT field instrumentation -- pressure transmitters, level gauges, temperature sensors, and flow meters that cannot be economically wired in many process environments. AES-128 encryption is mandatory in the standard; it cannot be disabled. Every device authenticates using a join key, a unique authentication code configured at commissioning, that the network manager (a software function built into the WirelessHART architecture) validates before allowing the device to join the mesh. Only devices with the correct join key and confirmed identity can become part of the network. ISA 100.11a, standardized as IEC 62734, covers a broader range of automation applications and adds IPv6 support and longer range capability. Both protocols were designed with security as a protocol-level requirement, not a configuration option. They belong in OT environments when correctly deployed. The architectural rule for legitimate OT wireless is isolation: the WirelessHART gateway that aggregates field instrument data connects into the control network zone through a defined, monitored path. Maintenance WiFi for field technician tablets runs on a dedicated VLAN, isolated from the control network by a firewall. A cellular modem at the plant boundary connects to the OT DMZ, not directly to the control network. Every authorized wireless path terminates at a controlled boundary before any OT system can be reached. A rogue access point bypasses that architecture entirely by connecting directly into the control network segment. When a maintenance technician plugs a consumer WiFi router into an OT switch for convenience -- which is the most common way rogue APs appear -- the physical boundary of the control network dissolves. Anyone within radio frequency range, including people in the parking lot or an adjacent building, can reach devices assumed to be air-gapped.

Rogue APs, Cellular Modems, and the Actual Network

The cellular modem is the single most common air gap failure in OT. A vendor installs one on a PLC or HMI to enable remote diagnostics, bypassing the IT and OT security approval process. The modem creates a direct connection from the device to the mobile carrier network, which connects it to the internet without passing through any plant firewall or DMZ. It does not appear on any network diagram. It bypasses every access control the organization believes is in place. The OT security team may have no knowledge it exists. Claroty's 2024 OT research found wireless connectivity -- including cellular modems and unauthorized hotspots -- in many OT networks that were expected to be isolated. The detection methods for cellular modems are limited: RF spectrum scanning and physical panel inspection are the two reliable approaches. Neither can be automated through the monitoring platforms that detect network-based threats; the modem creates a separate network path that the monitoring platform cannot see. A Wireless Intrusion Detection System scans the RF environment passively and alerts on any access point or wireless client not on the approved inventory. It operates independently of the wired network, which means it detects wireless threats that wired monitoring cannot see by definition. For operational WiFi carrying OT traffic -- control room wireless, field technician tablets, mobile HMIs -- WPA2-Personal provides inadequate protection for a shared-access environment. A single shared password means that when any device is lost or any person leaves, the password must be changed for everyone, or the security of every device that knows the old password is compromised. WPA2-Enterprise authenticates each user individually through a RADIUS server before granting network access, allowing access to be revoked for a single user without resetting credentials for everyone else. WPA3-Enterprise adds stronger cipher suites and better protection against offline dictionary attacks against captured authentication exchanges. NIST SP 800-82 Rev 3 -- the OT security guidance document introduced in Chapter 4 -- addresses wireless in four recommendations: isolate OT wireless segments behind firewalls, deploy a WIDS to detect rogue devices and unauthorized access points, require strong authentication and encryption on all operational WiFi, and scan for unauthorized access points within and beyond facility boundaries. The RF spectrum does not respect network diagrams. What you find when you walk the floor with an RF analyzer is the actual network.

What's Next

Chapter 10 has covered the access control layer: VPN architecture for site-to-site and remote access, the jump server as the single controlled entry point, MFA options that work in OT field conditions, vendor access as a time-bounded audited event, default credential exposure and the Unitronics attack, shared accounts and the IEC 62443 SR 1.1 requirement, and the wireless paths -- rogue APs and cellular modems -- that bypass the architecture entirely. Chapter 11 returns to the protocol layer for security analysis: what makes Modbus TCP, DNP3, EtherNet/IP, and OPC UA vulnerable by design, how PIPEDREAM/INCONTROLLER exploited those properties without any CVE, and what defense at the protocol layer -- rather than the network layer -- adds to an OT security architecture.

Reflect

• The Oldsmar case established that the inability to answer "was this an attack or an accident?" is itself a security failure. For a remote access event at your facility -- a vendor connecting to perform maintenance, or an after-hours SCADA login -- what is the minimum you could determine from current logs? Could you identify the authenticated user, the source address, and every command executed during that session?
• The jump server architecture makes the DMZ jump server the single routed path from outside into the OT zone. In your environment, is there a device in that role -- a hardened system all remote sessions must traverse before reaching control network assets? If sessions terminate at the VPN gateway and then have direct access to the control network, the jump server function does not exist yet.
• The default credential section identifies three patterns that cause factory passwords to persist: configuration tool dependency, hard-coded credentials in third-party applications, and vendor documentation that discourages changes. For the last device commissioned in your environment, is there documentation confirming the factory default password was changed before the device went live? Who is responsible for verifying that?
• The wireless section distinguishes authorized OT wireless (WirelessHART/ISA 100.11a, properly isolated) from unauthorized wireless (rogue APs, cellular modems). When was the last RF scan performed at your facility? Does your site have a WIDS providing continuous passive detection of unauthorized wireless, or does detection depend on physical observation?