Supply Chain Security for Industrial Automation (IEC 62443-2-4)

Industrial control systems are built by an ecosystem: automation vendors, system integrators, maintenance contractors, and software suppliers — all of whom receive access to plant networks, credentials, and source of truth. Every one of them is a potential entry point, and the attacks of recent years have demonstrated the pattern: the compromise enters through the supplier, not the plant. Supply chain security for OT means managing the risk that comes with every external party — through requirements, verification, and controlled access. IEC 62443-2-4 is the standard for security requirements on service providers (integrators, maintainers) working on industrial automation systems.

The OT Supply Chain Risks

  • Compromised tools and media — a contractor's laptop, a vendor's USB stick, or a software update carrying malware; the classic OT intrusion vector.
  • Excess access — accounts and remote connections that outlive the project; default credentials never changed; support access left permanently enabled.
  • Unverified personnel — subcontractors of subcontractors whose backgrounds, training, and security practices are unknown.
  • Software integrity — updates and patches that cannot be verified (no signatures), and open-source or third-party components with known vulnerabilities.
  • Knowledge exfiltration — plant configuration, documentation, and process data leaving with departing contractors.

Requirements on the Supplier (IEC 62443-2-4)

IEC 62443-2-4 defines security capabilities that service providers must implement when working on IACS, organized by requirement families: security management, specification of security requirements, security by design, and security during implementation and maintenance. In practice, the asset owner's procurement process should:

  1. Include security in the contract — the RFP and contract state: security responsibilities, required practices (credential handling, malware-free media, change documentation), reporting obligations, and the right to audit.
  2. Verify before access — require evidence: security certifications, the provider's own security policy, personnel vetting, and the specific people who will work on site.
  3. Scope the access — access (physical, network, remote) is granted per project, per person, with defined limits and an expiry; remote access is only through the plant's managed solution, never direct.
  4. Control the media and tools — maintenance laptops are plant-controlled (clean build, allowlisted), update media is verified and scanned, and files are transferred through controlled channels, not USB-to-USB.
  5. Define handover security — credentials changed at project end, access removed, documentation delivered, and the configuration's security settings verified (default passwords replaced).

Verification Without Paranoia

Verification must be proportionate to risk; a small, known local integrator and a global platform vendor warrant different processes. A practical verification scale: for routine work — checklist declarations and spot checks (are the laptops clean? are the credentials unique?); for high-risk work (network changes, security-relevant configuration) — evidence review and witnessed tests; for critical infrastructure — independent audits and, where justified, background checks. The key is that verification is real: an occasional surprise inspection reveals more than a binder of certifications.

Managing the Software Supply Chain

Software risk extends beyond the vendor's shipped product:

  • Update integrity — download updates only from official channels, verify signatures and checksums, test in a staging environment before production; vendor portals accessed from controlled machines.
  • Component inventory — record the software versions, libraries, and dependencies of the OT platforms (part of asset management); the Log4j-type events are survivable only with an inventory.
  • Vulnerability response expectations — the contract should state how the vendor communicates vulnerabilities and delivers patches (the CVSS-9-in-OT situation: the plant needs the vendor's timeline, not a press release).
  • OEM dependencies — for machines and packaged equipment, the machine builder is a supply chain node: define the security expectations for delivered machines (no default credentials, documented network behavior, supported update path).

Building the Program

  1. Maintain a supplier register: every external party with OT access, their scope, and their security status.
  2. Write the standard supplier security requirements (one page, referenced in every contract).
  3. Review supplier security status annually and at every contract renewal.
  4. Enforce access lifecycle: every supplier account has an owner, an expiry, and a review; removal is verified, not assumed.
  5. Audit the process: sampled projects reviewed for compliance with the requirements (access logs, credential changes, media controls).

Summary

Supply chain security for OT is procurement discipline plus access lifecycle: security requirements in every contract (per IEC 62443-2-4), verification proportionate to risk, controlled and expiring access, verified media and updates, and an audit loop. The vendor ecosystem is the plant's extended attack surface — managed as deliberately as the network itself. The best network design is moot if the contractor's laptop is the back door.