The Third-Party Integrator Risk: OT’s Most Overlooked Attack Surface
BLOG
5 min.
Industrial Control System (ICS) and operational technology (OT) networks have continued to grow and expand in substantial ways. The demand on the networks have increased as markets have grown, the convergence of IT and OT have changed how these networks look and heightened interest from threat actors have significantly altered the approach to security in these environments.
TL;DR – A third-party integrator can help scale OT environments, but without following best practices, they can also introduce new security risks.
- Rapid OT expansion has created the need for third-party support to help manage OT device integration and evolution.
- CISA and the FBI highlight the growing exposure risk presented by third-party integrators, which cannot be addressed by least privilege access alone.
- By following recommended best practices, including clear documentation, external-facing device reviews, remote access logging, visibility into new and updated devices and manual operations practice, you can reduce the risks associated with third-party integrator support.
Shifts in OT environments have not been small and in many cases, have required third-party support to help manage their evolution effectively. While integrators may help alleviate operational expansion and implement based on new requirements, they also introduce additional risks. Especially if these integrators and their clients don’t enforce proper cyber hygiene.
CISA Highlights the Growing Exposure Risk Created by Third-party Integrators
The OT third-party integrator risk concern was recently called out in a joint publication from CISA and the FBI. This publication “Considerations for Critical Infrastructure Operators Working With Third-Party ICS Integrators” highlights the growing exposure of ICS networks and includes a list of recommendations to help assess risk and reduce exposure. While these recommendations follow standard cybersecurity best practices, the historical need for system uptime and reliability has meant these practices sometimes fall on the back burner.
Notably, the core of these security recommendations builds on the “principle of least privilege.” This concept is a core tenet within many organizations, with system administrators restricting users to privileges based on their immediate roles and responsibilities. The goal of these controls is to limit the impact of an attack. If an account or system is breached, the principle of least privilege should minimize the overall reach and impact of an attack.
The Problem with Least Privilege in OT Environments
In reality, the application of “least privilege” poses a significant challenge within OT environments. Many of the foundational protocols, things such as Modbus, DNP3 and older versions of EtherNet/IP lack authentication and role- based access. While this may be difficult within the OT environment due to technical limitations with the basic protocols and the systems in use, additional steps can be taken to limit exposure of critical systems such as the following:
- A dedicated integrator access zone or jump host in a DMZ, with no direct path into Purdue Level 1/2 and per-vendor accounts rather than shared integrator credentials
- Just-in-time access to reduce the overall exposure of remote access solutions
- Enabling MFA on remote access to reduce risks associated with account compromise
- Continuous review of accessible user accounts, including integrator and vendor accounts and their activity to ensure permissions are appropriate
- Regularly purge stale, unused or deprecated accounts and access as projects close-out
Best Practices When Engaging with Third-party ICS Integrators
In its own publication, CISA also provided a handful of best practices organizations should consider when bringing in third party ICS integrators.
Include Cybersecurity and Supply Chain Cybersecurity in Contracts and Service Agreements
As with all things security, proper implementation needs to start at the beginning. Prior to allowing any third party into your ICS networks, ensure documentation exists, highlight security expectations and accountability. Things such as change management, patching expectations and remote access method documentation can all help organizations understand security practices, even before they begin.
The security of your ICS network doesn’t just rely on your environment, but those that touch it. Proper data hygiene, secure remote access capabilities and documented change management and patch policies all contribute to the security of your environment, even before an integrator steps foot on a factory floor. Additional documentation around steps that will be taken to secure the environment, prior to entering the environment, can help demonstrate and support long term security initiatives.
Evaluate Devices with External Internet Exposure
Internet exposed assets represent a long-lived and frequently exploited path into ICS environments. VPN appliances, cellular modems and internet facing PLCs and HMI all introduce a new avenue of attack.
When working with an integrator, ensure that systems have only the necessary network access. While publicly exposing these systems on the internet may allow for quick and easy management, it also provides threat actors with a low-effort means into the environment. While more effort to configure, secure remote access tools with MFA and no inbound port forwarding can significantly reduce the exposure of a system, while still allowing for robust support.
In addition to configuring secure remote access, regular reviews of your external-facing Ips can help to ensure access in this form isn’t left unchecked.
Monitor and Log Remote Access
Given the criticality of most ICS environments, remote access should be carefully monitored and regularly reviewed. ICS integrators perform important work with ICS environments and as such, these accounts provide a high value entry point into the environment. Unrestricted and unmonitored access can quickly lead to operational blind spots, significantly reducing the environment’s overall integrity.
When possible, organizations should work with integrators to provision “Just-in-Time” access. “Just-in-Time” approval allows for targeted provision access, on approval. As opposed to an always on solution, integrators must request access to a specific system at a specific time. This access can be extended or revoked, at any time.
Access of this nature allows integrators to perform their tasks but also provide the system owners with more granular control. Initial access requires the approval of a trusted legitimate user, reducing the risk of unauthorized access and in the event of a breach or suspicious behavior, the access can quickly be revoked, isolating the overall impact.
In addition to controls such as “Just-in-Time” access, robust logging and monitoring of remote access and sensitive networks can help to identify and flag anomalous behavior. Forwarding logs to an OT aware SIEM can help ensure that alerts are triaged and handled appropriately.
This can easily identify off-hour activity or out-of-scope behavior from integrators. Additionally, consistent passive network monitoring can help identify new integrators systems and devices, even if they aren’t immediately communicated.
Request an Inventory of All Software and Hardware Supplied by the Integrator
Protection begins with visibility. It is impossible to protect the things which you do not know exist. When working with an ICS integrator it is important your team understands the software and hardware they are introducing into the environment.
Each new piece of software and hardware introduces a new potential means of compromise. An asset inventory supports vulnerability management and helps teams choose between patching and compensating controls. Undocumented software or hardware can quickly fall out of date and introduce new vulnerabilities in the environment.
Additionally, logic output should also be requested. PLC project and logic files, system backs ups and any integrator tool should also be collected and understood. These files and components create an actionable audit trail that can be leveraged to ensure system and environment integrity.
Practice Procedures and Maintain Capabilities for Manual Operations
ICS integrators can become a core part of an organization’s operations. In these situations, it’s important to ensure that they understand their roles and responsibilities within the organization.
Regular reviews with integrators can ensure they are ready and able to perform any necessary manual operations and fail-safe procedures. When performing tabletop exercises, reviewing policy and maintaining daily operations, these integrators should be present to ensure they are available and ready in the event of an incident.
The following list several best practices that should be regularly reviewed and verified with integrators.
- Appropriate change management controls when interacting with and modifying PLCs logic. System owners should work with integrators and manage policy, to ensure that a reliable fallback logic is available and new logic is properly documented.
- Policy exists to ensure that integrator-owned systems are regularly scanned to mitigate risks of malware.
- Effective off boarding procedures should be in place to ensure inactive integrator accounts and systems cannot be used for an attack. Disable accounts and ensure unused systems/software are removed.
- Ensure appropriate controls and segmentation exist between remote access solutions and high priority safety systems.
Start with a Risk Assessment
Outside of following these recommendations, regular risk assessments are highly encouraged. While some integrators have always put security first and built the systems and environments they support with this in mind, others may have focused their efforts on operational reliance and performance. The use of default credentials, insecure network configurations, outdated and vulnerable software and insufficient documentation is common in some ICS environments.
In these situations it is important to have a trusted partner capable of not only validating past work but also helping to support and foster an environment of operational and security excellence. GuidePoint’s consultants and engineers are well positioned to help organizations establish an OT security baseline so they can grow securely.
FAQs
What happens when a third-party integrator is compromised in an OT environment?
A compromised integrator account can give attackers direct access to controllers and sensors that run physical processes. Lateral movement from an integrator’s entry point can bypass IT security controls entirely. The impact ranges from production downtime to safety incidents depending on the attacker’s objectives.
How should organizations vet third-party ICS integrators before granting access?
Start with documented security requirements in the contract before any access is provisioned. Request evidence of the integrator’s own security practices including patch management and remote access policies. Verify that the integrator can support your logging and monitoring requirements.
What is the CISA advisory on third-party ICS integrators?
CISA and the FBI published “Considerations for Critical Infrastructure Operators Working With Third-Party ICS Integrators” in 2026. The advisory highlights the growing exposure of ICS networks through third-party access. It recommends applying least privilege controls and monitoring all integrator activity.
Why is unmonitored remote access dangerous in ICS environments?
Unmonitored remote sessions create blind spots where unauthorized changes can go undetected. Persistent VPN tunnels and always-on connections give attackers a low-effort entry point into critical systems. Without session logging, organizations cannot trace the source or scope of a breach.
Austin Turecek is an penetration tester with a focus on IoT, embedded systems and application security. In the past Austin has worked within incident response, purple teaming and system administration roles. Prior to beginning his work as an IoT and application penetration tester, Austin worked as a malware analyst studying and tracking cyber criminals and their tools, throughout the deep and dark web. These combined experiences have all lent themselves to help support the diverse testing focuses required for IoT testing.
