Manufacturers Secure Remote Access

Secure remote access has become an operational necessity for modern manufacturing. Vendors need to troubleshoot PLCs without travelling across the country. Integrators update SCADA systems remotely. Internal engineers monitor production lines from central IT hubs. Multi-site operations demand visibility and responsiveness.

Digital transformation initiatives, predictive maintenance programmes, centralised monitoring, multi-site optimisation, and cloud-connected systems all rely on remote connectivity. All of this keeps production moving and adds efficiency. But in many ICS/OT environments, connectivity has expanded faster than the security controls governing it. Here’s how manufacturers can better secure remote access.

Why Securing Remote Access in OT Is Fundamentally Different from IT

Remote access in an IT environment is usually governed by established identity controls, centralised monitoring, and well-defined ownership. In OT environments, the reality is often more complex.

Industrial systems are frequently supported by a wide ecosystem of third-party and OEM vendors. It’s not unusual for a mid-sized manufacturer to work with dozens (sometimes hundreds) of external contractors responsible for PLC programming, robotics maintenance, SCADA configuration, or specialised machinery updates.

Each of those relationships may require remote connectivity.

Over time, this creates a landscape of vendor-specific access pathways, including things like VPN tunnels, remote desktop tools, firewall exceptions, and service accounts tied to particular machines or production lines. These connections are often legitimate and operationally necessary. The challenge lies in visibility and governance.

Remote sessions may not be logged centrally. Access may remain persistent long after a maintenance window has closed. Credentials may be shared across teams for convenience. The scale alone makes effective management difficult.

The human factor adds another layer of complexity. OT environments are typically operated by engineers and technicians whose primary focus is safety, uptime, and process optimisation rather than cybersecurity hardening. At the same time, there is a well-documented shortage of professionals with specialised OT security expertise. This creates a structural gap between connectivity and control.

Threat actors understand this dynamic. A recent industry report found that nearly half of documented ICS/OT incidents began with unauthorised external access, frequently linked to third-party remote maintenance connections. In other words, the entry point was remote access that had not been sufficiently secured.

Why Existing Remote Access Approaches Are Falling Short

Many industrial companies believe they have “secured” remote access because they have implemented VPNs or jump servers. In practice, these approaches often introduce new risks and operational inefficiencies.

VPNs, widely used across OT environments, were originally designed to extend trusted networks. They tend not to enforce granular, risk-aware access control in complex industrial architectures. From a security perspective, VPNs create several challenges.

First, they frequently establish direct connectivity into lower levels of the OT environment. This can undermine the intent of the popular Purdue Model, which is designed to enforce separation between enterprise IT systems and critical control layers. By tunnelling users directly into production zones, VPN configurations may bypass segmentation boundaries that were meant to provide layered defence.

Second, VPNs expand the attack surface. Once authenticated, users often gain broad network-level access rather than tightly scoped, asset-specific access. If a vendor’s endpoint device is compromised (or if credentials are stolen in some sort of social engineering attack) the attacker inherits that connectivity.

Third, scalability becomes an issue. As more vendors, integrators, and remote engineers require access, organisations often add infrastructure to support growing VPN demand. This increases operational overhead without necessarily improving control or visibility.

Jump servers are sometimes introduced to mitigate these risks. While they can provide an intermediary layer, they are frequently cumbersome to manage, difficult to scale across multiple sites, and reliant on manual processes. In many environments, session logging is inconsistent, access is not time-bound, and shared accounts remain common.

So, what’s the answer?

How to Strengthen Remote Access Security in ICS/OT Environments

Perhaps the most important point to remember is that no single magic bullet exists for this problem (despite what the marketing materials of some companies might say!). Effective protection requires layered improvements across distinct areas of this complicated problem.

1. Enforce Strong Identity and Privileged Access Controls

At a minimum, all remote access, including vendor connections, should be protected by multi-factor authentication (MFA). This applies not only to VPN access, but to any remote desktop, cloud gateway, or remote maintenance tool.

However, MFA alone is insufficient if access remains broad.

Privileged Access Management (PAM) solutions can significantly improve control by:

• Eliminating shared credentials
• Enforcing role-based access
• Providing session logging and recording
• Enabling time-bound or just-in-time access
• Centralising control of privileged accounts

For environments with multiple OEM vendors, PAM reduces the risk of persistent, untracked access pathways.

Combining PAM and MFA with a controlled jump host or secure access gateway can further limit direct connectivity into production zones. But the design must ensure access is tightly scoped to specific assets, not entire network segments.

2. Align Segmentation with Both Purdue and Zero Trust Principles

The Purdue Model remains foundational in industrial security. Its purpose is to enforce structured separation between enterprise systems and critical control layers. However, segmentation alone is no longer enough.

Zero Trust principles augment, rather than replace, Purdue. While Purdue defines hierarchical separation, Zero Trust enforces identity-based verification and least privilege within and across those layers. The idea is to never allow trust by default on the network.

In practice, this means:

• No implicit trust between zones
• Continuous verification of users and devices
• Access granted only to specific assets, not entire networks
• Strict control over east-west movement within OT environments

Used together, segmentation and Zero Trust reduce blast radius even if credentials are compromised.

3. Coordination and Visibility

Remote sessions should never be invisible.

Organisations should ensure:

• Centralised logging of all remote access activity
• Monitoring of anomalous behaviour across IT and OT boundaries
• Alerting for unusual vendor access patterns
• Asset-level visibility within OT segments

Given that many ICS/OT incidents begin with unauthorised external access, visibility is often the difference between containment and escalation. For geographically dispersed manufacturing environments, this requires coordination between IT security teams and OT operators.

IT teams often manage VPN infrastructure, identity systems, and logging platforms. OT teams manage production networks, PLCs, and vendor relationships. Remote access frequently sits in between, owned by neither fully.

Practical steps include:

• Establishing joint ownership of remote access governance: clearly define who approves vendor access, who reviews logs, and who is accountable for revocation.
• Creating a unified remote access inventory: a shared, regularly reviewed register of all remote connections, vendor accounts, and maintenance pathways.
• Defining standard access patterns: no ad hoc firewall rules or informal vendor arrangements. Every connection should follow a documented model.
• Running joint risk reviews quarterly: IT and OT leaders reviewing remote access exposure together, not in isolation.

4. Secure the Remote Endpoint

Don’t overlook the importance of security on the endpoint devices that users connect with remotely to OT networks. Third-party technicians often connect from devices outside your control. Those endpoints may operate on different patch cycles, use varying security tools, or connect from networks you cannot validate. If one of those devices is compromised, malware can piggyback on legitimate credentials and remote sessions.

Manufacturers should therefore treat endpoint security as a condition of access.

Practical measures include:

• Requiring vendors to meet defined security standards before remote access is granted (e.g., up-to-date OS, endpoint protection, disk encryption).
• Using secure access gateways or proxy architectures that prevent direct network-level connectivity.
• Enforcing application-level access instead of full network access.
• Blocking clipboard transfer, file transfer, and local drive mapping where unnecessary.
• Recording and monitoring remote sessions for anomalous behaviour.

OT Remote Access Security is About Strategy

It is tempting to search for a single “secure remote access solution” that fixes everything. Think instead about making deliberate architectural and governance decisions. Ask things like:

Which connections are truly necessary?

Which vendors require access to which assets?

How is that access authenticated, segmented, monitored, and revoked?

Who owns the process?

Manufacturers that approach remote access strategically by aligning identity controls, segmentation, endpoint conditions, and monitoring are far better positioned than those relying on incremental fixes layered onto legacy connectivity models.

The goal is not to structure remote access in a way that reflects today’s threat landscape, regulatory expectations, and operational realities.

At DIESEC, we work with German manufacturers to assess existing remote access exposure, design defensible connectivity architectures, and implement controls that align with both production continuity and compliance requirements.
Contact us to learn more.