The people who know an industrial control system best, and hold the most access to it, usually work for someone else. System integrators build and commission automation solutions, OEMs and maintenance contractors support them for decades, and both arrive with laptops, USB media, remote access tools and engineering accounts that the asset owner often cannot see. IEC 62443-2-4 is the international standard that defines the security programme requirements an IACS service provider should be able to meet during integration and maintenance. This guide explains what the standard covers, how to turn it into contract and onboarding requirements, and how to control integrator identities, remote sessions, transient devices and project data. It is for OT security leads, procurement and contract managers, and integrators preparing to meet asset owner requirements; remote access architecture is covered in more depth in the OT Remote Access Guide.
Key takeaways
- Use the current edition. IEC 62443-2-4:2023 (Edition 2.0, 15 December 2023) replaced the 2015 edition, which the IEC lists as withdrawn from 15 December 2023. Contracts that still cite 2015 or the ISA 2018 adoption should be updated at renewal.
- 2-4 is about the provider's processes, 2-1 about yours. The asset owner's security programme sits in IEC 62443-2-1; 2-4 describes the capabilities a service provider brings to integration and maintenance work. You need both to fit together.
- Every integrator account is a privileged identity you do not employ. Named accounts, multi-factor authentication, time-bound access and session recording replace shared vendor logins and always-on VPNs.
- Transient devices and project files are access too. Integrator laptops, USB media and the project archives that hold controller logic and passwords need the same controls as network access.
- Offboarding is where it fails. Dormant third-party accounts and forgotten remote access paths are a recurring root cause; the Colonial Pipeline Ransomware Attack 2021 started from an unused VPN account with no MFA.
What IEC 62443-2-4 covers
IEC 62443-2-4, "Security for industrial automation and control systems, Part 2-4: Security program requirements for IACS service providers", is published by IEC TC 65. The IEC describes the 2023 edition as specifying a comprehensive set of requirements for security-related processes that IACS service providers can offer the asset owner during integration and maintenance activities of an Automation Solution. It allows profiles (subclause 4.1.4) that subset the requirements for particular industries, and some of its requirements are associated with the system and component requirements in IEC 62443-3-3 and 62443-4-2.
| Part | Who it is for | How it relates to third parties |
|---|---|---|
| IEC 62443-2-1 | Asset owner | The asset owner's security programme sets the rules service providers must follow. See the IEC 62443-2-1 Asset Owner Security Programme Guide |
| IEC 62443-2-4 | Integration and maintenance service providers | Processes the provider should be capable of: staffing, architecture, remote access, account management, patching, backup and more |
| IEC 62443-3-2 | Asset owner and integrator | Risk assessment, zones and conduits, target security levels the integrator designs to. See the IEC 62443-3-2 OT Risk Assessment Guide |
| IEC 62443-3-3 | Integrator | System security requirements the delivered solution must meet |
| IEC 62443-4-1, 4-2 | Product supplier | Secure development and component requirements for the products the integrator selects |
The first edition grouped its requirements into twelve functional areas, from solution staffing and architecture through wireless, safety instrumented systems, configuration management, remote access, event management, account management, malware protection, patch management and backup and restore, and allowed a provider to state a maturity level for each capability. Check the structure in the 2023 edition you buy before quoting requirement identifiers in a contract, because numbering may have changed.
Two practical consequences follow. First, 2-4 describes what a provider is capable of, not what it must do on your site: the asset owner selects which capabilities apply in the contract. Second, a provider claiming "62443-2-4 compliance" should be able to show which edition, which requirements and, where certification exists, the scope of that certificate. For certification routes see the ISA/IEC 62443 Certification Guide.
Turning 2-4 into contract and onboarding requirements
Write security requirements into the request for proposal and the contract, not into a later email. The table maps common capability areas to contract wording and the evidence to ask for.
| Capability area | Contract requirement (example) | Evidence to request |
|---|---|---|
| Staffing | Named personnel with security training; background checks to [Organisation] standard; notification of staff changes within 2 working days | Training records, list of assigned personnel |
| Architecture | Design to the zones, conduits and target security levels in the [Organisation] risk assessment | Zone and conduit drawings, security level justification |
| Remote access | Only through the asset owner's approved remote access platform; no provider-installed modems, cellular routers or remote access software | Statement of tools used, test of removal at handover |
| Account management | Named accounts only; no shared or default credentials left at handover; all credentials handed over and changed | Account list at handover, default password change record |
| Malware protection | All transient devices and media scanned and approved before connection | Scan logs, device register |
| Patch management | Patch qualification for supplied software within an agreed time after vendor release | Qualification reports, patch compatibility list |
| Backup and restore | Verified backups of all configurations and logic at handover and after each change | Restore test record |
| Event management | Report suspected incidents to [Organisation] within [x] hours; preserve logs | Incident contact, notification procedure |
| Configuration management | Deliver project files, configuration and documentation for every change | Change records matched to project archive |
See the Third-Party Security Contract Clauses Template and the Third-Party Incident Notification Clauses Guide for reusable wording, and tier providers by the access they hold using the Vendor Tiering and Inherent Risk Questionnaire Template.
Integrator identities and privileged access
Integrators and maintenance providers typically hold the highest privileges in an OT environment: engineering rights on controllers, local administrator on servers and workstations, and domain accounts in the OT directory. Treat them as privileged third-party identities from the first day.
- Named accounts in your directory: create accounts per person, in an OT directory or a dedicated third-party organisational unit, with an internal sponsor and an expiry date that matches the contract or project phase.
- No shared vendor accounts: generic logins such as
vendor,supportor the OEM's standard service password are the most common finding in OT access reviews. Where a device only supports a shared account, vault the credential and check it out per session. - MFA at the boundary: require multi-factor authentication for every third-party connection into the OT network, enforced at the remote access platform or intermediate system.
- Just-in-time privilege: keep accounts disabled until a work order is approved, enable for the window, then disable. See the Vendor Privileged Access Management Guide.
- Provider-side service identities: integrators often leave behind scripts, scheduled tasks, OPC or historian connectors and remote support agents that run under service accounts or API keys. Inventory them at handover and assign an internal owner. See the Service Account Security Guide.
- Remote support platforms are a supply chain: the BeyondTrust Breach 2024 showed a compromised API key in a remote support SaaS being used to reset local account passwords on customer instances. Ask how your provider's tools store keys and who can reach your sessions through them.
Remote access, transient devices and project data
Remote sessions
- One approved path: all third-party remote access through a broker in the industrial DMZ, with session approval by site operations, recording and the ability to terminate. No direct VPN into control zones.
- Hunt for side doors: cellular routers in cabinets, OEM remote access appliances and remote desktop tools installed during commissioning. CISA's Guide to Securing Remote Access Software notes that threat actors increasingly co-opt legitimate remote access tools, so inventory every one and remove what is not approved.
- Scope by asset: a provider supporting one packaged unit should reach only that unit's zone, not the whole site.
Transient cyber assets and media
- Registered laptops: integrator laptops that connect to OT networks are registered, scanned and checked for current patches before each visit, or replaced with asset owner provided engineering laptops for critical zones.
- Media control: USB media scanned at a kiosk, with removable media blocked on OT hosts except where approved.
- Visitor networks: provide a dedicated maintenance VLAN or port with restricted routing rather than letting laptops plug into the control network.
Project data
Integrator project archives contain controller logic, network drawings, IP plans and often passwords. Require encrypted storage, access limited to named staff, return or destruction at contract end, and notification if the provider suffers a breach. The Schneider Electric Jira Breach is a reminder that industrial suppliers' project systems are themselves targets.
Assessing a provider before award
Ask high-tier providers to answer these in writing during tender, and score the answers alongside price:
- Standard and scope: which edition of IEC 62443-2-4 do you align to, which capabilities do you offer, and is any certification scoped to the team that will work on our site?
- People: who will be assigned, what security training have they had, and how will you tell us when they leave the project?
- Tools: which remote access, engineering and diagnostic tools will you use, where are their credentials and keys stored, and can you work entirely through our remote access platform?
- Devices: are engineering laptops dedicated to OT work, centrally managed, encrypted and patched, and do they visit other customers' sites?
- Data: where will our project files and passwords be stored, who can access them, and what happens to them at contract end?
- Incidents: how quickly will you tell us about a breach of your own systems that could affect us, and who is the contact out of hours?
Weak answers do not have to disqualify a specialist provider, but they should translate into specific compensating controls in the contract, such as asset owner supplied laptops or supervised sessions only.
Rolling out a third-party access programme
- Inventory providers and access: list every integrator, OEM and maintenance contractor, the sites and zones they touch, the accounts they hold, the remote access methods they use and the devices they bring.
- Tier them: by the access held and the consequence of misuse (safety systems and controllers highest).
- Close side doors first: remove unapproved remote access tools and modems, disable shared vendor accounts and dormant third-party accounts.
- Stand up the approved path: brokered remote access with MFA, approval and recording. Pilot with one provider and one site, keeping the old path disabled but restorable for the pilot period.
- Update contracts at renewal: add 2-4 based requirements, notification clauses and handover obligations.
- Run handover checks: at project completion, verify accounts, credentials, remote tools, backups and documentation against the contract.
- Review quarterly: access reviews of third-party accounts with sponsors, and removal at contract end. See the Vendor Offboarding and Termination Guide.
Decision guidance: a small site with two or three providers can manage with named accounts, a jump host with MFA and manual approval. A multi-site operator with hundreds of providers needs a third-party identity lifecycle tied to contracts, a remote access platform with workflow and recording, and periodic assessment of high-tier providers against 2-4. Choose provider-managed remote access only when the provider supports a fleet of identical units across many customers, and then require the same MFA, approval and logging evidence.
Detection and measurement
- Log: every third-party session (who, when, which asset, approver), account enable and disable events, privileged actions on controllers and servers, and connections from any remote access tool not on the approved list.
- Alert: third-party logins outside an approved work window, use of a disabled or expired account, new remote access software on OT hosts, and engineering downloads from a laptop not in the transient device register. See the OT Network Security Monitoring Guide.
Metrics:
- Percentage of third-party OT accounts that are named, MFA-protected and time-bound.
- Number of shared or default vendor credentials remaining (target zero).
- Third-party accounts with no login in 90 days still enabled (target zero).
- Percentage of remote sessions brokered and recorded.
- Projects closed with a completed handover check.
Framework mapping
| Control | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | Threat (ATT&CK for ICS v20) |
|---|---|---|---|
| Security requirements in provider contracts | SA-9, SR-6 | GV.SC-05, GV.SC-07 | T0862 Supply Chain Compromise |
| Named, time-bound third-party accounts | AC-2, PS-7 | PR.AA-02, PR.AA-05 | T0859 Valid Accounts |
| MFA and brokered remote access | AC-17, IA-2, MA-4 | PR.AA-03 | T0822 External Remote Services, T0886 Remote Services |
| No default or shared credentials | IA-5 | PR.AA-01 | T1694.001 Default Credentials |
| Transient devices and media | MP-7 | PR.PS-01 | T0864 Transient Cyber Asset, T0847 Replication Through Removable Media |
| Session logging and review | AU-12 | DE.CM-03 | Detection of the above |
| Offboarding at contract end | PS-7, AC-2 | GV.SC-10 | T0859 |
NIST SP 800-82 Rev. 3 (September 2023) is the US reference for OT security overall; NIST lists an initial public draft of Rev. 4 open for comment until 30 November 2026, so check for changes. See the NIST SP 800-82 OT Security Guide.
Common failure patterns
- Dormant third-party accounts: accounts created for commissioning that are never disabled; the Colonial Pipeline intrusion began with exactly this kind of unused VPN account.
- Shared OEM credentials: one support password used by every engineer at the provider and by the provider across every customer.
- Unmanaged remote access tools: remote desktop software installed during commissioning and left running with the provider's account.
- "62443 certified" accepted at face value: no check of edition, scope or which capabilities apply to your contract.
- No handover check: the project closes with default passwords on switches, test accounts on servers and no verified backup.
- Uncontrolled laptops: an integrator's laptop used across many customers' sites connects straight into a control network.
Lessons from incidents
The Colonial Pipeline case shows that an OT shutdown can follow from an IT-side identity failure: a legacy VPN account with a leaked password and no MFA, followed by a precautionary pipeline shutdown on 7 May 2021. The BeyondTrust case shows that the tools providers use to reach you can become the attack path. Both point to the same controls: named, MFA-protected and expiring access, and an inventory of every remote access route, including the provider's own platforms.
Practitioner checklist
- List every OT service provider with the sites, zones, accounts, remote access methods and devices it uses.
- Cite IEC 62443-2-4:2023 in new contracts and select the capabilities that apply to each engagement.
- Replace shared vendor logins with named, MFA-protected accounts that expire with the contract or work order.
- Route all third-party remote access through one brokered, recorded path with operations approval.
- Find and remove unapproved modems, cellular routers and remote access software.
- Register, scan and approve every transient laptop and USB device before connection.
- Require encrypted handling and return or destruction of project archives.
- Run a handover check covering accounts, credentials, remote tools, backups and documentation.
- Review third-party accounts quarterly with internal sponsors and disable unused ones.
Standards and references
- IEC: IEC 62443-2-4:2023, Security program requirements for IACS service providers
- IEC: IEC 62443-2-4:2015 (withdrawn)
- ISA: ISA/IEC 62443 Series of Standards
- IEC: Understanding IEC 62443
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology Security
- CISA: Guide to Securing Remote Access Software
- MITRE ATT&CK for ICS: External Remote Services
Related NHI Mgmt Group resources: OT Remote Access Guide · IEC 62443 Guide · Third-Party Access Guide · Vendor Privileged Access Management Guide · OT and ICS Identity and Access Guide