Third-Party Security in ICS

The Update That Was Not a Software Update

In early 2014, engineers at energy facilities across the United States, Europe, and Turkey downloaded a software update from their ICS vendor's official website. They ran the installer. They saw the confirmation screen. They went back to work. What they had installed was a reconnaissance tool belonging to a Russian intelligence service. No exploit was required. No phishing email arrived. The attack required only a trust relationship -- the one between an ICS vendor and the customers who download updates from that vendor's official distribution server. Chapter 7 introduced supply chain risk through the NotPetya attack: an accounting software vendor became an unwitting delivery vehicle for one of the most destructive pieces of malware ever deployed. Chapter 13 covers the structured methodology that IEC 62443 provides for managing that risk: how to classify the third parties who touch your ICS, what security capabilities to require from them and how to verify those capabilities, what makes a product secure before it ships, and how to measure whether the controls you put in place are actually being used -- or just installed.

Three Service Provider Roles, Three Risk Profiles

ISA/IEC 62443 defines three distinct categories of IACS service provider, each with a different relationship to the system lifecycle and a different security risk profile. An Integration Service Provider designs, installs, and configures the control system. They are the organization that builds the architecture, programs the PLCs, configures the SCADA system, and hands the system over to the asset owner. Their work begins at design and ends at formal handover. A Maintenance Service Provider handles the system after handover -- patching, firmware upgrades, configuration changes, and ongoing technical support during the operational phase. They have continuing access to a live system over months and years. A Product Supplier manufactures the hardware or software components embedded in the system: the PLC firmware, the HMI software, the switch operating system, the historian database. They typically never visit the customer's site, but every firmware vulnerability they shipped, every hardcoded service account they left in, and every unencrypted protocol the device speaks was a decision made during their development process -- and it follows the product into every facility that buys it. The handover boundary is the most consequential definition in this classification. Integration activities end when the asset owner takes formal control of the system. Maintenance activities begin at that same moment. An integrator who continues work after handover -- without a formal maintenance agreement that applies maintenance-phase security requirements to that ongoing work -- has moved into a second role without the controls that role demands. Accountability for what they touch becomes unclear, and the controls designed for each phase do not apply cleanly. Internal engineering departments that design, integrate, and maintain their own automation systems are not exempt. ISA/IEC 62443 makes no distinction between internal teams and external providers performing the same functions. The requirements that apply to an external integrator apply equally to an internal engineering group doing the same integration work. Being an employee does not reduce the security risk of an unreviewed service account or an undocumented remote access credential.

Evaluating Integration and Maintenance Providers: The 12 SP Areas

When you hire an integrator to commission a new control system, you are outsourcing a portion of your security program whether you have explicitly decided to or not. ISA/IEC 62443-2-4 makes explicit what you are outsourcing -- and what you should be requiring -- through twelve functional security program areas that integration and maintenance service providers must be able to demonstrate on request. A provider claiming conformance can show, with evidence, that these capabilities exist in their organization and are consistently practiced. The twelve areas cover every dimension of how a service provider manages security across your system lifecycle. ISA/IEC TR 62443-6-1, published in 2024, adds four maturity levels (ML1 through ML4) that can be assigned per area, allowing a provider to show where they have repeatable, documented processes and where they do not. A provider can claim different maturity levels for different SP areas, which gives asset owners a granular view of capability before any work begins on site.

Two SP areas deserve particular attention because they map to documented, recurring failure modes. SP.07 Remote access matters because every vendor remote session is a potential entry point into the control network. A provider who cannot demonstrate an ML2 or higher maturity level for remote access management -- documented procedures, access logging, time-bounded sessions -- represents a risk gap that will materialize during the first maintenance window. SP.09 Account management matters because shared accounts and undocumented credentials are the mechanism by which post-maintenance access persists invisibly after a job closes. An integrator who leaves a service account active because "it might be needed later" has created standing access with no audit trail and no expiry. Asset owners can and should require specific SP area coverage at specific minimum maturity levels as contract terms before work begins. The standard provides the framework for asking the question and a shared language for interpreting the answer.

Product Security: The Secure Development Lifecycle and SL-C

ISA/IEC 62443-4-1 applies to product suppliers -- the organizations that build PLC firmware, HMI software, embedded components, and the network infrastructure inside control systems. It defines a secure development lifecycle that requires threat modeling during the design phase, defense-in-depth architecture in the product structure, security testing before release, and a documented process for handling vulnerabilities after the product ships. Threat modeling asks how an attacker could misuse a product feature -- during design, before code is written. A diagnostic port that exposes all register values without authentication is detectable in a threat model during design. Without threat modeling, that same port ships in ten thousand devices and appears in vulnerability disclosures years later. The economics are straightforward: finding security weaknesses during development costs engineering time. Finding them after deployment may cost a production shutdown across every customer who installed the device. ISA/IEC 62443-4-2 addresses the technical security requirements for individual ICS components -- software applications, embedded devices, network components, and host devices. Each component can be assessed against its Security Level Capability: the security level the component achieves when properly configured, without requiring compensating controls from elsewhere in the system. SL-C is the component-level expression of the security level concept introduced in Chapter 6 and applied to zone design in Chapter 12. The system integrator uses the SL-T values from the zone risk assessment to select components. A zone requiring SL-T of 2 requires components with SL-C of 2 or higher. A component with a lower SL-C can be used, but only with explicitly documented compensating controls that bring the achieved protection level up to the SL-T. That documentation is not optional -- it is the mechanism that connects the risk assessment to the design accountability record. A component without a published SL-C rating means the integrator is working without verified capability data. ISA Secure is a conformance certification program that independently evaluates product suppliers against both 62443-4-1 and 62443-4-2, using CMMI-DEV maturity levels to assess how repeatable and sustained the vendor's development process is. A certified product gives asset owners independently verified evidence that the vendor's security claims reflect a genuine, audited process rather than marketing language.

The Security Protection Scheme: Is Your Security Actually Working?

The Security Program -- governed by ISA/IEC 62443-2-1 -- is the organization-wide cybersecurity framework introduced in Chapter 7: the policies, procedures, and integration activities that apply across the organization. The Security Protection Scheme is more specific. Governed by ISA/IEC 62443-2-2, it is the set of technical, physical, and process security measures applied to one particular IACS to address its specific cybersecurity risks. The Security Program sets the standard. The SPS is what you actually put in place for this system. The SPS is built from three inputs: the asset owner's Security Program requirements, the operational and enterprise constraints that limit available options, and the acceptable level of residual risk established by the risk assessment from Chapter 12. For each zone in the system, the applicable IEC 62443 requirements are identified, the required security measures are selected, and the combination of those measures becomes the SPS for that zone. The SPS is not an output of the design phase that gets filed when commissioning ends. It mirrors the system lifecycle: it must be validated before operation begins, actively maintained throughout the operational phase, updated whenever the system or threat environment changes, and applied through decommissioning to ensure the end-of-life process does not introduce new exposure.

Security Protection Ratings: Measuring the Gap Between Installed and Working

You can have multi-factor authentication configured on every remote access endpoint and still have technicians sharing a single generic account because nobody removed the workaround added during commissioning. The controls are installed. They are not working. That gap -- between what the security documentation describes and what actually happens during a routine maintenance window -- is exactly what the Security Protection Rating framework exists to make visible and measurable. Three SPR types exist. The Target SPR is the security level the asset owner requires, established during the risk assessment. The Implemented SPR reflects the security capability provided by the installed technical and process measures -- what the system could achieve if every control were operating as designed. The Operated SPR reflects what is actually demonstrated during real operation, accounting for whether the supporting processes are consistently and correctly performed. Scores range from 0, meaning not addressed, to 4, meaning fully operational, repeatable, and sustained. A security requirement is considered fulfilled only when two conditions are simultaneously true: the required technical or process capability exists, and the organizational processes that support it are consistently practiced. A firewall rule being in place does not fulfill a network segmentation requirement if the process for reviewing and updating that rule after system changes is not being followed. The Operated SPR measures both conditions. An Implemented SPR of 3 alongside an Operated SPR of 1 is a management fact: the investment was made, the controls are installed, and they are not being used consistently. That fact can be acted on through training, process redesign, or accountability assignment. An unmeasured gap stays invisible until something goes wrong.

Security Profiles: When the Standard Gets Sector Translation

IEC 62443 was designed to apply everywhere -- from a water treatment plant to an offshore platform to a hospital automation system. That breadth is its engineering strength. It is also why applying it to a specific sector requires translation. A security profile, governed by IEC Technical Specification 62443-1-5, is a structured selection of IEC 62443 requirements tailored to a specific industry, application, or operational environment. A profile does not create new requirements and cannot change the meaning of existing ones. It selects a subset of the standard's foundational and system requirements, maps them to the specific operational context, and specifies which are mandatory for this sector, which are optional, and which do not apply to the operational environment. The US Department of Energy, working with ISA99 Working Group 14, developed a reference architecture for electric energy OT systems from which sub-profiles for substations, generation facilities, distributed energy resources, and operations centers can be derived. A shared sector profile creates consistency that a horizontal standard cannot provide on its own: grid operators work to a common baseline, product suppliers know exactly which security features procurement will evaluate, and comparisons across vendors become consistent rather than dependent on each buyer's individual interpretation of the full standard. When a sector-specific profile exists, it represents the accumulated judgment of the people closest to that sector's threat environment about which requirements matter most and in what priority order. A poorly aligned profile -- one that excludes relevant requirements without documented justification -- creates exploitable gaps. Substation security is a different problem from water treatment security, and the people who operate those environments are best positioned to make those distinctions. If a profile exists for your sector, use it rather than applying the full horizontal standard without sector context.

What's Next

Chapter 13 has covered the third-party dimension of ICS security: the three service provider roles and their lifecycle boundaries, the twelve SP areas for evaluating integrators and maintenance providers, the secure development lifecycle and SL-C framework for evaluating products, the Dragonfly supply chain attack that demonstrated the vendor trust relationship as an attack surface, the Security Protection Scheme as the system-specific implementation of the organization-wide program, Security Protection Ratings as the mechanism for measuring whether controls are installed or actually working, and security profiles as the mechanism for translating the broad IEC 62443 standard into sector-specific guidance. The final chapter closes the book with a short reflection on what you can now do, and where to go from here to build practical capability on the foundation this book has laid.

Reflect

• The Dragonfly attack compromised the vendor's download server and relied on the absence of binary signing and cryptographic hash verification. For the last ICS software update installed in your environment, was there an independent mechanism to verify that the downloaded installer matched what the vendor published -- a signed binary, a published SHA hash, or a verification step in the update procedure? If not, what would a Havex-class attack look like in your environment today?
• The SP area framework allows different maturity levels per area. For any integrator currently under contract or under evaluation, which SP areas has the contract explicitly required them to demonstrate -- and at what minimum maturity level? SP.07 Remote access and SP.09 Account management are the two areas most commonly associated with post-maintenance access persistence. Are those two covered in the contract terms?
• The SPS distinction between Implemented SPR and Operated SPR captures the gap between installed controls and consistently working controls. For any security control implemented in your organization in the past two years -- a new authentication requirement, a network segmentation change, a session logging deployment -- has the Operated state been measured? Is there a process to detect when the control is installed but not being consistently followed?
• Security profiles provide sector-specific translation of IEC 62443 requirements. For your primary operational sector -- energy, water, manufacturing, oil and gas, transportation -- does a published IEC 62443-1-5-compatible profile exist that your organization is working toward? If your organization is currently applying the full horizontal standard without a sector profile, who is responsible for making the inclusion and exclusion decisions that the profile would otherwise standardize?