An OT remote access deployment should let an equipment vendor diagnose a fault without leaving a permanent, unaccountable path into the factory. This guide follows one maintenance request from approval through time-limited access, a DMZ broker, work records, disconnection, and equipment recovery. It then turns those steps into RFP requirements and FAT/SAT acceptance tests. For the broader security program, see our OT security procurement guide for Thai factories.
Define the permitted work before choosing a product
Separate reading status and collecting logs from changing parameters, downloading PLC logic, updating firmware, and testing outputs. Each has a different effect on production and safety. The request should identify the asset, person, local escort, permitted actions, prohibited actions, time window, and method of checking the result. Giving a vendor reachability to an entire subnet because a single machine needs support can expose unrelated HMIs and lines.
Reconcile the asset register and actual network diagram first. Record PLCs, HMIs, engineering workstations, industrial PCs, gateways and switches, including support status, IP addresses, communication partners, and backup locations. Inspect vendor-installed routers, cellular modems, and wireless bridges. The joint Secure connectivity principles for OT, published in January 2026, calls for a documented business case and access that is mediated, monitored, and controlled. It is design guidance, not a Thai manufacturing law.
A vendor support case in a Thai factory
Local technicians can perform first-line diagnosis while a machine maker in another country reads alarms and logs. Remote diagnosis can be authorised separately from program changes. Name the request channel and backup approver for nights and time-zone differences; an emergency should not become a standing exception. Even an urgent ticket can record who approved access, to which machine, until when, and who checked the result.
Legacy Windows systems and proprietary protocols may still be needed to support existing equipment. Avoid exposing them directly to the internet. A maintained boundary gateway helps, but does not replace identity management, MFA, destination restrictions, monitoring, updates, and backups. NIST SP 800-82 Rev. 3 is the final OT security guide as of October 2026 and treats performance, reliability, and safety as part of security design. Revision 4 remains an initial public draft; it is not the final replacement.
The operating sequence: approve, connect, broker, record, close
Use five explicit stages. First, a vendor submits a work ticket and the equipment owner approves the production impact and planned changes. Second, an administrator enables only the named individual, endpoint, target asset, rights, and time window. Third, the vendor authenticates with MFA and reaches the allowed equipment through an OT DMZ broker. Fourth, capture start and end times, target, actions, transferred files, and approval number; a local engineer checks the change. Fifth, end the session, expire the entitlement, check machine operation, and verify that the access path is closed. Assign an owner and evidence to each stage so the procedure remains auditable if the access product changes.
The minimum ticket fields are ticket ID, asset ID, symptom, reason, named technician and employer, scheduled start and end, allowed actions, file transfer, rollback method, local escort, and approver. Add shutdown and restart conditions when the machine cannot be changed in operation. Approval is for this job, not perpetual access for the supplier. Design machine-to-machine monitoring flows separately from interactive maintenance sessions.
Limit reachability through a DMZ and jump host
Draw the boundaries: an external authentication gateway, a broker in the OT DMZ, and the specific asset in its production segment. Enable the path only when needed. Restrict traffic beyond the DMZ to the authorised asset and services. Verify with routing, firewall, and jump-host settings that the vendor cannot move to another line. Prefer a brokered screen or tool session that does not disclose machine administrator credentials to the vendor laptop.
The 2026 joint OT connectivity guidance recommends just-in-time connectivity, brokered vendor connections through a secure DMZ gateway, and centralised access paths. It describes a preference for connections initiated outbound from OT to avoid inbound exposure. An implementation still needs to assess the broker’s cloud dependency, traffic destination, latency, and failure behaviour. A cloud outage must not stop the machine’s core control function.
A VPN protects a transport channel; it does not automatically restrict what the user can reach after authentication. A DMZ with a shared administrator account and broad access likewise fails the purpose. CISA’s Internet Exposure Reduction Guidance recommends finding exposed assets, removing unnecessary exposure, and protecting what remains, including jump hosts and MFA. Use those checks before commissioning and during routine reviews.
Bind personal identity, MFA, time, and rights to the ticket
A supplier-wide shared account cannot distinguish a departed employee from the current technician. Issue named identities, assign a vendor account owner, and revoke access after staffing or contract changes. Apply MFA at the entry point. If the platform permits, check endpoint posture or approved source networks as additional conditions. Separate “read logs on machine A” from “change settings on machine A.” If a legacy tool cannot provide fine-grained authorisation, compensate with local supervision and a separate change approval.
Record the beginning and end of the window and expire rights automatically. Label both ICT and the vendor’s time zone; a “17:00” window is ambiguous across borders. Extensions need a reason, a new end time, and an approver. If a repair runs long, a second work window can make local production review easier than a silent extension.
Treat remote control and file import as separate permissions
Screen access does not imply permission to upload firmware, PLC programs, recipes, or configuration files. Disable transfer by default. When required, record the source, file name, hash, version, ticket, and destination. Where practical, stage the file in a checked area in the DMZ and take a pre-change backup. Ask a supplier whose support tool has its own update function to disclose its communications path in the RFP.
Distinguish observation, parameter changes, program writing, and restart in the work record. Session recording helps, but link it with the ticket, gateway log, file inventory, and device change history. Some industrial protocols cannot be meaningfully recorded as a screen, so state which layer has evidence and where visibility is missing. Logs may include recipes or personal information. Access, storage, retention, and deletion must follow the factory’s policy and contract rather than an invented universal retention period.
Keep physical safety decisions at the site
A remote technician cannot reliably see who is next to a machine, whether a workpiece is jammed, or whether it is safe to release an emergency stop. A local equipment owner controls shutdown, exclusion zones, work start, and restart for program changes and movement tests. Remote access must not bypass interlocks or lockout and tagout procedures. Separate diagnosis that can be performed remotely from actions that require a person at the machine.
Test the communication channel between vendor and local escort. Define a stop-work condition for loss of voice contact, a change of escort, or unstable connectivity. Automatic session expiry is useful, but the effect of a connection dropping during a write also needs FAT testing. Stopping work and restoring the machine are different procedures: closing a VPN does not prove that the controller configuration, alarms, or product quality are sound.
Define recovery before work begins
At the end, the vendor reports completed actions and open issues. A local engineer compares pre- and post-change configuration or program versions, restarts the asset in stages, and checks alarms, quality, and upstream communication. The rollback decision and owner should be agreed in advance. A backup file is not sufficient evidence of recoverability unless its device version, restore rights, and tested procedure are known. Save an approved change as the new baseline.
On the access side, check session closure, entitlement expiry, residual jump-host processes, staged files, and firewall rules. A reusable identity may remain, but standing access should not. Review the following day’s logs for attempts outside the window or from unregistered endpoints. The runbook should name who can immediately disconnect access during a suspected incident.
Industrial remote access RFP: requirements that can be tested
“A secure remote maintenance solution” is too broad to compare. Use a response table with requirement ID, target asset and reason, mandatory or optional status, proposed method, compliant or conditional or noncompliant response, evidence, FAT test ID, and SAT test ID. Provide the existing network diagram, number of vendors, concurrency needs, maintenance hours, and required behaviour when a link fails under confidentiality terms.
Identity requirements include named users, MFA, revocation, supplier account review, and emergency approval. Authorisation requirements include asset-, role-, and time-based access; destination and port limits; and file-transfer control. Network requirements include the external entry, DMZ, jump host, traffic direction, DNS and cloud dependencies, encryption, and update route. Audit requirements include successful and failed login logs, activity evidence, clock synchronisation, tamper protection, and export format. Request actual communication rules and role lists, not only a high-level architecture drawing.
Contract requirements cover gateway patching, vulnerability notification, support life, migration to replacement devices, incident cooperation, configuration ownership, and data processing location. If a proprietary cloud broker is proposed, ask how the machine runs when the service is unavailable and how access can be removed when support ends. CISA’s ICS Recommended Practices includes a publication specifically on configuring and managing remote access for industrial control systems. Translate its recommendations into locally testable requirements; do not treat the publication as a compulsory Thai regulation.
Compare the cost of building the DMZ, connectivity, on-site tests, log storage, identity administration, updates, vendor training, and local incident response as well as licences. Clarify licensed asset counts and concurrent users. A low purchase price may omit recording or Thai site support. Conversely, a read-only diagnostic machine and a critical line where several suppliers write programs may need different depths of control. Pilot on a representative asset and assess approval time, local workload, failed sessions, and log searchability before expanding.
FAT: prove denial and expiry, not just successful connection
At the supplier’s test facility, exercise the normal chain: approved ticket, named identity plus MFA, permitted time, device, action, logging, and closure. Then attempt access without approval, before and after the window, to another asset or port, with a disabled identity or failed MFA, beyond the concurrency limit, and with forbidden file transfer. Also test loss of the log destination. Compare broker, firewall, and device records rather than relying on the product’s own success screen.
For each test, save its ID, initial configuration, action, expected result, observed result, log location, assessor, correction, and retest. Confirm time synchronisation and rejection of a reused session token after closure. Decide in advance whether loss of audit logging prevents new privileged sessions. FAT is evidence that the promised boundary works, not simply a product demonstration.
SAT: test the installed Thai factory environment
SAT uses the real site connection, firewall, DNS, clocks, power, production segment, supplier source, and local staff. A copied FAT configuration can still leave an old support path or different route at the factory. The network owner verifies the rules and proves that unrelated lines cannot be reached. The equipment owner verifies physical safety. Include real international latency and link loss, and confirm that the control process continues safely when the maintenance connection drops.
Run the approval, emergency contact, alternate approver, Thai and English handover, expiry, completion report, and backup restore with the people who will actually operate them. Remove temporary test accounts and open ports before sign-off. Observe the first real maintenance job closely and feed exceptions into change management. Dangerous failure tests belong in a simulator or planned shutdown, not an unsafe trial on a live line.
Acceptance criteria might say: access to any other machine is denied and logged with identity and time; the ticket entitlement cannot be reused after expiry; the control function continues during remote-link loss; reconnection requires fresh authentication; and pre- and post-change program versions and backups are identifiable. The site must set values such as log retention, connection wait time, and revocation delay from its own operational requirements. “High security” and “complete audit” cannot be accepted without observable tests.
Six common failures and how to correct them
The first is a permanently connected router for each vendor. The plant loses track of all entry points and old accounts remain. Inventory the physical paths, shut down unnecessary ones, and migrate the remainder to the approved DMZ process. The second is a supplier-wide shared account. Replace it with named users and a revocation process tied to staff and contract changes. The third is assuming that a VPN automatically makes the connection safe. Test whether an authenticated vendor can reach an unrelated line; if so, narrow the rules and prove denial at acceptance.
The fourth is collecting logs that cannot be linked to the asset, ticket, and program change. Use the ticket ID as a common reference and practise finding the evidence. The fifth is closing the connection without checking the machine. A local owner must confirm settings, alarms, operation, and product quality before closing the work order. The sixth is making the cloud broker or remote link essential to control. Design maintenance as a separate path and inject a link failure during testing. For the wider availability architecture, see our industrial network redundancy guide.
Acceptance evidence and limits of generic numbers
Agree evidence before testing: configuration exports, network diagrams, actual allow rules, request and approval tickets, gateway and device logs, screen records when useful, backups with version identifiers, and local sign-off. Separate “mandatory pass,” “conditional pass with a correction deadline,” and “hold for retest.” Record the owner of any temporary operating arrangement. The supplier’s assertion alone cannot establish that the factory will operate the process correctly.
Set numeric thresholds at the plant: retention time, connection wait, session revocation delay, and tolerated interruption depend on production and existing policies. Do not lift a universal number or an unsupported efficiency percentage from a generic article. When identities, gateways, routes, or vendors change, repeat the acceptance tests affected by that change. The contract should identify who pays for and performs those tests.
Legacy exceptions, ownership, and ongoing review
Older maintenance tools may require an unsupported OS or lack exportable diffs. That does not justify unrestricted internet reachability. Named authentication and time limits at a modern boundary, a dedicated jump host, destination restrictions, local supervision, and backups can often be implemented without modifying the controller. Record the constraint, compensating controls, residual-risk approver, review date, and replacement plan. Tie retirement to a concrete HMI refresh, support contract, or network upgrade so the exception does not become the standard.
The equipment team owns safe operation and change scope. IT/OT network staff own gateways, identity integration, firewall rules, log transfer, and updates. The vendor provides named technicians and change reports. Quality joins when product judgement may change. Where several vendors service one line, define which controller each can change and who leads first-line incident diagnosis. Give each role an alternate for absences and night shifts.
After SAT, review accounts against current contracts, remove unused rights, compare allow rules with actual routes, look for unregistered cellular equipment, and sample tickets against sessions. Track boundary-device vulnerabilities and support life. Re-run the tests affected by configuration changes. Practise stopping a suspicious vendor session, checking the local machine, preserving logs, and contacting the responsible people. Security controls must remain usable after staff and equipment change.
How to use NIST SP 1800-45
NIST NCCoE published SP 1800-45 as a final practice guide on 24 June 2026. It builds an OT remote-access architecture for the water and wastewater sector. A manufacturer can learn from its design approach, but the guide does not impose a requirement on Thai factories, and its example product architecture should not be copied without checking the plant’s machines, work process, and recovery needs. The NIST, CISA, and joint guidance cited here are public design references. Customer, parent-company, insurance, or sector-specific obligations must be checked separately.
FAQ: Where should factory remote-maintenance security start?
Inventory the assets and every support path, including vendor routers and cellular links. Define who may do what, with local supervision and a recovery plan. Check exposed ports, shared accounts, and permanent connections before installing another gateway; otherwise the old path remains.
FAQ: Is a VPN enough for an OT vendor connection?
A VPN is one transport control. Assess named identity, approval, time limits, asset and action restrictions, DMZ brokering, monitoring, and expiry. Ask the vendor for a connection diagram and ports, then compare options against the same acceptance criteria.
FAQ: What belongs in an industrial remote-access RFP?
Specify target equipment, tasks, shutdown conditions, MFA, time-limited rights, DMZ path, logging, file transfer, updates, support, link-loss behaviour, backups, and FAT/SAT evidence. Require settings, diagrams, and results behind a vendor’s “compliant” answer.
FAQ: What is the difference between OT remote-access FAT and SAT?
FAT verifies the functions and denial cases before delivery in a controlled environment. SAT verifies the installed path, real asset, network, local approvers, and recovery at the Thai site. Passing FAT does not reveal an old parallel route, wrong site clock, poor line quality, or actual recovery behaviour.
Conclusion
Vendor remote maintenance is a complete job, not merely a connection. Approve its purpose, grant an individual time-limited path to one asset, broker and record the work, then close both access and equipment change. Put that sequence into the RFP, test permission and denial at FAT, and prove local operation at SAT. For related availability planning, see our industrial network redundancy guide.
If you are mapping existing support routes or preparing RFP and FAT/SAT criteria, contact TOMAS TECH. We can help structure the decision from your actual equipment and maintenance workflow.
