Third-Party ICS Access: Know What Vendors Can Reach
Controls integrators and equipment vendors require remote access to maintain and support operational systems. Operators need to know where that access enters, what systems it can reach, what activity occurs through it, and what happens if the vendor is compromised.
Based on CISA and FBI guidance for third-party ICS integrators ↗
Control the vendor access path.
Trust in the vendor does not define the security of the connection. Third-party ICS access needs a defined scope, route, access window, and owner.
Scope the job
Define the PLC, HMI, engineering workstation, SCADA server, remote site, or supporting system required for the work.
Trace the route
Document whether access enters through a VPN, jump host, remote access appliance, cellular connection, vendor service, or another path.
Limit the window
Define whether access remains continuously available or is enabled only when maintenance and support require it.
Own the change
Document who approves access, who can change it, and who removes it when the work or relationship ends.
Trace the actual path into the control environment.
“They use the VPN” does not describe the access path. Follow the connection from the vendor entry point through each boundary to the operational systems and privileges it exposes.
Expected Access Path
Vendor / Integrator
Technician, support account, vendor workstation, or vendor-managed service.
Remote Access Point
VPN, remote access appliance, vendor service, cellular modem, or another inbound path.
Security Boundary
Firewall, jump host, gateway, or IT and OT boundary that passes the traffic.
Control Environment
Engineering workstation, HMI, SCADA server, PLC, RTU, remote site, and supporting systems.
Understand the dependency behind the connection.
Vendor risk extends beyond the remote session. Integrators hold operational information, introduce technology, and become part of how the environment is maintained, recovered, and operated.
What the vendor holds
- Network diagrams and device details
- Configurations and engineering files
- Logs and operational data
- SCADA information
- Credentials or account information
- Support documentation and backups
What the vendor introduced
- Remote access appliances
- Gateways and cellular modems
- Engineering workstations
- Vendor software and services
- External communications paths
- Accounts and update mechanisms
CISA and the FBI cite a 2025 compromise of a U.S. industrial automation company in which actors searched for customer and SCADA information and prepared about 800 files for presumed exfiltration. A compromised vendor can expose operational information before an attacker reaches the operator network.
Read the Fact Sheet ↗If every vendor connection disappeared tonight, what breaks tomorrow?
Vendor access should support operations without becoming a single point of operational failure.
Put the handoffs in writing.
Contracts and support agreements need to match the operating environment. Remote access, system changes, incident support, data custody, and recovery all need an explicit owner.
Six answers every operator needs from third-party access.
Review these with operations, controls, IT or security, the vendor, and leadership.
Access paths: Every third-party path into the control environment is documented.
Reach and privilege: Every path has defined reachable systems and permitted actions.
Evidence: Activity through each path can be reconstructed after the session.
Vendor-held data: Operational information held by the vendor and its storage location are known.
Introduced systems: Vendor-supplied hardware, software, accounts, and communications paths are inventoried.
Continuity: Critical operations can continue if every vendor connection is disabled.
Where CrunchAtlas fits.
Secure remote access controls who is allowed to connect. CrunchAtlas supports the evidence and investigation side of the problem by showing what vendor activity did across monitored IT and OT networks, then carrying suspicious behavior into an investigated case.
Network Detection and Response
Passively surface vendor and third-party activity across monitored IT and OT networks without actively probing operational systems.
Explore NDRAlert Investigation
Turn unexpected vendor activity into an evidence-backed case with scope, verdict, confidence, and recommended next steps.
Explore Alert InvestigationHost and Network Forensics
Reconstruct what happened when the investigation begins after the vendor session or suspicious activity has ended.
Explore ForensicsIncident Reporting
Preserve affected systems, timeline, evidence, verdict, and recommended actions in one investigation record.
Explore Incident ReportingPower and Energy
See how CrunchAtlas supports connected, segmented, and fully air-gapped electric environments.
Explore Power & EnergyCoverage depends on deployment scope, available telemetry, and the systems being monitored. Consequential actions remain operator-controlled.
Third-Party ICS Access Questions
Should integrator remote access stay enabled all the time?
No. Access should match the operating requirement. If continuous access is not required, define when it is enabled, who approves it, and when it is removed.
Is a VPN enough for vendor access to an ICS or SCADA environment?
No. A VPN can secure and authenticate the connection, but operators still need to know what it can reach and what happens after the session starts.
Does the controls integrator own cybersecurity for the systems they support?
Only when the scope assigns those responsibilities. Engineering support, remote maintenance, monitoring, backups, investigation, and incident response can be owned by different parties.
What should operators retain from third-party remote access?
Retain enough evidence to show when the connection occurred, which systems communicated, where the activity went, and whether it stayed inside the expected path.
Sources and Guidance
This guide applies federal and NIST guidance to third-party remote access, integrator relationships, and operational dependencies in ICS and OT environments.
Architecture, support agreements, and third-party responsibilities vary by environment. Apply the guidance to the systems and operating requirements actually in scope.
Trusted access still needs evidence.
See where a vendor connection went, what systems it reached, and what happened through it.