OT Vendor Remote Access Security Checklist

0%

0 of 34 items complete

11 critical items still open - these are the highest-risk gaps.

Download checklist:

Identity and approval

Every vendor user has a named individual account, never a shared loginCRITICALMulti-factor authentication is enforced on every remote pathCRITICALAccess is approved per request with a stated purpose, system and end timeCRITICALA named internal owner is accountable for each vendor relationshipVendor staff changes trigger notification so accounts can be removedAccounts are disabled by default and enabled only for approved windowsContract includes security obligations and breach notification terms

Network path

All access goes through a hardened jump host or remote access gatewayCRITICALDirect inbound RDP, VNC or SSH from the internet to plant systems is blockedCRITICALCellular routers and vendor-supplied modems on machines are inventoried and controlledCRITICALThe gateway sits in a DMZ with rules limiting reachable systems to the approved listVendor sessions can reach only the systems named in the requestOutbound connections from plant zones to vendor clouds are allow listedSplit tunneling is disabled on any VPN used for vendor access

Session control and monitoring

Sessions are logged with user, source, target and durationCRITICALPrivileged sessions are recorded or observable in real timeFile transfer in and out of the jump host is controlled and scannedPlant staff can end a session immediately and know howCRITICALAlerts fire on access outside the approved windowIdle sessions time out automaticallyLogs are forwarded off the gateway to a central collectorSoftware and firmware changes by vendors are recorded in a change log

Endpoint and data hygiene

Vendor laptops meet a stated minimum for patches and endpoint protectionVendor-supplied USB media and laptops are scanned before connecting to plant networksCRITICALBackups of PLC, CNC and HMI programs are taken before vendor changesCredentials for equipment are held in a vault and rotated after vendor workDefault passwords on vendor-installed devices are changed at handoverRemote support tools installed by vendors are approved and listed

Lifecycle and review

All active vendor accounts are reviewed at least quarterlyCRITICALAccounts and tunnels are removed at project close or contract endCRITICALVendor access appears in the incident response plan with contactsA test of the kill switch for vendor access is done at least yearlyVendors notify you of compromises in their own environmentFindings from the review feed the risk register with owners and dates

Aim for every critical item complete. Any critical item unchecked is a gap to log in your risk register with an owner and date.

Vendor access review

Optional review of your remote access paths and vendor accounts.

Optional. The tool and every export work without this. No spam.

How to use it

Go through the list once per vendor or once for your overall remote access service. Tick what is in place today and mark gaps. Critical items are the ones that, if missing, create a direct path from the internet or a vendor to your controllers. Export the completed list as evidence for an audit, an insurer questionnaire or a customer assessment.

Do one pass per vendor for high-risk machines
Treat unchecked critical items as open risks
Repeat after any change of vendor or tool

Why vendors are a priority

A vendor account usually has more access than a staff account, is used from networks you do not control, and is rarely reviewed. Compromises at service providers have repeatedly led to downstream intrusions. Reducing blast radius with a single gateway, per-request approval and a hard time limit addresses most of that exposure.

Jump host design

A good gateway authenticates with MFA, authorizes against a list of approved targets, records the session and holds credentials the vendor never sees. It lives in a DMZ, not on the plant network, and is patched like a perimeter device. Vendor tools that install their own tunnel on a machine bypass all of this and must be found and removed or controlled.

Common mistakes

The usual failures are shared vendor logins that never change, a cellular router on a machine that someone installed for a service visit, and accounts left active years after a project ended. Another is an approval process so slow that vendors work around it. Make the sanctioned path the easy one.

Frequently Asked Questions

Is a VPN enough for vendor access?

Rarely. A VPN gives network reach. You also need MFA, per-system authorization, session logging and a time limit. Without those, a stolen VPN credential becomes full access to whatever the tunnel can reach.

How do I handle machine builders with built-in remote support?

Inventory every such connection, route it through your gateway where the vendor allows, and keep it disabled until needed. Where it cannot be controlled, isolate the machine in its own zone.

How often should access be reviewed?

At least quarterly for active vendor accounts, plus at project close. Link the review to a calendar owner so it does not depend on memory.

What should contracts say?

Require MFA, named accounts, patched endpoints, breach notification within a set period, and cooperation in investigations. Have legal review the wording, as this checklist is operational guidance, not legal advice.

If you want a vendor access request flow tied to your ERP or ticketing system with expiry built in, Netray can help design it.

Talk to an Expert Explore More Free Tools

Related Tools

Compliance & Contracts

More Compliance & Contracts tools

See all

OT Vendor Remote Access Hardening Checklist