Under IEC 62443, you ask suppliers to meet requirements you have already set, not to be "62443 compliant" in general. Give them your target security levels and your cyber security requirements specification. Then ask product suppliers for evidence of secure development and component capability, and ask integrators and maintainers for evidence of their security processes and how mature those processes are. Which part answers which question IEC 62443 splits the work by role. An IACS (industrial automation and control system) involves an asset owner, product suppliers and service providers, and each has its own parts of the series. Asset owner: IEC 62443-3-2 covers the risk assessment, the zone and conduit model and the security requirements you hand to suppliers. Product supplier, development process: IEC 62443-4-1 sets requirements for a secure product development lifecycle. It applies to the developer and maintainer of a product, not to the integrator or user (IEC webstore abstract). Product supplier, capability: IEC 62443-3-3 sets system requirements by security level. IEC 62443-4-2 does the same for components: embedded devices, host devices, network devices and software applications (IEC webstore abstract; ISAGCA quick start guide). Integrator or maintainer: IEC 62443-2-4 sets requirements for the security processes that IACS service providers offer during integration and maintenance (IEC 62443-2-4:2023, Clause 1). What to put in the tender Start with your own requirements. IEC 62443-3-2 requires a target security level (SL-T) for each zone and conduit (IEC 62443-3-2:2020, ZCR 5.6). SL-T is the level of protection a zone or conduit needs, set from your risk assessment. Our guide to security levels explains how SL-T works. The results go into a cyber security requirements specification (CRS). This document records the mandatory countermeasures from the risk assessment, plus requirements from your own policies, standards and relevant regulations (IEC 62443-3-2:2020, ZCR 6.1). At a minimum it includes the system description, zone and conduit drawings and characteristics, operating environment assumptions, threat environment, security policies, tolerable risk and regulatory requirements (IEC 62443-3-2:2020, ZCR 6.2 to ZCR 6.9). The CRS does not need to be a single document. IEC 62443-2-4 describes the same pattern for services. The asset owner issues a request for quote with a statement of work that sets out its security policies and the service provider requirements it wants, then both sides agree the detail in the contract (IEC 62443-2-4:2023, 4.1.3). State in the tender what evidence you expect to see. What to ask a product supplier to show Development process (IEC 62443-4-1). Ask how the supplier develops and maintains the product securely. IEC 62443-4-1 groups its requirements into eight practices: security management, specification of security requirements, secure by design, secure implementation, security verification and validation testing, management of security-related issues, security update management and security guidelines (ISASecure public material; IEC webstore abstract). Threat modelling is a key part of the lifecycle, and the threat model should be kept up to date (ISAGCA quick start guide). Product capability (IEC 62443-3-3 and 4-2). Ask for the capability security level (SL-C) of each system or component. SL-C is the level a product can meet natively, without extra compensating countermeasures, when properly configured and integrated (IEC 62443-3-3:2013, A.2.2). Product suppliers state SL-C by comparing their features with the requirements of the series. The supplier or integrator must also give guidance on how to configure the product to meet the claimed level (IEC 62443-3-3:2013, A.2.3). Ask for that guidance as a deliverable. Where SL-C falls short of SL-T, compensating countermeasures need to be considered (IEC 62443-3-3:2013, A.2.3). What to ask an integrator or maintenance provider IEC 62443-2-4 lets an asset owner request specific security processes from a service provider, and check whether its security program includes the ones the owner needs (IEC 62443-2-4:2023, 4.1.2). The requirements are grouped into functional areas, including solution staffing, assurance, architecture, wireless, SIS, configuration management, remote access, event management, account management, malware protection, patch management and backup and restore (IEC 62443-2-4:2023, 5.5.3, Table 3). Service providers must state a maturity level for each requirement they implement, from 1 (Initial) to 4 (Improving). At level 3 (Defined), the provider has practised the process for an asset owner at least once (IEC 62443-2-4:2023, 4.2, Table 1). Ask for those maturity levels against the requirements you selected. Not every requirement applies to every provider, and you can ask for a subset (IEC 62443-2-4:2023, 5.1). How to treat the evidence A supplier's own statement, an independent assessment and a certificate are different things. Weigh them accordingly. The ISA Security Compliance Institute runs ISASecure certification programmes against IEC 62443-4-1, 4-2 and 3-3 (ISAGCA quick start guide). If a certificate is offered, read what it covers. "IEC 62443 compliant" on its own tells you nothing. Ask which part, which edition, which product and version, which security level and which scope. A certified development process under 4-1 is not the same as a certified component under 4-2. A component's SL-C also does not mean the zone it sits in reaches that level. Contract points Public guidance from CISA, the UK NCSC and partner agencies on choosing OT products adds points worth writing into the contract (CISA and partners, Secure by Demand, 2025): a clearly defined support period, with vulnerabilities managed and patches supplied during it a vulnerability disclosure programme and a commitment to timely fixes hardware and software bills of materials with the delivery a documented patch and upgrade process that you control secure defaults, with no default passwords From the standards, also specify remote access controls (IEC 62443-3-3:2013, SR 1.13; IEC 62443-2-4:2023, SP.07.XX), patch management by the service provider (IEC 62443-2-4:2023, SP.11.XX), and the configuration guidance to be delivered with the system (IEC 62443-3-3:2013, A.2.3). Set out what security documentation you need at handover, the point where responsibility for operation and maintenance passes to you (IEC 62443-2-4:2023, 3.1.9). Common mistakes and a short checklist Common mistakes: asking for "IEC 62443 compliance" without an SL-T or a CRS accepting a certificate without checking its part, scope and product version treating a product's SL-C as the security of the installed system leaving patching, support lifetime and remote access out of the contract Checklist: SL-T for each zone and conduit, from the risk assessment a CRS issued with the tender 4-1 evidence and SL-C per product, with configuration guidance 2-4 processes and maturity levels from the integrator and maintainer contract terms for patching, disclosure, support period, remote access and handover Where ControlShield can help ControlShield can write the SL-T and CRS content for your tender and set out the evidence to ask each supplier for. We can also review supplier responses against your requirements before you place the order. Sources IEC 62443-2-4, Security for industrial automation and control systems, Part 2-4: Security program requirements for IACS service providers, Edition 2.0, 2023 IEC 62443-3-2, Security for industrial automation and control systems, Part 3-2: Security risk assessment for system design, Edition 1.0, 2020 IEC 62443-3-3, Industrial communication networks, Network and system security, Part 3-3: System security requirements and security levels, Edition 1.0, 2013, with Corrigendum 1, 2014 IEC 62443-4-1, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, Edition 1.0, 2018 (public summary only: IEC webstore abstract and ISASecure public material, not the standard text) IEC 62443-4-2, Security for industrial automation and control systems, Part 4-2: Technical security requirements for IACS components, Edition 1.0, 2019, with Corrigendum 1, 2022 (public summary only: IEC webstore abstract, not the standard text) ISA Global Cybersecurity Alliance, "Quick Start Guide: An Overview of ISA/IEC 62443 Standards", 2024 (public summary) CISA and partner agencies including the UK NCSC, "Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products", January 2025 (public guidance)
Under IEC 62443, you ask suppliers to meet requirements you have already set, not to be "62443 compliant" in general. Give them your target security levels and your cyber security requirements specification. Then ask product suppliers for evidence of secure development and component capability, and ask integrators and maintainers for evidence of their security processes and how mature those processes are. Which part answers which question IEC 62443 splits the work by role. An IACS (industrial automation and control system) involves an asset owner, product suppliers and service providers, and each has its own parts of the series. Asset owner: IEC 62443-3-2 covers the risk assessment, the zone and conduit model and the security requirements you hand to suppliers. Product supplier, development process: IEC 62443-4-1 sets requirements for a secure product development lifecycle. It applies to the developer and maintainer of a product, not to the integrator or user (IEC webstore abstract). Product supplier, capability: IEC 62443-3-3 sets system requirements by security level. IEC 62443-4-2 does the same for components: embedded devices, host devices, network devices and software applications (IEC webstore abstract; ISAGCA quick start guide). Integrator or maintainer: IEC 62443-2-4 sets requirements for the security processes that IACS service providers offer during integration and maintenance (IEC 62443-2-4:2023, Clause 1). What to put in the tender Start with your own requirements. IEC 62443-3-2 requires a target security level (SL-T) for each zone and conduit (IEC 62443-3-2:2020, ZCR 5.6). SL-T is the level of protection a zone or conduit needs, set from your risk assessment. Our guide to security levels explains how SL-T works. The results go into a cyber security requirements specification (CRS). This document records the mandatory countermeasures from the risk assessment, plus requirements from your own policies, standards and relevant regulations (IEC 62443-3-2:2020, ZCR 6.1). At a minimum it includes the system description, zone and conduit drawings and characteristics, operating environment assumptions, threat environment, security policies, tolerable risk and regulatory requirements (IEC 62443-3-2:2020, ZCR 6.2 to ZCR 6.9). The CRS does not need to be a single document. IEC 62443-2-4 describes the same pattern for services. The asset owner issues a request for quote with a statement of work that sets out its security policies and the service provider requirements it wants, then both sides agree the detail in the contract (IEC 62443-2-4:2023, 4.1.3). State in the tender what evidence you expect to see. What to ask a product supplier to show Development process (IEC 62443-4-1). Ask how the supplier develops and maintains the product securely. IEC 62443-4-1 groups its requirements into eight practices: security management, specification of security requirements, secure by design, secure implementation, security verification and validation testing, management of security-related issues, security update management and security guidelines (ISASecure public material; IEC webstore abstract). Threat modelling is a key part of the lifecycle, and the threat model should be kept up to date (ISAGCA quick start guide). Product capability (IEC 62443-3-3 and 4-2). Ask for the capability security level (SL-C) of each system or component. SL-C is the level a product can meet natively, without extra compensating countermeasures, when properly configured and integrated (IEC 62443-3-3:2013, A.2.2). Product suppliers state SL-C by comparing their features with the requirements of the series. The supplier or integrator must also give guidance on how to configure the product to meet the claimed level (IEC 62443-3-3:2013, A.2.3). Ask for that guidance as a deliverable. Where SL-C falls short of SL-T, compensating countermeasures need to be considered (IEC 62443-3-3:2013, A.2.3). What to ask an integrator or maintenance provider IEC 62443-2-4 lets an asset owner request specific security processes from a service provider, and check whether its security program includes the ones the owner needs (IEC 62443-2-4:2023, 4.1.2). The requirements are grouped into functional areas, including solution staffing, assurance, architecture, wireless, SIS, configuration management, remote access, event management, account management, malware protection, patch management and backup and restore (IEC 62443-2-4:2023, 5.5.3, Table 3). Service providers must state a maturity level for each requirement they implement, from 1 (Initial) to 4 (Improving). At level 3 (Defined), the provider has practised the process for an asset owner at least once (IEC 62443-2-4:2023, 4.2, Table 1). Ask for those maturity levels against the requirements you selected. Not every requirement applies to every provider, and you can ask for a subset (IEC 62443-2-4:2023, 5.1). How to treat the evidence A supplier's own statement, an independent assessment and a certificate are different things. Weigh them accordingly. The ISA Security Compliance Institute runs ISASecure certification programmes against IEC 62443-4-1, 4-2 and 3-3 (ISAGCA quick start guide). If a certificate is offered, read what it covers. "IEC 62443 compliant" on its own tells you nothing. Ask which part, which edition, which product and version, which security level and which scope. A certified development process under 4-1 is not the same as a certified component under 4-2. A component's SL-C also does not mean the zone it sits in reaches that level. Contract points Public guidance from CISA, the UK NCSC and partner agencies on choosing OT products adds points worth writing into the contract (CISA and partners, Secure by Demand, 2025): a clearly defined support period, with vulnerabilities managed and patches supplied during it a vulnerability disclosure programme and a commitment to timely fixes hardware and software bills of materials with the delivery a documented patch and upgrade process that you control secure defaults, with no default passwords From the standards, also specify remote access controls (IEC 62443-3-3:2013, SR 1.13; IEC 62443-2-4:2023, SP.07.XX), patch management by the service provider (IEC 62443-2-4:2023, SP.11.XX), and the configuration guidance to be delivered with the system (IEC 62443-3-3:2013, A.2.3). Set out what security documentation you need at handover, the point where responsibility for operation and maintenance passes to you (IEC 62443-2-4:2023, 3.1.9). Common mistakes and a short checklist Common mistakes: asking for "IEC 62443 compliance" without an SL-T or a CRS accepting a certificate without checking its part, scope and product version treating a product's SL-C as the security of the installed system leaving patching, support lifetime and remote access out of the contract Checklist: SL-T for each zone and conduit, from the risk assessment a CRS issued with the tender 4-1 evidence and SL-C per product, with configuration guidance 2-4 processes and maturity levels from the integrator and maintainer contract terms for patching, disclosure, support period, remote access and handover Where ControlShield can help ControlShield can write the SL-T and CRS content for your tender and set out the evidence to ask each supplier for. We can also review supplier responses against your requirements before you place the order. Sources IEC 62443-2-4, Security for industrial automation and control systems, Part 2-4: Security program requirements for IACS service providers, Edition 2.0, 2023 IEC 62443-3-2, Security for industrial automation and control systems, Part 3-2: Security risk assessment for system design, Edition 1.0, 2020 IEC 62443-3-3, Industrial communication networks, Network and system security, Part 3-3: System security requirements and security levels, Edition 1.0, 2013, with Corrigendum 1, 2014 IEC 62443-4-1, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, Edition 1.0, 2018 (public summary only: IEC webstore abstract and ISASecure public material, not the standard text) IEC 62443-4-2, Security for industrial automation and control systems, Part 4-2: Technical security requirements for IACS components, Edition 1.0, 2019, with Corrigendum 1, 2022 (public summary only: IEC webstore abstract, not the standard text) ISA Global Cybersecurity Alliance, "Quick Start Guide: An Overview of ISA/IEC 62443 Standards", 2024 (public summary) CISA and partner agencies including the UK NCSC, "Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products", January 2025 (public guidance)