What Are Vendor-Specific OT Remote Access Platforms?

Vendor-specific OT remote access platforms go beyond the jump server model to provide just-in-time access provisioning, granular OT-aware access policies, and integrated session management for multi-vendor OT environments. Three platforms lead the OT remote access market: Claroty Secure Remote Access (SRA), Xage Security, and Cyolo. Each provides a different architectural approach to the same core requirement: give vendors and remote staff least-privilege, time-limited, recorded access to specific OT systems without VPN-style network access.

Claroty SRA provides OT-specific remote access with integration to Claroty's OT asset inventory, enabling access policies scoped to specific OT assets discovered through passive monitoring. Access sessions are linked to OT asset records, providing context for security review. Session recordings are OT-protocol-aware: SCADA screen recordings are annotated with the OT actions performed (setpoint changes, alarm acknowledgments) rather than just capturing pixel-level video.

Citation Capsule: Remote access to OT is provided by 83% of industrial organizations as of 2024, and remote access exploitation remains one of the top two OT initial access vectors in documented incidents. Just-in-time OT remote access platforms that replace persistent VPN connections with time-limited, recorded, least-privilege sessions reduce OT remote access attack surface by eliminating persistent credential exposure and over-privileged network connectivity (SANS ICS Security Survey, 2024).

How Do You Secure Cloud SCADA and Cloud-Connected OT?

Cloud SCADA systems, SCADA applications running in AWS, Azure, or GCP rather than on dedicated OT hardware, are increasingly deployed for geographically distributed operations where connecting to a cloud-hosted SCADA is more practical than maintaining regional on-premise servers. Cloud SCADA introduces specific security requirements that on-premise SCADA doesn't face: cloud account security, tenant isolation between multiple customer environments on shared cloud infrastructure, API security for cloud SCADA interfaces, and cloud-to-OT connectivity security for the data paths between cloud-hosted SCADA and on-premise field devices.

Cloud SCADA cloud account security requires the same controls applied to any critical cloud workload: MFA for all administrator accounts, least-privilege IAM roles for cloud SCADA service accounts, CloudTrail or equivalent audit logging for all cloud SCADA API calls, and network security groups restricting access to cloud SCADA resources to authorized IP ranges. The OT-specific addition is that the IAM roles used by cloud SCADA services to access on-premise OT systems must be treated as OT access credentials, managed through OT access control policies, and monitored for anomalous use.

Securing Cloud-to-OT Data Paths

The data path from on-premise OT to cloud SCADA passes through several security boundaries: the OT network, the industrial DMZ, the corporate IT network, and the internet. Each boundary must enforce explicit allow policies for cloud SCADA traffic. The OT device or gateway that sends data to cloud SCADA should communicate only with the cloud SCADA endpoint, not with the broader internet. This restriction is enforced by industrial DMZ firewall rules that permit only the specific cloud SCADA IP addresses or DNS names. Cloud SCADA connections from on-premise OT should use encrypted transport (TLS) with certificate validation to prevent man-in-the-middle interception.

How Do You Audit and Monitor OT Remote Access?

OT remote access monitoring requires three capabilities. Authentication monitoring: all remote access authentication events logged and reviewed for unauthorized access attempts, unusual source IPs, and after-hours access patterns. Session monitoring: all remote access sessions recorded and flagged for review when they involve unusual systems, unusual actions (configuration changes, file downloads), or unusually long duration. Access entitlement review: quarterly review of all remote access accounts and permissions, removing stale accounts and over-privileged access rights. These three capabilities convert remote access from a security liability into a monitored, controlled operation.

Access entitlement review deserves particular attention for vendor accounts. Vendor accounts are typically provisioned for specific projects or maintenance tasks and should be deprovisioned when those tasks conclude. In practice, they frequently remain active for months or years after the original need has passed, accumulating entitlements across projects until they represent a broad access account that no longer corresponds to a specific operational need. Quarterly vendor access reviews that require active business justification for continued access prevent this entitlement sprawl.

Frequently Asked Questions

What is ZTNA and how does it apply to OT remote access?

Zero Trust Network Access (ZTNA) is an alternative to VPN-based remote access that provides application-specific access rather than network-level access. Instead of placing remote users on the OT network, ZTNA provides access only to specific SCADA applications, historian interfaces, or HMI systems that the user is authorized to access, verified against their identity and device health posture. ZTNA for OT remote access reduces the over-privilege inherent in VPN-based access. Vendors including Zscaler, Palo Alto Prisma Access, and Cloudflare Access provide ZTNA capabilities applicable to OT remote access scenarios (NIST SP 800-207, 2020).

Should vendor remote access to OT use shared accounts?

No. Shared vendor accounts make it impossible to attribute specific actions to specific individuals, limit accountability for accidental or malicious changes, and require credential rotation every time any user with the shared credential leaves the vendor organization (often not done in practice). Individual vendor accounts, provisioned per named individual with access scoped to their specific responsibilities, are the security baseline for OT vendor access. Just-in-time provisioning platforms can create individual accounts automatically for each approved access request without the operational overhead of manual account management.

How do you handle multi-vendor OT remote access?

Multi-vendor OT environments, where multiple vendors maintain different systems, require a centralized remote access platform that provides unified authentication, access policy management, and session recording across all vendor connections. Without centralization, each vendor uses different remote access tools and credentials, creating visibility gaps and audit complexity. Platforms including Claroty SRA, Xage, and CyberArk Alero support multi-vendor OT remote access from a single management console with per-vendor access policies, session recording, and audit reporting. This centralization also enables a single kill-switch for terminating all vendor access simultaneously in the event of a security incident.

What is the security risk of cloud SCADA?

Cloud SCADA shifts SCADA security responsibility from a closed on-premise system to a shared cloud infrastructure model. The primary risks are: cloud account compromise (weak credentials or misconfigured IAM roles providing unauthorized SCADA access); cloud platform vulnerabilities (though major cloud providers' security track records are strong); and the cloud-to-OT connectivity path, which creates a network connection from the internet to on-premise OT that must be tightly controlled. Organizations deploying cloud SCADA should apply cloud security best practices (MFA, least-privilege IAM, CloudTrail logging) in addition to OT-specific controls for the cloud-to-OT connectivity path.

Conclusion

Remote access to OT is a business necessity that has become a primary security liability through inadequate architecture. The 83% of industrial organizations providing OT remote access in 2024 are not wrong to do so: the operational efficiency benefits are real. The security failures are in how that access is provided: persistent VPN connections with shared credentials, internet-facing OT components without MFA, and vendor access that was never terminated after the project concluded.

The architectural solution is straightforward: eliminate direct network access VPNs, implement jump servers or dedicated OT remote access platforms in the industrial DMZ, require individual authenticated accounts with MFA for all remote access, record all sessions, and conduct quarterly entitlement reviews that remove stale access. These four changes, implemented together, convert OT remote access from the primary attack vector it currently is into a controlled, monitored, and auditable access path that meets both operational and security requirements.

Explore Opsio's OT security services to understand how we design and implement secure remote access architecture for industrial environments.