Securing OT remote access: why VPN and MFA alone are not enough

Remote access to operational technology (OT) has become the most important entry point for attacks on industrial environments. Remote maintenance, vendor support, distributed sites: all of this has long been indispensable in daily operations. But this is where the risk arises: according to the current SANS 2025 State of ICS Security Survey, roughly half of all ICS security incidents trace back to remote access. VPN and multi-factor authentication (MFA) are a solid foundation, but on their own they are not enough. Securing OT remote access takes more than a tunnel and a second factor.

The numbers: remote access is the number one entry point

The SANS report paints a clear picture of the situation in industrial environments:

• 50% of ICS incidents originate from remote access.
• 22% of organizations had an ICS/OT security incident within twelve months, 38% of which involved ransomware.
• 31% keep no formal inventory of their remote access paths. In other words, they do not know who gets in through which routes.
• 83% use cloud in IT and OT, but only 13% include these cloud activities in their monitoring.

Especially critical: even when an incident is detected quickly, remediation often takes a long time. A notable share of organizations needs days to months to return to a secure state. In a production environment, that is expensive and dangerous at the same time.

Why VPN and MFA are not sufficient

VPN and MFA reliably answer a single question: is the user who they claim to be? They authenticate identity and establish a secure connection. What they do not deliver: they say nothing about which actions a user may perform, which devices they interact with, and how their actions affect physical operations.

In IT, that is often acceptable. In OT, a wrong action on a controller, intentional or accidental, can have real consequences: a production stop, damaged equipment, or a safety risk to people. On top of that, modern remote access paths have long gone beyond the classic VPN: vendor portals, cloud services, and installed agents open up additional routes that a pure VPN does not control at all. An authenticated tunnel says nothing about what happens inside it.

What ICS-specific controls have to deliver

SANS therefore recommends treating remote access to OT as a security-critical function with its own requirements. In concrete terms, this means a set of ICS-specific controls that are still implemented far too rarely today:

• Least privilege per action: Going beyond “access yes/no” to govern which specific actions are allowed on which device.
• Device- and configuration-aware controls: Access only from authorized, properly maintained engineering workstations.
• Session recording & replay: complete recording for incident analysis, compliance, and resolving vendor disputes (only around 13% implement this).
• Real-time approvals: critical access is coordinated with on-site staff and maintenance windows (only around 8%).
• Jump host / session broker: an enforced, controlled chokepoint for all remote access, aligned with the OT DMZ under the Purdue model (around 23%).
• Protocol mediation: restriction to permitted applications and industrial protocols instead of open network access.

Xage Security as a solution

Xage Security closes exactly this gap between “authenticated” and “controlled.” Xage's approach is an identity-based Zero Trust access model built specifically for OT and ICS environments: instead of yet another VPN, Xage places a consistent control layer over all access paths. The platform's capabilities cover the controls SANS calls for point by point:

• Granular access per user, device, and action instead of a blanket tunnel into the network. This makes least privilege enforceable down to the asset level.
• MFA for legacy systems too: Xage layers strong authentication over OT assets that do not natively support modern MFA, without touching the devices themselves.
• Privileged remote access with session brokering, recording, and replay: the controlled session replaces the open tunnel.
• Uniform policies across IT, OT, cloud, and vendor portals, including the access routes a classic VPN overlooks.
• Distributed, fault-tolerant architecture: access decisions work across multiple sites and without a central single point of failure. This fits well with segmented OT networks under the Purdue model.

The decisive difference: Xage verifies who is accessing, enforces what is allowed in the process, and records without gaps what actually happened. An authenticated access thus becomes a controlled, traceable action.

OT security with KAEMI

The technology alone is not enough; it also needs to be managed securely. As a managed security service provider focused on Zero Trust and segmentation, we help companies put their OT remote access on a solid footing: from taking inventory of all access paths to introducing a controlled access model to ongoing monitoring, requirements-driven and from a single source.

OT remote access is closely interlinked with network segmentation: those who control access at a granular level and consistently segment their networks prevent a compromised access from becoming a company-wide threat.

How we secure networks according to the Zero Trust principle is shown on our Zero Trust microsegmentation page .

Conclusion: remote access is not an IT topic, it is security-critical

The core of the SANS recommendation is clear: OT remote access must be treated as a security-critical function that demands technical precision. VPN and MFA remain the foundation, but only ICS-aware access control makes the defense effective. Getting started does not require a major transformation: a complete inventory of access paths, a controlled chokepoint via jump host, and an identity-based access model are concrete first steps.