IEC 62443 family overview for product manufacturers

The IEC 62443 series (formerly ISA-99) was developed jointly by the International Society of Automation (ISA) and the International Electrotechnical Commission (IEC) to cover the full lifecycle of industrial automation and control system (IACS) cybersecurity — from asset-owner programs, through system architecture and zoning, down to the components and the development processes that produced them. Each part is written for a specific stakeholder group, and you should not read them all unless you are an integrator with end-to-end responsibility.

Hardware product manufacturers are mostly affected by -4-1 and -4-2, which describe respectively the secure development lifecycle and the technical security requirements that an IACS component (controller, gateway, sensor, networked device) must satisfy. Both parts are increasingly cited in the European compliance landscape — the Cyber Resilience Act (Regulation (EU) 2024/2847) and the Radio Equipment Directive 2014/53/EU supplemented by Commission Delegated Regulation (EU) 2022/30 — so it pays to understand which document does what before you start collecting evidence.

How the family is organised

The series is split into four working categories. The [IEC 62443 overview](https://www.iec.c h/blog/understanding-iec-62443) describes them as General, Policies and Procedures, System, and Component, with two further evolving categories for Profiles and Evaluation methodology.

Per the ISA standards catalogue, the currently published anchor documents include ISA-62443-1-1-2007 (terminology), ANSI/ISA-62443-2-1-2024 (asset-owner program — re-edition), ANSI/ISA-62443-2-4-2018 (service providers), ANSI/ISA-62443-3-2-2020 (risk assessment for system design), ANSI/ISA-62443-3-3-2013 (system security requirements), ANSI/ISA-62443-4-1-2018 (secure product development) and ANSI/ISA-62443-4-2-2018 (component requirements). The IEC versions of -4-1 and -4-2 carry essentially identical technical content under the IEC numbering.

IEC 62443-1-1 — terminology, concepts and models

Part 1-1 is the dictionary. It defines the core vocabulary (asset, zone, conduit, security level, foundational requirement) and the reference models that the rest of the series uses. The most consequential concepts introduced here are:

• Zones and conduits. Systems are grouped into homogeneous zones with shared security requirements; communication between zones flows through conduits whose security properties are explicitly engineered.
• Security Levels (SL 0-4). Each Foundational Requirement can be specified at a level reflecting the attacker capability the design defends against. SL 1 covers casual misuse; SL 4 advanced attackers with extensive resources.
• Seven Foundational Requirements (FRs). FR 1 Identification and authentication control, FR 2 Use control, FR 3 System integrity, FR 4 Data confidentiality, FR 5 Restricted data flow, FR 6 Timely response to events, FR 7 Resource availability.

You will see these terms reused everywhere downstream — in -3-3 (system requirements) and -4-2 (component requirements) the FRs map directly to System Requirements (SRs) and Component Requirements (CRs).

IEC 62443-2-1 and -2-4 — for whoever runs the plant

-2-1 (security program for asset owners) describes how an operator of an IACS facility — a chemical plant, a water utility, a factory — establishes a documented cybersecurity management system (CSMS) covering governance, risk management, training, incident response and so on. It is the IACS equivalent of an information-security management system. The 2024 re-edition (ANSI/ISA-62443-2-1-2024) tightens alignment with the rest of the family.

-2-4 (service providers) lists the security requirements that integrators and maintenance contractors must meet when working on an asset owner's IACS — staffing, access control, change management, handover documentation, sub-contractor governance.

For a component manufacturer these two parts are usually not in scope unless you operate your own factory under IEC 62443 or you offer managed services on top of your hardware. They are still worth understanding because your customers will be reading them.

IEC 62443-3-2 and -3-3 — for the system integrator

-3-2 (risk assessment for system design) is the methodology for partitioning an IACS into zones and conduits, performing a security risk assessment per zone, and assigning target Security Levels. It is process-heavy and largely site-specific.

-3-3 (system security requirements and security levels) sets out, per Foundational Requirement and per Security Level, the System Requirements (SRs) a complete IACS must meet. It is the document that auditors point to when they ask "is this control system SL-2 capable?"

Hardware manufacturers should know -3-3 exists because the System Requirements are the conceptual parent of the Component Requirements in -4-2 — if your customers are designing to SL-2 system-wide, they will expect components that can support SL-2 capability.

IEC 62443-4-1 — secure product development lifecycle

This is the standard against which a manufacturer's processes are audited. Per the IEC catalogue entry for 62443-4-1, the standard specifies process requirements for secure development of products used in IACS, addressing the full lifecycle:

• Security management
• Security requirements definition
• Secure design (including defense-in-depth and threat modeling)
• Secure implementation with coding guidelines
• Verification and validation
• Defect management and security update management
• Patch management
• Product end-of-life considerations

The standard applies to developers and maintainers handling hardware, software or firmware — not to integrators or end users. It is the closest thing the industrial world has to a "secure SDLC" standard, and it is the part most often cited by ISASecure certification, IECEE CB Scheme assessments, and informally by CRA reviewers when asking how a manufacturer handles vulnerability disclosure and update delivery.

If you are starting from zero, -4-1 is the part to internalise first: it gives you the process backbone that downstream certifications and the CRA's Annex I Part 2 vulnerability-handling requirements then plug into. See CRA Annex I explained for the regulatory mapping.

IEC 62443-4-2 — technical security requirements for components

Part 4-2 is where individual products live. Published in February 2019 (latest IEC catalogue confirms IEC 62443-4-2:2019, 192 pages, stability date 2027, with August 2022 corrigendum incorporated), the standard delivers "detailed technical control system component requirements (CRs) associated with the seven foundational requirements (FRs)" for IACS components.

The technical content is structured around:

• Common Component Security Constraints (CCSC) — four overarching constraints that apply regardless of FR (system context awareness, compensating controls, least privilege, compliant development processes).
• Component Requirements (CRs) — per-FR requirements that a component must satisfy. Each CR has Requirement Enhancements (REs) that lift the component from one SL to the next.
• Component types — software application, embedded device, host device, network device. Different CRs apply depending on what kind of component you are building.
• SL-Capability declaration — the manufacturer declares the capability level (SL-C) the component reaches per FR. The system integrator then combines components to meet a system-wide target SL.

For a hardware manufacturer, -4-2 is the closest equivalent to a normative "what does your product have to do" document. A networked controller that supports certificate-based authentication, signed firmware updates, role-based access control, audit logging and brute-force lockout is, in the language of -4-2, building toward SL-2 capability on FR 1 and FR 3.

EN 18031 cross-reference

Under the Radio Equipment Directive, EN 18031-1, -2 and -3 are the harmonised standards published in late 2024 to give presumption of conformity with RED Article 3(3) points (d) network protection, (e) personal data and privacy, and (f) fraud protection, applicable from 1 August 2024 per Commission Delegated Regulation (EU) 2022/30.

EN 18031 includes an informative Annex B mapping its requirements to EN IEC 62443-4-2:2019. The mapping is informative — meaning manufacturers cannot claim RED conformity by pointing to IEC 62443 alone — but it is practically useful in two directions:

• A manufacturer who already has EN IEC 62443-4-2:2019 evidence (test reports, CRs satisfied) can reuse a significant share of that evidence as input to the EN 18031 conformity argument.
• A manufacturer doing EN 18031 work for RED can structure their security architecture in a way that later supports a 62443-4-2 assessment for industrial customers, without rebuilding everything.

This is one of the cleaner cross-regime synergies in EU cybersecurity right now, and it is worth designing for from day one rather than retrofitting.

What to do with this map

For a practical hardware compliance program:

1. Anchor on -4-1. Set up your secure development lifecycle so vulnerability handling, threat modeling and update management exist as repeatable processes. CRA Annex I Part 2 then becomes a derivative of work you already did.
2. Anchor on -4-2. Choose the SL-Capability you target per FR — based on customer requirements (industrial customers often ask for SL-2) and the regulatory floor (CRA Annex I Part 1, EN 18031 baseline).
3. Treat -3-3 as a translation layer. When customers send you system-level requirements, map them down to your -4-2 CRs rather than reinventing.
4. Cross-reference EN 18031. If your product falls under RED Article 3(3)(d)(e)(f), the Annex B mapping is your cheapest path to dual coverage.
5. Leave -2-1 and -2-4 to your customers. Unless you also operate IACS facilities, those are not your audit scope.

Common mistakes

• Treating IEC 62443 as one standard. It is a family with seven-plus published parts written for different audiences. Asking "are you 62443-compliant?" without specifying the part is meaningless — and treating asset-owner program requirements as if they applied to a component vendor wastes weeks of effort.
• Assuming -4-2 alone is enough. Component requirements without the development-process backbone of -4-1 will fail any serious audit. Both parts are needed for ISASecure CSA certification.
• Confusing target SL (SL-T) and achieved SL (SL-A) with capability SL (SL-C). The manufacturer declares SL-C for the component; the asset owner sets SL-T for the system; the integrator delivers SL-A. Mixing these terms in a datasheet is an immediate credibility hit.
• Citing IEC 62443 as CRA harmonised evidence today. The CRA harmonised standards list is still being built by CEN-CENELEC and ETSI per the European Commission's CRA standardisation request. Until harmonised versions are listed in the Official Journal, IEC 62443 evidence supports a presumption argument but does not by itself give automatic presumption of conformity with CRA Annex I.
• Treating EN 18031 Annex B as normative. It is informative. Manufacturers must still demonstrate compliance with EN 18031 requirements directly, with IEC 62443 evidence used as supporting material rather than as a substitute.

How Cenitia helps

Cenitia is building an EU compliance platform for connected hardware that maps your product's security architecture across the CRA, RED, EN 18031 and IEC 62443 frameworks simultaneously. Each technical claim you make — signed updates, role-based access control, brute-force lockout, audit logging — is recorded once, then projected into the artefacts each regime wants (technical file sections, declaration of conformity references, vulnerability handling policy, Annex B mapping table).

For IEC 62443 specifically, the platform helps you declare SL-Capability per Foundational Requirement, generate the evidence index a notified body or ISASecure assessor will ask for, and keep the cross-references to EN 18031 and CRA Annex I in sync as standards evolve. When -4-2 is amended or a new harmonised version is listed in the Official Journal, your existing technical file is flagged for review automatically.

Frequently asked questions

Which IEC 62443 parts matter most for a hardware product manufacturer?

For product suppliers, the two practical anchors are IEC 62443-4-1 (secure product development lifecycle) and IEC 62443-4-2 (technical security requirements for IACS components). Asset-owner and service-provider parts (-2-1, -2-4) and system-integration parts (-3-2, -3-3) are written for the operators of industrial facilities, not for component vendors.

Is IEC 62443 mandatory under the EU Cyber Resilience Act?

No. The CRA Regulation (EU) 2024/2847 sets essential cybersecurity requirements in Annex I but does not name a specific standard. IEC 62443-4-1 and -4-2 are widely used to demonstrate compliance with CRA's secure-development and product-property requirements, and parts of the family are expected to be cited in CRA harmonised standards published by CEN-CENELEC and ETSI.

How is IEC 62443 connected to EN 18031 under the Radio Equipment Directive?

EN 18031-1/-2/-3 are the harmonised standards for RED Article 3(3)(d), (e), (f), activated by Commission Delegated Regulation (EU) 2022/30 from 1 August 2024. EN 18031 contains an informative mapping annex to EN IEC 62443-4-2:2019, helping manufacturers reuse component-security evidence across both regimes — but EN 18031 conformity is what triggers presumption of conformity for RED radio products, not IEC 62443 directly.

What are the Security Levels (SL 1-4) in IEC 62443?

IEC 62443 defines four security levels reflecting attacker capability: SL 1 protects against casual or accidental misuse; SL 2 against intentional violation using simple means; SL 3 against sophisticated attackers with moderate resources and IACS-specific knowledge; SL 4 against advanced attackers with extensive resources. Manufacturers declare the SL-Capability their component can achieve per Foundational Requirement.

What are the seven Foundational Requirements (FRs)?

Per IEC 62443-1-1 and -3-3, the seven Foundational Requirements are: FR 1 Identification and authentication control, FR 2 Use control, FR 3 System integrity, FR 4 Data confidentiality, FR 5 Restricted data flow, FR 6 Timely response to events, and FR 7 Resource availability. IEC 62443-4-2 derives component-level Component Requirements (CRs) from these seven FRs.

Do I need certification, or is self-assessment enough for IEC 62443?

Both routes exist. Third-party certification schemes — ISASecure CSA (Component Security Assurance) and IECEE CB Scheme — certify products to IEC 62443-4-1 and -4-2. Self-declaration is also possible. Notified bodies such as TÜV, DEKRA and Bureau Veritas offer recognised audits. For CRA Class III important products or notified-body conformity assessment, third-party evidence will usually be expected.

Related from the Library

• EN 18031 parts 1, 2, 3 comparison — the harmonised standards that cross-reference IEC 62443-4-2 in Annex B.
• CRA Annex I explained — how the CRA essential cybersecurity requirements map to IEC 62443-4-1 and -4-2 evidence.
• RED CRA overlap for connected radio — how products under both RED and CRA can reuse 62443 evidence.
• SBOM CycloneDX vs SPDX for hardware — the SBOM dimension referenced by IEC 62443-4-1 patch management.
• Technical file 101 — how IEC 62443 evidence is filed inside the EU technical documentation.

Further reading

• IEC blog — Understanding IEC 62443 — the IEC's own overview of the family structure.
• IEC 62443-4-2:2019 catalogue page — official scope, edition, stability date.
• IEC 62443-4-1:2018 catalogue page — secure product development lifecycle reference.
• ISA standards index — ISA/IEC 62443 series — full list of ANSI/ISA editions.
• Commission Delegated Regulation (EU) 2022/30 — RED Article 3(3) (d), (e), (f) activation including the 1 August 2024 application date.
• Cyber Resilience Act — Regulation (EU) 2024/2847 — the EU horizontal cybersecurity regulation referencing harmonised standards under development.
• European Commission — Cyber Resilience Act policy page — current CRA standardisation activity.

Last reviewed: 5 July 2026. Cited regulations watched continuously by Cenitia — when one amends, this article is flagged for update.