Cyberuptive

What Should Manufacturers Require Before a Vendor Gets Remote Access to Plant Systems?

By Chuck Lerch, Founder and CEO, Cyberuptive

Require that every vendor session is requested, approved by a named internal owner, authenticated to an individual identity with multifactor authentication, scoped to the specific assets the work needs, logged, and torn down when the work ends, with the teardown verified. Vendors who cannot work that way are asking for standing trust in your plant network.

Manufacturers cannot simply refuse vendor access. Controller vendors, system integrators, and equipment makers often need to reach PLCs, HMIs, historians, and robot cells to diagnose faults and apply updates, and NIST notes that for OT, service support is sometimes only available from a single vendor. The question is not whether to allow remote access. It is whether each session is a managed event or an open door that nobody has reviewed since the last commissioning project.

This guide lays out a session lifecycle you can hold vendors to, the contract terms that support it, and the always-on tools that quietly undermine it. It draws on NIST and CISA guidance rather than any single product.

Why vendor sessions deserve their own process

NIST SP 800-82 Rev. 3 lists vendors and system integrators performing maintenance among the main reasons OT is accessed remotely, and it lists poor remote access controls among common weaknesses. Its guidance is to apply least privilege to remote access and to consider multifactor authentication for remote access to the OT system. CISA's remote access guide adds that malicious actors often co-opt legitimate remote access tools to reach victim systems, including in IT, OT, and industrial control environments. A vendor's approved tool and an attacker's borrowed tool can look alike in your logs unless you know which sessions to expect.

Plants also have an operational reason for discipline. When a technician pushes a change through a remote session while operators are running a line, the change can look like an attack or cause an outage. NIST's remote access guidance for utilities makes the point directly: operations personnel should be aware of planned or unscheduled remote activity so authorized changes are not mistaken for adversarial ones. Although that publication addresses water systems, the same logic applies on a plant floor.

The five stages of a controlled vendor session

  1. Request and approval. The vendor asks for a session with a purpose, a time window, and the assets involved. A named internal sponsor, usually in operations or engineering, approves it. NIST SP 800-53 control MA-4 calls for approving and monitoring nonlocal maintenance, and its enhancement MA-4(5) calls for approval of each nonlocal maintenance session by designated personnel or roles and notification of planned sessions.
  2. Authentication. The technician signs in with an individual account and strong authentication. NIST SP 800-82 recommends unique usernames, removal or change of default credentials, and, where practical, separate credentials for the OT network and the corporate network. Shared vendor logins fail this test, because you cannot tell who did what.
  3. Scope. Access should land in a controlled zone, not directly on production assets. CISA's guidance on remote access for industrial control systems recommends eliminating direct connections to critical operational assets and using demilitarized zones to separate business and control architectures. Grant access to the specific assets named in the request, not the whole cell network.
  4. Monitoring. Log the session and review it. MA-4 requires records of nonlocal maintenance activities, and MA-4(1) adds logging of defined events and review of the audit records to detect anomalous behavior. Someone, or a SOC working from your runbook, should know when a vendor session is expected, so an unexpected one gets investigated.
  5. Teardown. The session ends when the work ends. NIST SP 800-82 says the remote access tool should support immediate teardown once maintenance is done and suggests automatic timers for removing access, or change processes that manually confirm removal. MA-4(7) goes a step further and calls for verifying that session and network connections are actually terminated.

Contract terms that make the process stick

A process the vendor has not agreed to is a policy only your team follows. NIST's utility guidance recommends developing security requirements for third-party remote access in advance and addressing them in contracts and agreements. In a vendor agreement or statement of work, consider:

  • Named individuals, with a notice period when staff change, and no shared accounts.
  • Use of your approved access method only, with no alternative tools installed on your systems.
  • Advance notice and a change record for every remote session that alters configuration or logic.
  • Minimum hygiene for the vendor endpoints that connect, such as supported operating systems and current security updates.
  • Notification duties if the vendor suspects its own environment is compromised, and a clear way to revoke access immediately.
  • Flow-down of the same rules to the vendor's subcontractors.

The standing access nobody approved

The riskiest vendor access is often the connection that was set up for a project and never removed. CISA's guide recommends auditing remote access software and configurations to identify which tools are in use and which are authorized, allowlisting approved tools, and blocking common remote management ports at the perimeter. It also recommends requiring that authorized tools be used only over approved remote access solutions such as VPNs or virtual desktop interfaces. Run that audit across your plants, including cellular gateways and vendor-installed appliances, and compare it to the list of sessions you approved. The gaps are your standing trust.

For recent examples of why remote access and controller exposure matter on the plant floor, see our write-ups of the Danfoss refrigeration controller attacks and the Universal Robots PolyScope vulnerability.

Practical limits in a production environment

Do not roll out a session gateway on a line that cannot tolerate change windows. NIST notes that OT security solutions sometimes conflict with vendor licensing and service agreements, and that support can be lost if third-party software is installed without the vendor's acknowledgement. Where full controls are not yet possible, NIST lists compensating measures: limit maintenance to the minimum essential activities and monitor and audit it carefully. Start with the plants and assets where a vendor session could stop production or affect safety, and phase the rest.

Where managed security fits

A managed provider can inventory remote access paths, watch vendor sessions against your approvals, and keep the records you will want for customer audits. Cyberuptive's manufacturing security practice, managed detection and response, and zero trust services are good places to start scoping that work. The approval decisions, though, stay with your operations and engineering leaders.

Frequently asked questions about vendor remote access in manufacturing

Should manufacturers allow vendor remote access to OT at all?

Often they must, because vendor support for controllers and equipment is sometimes only available from the vendor. The goal is to make each session approved, scoped, monitored, and time-limited, rather than to ban remote access outright.

What is a controlled vendor remote session?

A session that is requested for a defined purpose and window, approved by a named internal owner, authenticated to an individual account with strong authentication, limited to specific assets, logged and reviewed, and terminated with the teardown verified. NIST SP 800-53 control MA-4 and its enhancements describe these elements.

Why are shared vendor logins a problem?

Shared credentials make it impossible to attribute actions to a person, and they tend to persist after staff leave the vendor. NIST SP 800-82 recommends unique usernames for remote access, so give each technician an individual account.

Should vendors connect directly to PLCs and HMIs?

Generally no. CISA's guidance on remote access for industrial control systems recommends eliminating direct connections to critical operational assets and using demilitarized zones to separate business and control networks. Route sessions through a controlled access point instead.

How do we find vendor access nobody remembers approving?

Audit remote access software and configurations across each site, as CISA's remote access guide recommends, and compare the findings to your approved list. Include cellular gateways, vendor-installed appliances, and tools left from past projects.

What should we do if we cannot add full controls to a line right away?

Use compensating measures: limit vendor maintenance to the minimum essential activities and monitor and audit it closely, as NIST SP 800-82 suggests. Then prioritize the assets where a session could affect safety or stop production, and extend controls from there.