How to prepare the network and remote service access without putting production at risk ART-163

Why ordinary corporate remote desktop is insufficient

An OT environment differs from an office. A machine controls a physical process, has a long lifecycle, depends on vendor software, and may not tolerate a normal enterprise patch cadence. A failed update, scan, or antivirus action can affect availability. A compromised account can change parameters, stop production, or hide diagnostic data.

NIST SP 800-82 Rev. 3 explicitly addresses OT security with performance, reliability, and safety in mind. The goal is therefore not merely to block attacks, but to preserve predictable operation and a safe physical state.

Typical weak arrangements:

• permanent TeamViewer/equivalent on the machine PC;
• a shared “service” password;
• direct port forwarding to the CNC;
• the machine network in the same VLAN as office laptops;
• a vendor router with an unknown configuration;
• no record of who did what;
• remote start/reset allowed without a local check;
• a channel left active after the ticket;
• connection of a technician's personal laptop without control.

Start with inventory and data flows

Unknown assets cannot be protected. For every machine cell, record:

• CNC/PLC/HMI and firmware/software versions;
• machine PC, engineering workstation, vision system;
• laser source, chiller, compressor, and filtration interfaces;
• automation controllers and safety systems;
• network switches, wireless links, routers, and modems;
• vendor remote appliance;
• protocols, ports, and connection directions;
• external services, licensing, cloud telemetry;
• USB and other removable-media routes;
• accounts, owners, and support contacts;
• data leaving and commands that may enter;
• production dependence on each connection.

Distinguish remote monitoring, screen sharing, file transfer, log collection, parameter changes, software updates, and control actions. The word “service” does not describe permissions.

Classify service scenarios

Create a positive list of use cases:

1. Viewing status and logs without modification capability. 2. Controlled file transfer through verified staging. 3. Interactive diagnostics with a local operator. 4. Configuration or software changes under a change procedure. 5. Emergency support under a separate break-glass process.

For each, define the requester, approver, vendor identity, target asset, allowed tools, permitted actions, duration, monitoring, local presence, backup prerequisite, and closure evidence. The lowest-risk option must be the default; broader privileges are enabled only for a specific reason.

Target architecture: no direct route to the machine

The specific design depends on the plant, but a robust approach generally has several boundaries:

| Layer | Function | Desired control | |---|---|---| | Internet/vendor | external identity | approved source, MFA, contractual identity | | Security gateway/VPN | single controlled entry point | encryption, policy, time window, logs | | OT DMZ | buffer between enterprise/external networks and the cell | proxy, file staging, monitoring | | Jump host | managed service workstation | hardening, session recording, no shared use | | Cell firewall | minimum machine flows | allowlist, deny by default where feasible | | Machine/CNC | target asset | least privilege; local safety remains authoritative |

The arrangement must not create transit from a vendor laptop to all of OT. In its recent recommendations, CISA consistently advises placing a gateway/firewall/VPN in front of industrial controllers when remote access is needed. This is a protection direction, not a ready-made configuration.

Segmentation must be tested

A VLAN label alone is not segmentation. Rules between zones, an inventory of permitted flows, and a test proving forbidden routes do not work are required. A machine may need CAM files, time synchronization, a license server, or production data, but this does not mean general corporate-network access.

For every flow, record source, destination, protocol, direction, business owner, technical owner, reason, expected frequency, and review date. A temporary commissioning port must close unless an approved need remains.

Control wireless and cellular channels separately. A vendor modem that bypasses the plant gateway bypasses the rest of the architecture.

Identity, MFA, and no shared accounts

Every session must be linked to a real person and organization. A shared vendor account destroys attribution and complicates revocation. Use individual identities, MFA, role-based permissions, short validity, and approval for the target asset.

Check the lifecycle:

• who creates the account;
• how the vendor employee is verified;
• when access begins and ends;
• who revokes it after personnel changes;
• how a lost factor is handled;
• where emergency credentials are stored;
• how periodic recertification is performed;
• whether access can technically be limited to a specific ticket.

MFA reduces stolen-password risk but does not compensate for excessive privileges or a compromised endpoint.

Time-bound and locally enabled access

The best permanent service channel is one that is not permanently accessible. A practical pattern: a locally authorized person confirms the ticket, opens a session window, checks machine state, observes the work, and access closes automatically afterward.

Define:

• maximum session duration;
• inactivity timeout;
• local enable/consent;
• permitted production state;
• prohibition of remote start or safety reset;
• automatic revocation;
• emergency termination;
• behavior on network loss;
• reapproval for an extension.

If local presence is unnecessary for read-only monitoring, justify this separately. Monitor permissions must not quietly include control.

Least privilege at the action level

The “administrator” role is too broad for most diagnostics. Separate log viewing, export, upload, parameter editing, software installation, firmware updates, rebooting, and controller access. Where the platform does not support granular rights, compensating controls may include a jump host, supervised session, shorter window, and prohibition of certain use cases.

Treat safety PLCs, interlocks, laser parameters, and machine programs with particular care. Remote access must not enable bypassing physical safety logic. Changes affecting machine behavior undergo MOC and validation.

File transfer without direct exchange

Service often needs logs, a backup, or an update package. Dragging a file directly from a vendor laptop to the CNC creates malware and traceability risks. Controlled staging is preferable:

1. the file arrives in a defined zone; 2. source, hash/signature where available, malware policy, and compatibility are checked; 3. it receives a ticket/change ID; 4. the target-system backup is confirmed; 5. transfer uses a permitted channel; 6. the result and version are recorded; 7. the temporary file is deleted under the retention rule.

Log exports are also checked for confidential production data, drawings, personal data, and commercial information. The vendor must not automatically receive the entire order archive.

Logging and session recording

Visibility is needed into authentication, approvals, start/end, target, source, commands/actions where technically possible, transferred files, privilege elevation, configuration changes, and results. Protect logs against alteration, synchronize time, and retain them under an agreed policy.

A screen recording helps investigate an incident but does not replace the machine audit log. It may also contain sensitive data, so access and retention are controlled.

A useful session closure record answers five questions: who connected, why, what they viewed/changed, the machine's state afterward, and who accepted the result.

Backup and recovery before a change

A remote change requires a verified backup and rollback plan beforehand. The copy must cover precisely what changes: CNC configuration, PLC project, machine parameters, recipes, HMI, licenses/keys, network settings, or a PC image under OEM-supported rules.

The existence of a backup file does not establish recoverability. Version, date, asset identity, integrity, storage separation, and periodic restore testing in a safe environment where possible are required. Only the OEM can restore some parameters or licenses; know this before an event.

After the change, validate with local personnel. Do not close the ticket merely because the remote technician disconnected.

Patch and vulnerability management without blind updates

OT patching requires vendor support, testing, planned downtime, and rollback. Ignoring known vulnerabilities is hazardous, but automatically installing office updates on a machine PC is risky too.

Each asset needs a support status, approved versions, vulnerability intake, risk decision, compensating controls, and target date. If patching is impossible, strengthen segmentation, application allowlisting, access restrictions, or monitoring under an agreed plan.

CISA ICS advisories and vendor notices are inputs to the process, not automatic update commands.

Third-party governance

External service access must form part of the contract and operating procedure. Define:

• permitted subcontractors;
• identity and MFA requirements;
• approved tools/endpoints;
• incident notification;
• vulnerability disclosure;
• customer-data handling;
• log availability;
• access revocation;
• support after product end-of-life;
• responsibility for backup and validation.

IEC 62443-2-1 addresses the IACS owner's security program. This matters: even a robust vendor portal does not replace the asset owner's policies.

Availability and safe degradation

A security gateway, MFA service, DNS, time source, or certificate may fail. Loss of remote access must not automatically stop safe local operation unless the process design requires it. At the same time, the machine must not switch to a less protected direct connection “temporarily, while the VPN is down.”

For every external dependency, define expected behavior: production continues locally, new service sessions are prohibited, the active session terminates, an alert is generated, or the machine is placed on hold. The decision depends on the function. Losing a read-only dashboard and losing a channel that carries critical commands have different consequences.

Local contacts, offline documentation, and a manual support route are needed so a network incident does not force an unsafe workaround. Break-glass access must be rare, individual, time-limited, more extensively logged, and subject to post-use review.

Privacy, commercial data, and the export boundary

Machine logs may contain customer names, drawing filenames, production volumes, operator identities, timestamps, and process parameters. Before sending them to a vendor, define the minimum dataset, legal/contractual basis, secure transfer, retention, and deletion. A screenshot in a messenger is not a controlled channel.

If diagnostics require a full disk image or database, treat this as a separate high-risk use case with approval and a data inventory. Where possible, remove unnecessary commercial content from exports without destroying technical evidence. Link every data extraction to a ticket and recipient.

Periodic access review

Even a correct architecture ages. Vendor personnel, contracts, machine ownership, software versions, IP ranges, and supported tools change. At least on a risk-based cadence, reconcile accounts, groups, certificates, gateways, open rules, inactive appliances, logs, vendor lists, and emergency contacts.

Review after commissioning and warranty expiry is especially important: temporary accounts and ports often remain. Also check whether all actual sessions used the approved path. Remove or formally assess a discovered shadow remote tool; do not retroactively legitimize it merely for convenience.

Incident response and emergency disconnection

The team must know how to terminate remote access quickly without an unsafe process stop, whom to notify, which logs to preserve, and how to move production into a safe state. Network isolation and machine emergency stop are different actions with different consequences.

The playbook must cover stolen vendor credentials, a suspicious session, malware detection, an unauthorized file, gateway loss, a compromised machine PC, and unexpected configuration changes. Each needs containment, evidence preservation, a production decision, OEM contact, and a recovery gate.

Do not hastily wipe the system or logs. At the same time, a cyber investigation must not delay actions necessary for people's safety.

How to commission remote access

1. Confirm the inventory and data flows. 2. Check network zones and rules. 3. Create test identities with the required roles. 4. Test MFA, approval, and the time window. 5. Prove forbidden paths are blocked. 6. Conduct a read-only diagnostic session. 7. Test controlled file transfer. 8. Check logging and session closure. 9. Simulate communication loss and emergency revocation without hazardous actions. 10. Check the backup/rollback process. 11. Record residual risks and approvers.

Commissioning must not include hazardous production changes merely for testing. OT security agrees the method with the OEM and operations.

Common mistakes

• direct internet access to the CNC;
• a permanent remote agent without an owner;
• a shared vendor account;
• MFA without least privilege;
• a VLAN without firewall rules;
• a hidden cellular modem;
• file transfer without staging;
• changes without backup;
• logs only on the target PC;
• remote reset of a safety alarm;
• automatic office patches;
• closing a ticket without local validation.

Checklist

• [ ] A complete asset and connection inventory exists.
• [ ] Use cases and allowed actions are separated.
• [ ] There is no direct internet-to-machine path.
• [ ] Access passes through a controlled gateway/jump host.
• [ ] Zones and allowlisted flows have been tested.
• [ ] Every user has an individual identity and MFA.
• [ ] Access is time-bound and locally enabled where needed.
• [ ] Remote start/safety reset are prohibited without a separate design.
• [ ] File transfer has staging and traceability.
• [ ] Sessions and changes are logged.
• [ ] Backup and rollback have been tested.
• [ ] Incident revocation/recovery has been exercised.

Conclusion

Secure remote service is a controlled temporary session through a segmented architecture, not a permanent internet channel to the machine. The owner must know all assets and flows, permit minimum actions for a specific person, control file transfer, retain logs, and have recovery capability. If access cannot be unambiguously opened, observed, and closed, it should not be connected to a production machine.

Safety boundaries

This article is not a network design, firewall rule set, or authorization for remote control. Do not open ports, install software, change PLC/CNC, or bypass safety interlocks without OEM and OT-security approval. The specific architecture, cryptography, retention, and compliance are determined locally.

Need service advice?