Remote access to production systems should be opened only to a named person, for an approved task, through a restricted access point and for a defined period. After the session, access should be revoked, the change checked and the record retained under internal rules. This keeps remote machine service operationally useful without turning it into a permanent, poorly visible entry point into the production network.
A machine vendor or integrator can remotely resolve a fault, review diagnostics or prepare an agreed change. This can reduce waiting time for service, especially where a specialist technician is needed. However, the same connection becomes a risk if the company cannot answer simple questions: who accessed the environment, what they accessed, why, when, by which route and what they changed.
OT security is not reduced to one VPN account or the installation of a remote desktop tool. Access control should connect the business reason, the person's identity, the technical route, work oversight and post-session verification. Each of these steps leaves a verifiable event:
This sequence also applies where production equipment lacks modern identity management capabilities. In that case, protective controls should be moved to an intermediary workstation, network zone and approval process, rather than assuming that an older device can enforce controls it does not support.
The first step is not technically opening a connection but raising a service request. The responsible internal person should state at least:
A request for access to an entire plant or all of a vendor's systems is not specific enough for effective access control. The technician should receive only the route to the required target. If the work involves transferring a configuration, installation package or diagnostic tool, this should be stated separately. This distinguishes reviewing a system state from changing the system.
Linking the request to a service or production record makes later verification easier. For example, Manufacturing work orders can provide the business context for an intervention, while the access record should show which identity technically performed the work.
A shared account for an entire service company makes accountability difficult to establish. Each external technician should use an individual identity tied to that person and the approved task. Where possible, an additional identity check reduces the risk that a stolen password alone is enough to connect.
Permission should not remain active after the agreed appointment. Access can be opened for a specific window, such as a planned intervention, and automatically revoked when the window ends. If the work is extended, new or extended approval is required. This avoids the practice in which a temporary account remains available because nobody closed it.
Older equipment often has only a local, shared or factory user account. That account should not be shared directly with an external person over the network when another workable option exists. A practical safeguard is a controlled access workstation:
This does not remove the limitations of the older device, but it reduces the network visibility available to the external person and improves traceability.
A vendor connection should not end as general access to the internal network. Instead, it should terminate in an intermediary zone or on a controlled access workstation. From there, only the necessary destinations, ports and protocols are allowed. Rules should fit the specific service task, not a general assumption that the vendor needs to see the entire production zone.
Before opening access, decide whether the session needs to allow:
File and tool transfer deserves a separate decision because it can change the scope of a service session. The company can define a transfer channel, a person responsible for review and a location where the file is kept before use. A service tool, configuration copy or log file should not automatically be assumed to be allowed through the same route as remote desktop access.
NIST SP 800-82 Rev. 3 - Guide to Operational Technology Security describes requirements that are specific to operational technology. The NIST - Operational Technology Security Publications collection provides additional material. These sources can help shape controls, but they do not replace a review of the actual zones, connections and operational consequences in a plant.
Not every remote session is the same. Reviewing alarms on a non-production system and changing a parameter on an active production line do not have the same operational effect. Approval and oversight should therefore follow the type of work.
For routine diagnostics, an approved request, a restricted identity and post-work record review may be sufficient. For changes to configuration, control logic, network settings or software, the responsible production person should be involved before work begins. Depending on risk, that person can monitor the work live or review the complete session and change record promptly after the intervention.
It is useful to separate three kinds of work in advance:
An emergency process may be faster, but it must not be ownerless. Define in advance who can approve emergency access, how the reason is recorded, who monitors the intervention where feasible and when the event is reviewed afterwards. After an emergency session, confirm what was done and decide whether a permanent change needs to be formalised.
A record does not replace an agreed scope of work. Its purpose is to make it possible to check whether the session followed its approval and to support analysis if a problem appears after the work. Depending on the architecture and risk, the record may include:
If a session is recorded, the technician should be informed about what is being recorded. The company should also define who can access the records, where they are retained and for how long, according to internal rules and actual need. A recording without protection and an owner can create a new problem instead of useful evidence.
Remote service is not finished when the vendor signs out. Closing steps should confirm that temporary access is actually closed and that the production system operates as expected.
After the work, check the following:
This step connects technical security with operational continuity. If the change was successful, the record remains linked to its reason and approval. If a deviation appears, the team knows where to begin checking without relying on informal messages or participants' memory.
CISA - ICS Recommended Practices can serve as an additional control framework. Specific rules should still follow the actual network zones, equipment criticality, vendor operating model and capabilities of existing systems.
As a practical starting point, list every active channel through which external people can connect to production systems. The list often includes an official VPN, modem, manufacturer tool, remote desktop, service workstation and temporary user accounts.
For each channel, record:
If a channel has no owner, no clear revocation point or no way to link a session to a person and reason, it should be reviewed as a priority. Not every older connection needs to be replaced immediately, but every existing route should have known boundaries and accountability.
A useful next step is linking the service request, equipment and completed change into one operational trail. ORKA manufacturing can help connect a service event with equipment and production context, while access control remains separate evidence of who made the change, when and under which approval.