Why self-hosted remote access for manufacturing OT and machine vendors needs its own design
A plant that depends on machine builders and integrators needs a remote access design built around zones and conduits, not around the remote desktop tool. Vendors need to reach PLCs, HMIs and line controllers to diagnose faults and push approved changes, but a standing VPN or a vendor-installed RMM agent gives an outside party a path into the control network that nobody on site can see, scope or switch off quickly. The ISA/IEC 62443 series frames the problem in terms of zones (groups of assets with shared security requirements) and conduits (the controlled communication paths between them). The access path is a conduit, so it has to be placed, authenticated, logged and time-limited like one. Safety matters too: the Machinery Regulation, Regulation (EU) 2023/1230, applies from 14 January 2027 and adds an essential requirement that machinery be protected so that connecting another device or remote device does not lead to a hazardous situation. That makes the vendor path a safety question as well as a security one. For most OT vendor sessions, the short answer is Apache Guacamole deployed as a browser gateway in a DMZ, with the vendor authenticating to the gateway over multi-factor authentication and the gateway opening only the approved protocol session to the target host. Guacamole's documentation describes a clientless design in which the web application handles authentication and guacd connects to the remote desktop server on the user's behalf, so no vendor software needs to live on the controller network. RustDesk can be considered only where its controls and placement are confirmed for your environment: its open-source server (hbbs and hbbr) and its Server Pro audit and access features are useful, but whether they fit your zone model, recording requirements and change process must be verified, not assumed.
Before selecting a platform, the reader should confirm three things with the plant's OT and security teams: which zone each target sits in, which conduits the vendor session may cross, and who approves each session and for how long. Those answers set the gateway placement, the identity model and the recording scope. They also determine whether a vendor session is permitted to touch a safety-related system at all, which is a decision for the plant's safety and engineering owners rather than the remote access project. Ask the machine builder to state in writing which protocols, hosts and maintenance tasks they need, because a broad grant recreates the flat network that segmentation was meant to remove.
Which requirements shape a manufacturing OT remote access design
This table maps each regulation and standard that touches machine vendor access to what it means for the gateway, zone placement, session approval and recording. Read it as a checklist of design inputs: the first column names the requirement, and the other columns show what it changes in the build and what evidence an assessor or regulator will expect.
| Requirement | What it asks for | Design impact on the gateway, zones, approval and recording |
|---|---|---|
| ISA/IEC 62443 asset owner program (ANSI/ISA-62443-2-1-2024) | A security program for the plant owner, covering roles, policies and how third-party access is governed | Vendor access becomes a documented process with named owners, approval steps and periodic review, not an informal exception for the integrator |
| ISA/IEC 62443 risk assessment (ANSI/ISA-62443-3-2-2020) | Zones and conduits identified and risk-assessed during system design | Place the remote access gateway in a DMZ conduit between the business network and the control zone, and document each allowed path |
| ISA/IEC 62443 system requirements and security levels (ISA-62443-3-3-2013) | System-level requirements and target security levels for each zone | Set authentication, session control and audit expectations per zone, so the cell with safety functions receives stricter controls than a utility zone |
| Product supplier lifecycle (ANSI/ISA-62443-4-1-2018) | Secure development practices from the machine builder or component supplier | Ask machine builders whether they follow this lifecycle and how they handle vulnerability fixes that must reach the remote access path |
| Component technical requirements (ANSI/ISA-62443-4-2-2018) | Technical security features expected of industrial components | Confirm which PLCs, HMIs and controllers support the authentication and logging you need, since the gateway cannot add features the device lacks |
| NIST SP 800-82 Rev. 3 (September 2023) | OT security guidance covering ICS, SCADA, DCS, PLCs and physical access systems, weighted toward performance, reliability and safety | Test every remote session path for its effect on cycle times and availability, and require a plant-approved change window before any gateway update |
| NIS2 manufacturing sector (Annex II, NACE Rev. 2 divisions 26 to 30) | Machinery, electrical equipment, motor vehicles and related manufacturing are critical sectors | If in scope, the remote access path is part of the entity's risk management and must be covered by logging and incident handling |
| NIS2 incident reporting clock (Article 23(4)) | Significant incidents reported with an early warning within 24 hours, a notification within 72 hours and a final report within one month | Gateway logs, session records and alerts must be retrievable fast enough to meet these deadlines, so confirm log export and retention before go-live |
| Machinery Regulation remote device requirement (Regulation (EU) 2023/1230, Annex III 1.1.9) | Machinery protected so that connecting another or remote device does not lead to a hazardous situation, applicable from 14 January 2027 | Machine builders need a documented remote connection design, and integrators should require interlocks, operator confirmation and safe-state behavior for any remote intervention |
| Cyber Resilience Act reporting duty (Regulation (EU) 2024/2847, Article 14 and Article 71(2)) | Manufacturers report actively exploited vulnerabilities and severe incidents, applicable since 11 September 2026 | Machine builders must reach their own vulnerability process when a remote path is involved, so agree on who detects, triages and reports issues in the vendor contract |
| Sector-specific evidence needs (where applicable) | Some manufacturers also fall under 21 CFR Part 11 for electronic records, or defense rules such as CMMC | Session approvals, recordings and access logs may need to meet record integrity and signature rules, so confirm applicability with counsel and the auditor |
How zone and conduit thinking places the remote access gateway
The point for an asset owner is simple: the remote access gateway is a conduit, not a new part of the control network. Under the ISA/IEC 62443 series, a zone is a group of assets that share security requirements, and a conduit is the controlled communication path between zones. A vendor session into a machine is therefore a flow that crosses at least one zone boundary, and it has to be placed, filtered and logged as deliberately as any other inter-zone traffic. The exact zone assignment, the number of zones and the security level targeted for each are outputs of your risk assessment under ANSI/ISA-62443-3-2-2020, not choices this page can make for you. Confirm them with your own controls engineering, process safety and plant operations teams before any firewall rule is written.
In a typical layout, the Guacamole web application, guacd and the session recording store sit in a DMZ-level segment, which is a buffer between the enterprise or vendor-facing side and the plant. The connection targets, meaning the PLC engineering workstations, HMIs or machine controllers, sit deeper in the control zone. Guacamole's architecture supports this split: the web application handles the browser session and authentication, and guacd opens the protocol connection to the target on the user's behalf. That means the vendor's browser never needs a route into the control zone, and only guacd needs permission to reach the specific hosts and ports listed in the asset owner's conduit definition. Ask the integrator to document which host, port and protocol each conduit permits, and to show that no other path exists.
The design should rule out any direct path from the vendor network to the control zone. A vendor laptop that can route to a PLC by any other means, such as a site-to-site tunnel, a vendor-installed remote management agent or a shared jump host with open routing, undermines the conduit regardless of how strong the browser login is. Test this during commissioning: from the vendor segment, attempt to reach control-zone addresses directly and confirm that every attempt fails, and confirm that the only accepted path ends at the gateway. Record the results as evidence for the zone and conduit documentation. Also confirm with your safety team whether the Machinery Regulation essential requirement on connected devices changes what the conduit must prevent for the machines in scope.
Which open-source platforms fit OT vendor access and why
Machine builders and integrators need sessions into plant equipment that the plant can approve, limit and record. The two platforms below cover different access patterns, and both only work well when they sit behind a DMZ gateway, a jump host pattern and the plant's existing firewall and change control.
Apache Guacamole for browser access
Guacamole is a clientless gateway that serves VNC, RDP and SSH sessions to any HTML5 browser, so a vendor engineer needs no installed client or permanent VPN. Its web application handles authentication while the guacd daemon loads the protocol plugins, which keeps the exposed component narrow. Check the MFA and SSO extensions you need, the database-backed connection permissions, and the session recording player. Confirm which protocols your HMIs and engineering workstations actually expose.
Jump host pattern for engineering workstations
Engineering workstations and vendor HMI access often should not be reached directly from the vendor's network. A common pattern places a hardened jump host in the DMZ, with the gateway connecting vendors to that host and the host connecting onward to the target. This adds one more point to log, time-limit and disable. Confirm with the plant's OT team which zones may be traversed, and document the conduit rules that allow each hop.
RustDesk for attended and unattended support
RustDesk suits attended or unattended support where its ID and relay servers (hbbs and hbbr) can run inside the plant network or DMZ rather than on a public service. The client is AGPL-3.0 and the RustDesk README carries a misuse disclaimer, so the plant should set its own acceptable use rules. Server Pro adds audit logs, access control and OIDC or LDAP sign-in, with published monthly plan prices of $11.88 for the Individual plan and $23.88 for the Basic plan. Confirm that the plan limits match your device count.
Guacamole does not replace OT controls
A remote desktop gateway does not replace the OT firewall, network segmentation or the change control process. Sessions that reach a PLC or HMI still need to be approved against a change ticket, limited to the planned window and checked against the zone and conduit model under the ISA/IEC 62443 series. Treat the gateway as one enforcement point among several. Ask the vendor and plant to agree in writing which actions are permitted in a session and who reviews the recordings.
How a plant rolls out vendor access in phases
The sequence moves from zone and conduit definition to a single-vendor pilot and then to broader rollout, so each machine builder reaches only the equipment it supports, under approval, with every session recorded and revocable. Each phase closes with a written artifact the plant can review and keep.
Define zones and conduits from the risk assessment
Start from the plant's existing risk assessment and map the machine cells, PLC networks, historians and engineering workstations into zones, then define each conduit that vendor traffic may cross. Work with OT engineering, the plant security lead and the site operations owner so that the boundary reflects how the lines actually run. The closing artifact is an approved zone and conduit diagram listing permitted protocols, source and destination assets, and the owner who accepted the residual risk. Confirm the ISA/IEC 62443 requirements your asset owner program already follows, since they shape how the zones are documented.
Build the gateway in the DMZ
Deploy the browser gateway, typically Apache Guacamole, in a DMZ segment between the corporate network and the control network, with the guacd connectors placed so that only the conduit's approved targets are reachable. Harden the host, restrict inbound ports to the browser entry point, and disable any protocol or feature the conduit does not need. The closing artifact is a build record and a firewall rule set that matches the approved diagram, verified by a test that attempts a connection to an asset outside the conduit and confirms it fails.
Integrate identity and multi-factor authentication
Connect the gateway to the plant's identity provider so that every vendor account is named, federated where possible, and protected by multi-factor authentication. Guacamole supports Active Directory and LDAP, Duo and TOTP, OpenID Connect and SAML extensions, so confirm which of these matches your directory before build. Separate plant staff from vendor identities so that vendor accounts can be disabled without affecting internal users. The closing artifact is a tested login matrix showing each identity type, its factor and its permitted connections.
Set per-vendor permissions and time-limited approval
Create one connection group per machine builder and grant each group only the target machines named in its support agreement. Define the approval path that a plant owner uses to open a session window, including who approves, the reason field, and the time limit that ends the session automatically. Vendors should not hold standing access to the cell. The closing artifact is a permissions register that lists each vendor, its targets, its approver and its maximum window, reviewed by the plant owner before any vendor logs in.
Configure recording and log retention
Turn on session recording for every vendor connection and forward gateway authentication and connection logs to the plant's central logging or SIEM platform. Set retention periods according to the plant's own policy and any customer, contractual or regulatory obligation that applies, and confirm who can read recordings and who can delete them. Recording storage should sit in a location the vendor cannot alter. The closing artifact is a retention schedule and a sample recording that the plant security lead has reviewed and signed off on. Confirm the storage size and retention cost with the implementation partner before committing.
Pilot with one machine builder
Select a single machine builder and one cell, then run real support sessions under the approval, time-limit and recording controls. Observe the vendor's workflow, note any protocol or file transfer needs that the design missed, and adjust permissions without widening the conduit. Test the revocation procedure during the pilot by ending a session early and disabling the vendor account, then confirming that access stops. The closing artifact is a pilot report listing findings, changes made and the revocation test result, approved by OT engineering and the plant owner.
Roll out to remaining vendors and hand over
Add the remaining machine builders and integrators one group at a time, repeating the permissions and approval steps for each and updating the zone and conduit diagram when a new target is added. Train plant staff on approving sessions, reviewing recordings and running the revocation procedure, and document the operating runbook for patching, backups and access reviews. Agree how vendor access is reviewed on a recurring basis. The closing artifact is a handover package containing the approved diagram, permissions register, runbook, and a signed access review record for each vendor.
What auditors and plant safety reviewers ask to see
This table maps each evidence item an assessor or plant safety reviewer typically asks for to the component that produces it and what it should show. Use it to plan logging and document ownership before the first vendor session. DeployOpen prepares this evidence for your assessments but does not issue audit reports or certifications.
| Evidence item | Producing component | What it should show |
|---|---|---|
| Conduit and zone diagram | Architecture documentation maintained by the implementer and plant engineering | Gateway placement in the DMZ, the zones it bridges, allowed conduits to machine networks, and the ports and protocols permitted on each |
| Access approvals with time windows | Approval workflow or ticket record in the plant's ITSM or change system | Who requested access, which machine or cell, who approved it, and the start and end times of each window |
| Per-vendor account records | Guacamole user accounts and connection permissions, or RustDesk Server Pro user and device records | One named account per vendor technician, the connections each account may reach, MFA enrollment status, and last-used dates |
| Session recordings | Guacamole session recording and its player extension, or the equivalent recording store where RustDesk is used | Who connected, when, to which machine, and what was done, stored with restricted access and a defined retention period |
| Gateway audit logs | Guacamole logs forwarded to the SIEM already run by the plant or corporate security team; RustDesk Server Pro audit log where used | Login attempts, failed MFA, session starts and ends, and permission changes, with timestamps that match plant and firewall logs |
| Revocation records at contract end | Account disable or deletion records in the identity provider or gateway, linked to the vendor contract | Date access was removed, who confirmed it, and proof that no active sessions or standing credentials remained |
| Change records for gateway updates | Change tickets and version records for Guacamole, guacd, the host OS and any relay or identity component | Each patch or upgrade with its version, test evidence, approver, and rollback plan, reviewed against the zone design |
How much effort, time and input does a plant need to prepare for this work
What drives the cost and effort of self-hosted remote access for plant equipment?
The main drivers are the number of machines and vendors that need access, the number of OT zones and conduits the gateway must cross, how identity is integrated (directory, MFA and vendor accounts), how long session recordings must be kept, and whether the design needs a formal safety review before go-live. Each driver adds design, configuration and testing work, so a plant with a few machines behind one cell is far lighter than a multi-site estate with several machine builders. Ask any partner to show how each driver changes the written scope and the deliverables.
Which parts of remote access work are one-time and which recur?
One-time work usually covers the zone and conduit design, DMZ gateway build, identity integration, hardening, connection permissions, recording setup and handover. Recurring work covers gateway operations, patching and upgrades of the gateway and its components, monitoring, access reviews for vendor accounts, and storage growth for session recordings. Recording storage grows with the number of sessions and the retention period you set, so ask for the retention assumption in writing. Confirm with your partner whether patching and upgrades sit under a retainer or a separate agreement.
What must the plant supply before implementation can start?
Plants typically need to provide current network diagrams showing OT zones, existing firewalls and any conduits, a list of machines and their protocols, a list of machine builders and integrators who need access with their named individuals, and the outputs of the existing risk assessment or the one you plan to run under ISA/IEC 62443-3-2. You also need the security policy owner, an identity source for vendor accounts, and a change window with the production team. Missing diagrams are the most common cause of rework, so confirm what exists before scoping.
Can our own OT and IT staff run this without an external partner?
Some plants can run parts of it in-house, especially teams already operating Linux, Docker, directory services and firewalls. Work that is harder to staff internally includes building the zone model against ISA/IEC 62443, designing the DMZ placement, testing the gateway against OT change control, and producing evidence in a form auditors can follow. A useful test is whether your team can answer the questions in the risk assessment and operate the gateway without the original builder. Confirm skills and the training you would need before deciding.
How do the Machinery Regulation and NIS2 dates affect planning?
The Machinery Regulation, Regulation (EU) 2023/1230, applies from 14 January 2027 and adds an essential requirement that machinery be protected so that connecting another device or remote device does not lead to a hazardous situation. Plants that buy or modify machines for the EU market should plan remote connections to meet that requirement before that date. NIS2 Annex II lists manufacturing as a critical sector, and in-scope entities must give an early warning within 24 hours, a notification within 72 hours and a final report within one month of a significant incident. Ask counsel which obligations apply to your entity and when.
How does a fixed-scope quote for plant remote access get built?
A DeployOpen engagement is normally fixed-scope, so the written scope, deliverables and timeline are agreed before work starts. The scope usually lists the machines and zones covered, the identity integration, the recording and retention design, the hardening baseline, documentation, handover and any testing. Ask the partner to tie each deliverable to a named owner on your side, and to state what is excluded, such as changes to PLCs, machine software or safety functions. DeployOpen does not publish a price list, so the quote follows from that written scope.
What does RustDesk Server Pro cost, if we use it alongside the gateway?
RustDesk's pricing page lists self-hosted Server Pro plans billed annually: Individual at $11.88 per month for 1 login user and 20 managed devices, and Basic at $23.88 per month for 10 login users and 100 managed devices, with unlimited concurrent connections. The page states Pro is not a SaaS subscription. Customized plans add users at $1.20 and devices at $0.12 per month on top of the Basic base price. Licenses do not auto-renew and there is no monthly billing, so budget for each annual renewal. Confirm current terms on the vendor page before quoting.
What to ask an implementation partner before approving OT remote access
Start with the zone and conduit design method. Ask the partner which method they use to derive zones and conduits from the asset inventory, how they assign security levels to each zone, and where that work is recorded. The reference for this is the ISA/IEC 62443 series, particularly ANSI/ISA-62443-3-2-2020 for risk assessment during system design and ISA-62443-3-3-2013 for system security requirements and security levels. Ask who signs off the zone model on the plant side. If the answer is only a network diagram, the remote access gateway has no defined place in the design yet. Next, ask how the partner works with your safety and controls engineers. Remote access into a machine is a change that can affect safe operation, and the Machinery Regulation, Regulation (EU) 2023/1230, applies from 14 January 2027 with an essential requirement that connecting another or remote device must not lead to a hazardous situation. Ask who approves each vendor session type, which machine states block remote write access, and how the partner documents that a session cannot alter safety functions. Ask for the change record that links the gateway to the machine's risk assessment.
Ask how DMZ placement and firewall rules are documented. The partner should provide the rule set for the gateway, every conduit it creates, and the reason for each allowed flow, with the rules exported as configuration you can review. Confirm that the design avoids a permanent path from the vendor network into the control zone and that the gateway is the only permitted entry point. Ask how changes to these rules are reviewed and who can make them. Ask how MFA and approval workflows are tested. Request the test plan, including what happens when the approver is unavailable, when a vendor account is disabled, and when a session outlives its approved window. Ask how the partner proves that recording cannot be disabled by the vendor, and how recordings are stored and protected: where they live, who can read them, how long they are kept, and whether they are encrypted at rest. Confirm the retention period with your own legal and records owners, since no retention figure is supplied for this use case. Finally, ask how vendor revocation is proven, how the partner supports incident response, and what they need to support NIS2 reporting. Revocation should be demonstrated, not described: ask for a test where an account is removed and a live session is terminated. For incidents, ask who receives the alert, how the logs reach your security monitoring, and how the partner supports the 24-hour early warning, 72-hour notification and one-month final report that Article 23 of Directive (EU) 2022/2555 requires for in-scope entities. Ask for a handover package that includes runbooks, administrator credentials held by you, and a named owner for each control.
How DeployOpen scopes and supports OT vendor access on self-hosted platforms
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source remote access platforms inside your own infrastructure, including the browser gateway, its identity integration, session recording storage and the monitoring around them. For OT vendor access, the scope usually starts with a written list of the machines, vendors and protocols in question, the network segments where the gateway will sit, and the approval and time-limit rules each vendor must follow. Because the gateway is the single point where machine builders and integrators reach plant equipment, we also run security testing against the gateway and its integrations before it carries live vendor sessions. Engagements are fixed-scope: deliverables, responsibilities and timelines are agreed in writing before work begins, so your team can see exactly what is in and out.
Plant equipment is never changed on our side without the plant's own OT, controls and safety teams agreeing to it. Those teams own the process, the safety functions and the change approval for machinery, so DeployOpen works through them for zone and conduit decisions, maintenance windows and any change to a controller-facing path. Confirm early who signs off each change and who can stop a vendor session in progress. For compliance, DeployOpen prepares systems, controls and evidence, such as access logs, approval records, recording configurations and network diagrams, for assessments performed by your auditors or certification bodies. DeployOpen does not issue audit reports, attestations or certifications.
Ongoing support, upgrades, periodic retesting and handover of operating procedures are available as a retainer, which suits plants that add vendors or equipment over time. Ask any implementation partner, including DeployOpen, to state in the scope which tasks are one-time and which recur, who pays for hardware and licenses, and how emergency vendor access is handled outside business hours. Do not treat a partner's involvement as partner status with any vendor or standards body unless that status is documented separately in writing.
