Cyberattacks on operational technology systems increased 87% in 2024 (Dragos 2024), with endpoint access emerging as THE top attack vector for OT and industrial control systems (ICS).
This means the same connections vital to maintaining your critical systems, whether a vendor connecting remotely via VPN or an employee logging into a local workstation, represent a potential entry point into your environment.
And unlike IT, where an attack typically results in data theft or held hostage, OT environments present unique challenges that pose real world risks.
What Makes OT Endpoint Access So Risky?
A compromised OT endpoint exposes physical consequences: unsafe working conditions, disrupted production lines, poisoned water supplies, even regional blackouts. So, it’s less about stolen records and more about keeping the lights on and people safe. Each endpoint is a critical vulnerability demanding immediate attention.
Here’s why OT environments are especially vulnerable to endpoint threats.
The Remote Endpoint Challenge
According to Dragos, over 50% of initial access in OT ransomware campaigns comes from third-party vendor tools like VPNs and remote desktop protocol (RDP). That means the very tools enabling external vendor support are now one of the biggest threats to uptime, safety, and compliance.
These are typically users you don’t employ, connecting from devices you don’t control, into environments that demand 99.999% uptime.
Untrusted Remote Devices: Vendor laptops aren’t yours to secure. They may carry malware, lack endpoint protection, and have connected to multiple unknown networks that week.
Dormant Remote Access: When a technician leaves their company, how fast is their access revoked? Sometimes it’s days or even weeks before your team is notified.
Lateral Movement Exposure: Remote connections like VPNs and RDP often gives broad, lateral network access. If compromised, attackers can move from the HMI to the historian to engineering workstations undetected.
While these remote endpoint threats get significant attention, many teams over-invest in external controls leaving a critical vulnerability much closer to home.
The Local Endpoint Blind Spot
Remote access risks dominate security conversations. And for good reason. But here’s what’s often overlooked: local access (employees, contractors, and technicians connecting directly to systems on-site) is still a major threat vector, and one of the least protected.
So while teams are hardening perimeter connections and managing remote vendors through VPN replacements and zero trust models, these local endpoint risks remain.
Shared Local Credentials: Teams often reuse generic logins for local workstations. “Everyone knows the password to ENG-01.” If something goes wrong, there’s no way to track who did what and when they did.
Unmonitored Local Sessions: In environments where every remote login is subject to MFA, session recording, and approval workflows – local access is often still running on muscle memory and trust.
Assumed Physical Security: The legacy model assumes that if someone has badge access and knows the workstation password, that’s considered good enough. But that trust model never included traceability, MFA, or per-user accountability.
The Common Thread: Systemic OT Access Gaps
Remote and local access may feel like separate challenges. But dig deeper and you’ll find the same set of systemic flaws undermining both:
Identity Blindness – Shared logins, default credentials, and a lack of per-user traceability mean organizations can’t answer a basic question: “Who made that change?”
Credential Sprawl – Old contractor accounts, dormant VPN users, and permanent passwords create standing backdoors attackers love to find.
Audit Gaps – Most OT sessions (remote or local) aren’t monitored or recorded. That means you can’t catch misuse in real time or explain what happened after the fact. NERC CIP, TSA Security Directives, and EU NIS2 all require documented access controls and audit trails. Shared credentials and unmonitored sessions create automatic compliance failures during audits.
Inconsistent Controls – Some vendor access goes through layered authentication. Other on-site engineers log in with a badge and shared password. That kind of inconsistency is what adversaries exploit.
Whether someone logs in from across the world or walks up to a workstation on the plant floor the common issues persist: unverified identities, unmonitored sessions, and stale credentials continuing to create cracks in your defenses.
How Did We Get Here?
Given these clear vulnerabilities, it’s tempting to ask, “Why hasn’t this been solved already?” The answer, like most OT security issues, has layers.
To understand why these inconsistencies persist, it’s important to understand how IT and OT evolved differently.
Traditional IT Tools Don’t Translate to the OT Floor
Most IT endpoint security tools rely on installing agents to collect data and enforce policy. Many OT devices can’t support agents. Some run legacy or embedded operating systems. Others are simply off limits because of vendor constraints or operational risk. Even if agent deployment were possible, there’s usually no window for it when uptime is on the line.
And the problem doesn’t stop at agents. Identity governance platforms, user behavior analytics systems, and even your basic SSO weren’t built for legacy controllers running ladder logic.
- You’re not deploying CrowdStrike to a Siemens S7-300
- You’re not federating access to an HMI running Windows XP Embedded
Plant-floor devices weren’t designed with enterprise IAM system integration in mind. They don’t speak LDAP or SAML. Some don’t even support encrypted protocols.
OT teams are frequently forced to operate outside the enterprise access tools the rest of the business relies on. This causes visibility, and control, to drop off sharply at the OT boundary.
The fundamental IT/OT divide set the stage for two completely different approaches to access control as connectivity needs grew.
Different Evolution Paths for Remote vs. Local Access
When IT/OT convergence began, the technology gap forced different evolution paths for remote and local access.
Remote Access Evolution: Organizations spent years building robust remote access controls, especially as COVID accelerated the need for offsite connectivity.
Local Access Stagnation: The legacy model for local access hasn’t kept pace. For years, the implicit model was “once you’re inside the facility, you’re inside the trust zone”. Security at the perimeter. Trust inside the walls.
But business demands weren’t going to wait for OT access models to catch up.
OT Is Now Connected…and Exposed
Today’s reality is that OT connectivity is no longer optional. With the rapid push for digital transformation, cloud-integrated telemetry, and remote diagnostics, the boundary between local and remote access has blurred.
Field devices are pushing telemetry to cloud dashboards. Remote diagnostics are being performed over LTE failovers. Engineering laptops bounce between internal and external networks.
So, while the architecture has evolved, the access model hasn’t. Both local and remote access are still treated with inconsistent security standards even though they’re increasingly wired into systems and services that sit well beyond the perimeter.
This has left many OT and ICS professionals stuck with a patchwork of legacy tools for today’s threat landscape.
The Legacy Tools Creating Modern Problems
These tools tell the story of our predicament.
VPNs, jump servers, RDP, and shared local workstations made sense when critical systems were siloed. But as more organizations push convergence, we see an increase in attackers targeting critical infrastructure. And they’re doing so primarily through insecure endpoints and using tools meant to manage remote and local access.
The Remote Access Problem
In breach after breach, attackers are exploiting weak remote access paths: RDP tunneling, credential reuse, and outdated VPN setups. These legacy tools are present in nearly every OT-targeted incident in the past two years. CISA has even issued emergency directives warning federal agencies to abandon vulnerable VPN systems.
VPNs were built for encrypted traffic, not secure control.
They offer broad access with little visibility. And when they fail, they fail hard like in the Colonial Pipeline incident traced to an unused, unmonitored VPN profile.
The Local Access Gap
Here’s how endpoint access is typically handled in many organizations:
| Capability | Remote Access | Local Access |
|---|---|---|
| Identity verification | SSO with SAML or AD | Shared workstation credentials |
| MFA enforcement | TOTP, Push, Smart Card | Rare to nonexistent |
| Session recording | Screen, commands, timestamped | None |
| Approval workflow | Integrated with ITSM (e.g., ServiceNow) | Manual or informal |
| Logging | Forwarded to SIEM (e.g., Splunk, Elastic) | No forwarding or centralized logs |
We’ve spent years engineering discipline into remote access with SSO, MFA, session recording, approvals, and detailed logging, while local access is still operating on legacy assumptions.
The typical local access setup still relies on shared workstations, generic credentials, and little to no session visibility. No MFA. No logging. No accountability.
The Stakes Are the Same, So the Standards Should be Too
These differences mean a vendor connecting remotely will face more authentication steps than a technician walking up to a workstation inside the facility.
But attackers don’t care whether the connection is remote or local. They don’t care if the device is corporate-issued or personal. They care about access and what they can do once they’re inside. To them, both are doors to the same pot of gold at the end of the rainbow.
Without consistent, identity-based controls across both access types, your defenses are fragmented. You lose visibility. You lose accountability. And you lose defensibility along with the ability to prove to auditors, regulators, or even your own team that your access model stands up to scrutiny.
The consequences of production downtime, safety risks, or regulatory fallout are the same no matter how access is gained.
In manufacturing, one compromised endpoint session can bring down an entire line, whether that’s an OEM connecting remotely or an engineer connecting locally.
Oil & gas, rely on satellite-connected remote sites using fragile VPN tunnels, while local access points largely remain unmonitored.
Utility cyberattacks are up 70% year-over-year, and both third-party access and internal endpoint connections are still essential to maintaining grid infrastructure.
That’s why remote and local access can’t be treated with two different sets of rules. If both represent an equal endpoint risk, both deserve the same level of control.
You can start by eliminating the inconsistent, outdated access assumptions still baked into many OT environments.
How to Eliminate Endpoint OT Access Risk (Without Breaking Ops)
Whether someone connects from across the world or across the room, the same secure-by-design approach should apply. Every session, remote or local, should be governed by identity, limited by purpose, and recorded for accountability.
Here’s what a secure-by-design endpoint access model looks like:
Uses Clientless, Browser-Based Access: No installs or config changes. Just log in. This works for both remote third-party access and local engineering workstations.
Integrates with Authentication Stack: Use your IdP (SAML, OIDC) to enforce identity for all connections.
Provides Granular Access Controls: Grant access only to the system, protocol, and time window needed regardless of connection location.
Utilizes Just-in-Time Approvals: Eliminate standing access for both remote and local connections. Require approvals.
Retains Full Session Recording: Video-level auditability for compliance and forensics across all endpoint types.
Forces Individual Identity: Implement individual accounts with role-based permissions. For example: John.Smith.Maint accesses only maintenance HMIs, while Sarah.Jones.Config can modify PLC parameters, but only during scheduled maintenance windows.
The goal? Stop asking “Can we trust them?” and start asking “What are they allowed to do?”
These are the access controls every environment needs in place to eliminate endpoint risk without introducing operational drag.
Your Minimum Access Requirements Checklist
If you’re managing OT access, make sure your secure access solution provides these foundational elements:
☐ No direct network access – Ensure that all endpoints never connect directly to critical systems
☐ Session-level controls – Maintain full audit trails and video recordings for accountability across all access types (required for NERC CIP-005, TSA SD 1582-21, and SOX compliance in industrial settings)
☐ Zero trust architecture – Authenticate based on verified individual identity, not IP, location, or physical presence
☐ Enforced multi-factor authentication (MFA) – Non-negotiable for all users, not optional
☐ Asset isolation – Keep all endpoint devices completely separate from core OT systems
☐ Unified access model – Apply consistent security policies whether access is remote or local
☐ Rapid deployment – If it takes weeks to implement, it won’t get used
This should become your baseline, minimum access requirements. Keep in mind, these aren’t standalone controls but if you can’t check all the boxes, you’re exposed and unprepared.
Secure Access Is the New Foundation
The secure-by-design model works when it’s enforceable consistently, across every user and session. But secure endpoint access is just one layer of your defense.
Your comprehensive endpoint access strategy should support:
- OT visibility platforms
- Asset management systems
- SIEM/logging infrastructure
- Your existing identity providers
- Both remote and local access requirements
Defense-in-depth works best when your tools integrate to improve security across all connection types without adding complexity.
Final Thoughts
Your vendors and employees keep your critical systems running. But choosing between security and uptime is a false choice that legacy tools force on you.
The reality is every day you operate with uncontrolled endpoint access you’re one compromised session away from potential production downtime, safety incidents, or regulatory violations. Whether that compromise comes from a vendor laptop in another time zone or a shared workstation on your plant floor.
The same amount of time you’d spend in a typical vendor meeting (30 minutes) is enough to deploy secure remote access controls that would eliminate your biggest endpoint vulnerabilities.
Want to see how this works in practice? Let’s talk about how Xona can help you eliminate endpoint risk without operational friction.
Published September 2, 2025.