Remote access
Give each remote support session a defined purpose, scope and expiry. Restrict permissions and record administrative actions through the site's approved process.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Research and static guidance only; product and deployment specific behaviour requires controlled environment validation and authoritative product evidence.
On this page
Overview#
Remote support often crosses the strongest physical security boundary and can expose high impact administrative or actuation functions. Treat it as an exceptional, observable workflow rather than permanent background connectivity.
Preferred pattern#
- A named operator, support engineer, or vendor representative requests access for a defined purpose, system, and time window.
- An accountable site authority approves the scope.
- Strongly authenticated identity enters through a managed access service or bastion.
- Policy permits only named destinations, protocols, and role capabilities.
- The session and administrative actions are logged; sensitive screen/traffic recording follows applicable privacy rules.
- Access expires automatically, credentials/tokens are invalidated, and temporary rules are removed.
- Changes and resulting system state are reviewed.
Requirements#
- No direct inbound exposure of device or management interfaces to the public Internet.
- Separate vendor identities; never share the local administrator account.
- Phishing resistant multifactor authentication where practical, plus managed endpoint posture.
- Just in time authorisation, short session lifetime, and explicit elevation.
- Destination allowlists and prevention of arbitrary lateral movement.
- File transfer controls, malware handling, and provenance for tools/firmware.
- Out of band revocation and a local method to disable the path.
- Safe behaviour if the remote session drops during a configuration change.
- Monitoring for access outside approved windows, unusual targets, repeated denial, and new tunnels.
Vendor cloud and outbound tunnels#
Inventory every device originated cloud connection, destination, identity, purpose, data category, update behaviour, and disablement path. Outbound TLS isn't automatically trustworthy: validate destination identity, constrain DNS/routing, monitor changes, and understand whether the tunnel permits reverse administration.
Prohibited shortcuts#
- persistent shared remote desktop credentials;
- consumer remote access tools installed outside asset/change management;
- port forwarding directly to cameras, controllers, recorders, or panels;
- disabling certificate checks to reach an appliance;
- unmanaged support laptops bridging trusted and untrusted networks;
- leaving commissioning VPNs or firewall exceptions permanently enabled.
Sources#
- NIST 800 46, NIST SP 800-46 Rev. 2: Guide to Enterprise Telework, Remote Access, and BYOD Security, accessed 25 August 2026.
- NIST 800 82, NIST SP 800-82 Rev. 3, OT remote access and architecture guidance, accessed 25 August 2026.
- NIST 1800 45, NIST SP 1800-45: Operational Technology Remote Access, final June 2026, accessed 25 August 2026.