What do security teams get wrong about managing integrator access in ICS environments?

Why integrator access should be treated as a governed relationship, not a handoff

Integrator access in ICS is not just another onboarding task. It is a bounded trust relationship that should be defined, approved, and continuously observable for the whole engagement. The key question is not whether the integrator needs access, but whether the operator can prove who is authorised, what paths exist, and when that access must end.

In practice, that means treating the integrator as a distinct access population with its own scope, timing, and approval path. A contract or statement of work should translate into explicit access conditions, including named personnel, approved endpoints, and defined remote support methods. Where the access model is vague, the environment becomes difficult to defend because the operator cannot separate legitimate maintenance from unplanned reach into control assets.

For remote sessions, visibility matters as much as authentication. Remote Access Identity Guide is useful here because the same weaknesses that affect third-party remote support in enterprise environments also apply in ICS, especially when VPNs, shared jump paths, or dormant accounts are left in place between engagements.

Where security teams lose control of integrator access

The most common failure is assuming the access path is harmless once the vendor is “known.” That shortcut often leaves standing entitlements, shared credentials, or unmanaged remote channels that outlive the job they were created for. In ICS, that is especially dangerous because a maintenance path can reach engineering workstations, historian systems, HMI layers, or other components that were never meant to be broadly reachable.

Another failure is relying on the integrator’s internal process instead of the operator’s own control plane. If the operator cannot see which individuals are active, cannot log the route used to connect, or cannot confirm which assets were touched, the relationship has effectively escaped governance. The practical problem is not just overexposure, but the inability to reconstruct activity after an incident or dispute.

This is where operational technology-specific guidance helps anchor the control model. OT and ICS Identity and Access Guide covers the realities that make integrator access harder than ordinary third-party access, including shared accounts, vendor remote access, and segmentation expectations in industrial environments.

For external baselines, NIST SP 800-82 Rev 3, OT Security Guide remains a strong reference because it frames ICS security around architecture, segmentation, and controlled access paths rather than assuming office-network style administration. CISA Industrial Control Systems is also relevant for operators who need current ICS-specific guidance and advisories tied to real industrial environments.

What good integrator access looks like in an ICS environment

Good practice starts with a narrow, explicit access agreement. The operator should know who may connect, from where, for what purpose, and through which approved control points. That scope should be time-bound and reviewed whenever the work changes, because many failures begin when temporary access quietly becomes the default operating model.

Technical controls need to match that governance model. Privileged routes should be logged, remote sessions should be attributable to a person rather than a generic vendor identity, and inactive access should be removed at the end of the engagement. If the environment still depends on shared accounts or undocumented jump paths, it is usually a sign that the access process is managing convenience rather than risk.

Operators that want a more formal control lens can map these expectations to NIST SP 800-53 Rev 5 Security and Privacy Controls for access control, identification and authentication, audit, and configuration management, and to CIS Controls v8 for account management, logging, and access control discipline. In tightly regulated environments, ISO/IEC 27001:2022 Information Security Management is useful where the organization needs to show that access, authentication, and privileged use are governed as part of a repeatable management system.

Practitioner Guidance

What to verify: Confirm that every integrator has a named business sponsor, a defined scope of work, an approved access route, and a documented end date. If any of those elements is missing, treat the access path as provisional and higher risk until it is corrected.

What to prioritise: Focus first on observability and removal of dormant access. If you cannot see who connected, when they connected, and which path they used, rotation and least-privilege changes will not give you enough assurance on their own.

Common mistake: Teams often harden the initial approval step but forget the full lifecycle. The more reliable control is not “vendor approved once,” it is “vendor access remains continuously attributable and automatically expires when the work is over.”

Practitioner takeaway: In ICS, integrator access is safest when it is treated like a temporary privileged operating relationship, not a courtesy exception, because the real control failure is usually loss of visibility and offboarding discipline rather than the initial grant itself.

Related resources from NHI Mgmt Group

• What do security teams get wrong about managing client access in MSP environments?
• What do security teams get wrong about vendor access in public safety environments?
• What do security teams get wrong about zero trust in agentic access environments?
• What do security teams get wrong about third-party access in CJIS environments?