Managing Cybersecurity Risks of IACS Service Providers Using ISA/IEC 62443-2-4
Every industrial facility depends on outside hands to keep its control systems running. System integrators commission the DCS. Maintenance contractors patch the historian. OEMs dial in remotely to troubleshoot a PLC. Engineering contractors touch the SIS during a turnaround.
Each of these relationships is necessary. Each of them is also a door to the Automation Solution.
This is where ISA/IEC 62443-2-4 becomes one of the most practical and underused tools an asset owner has.
Why Third-Party Access Is an OT Risk, Not Just a Vendor Decision
Asset owners increasingly rely on a wide network of external organizations to keep their industrial automation and control systems (IACS) running:
- System Integrators
- Maintenance Service Providers
- OEMs
- Remote Support Vendors
- Engineering Contractors
These organizations are not occasional visitors. They often hold privileged, recurring access to the systems that matter most:
- DCS and SCADA platforms
- PLCs
- Safety Instrumented Systems (SIS)
- Historians
- Engineering Workstations (EWS)
- Remote access infrastructure
If a service provider shows up with an infected laptop, an unmanaged USB drive, a shared administrator password, or a remote session that nobody is logging, the asset owner inherits that risk, whether or not it shows up in their own internal security program.
Most organizations have mature policies for their own employees. Far fewer have the same rigor for the contractor who logs into the EWS twice a year.
Safety Comes First-This Is What Makes OT Different
OT cybersecurity is not IT cybersecurity with a different network diagram. The priority order is different, and it has to stay that way:
- Safety of personnel
- Protection of the environment
- Operational continuity
A poorly managed laptop on a corporate network is an inconvenience. A poorly managed laptop connected to a Safety Instrumented System or an Emergency Shutdown System (ESD) is a different category of risk entirely.
When a service provider’s technician connects to a SIS controller for routine maintenance, the integrity of that connection is not just an IT concern — it is a direct input into whether the protection layer will function correctly when it is needed. Weak service provider practices around access control, change management, or remote connectivity can quietly erode the safety case that the SIS was designed to deliver.
This is exactly why ISA/IEC 62443-2-4 exists as its own standalone standard rather than being folded into general supplier security guidance. It is written for the reality of automation solutions, not enterprise IT.
What ISA/IEC 62443-2-4 Actually Asks For
ISA/IEC 62443-2-4 defines a security program that IACS service providers — specifically integration and maintenance service providers — should be able to demonstrate to an asset owner. Stripped of standard language, the requirements fall into business-relevant areas such as:
- Solution staffing — assigning trained, vetted personnel to the Automation Solution
- Assurance — providing confidence that the security policy is actually being enforced, not just documented
- Architecture — secure design practices for how the solution is built and integrated
- Wireless — controls specific to wireless use within the Automation Solution
- SIS integration — requirements specific to safety system touchpoints
- Configuration management — controlling changes to the solution over its lifecycle
- Remote access — how external connections into the solution are authenticated, authorized, and logged
- Event management — detecting and responding to security events
- Account management — administering user accounts, including provisioning and de-provisioning
- Malware protection — anti-malware practices appropriate for control system components
- Patch management — evaluating, qualifying, and applying security patches without destabilizing the process
- Backup/restore — protecting the ability to recover the Automation Solution after an incident
Each area is backed by base requirements — the minimum capability a service provider should be able to demonstrate — and, in many cases, requirement enhancements that raise the bar further for higher-risk environments.
Used correctly, this becomes a shared reference point. The asset owner can point to a specific, internationally recognized requirement instead of relying on a generic “please be secure” clause buried in a contract.
How CS4 Helps Asset Owners Put This Into Practice
At CS4 by DTS Solution, we do not treat ISA/IEC 62443-2-4 as a checklist to tick. We use it as a structured framework to translate written standard requirements into something an OT manager, a procurement lead, and a service provider’s account manager can all act on.
In practice, this means we help organizations:
- Assess service providers against the relevant functional areas of IEC 62443-2-4, based on the actual scope of their access — not a generic questionnaire
- Define contractual cybersecurity requirements that can be referenced in statements of work and tied to acceptance criteria
- Develop policies and procedures that close the gap between what a service provider claims and what they can demonstrate
- Establish governance frameworks for ongoing oversight of integration and maintenance providers across the contract lifecycle
- Evaluate implementation effectiveness, not just the existence of a document
- Identify gaps between current practice and the base requirements that matter most for the facility’s risk profile
- Develop improvement roadmaps that sequence corrective actions by operational impact and feasibility, not just by standard clause number
This is the same lens we apply across oil & gas, petrochemical, power generation, utilities, and manufacturing environments — industries where the cost of getting service provider security wrong is measured in safety incidents and downtime, not just data breaches
The CS4 Service Provider Cybersecurity Maturity Model
One of the most useful things ISA/IEC 62443-2-4 gives asset owners is a maturity concept — a way to describe how a service provider does security, not just whether they claim to do it. CS4 applies this concept practically when helping clients select and manage service providers.
ML1 — Initial
Security practices exist, if at all, on an ad hoc basis. Documentation is limited or inconsistent across projects. The provider is largely reactive, addressing security only when an issue is raised by the asset owner.
ML2 — Managed
The provider has written policies covering its service delivery, with defined responsibilities for personnel involved in the Automation Solution. Activities are repeatable — the same task performed by different technicians produces a consistent, documented result.
ML3 — Established
The provider operates a formal cybersecurity management system specific to its service delivery. Implementation is consistent across projects and personnel, and the provider can show evidence of periodic internal reviews of its own practices.
ML4 — Optimized
The provider drives continuous improvement through metrics — tracking things like patch turnaround time, remote access exceptions, or incident response performance — and uses governance and monitoring practices that go beyond minimum compliance.
The Industrial DMZ (IDMZ) deserves particular attention. It is not simply a network segment. It is a deliberate architectural construct that ensures no direct communication path ever exists between OT systems and IT Networks/cloud environments. Every data exchange passes through an intermediary such as a historian, a data broker, or a protocol gateway that validates, transforms, and logs the communication. This design pattern is what makes cloud connectivity achievable without compromising OT integrity.
Why This Matters When Selecting a Service Provider
Asset owners can apply this maturity model directly when evaluating:
- System Integrators bidding on new automation projects
- Maintenance Providers with recurring site access
- OEM Support Organizations performing remote diagnostics
- Long-Term Service Contractors embedded in day-to-day operations
A provider at ML1 may still be acceptable for low-risk, tightly scoped work — but should not be given standing remote access to a SIS or unsupervised access to engineering workstations without compensating controls. A provider at ML3 or ML4, by contrast, is a candidate for broader trust and reduced oversight overhead, because they can demonstrate — not just claim — that their security practices are consistent and improving.
This turns “do you have a security policy?” into a much more useful procurement question: at what level of maturity does this provider actually operate, and does that match the risk of the access we are about to give them?
Conclusion: Third-Party Risk Is Operational Risk
Service provider cybersecurity is not a side issue in OT environments — it is a direct input into operational resilience and process safety. Every integrator, maintenance contractor, and OEM with access to the Automation Solution is, in effect, an extension of the asset owner’s own security posture, whether that relationship has been formally managed or not.
ISA/IEC 62443-2-4 gives asset owners a structured, internationally recognized way to define, assess, and improve that posture — without needing to write a cybersecurity standard from scratch for every contract.
Used as a practical framework rather than a compliance exercise, ISA/IEC 62443-2-4 turns service provider cybersecurity from an assumption into something asset owners can actually verify.