IEC 62443 Explained: 4-1, 4-2, 3-3, Security Levels and Certification for Product Companies

IEC 62443 is a series of international standards, developed by the IEC and ISA, for securing industrial automation and control systems (IACS). A product company selling into OT usually needs two parts: IEC 62443-4-1 for its secure development lifecycle and IEC 62443-4-2 for the technical security of a component, both certified by accredited certification bodies under the ISASecure or IECEE programs.

In a typical case, a gateway maker answering a utility RFP finds two lines in the security section: a certificate for the development process to IEC 62443-4-1, and a component certificate to IEC 62443-4-2 at a stated security level. The deal depends on a dated answer to both.

How the IEC 62443 Standard Is Organized: General, Policies, System and Component Parts

The IEC 62443 standard groups its parts into four clusters, and each cluster serves a different reader.

The seven foundational requirements defined in 62443-1-1 organize the technical requirements in both 3-3 and 4-2.

Who IEC 62443 Applies To: Asset Owners, Integrators, Service Providers and Product Suppliers

ISA lists four stakeholder groups for IEC 62443: asset owners (end users), automation product suppliers, integrators who build and maintain control system solutions and their components, and service suppliers who support the operation of control systems.

• Asset owners (a utility, a plant operator) own the security program in 2-1 and set target security levels for zones and conduits under 3-2.
• Integrators and service providers build and maintain the automation solution, against 2-4 for their capabilities and 3-3 for the system.
• Product suppliers (device, gateway, controller and industrial software vendors) build components, against 4-1 for the process and 4-2 for the product.

What IEC 62443-4-1 Requires: A Secure Development Lifecycle for Product Suppliers

IEC 62443-4-1 sets process requirements for developing and maintaining secure IACS products. Its IEC abstract lists the scope as security requirements definition, secure design, secure implementation (including coding guidelines), verification and validation, defect management, patch management and product end-of-life. The requirements apply to new or existing processes for hardware, software or firmware, and the abstract states they only apply to the developer and maintainer of the product.

An ISASecure-published presentation on the SDLA program groups 4-1 into eight practice areas:

IEC 62443-4-1 also rates process maturity. The same presentation describes maturity level 2 as process defined, level 3 as process practiced and level 4 as process improved. ISASecure offers an SDLA readiness evaluation and a full evaluation, which needs artifacts showing the process was followed.

SOC 2 change control produces part of this evidence. The SOC 2 secure development guide for self-hosted GitLab covers pipeline records, and the ISO 27001 A.8.28 secure coding guide covers coding guidelines.

What IEC 62443-4-2 Requires: Technical Security Requirements for IACS Components

IEC 62443-4-2 sets technical component requirements (CRs) under the seven foundational requirements and defines capability security levels for components, written SL-C(component). The IEC Systems Committee notes the requirements are derived from the system requirements in IEC 62443-3-3.

IEC 62443-4-2 covers four component types, defined on the ISASecure CSA page:

Higher capability security levels add requirement enhancements and further base requirements. For a product team, the seven foundational requirements become product features: user authentication (identification and authentication control), role-based permissions (use control), integrity of software and communications (system integrity), protection of sensitive data (data confidentiality), network segmentation support (restricted data flow), audit logs (timely response to events) and behaviour under load (resource availability).

What IEC 62443-3-3 Requires From System Integrators

IEC 62443-3-3 sets technical system requirements (SRs) for a control system under the seven foundational requirements and defines capability security levels for the system, SL-C(control system). Under IEC 62443-3-2, the asset owner splits the system into zones (groups of assets based on risk) and conduits (communication between zones), and assigns each a target security level, SL-T. IEC 62443-3-3 defines the capabilities the system needs to meet those targets.

A product company deals with 3-3 directly when it sells a complete system, such as a building automation platform with its own controllers, network and supervisory software; ISASecure SSA certifies systems to 3-3. A company selling a single component deals with 3-3 through the integrator, who needs the component to support the system's target levels.

IEC 62443 Security Levels SL 1 to SL 4: Capability and Target Levels

IEC 62443 security levels range from SL 1 to SL 4, and the IEC Systems Committee describes them this way: These security levels correlate the required set of countermeasures with the strength of a potential adversary, in order to counter different levels of risk. Each higher level answers a more capable adversary and adds requirements.

Two kinds of level appear in buyer documents:

• Capability security level (SL-C): what a component (4-2) or system (3-3) can deliver when configured as intended. CSA certificates state this level.
• Target security level (SL-T): what the asset owner needs for a zone or conduit, set through the 3-2 risk assessment.

A security level is more precisely a vector with one value per foundational requirement. The IEC page gives SL=(3,3,3,1,2,1,3) as an example for a zone where data confidentiality matters less than integrity and availability. IEC 62443-3-3 also allows compensating countermeasures, so a system can reach a level when a legacy component cannot support a feature directly.

How IEC 62443 Certification Works: ISASecure SDLA, CSA, SSA and IECEE

IEC 62443 certification for products comes from two main programs, ISASecure and IECEE. ISASecure states that its product assessments are conducted by a global network of ISO/IEC 17065 accredited certification bodies.

A CSA certification combines a lifecycle process assessment for component development (SDLPA-C), a review of security development artifacts (SDA-C), a functional security assessment (FSA-C) and vulnerability identification testing (VIT-C). ISASecure states that a CSA certificate at capability security level n includes a requirement for compliance to ISA/IEC 62443-4-1. A supplier needs a working 4-1 process before the component certificate.

A consultant helps build the secure development lifecycle, documentation and evidence; the accredited certification body assesses and issues the certificate. Truvo does the first and is not a certification body.

A Realistic IEC 62443 Sequence for a Product Company: 4-1 First, Then 4-2 for One Flagship Product

A product company new to IEC 62443 gets the most from building the 4-1 process first and then taking one flagship product through 4-2. The 4-1 process is a prerequisite for CSA, and it produces the artifacts every later product reuses.

1. Collect the customer requirements: which RFPs name 62443, which parts and which security levels.
2. Assess the development process against the eight 4-1 practice areas, recording what exists, what lacks evidence and what is missing.
3. Write the secure development lifecycle as a version-controlled document with named roles: threat modeling, security requirements, coding guidelines, security testing, defect handling and update delivery.
4. Apply it to one real release, so the threat model, design reviews, test results and vulnerability records exist as dated artifacts.
5. Set up vulnerability intake and update delivery. The SOC 2 vulnerability scanning guide for on-prem and the SOC 2 patch management guide for on-prem cover the internal side of both.
6. Choose the flagship product with the most revenue behind the 62443 requirement, and map it against the 4-2 requirements at the target capability security level.
7. Close the product gaps in the roadmap, write the security guidelines for customers, and commission penetration testing on the release. The SOC 2 pen testing guide for on-prem covers scoping test work on owned hardware.
8. Engage a certification body for SDLA and then CSA, or the IECEE route, and get its schedule before quoting dates to customers.

How IEC 62443 Relates to SOC 2, ISO 27001 and the EU Cyber Resilience Act

IEC 62443-4-1 and 4-2 assess a product and the process that builds it, while SOC 2 and ISO 27001 assess an organization and the service or management system it operates. A device maker with a cloud management portal often needs a SOC 2 report for the portal and 62443 certificates for the device. The shared security capabilities (secure development, vulnerability management, patching, incident response) let one program feed both. The SOC 2 Trust Services Criteria guide and the SOC 2 vs ISO 27001 comparison cover the organizational side.

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is law for products with digital elements sold in the EU, while IEC 62443 is a voluntary standard. CRA reporting obligations apply from 11 September 2026 and the main obligations from 11 December 2027. Using harmonised European standards gives a presumption of conformity. CEN, CENELEC and ETSI accepted the CRA standardization request (M/606) on 3 April 2025, and that work is ongoing, so check the current list of harmonised standards before relying on any 62443 part for CRA conformity.

IEC 62443 Turns Product Security Into a Certificate Industrial Buyers Accept

IEC 62443 gives industrial buyers a shared language for product security: 4-1 for how the product is built, 4-2 for what the component can do, 3-3 for the system, and security levels for how strong each needs to be. For a product company, the practical order is process first, then one flagship product. The SOC 2 for bare metal and on-prem infrastructure page covers the service side for companies that also operate their own platform.

Related Guides

• EU Cyber Resilience Act (CRA): What It Is, Timeline and Requirements for Hardware and Software Makers
• SOC 2 vs IEC 62443 vs ETSI EN 303 645: Which Does Your Hardware Customer Want?
• Is Firmware in SOC 2 Scope? OTA Updates, Signing Keys and Device Fleets

Frequently Asked Questions

What is IEC 62443?

IEC 62443 is a series of international standards for the security of industrial automation and control systems, developed by the IEC and ISA. Its parts cover general concepts (1-x), policies and procedures (2-x), system requirements (3-x) and component requirements (4-x), with roles for asset owners, integrators, service providers and product suppliers.

What is the difference between IEC 62443-4-1 and IEC 62443-4-2?

IEC 62443-4-1 covers the product supplier's secure development lifecycle: security requirements, secure design and implementation, testing, defect and patch management, and end-of-life. IEC 62443-4-2 covers the technical security capabilities of one component, such as an embedded device or software application, at capability security levels 1 to 4.

Who issues IEC 62443 certification?

Accredited certification bodies issue IEC 62443 certificates, under programs such as ISASecure (SDLA for 4-1, CSA and ICSA for 4-2, SSA for 3-3), which uses ISO/IEC 17065 accredited bodies, or IECEE Certificates of Conformity. Consultants help prepare the process, documentation and evidence, and the certification body performs the assessment.

Which IEC 62443 security level should a component target?

Asset owners set target security levels for zones and conduits under IEC 62443-3-2, and those levels appear in RFPs and integrator specifications. Each security level is a vector across the seven foundational requirements, so confirm the level per requirement before planning product changes.

Does IEC 62443 satisfy the EU Cyber Resilience Act?

IEC 62443 is a voluntary standard, and the CRA is law for products with digital elements sold in the EU. Harmonised standards give a presumption of CRA conformity, and the standardization work by CEN, CENELEC and ETSI is ongoing, so check the current list before relying on 62443.

Sources

• ISA, ISA/IEC 62443 Series of Standards
• IEC SyC Smart Energy, IEC 62443 background and organization
• IEC Webstore, IEC 62443-4-1:2018 Secure product development lifecycle requirements
• IEC Webstore, IEC 62443-4-2:2019 Technical security requirements for IACS components
• IEC Webstore, IEC 62443-3-3:2013 System security requirements and security levels
• ISASecure, Certification programs
• ISASecure, IEC 62443 CSA certification
• ISASecure (TUV Rheinland and Schneider Electric webinar), ISA/IEC 62443-4-1 audit and certification process
• ISA, Why Security Level 2 of Industrial Control System Components (2024)
• European Commission, Cyber Resilience Act summary
• CEN-CENELEC, CRA standardization request accepted by CEN, CENELEC and ETSI