IEC 62443-4-1 and 4-2: A Complete Guide to Industrial Product Security Certification

IEC 62443 is the series of standards addressing the security of industrial automation and control systems. Its individual documents are designated as parts, and those parts are grouped into four categories: General, covering concepts and terminology; Policies and Procedures, covering the security programme of the asset owner and of service providers; System, covering risk assessment and system security requirements; and Components, covering the products from which a system is assembled.

Two parts within the Components category apply to equipment manufacturers. IEC 62443-4-1, Secure product development lifecycle requirements, specifies the process by which a product is developed. IEC 62443-4-2, Technical security requirements for IACS components, specifies the security capabilities the product itself must provide. Both are now cited in industrial tender documents and in sectoral regulation.

What Product Security Means

Most cybersecurity work in an industrial environment is performed after equipment has been installed, through network segmentation, access control, monitoring and procedural measures. Product security concerns an earlier stage: the capability engineered into a component during its development.

The distinction is more consequential in industrial environments than in enterprise information technology. A component is specified once and thereafter remains in service for a prolonged period, frequently measured in decades, and its security capabilities are fixed at the point of manufacture. Where a device provides no means of authenticating a user, verifying a firmware image or recording a configuration change, those functions cannot subsequently be introduced through configuration, and the operator must provide equivalent protection through the surrounding architecture and procedural controls for the remainder of the asset's service life. A decision taken during procurement therefore determines the security capability available to the plant for the working life of the equipment.

The Two Standards

The series allocates requirements according to the party responsible for meeting them, recognising three: the asset owner, who operates the industrial environment; the service provider, who integrates and maintains it; and the product supplier, who manufactures the equipment. It is this third party that Parts 4-1 and 4-2 address, and a manufacturer is accountable under them irrespective of the security programme its customer operates.

IEC 62443-4-1: Published as Edition 1.0 in January 2018, this part specifies the process requirements for the secure development of products. It is assessed against the development organisation rather than against any individual device.
IEC 62443-4-2: Published as Edition 1.0 in February 2019, with a corrigendum issued in August 2022, this part specifies the technical security requirements for IACS components. It is assessed against a specific product at a specific version.

The two are intended to be applied together. Part 4-2 additionally requires the component to have been developed under a process conforming to Part 4-1, so a component assessment will normally examine the development process alongside the device.

IEC 62443-4-1: The Development Process

Part 4-1 concerns the manner in which a manufacturer develops its products. Its requirements "apply to the developer and maintainer of the product, but not to the integrator or user of the product".

Because the subject of the assessment is a process, a certificate issued against Part 4-1 identifies the development organisation and the documented process to which it applies. It does not identify a product line, and asserts nothing regarding any particular device. A manufacturer may hold a valid Part 4-1 certificate while supplying a product of limited security capability, since the two parts address different questions.

The standard organises the development lifecycle into eight practices.

Security management: Thirteen requirements covering the development process, responsibilities, products in scope, security expertise and process verification. It extends to the conditions of development, requiring file integrity, development environment security and controls over private keys, and imposes requirements upon externally provided components.
Specification of security requirements: Five requirements covering the product security context, the threat model, the security requirements and their review. The threat model is specified here rather than at design, so that requirements derive from an identified threat.
Secure by design: Four requirements covering secure design principles, defence in depth design, security design review and secure design best practices.
Secure implementation: Two requirements covering secure coding standards and security implementation review.
Security verification and validation testing: Five requirements covering requirements testing, threat mitigation testing, vulnerability testing, penetration testing and independence of testers.
Management of security-related issues: Six requirements covering the receipt, review, assessment, resolution and disclosure of security-related issues, and periodic review of the practice itself.
Security update management: Five requirements covering the qualification and documentation of updates, updates to dependent components and operating systems, and the timely delivery of security patches.
Security guidelines: Seven requirements covering the product's defence in depth strategy, the measures expected of the environment, hardening, secure disposal, secure operation, account management and documentation.

Two characteristics of this structure merit attention.

Three practices apply after release: Management of security-related issues, security update management and security guidelines govern products already installed, and are continuing obligations rather than activities concluded at the end of a project.
Conformance is assessed by maturity: Each practice is measured against four levels: Initial, where the activity is ad hoc; Managed, where the process is documented and personnel trained in it; Defined, where it is practised across the organisation; and Improving, where its effectiveness is measured. Outcomes most frequently turn on the distinction between holding a documented procedure and evidencing that it was applied to a specific release.

IEC 62443-4-2: The Product Capability

Where Part 4-1 examines the manufacturer, Part 4-2 examines the equipment. Since industrial products vary considerably in the capability they can support, the standard defines four component types, each carrying additional requirements appropriate to its function.

Embedded devices: A "special purpose device designed to directly monitor or control an industrial process", such as a programmable logic controller or intelligent electronic device.
Host devices: A "general purpose device running an operating system capable of hosting one or more software applications, data stores or functions from one or more suppliers", such as an operator workstation.
Network devices: A "device that facilitates data flow between devices, or restricts the flow of data, but may not directly interact with a control process", such as a switch or virtual private network terminator.
Software applications: "One or more software programs and their dependencies that are used to interface with the process or the control system itself", such as configuration software or a historian.

Classification follows the nature of the product rather than its designation. A human machine interface may be an embedded or a host device according to whether it runs embedded firmware or a general purpose operating system, and a historian is a software application whereas the server hosting it is a host device. Classification is among the first matters to settle when scoping a programme.

Requirements are organised under the seven foundational requirements used throughout the series, allowing a component assessment to align with those defined for the system into which it is integrated.

Identification and authentication control: Fourteen requirements covering the authentication of human users, software processes and devices, account and authenticator management, authentication strength, and access via untrusted networks.
Use control: Thirteen requirements covering authorisation enforcement, session lock and termination, mobile code, non-repudiation and physical diagnostic interfaces. The generation of audit records is specified here rather than under timely response to events.
System integrity: Fourteen requirements, the most extensive of the seven, covering communication integrity, protection from malicious code, software and information integrity, input validation, deterministic output, support for updates, physical tamper resistance, roots of trust and boot process integrity.
Data confidentiality: Three requirements covering information confidentiality, persistence and the use of cryptography.
Restricted data flow: Four requirements covering network segmentation, zone boundary protection, restrictions upon general purpose communication and application partitioning.
Timely response to events: Two requirements covering audit log accessibility and continuous monitoring, a narrower scope than the title suggests.
Resource availability: Eight requirements covering denial of service protection, resource management, backup and recovery, emergency power, configuration settings, least functionality and component inventory.

Above these sit four common component security constraints. Support of essential functions establishes that a component's security capabilities must not compromise the essential functions of the process, and governs the application of every other requirement. Software development process requires the component to have been developed under a process compliant with Part 4-1, and is the provision establishing the product standard's dependency on the process standard.

Security Levels

IEC 62443 expresses security capability as a security level from 1 to 4. Each describes a class of adversary rather than a grade of quality: a component certified at a lower level has not failed an assessment at a higher one, but has been assessed against a different adversary. The levels are compounded, so each incorporates those below it.

Security Level 1: Protection from coincidental or casual access, misuse or manipulation. It does not address deliberate attack.
Security Level 2: Protection from intentional attack by an attacker with low resources, generic skills and low motivation.
Security Level 3: Protection from intentional attack by an attacker with moderate resources, industrial control system specific skills and moderate motivation.
Security Level 4: Protection from intentional attack using sophisticated means by an attacker with extended resources, industrial control system specific skills and high motivation.

Analysis published by the ISA Security Compliance Institute records 50 requirements at Security Level 1, 93 at Level 2, 116 at Level 3 and 122 at Level 4, and recommends Level 2 as a minimum for commercial off-the-shelf components.

A requirement for IEC 62443 certification that omits a security level does not define what is being requested. A certificate also applies to a defined product scope and version, so the scope recorded determines what has been assessed.

Capability, Target and Achieved

A security level is applied in three ways, each answering a different question and belonging to a different party.

SL-C, capability: What a component provides when correctly configured, without compensating countermeasures. This is the level recorded on a Part 4-2 certificate.
SL-T, target: What a given zone requires. The asset owner establishes it through the risk assessment and zone design process defined in IEC 62443-3-2.
SL-A, achieved: What the installation attains once equipment is deployed and maintained. It may fall below the capability level through configuration, or exceed it where compensating countermeasures exist.

Two consequences follow. A certificate records the capability of a product and cannot establish the security level of an installation, which depends on how equipment is integrated, configured and maintained. And where a product's capability falls below the level a customer requires, this is not a defect but a specification of the controls the asset owner must provide around it.

What Certification Provides

Tender eligibility: Where a tender specifies either part, conformance determines whether a bid is technically compliant.
Regulatory readiness: Conformance establishes most of the practice product security regulation requires.
Independent evidence: A certificate from an accredited body substitutes an assessed statement of capability for assertion.
Documented artefacts: Threat models, traceable requirements, test evidence and a vulnerability handling process, each retaining value on later releases.
Earlier defect correction: Defects found during development are resolved in the development cycle rather than through coordinated disclosure and patch delivery to installed equipment.
Reuse across the product range: The certified process applies to the manufacturer's other products, so the work is performed once.

The regulatory position warrants precise statement, since it is frequently represented inaccurately. The EU Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024, with vulnerability reporting obligations applying from 11 September 2026 and those governing essential requirements, conformity assessment and CE marking from 11 December 2027. The Act does not identify IEC 62443 as a route to compliance, and no harmonised standard has yet been cited in the Official Journal, so conformance does not at present confer a presumption of conformity. CENELEC is nonetheless amending the European adoptions of both parts under standardisation request M/606, so a manufacturer certifying now should plan for reassessment against the amended text.

A 2024 joint analysis by the European Commission's Joint Research Centre and ENISA, mapping the Act against existing standards, recorded that on minimisation of attack surface "Standard EN IEC 62443-4-2:2019 is a partial exception to this as it included concrete requirements", and that "The IEC 62443-4-1 standard prescribes several security tests on the product".

Outside Europe the pattern is comparable. India's Central Electricity Authority Guidelines, 2021 require equipment supplied to the power sector to carry a certificate of conformance to the IEC 62443-4 standards from an accredited body, permitting a self-declaration only as an interim measure. The CEA (Cyber Security in Power Sector) Regulations, 2026, in force from 1 April 2027, place vendor obligations on a statutory footing, several corresponding closely to Part 4-1 practices.

The Certification Routes

Two routes are available, under separate governance and frequently represented as one.

ISASecure: Operated by the ISA Security Compliance Institute, providing SDLA certification for the development process against Part 4-1 and CSA certification for components against Part 4-2. Certificates are issued by accredited bodies, at present including exida, TÜV Rheinland, TÜV SÜD, FM Approvals, UL Solutions and BYHON, whose differing scopes of accreditation should be confirmed before appointment.
IECEE: The IEC conformity assessment system operates a route governed by operational document OD-2061, under which a Certificate of Conformity for industrial cyber security capability is issued through national certification bodies and accredited laboratories.

Under the ISASecure scheme the process certification is a prerequisite for component certification, though the two may be pursued concurrently. The component assessment comprises four elements: assessment of the development process as it applies to components, examination of the artefacts for that component, functional assessment of its capabilities against the target level, and vulnerability identification testing. Two of the four concern the development process.

As of September 2026 the ISASecure register recorded 47 Part 4-1 certificates held by approximately 40 development organisations, among them ABB, Emerson, Honeywell, Schneider Electric and Yokogawa. It is not a complete worldwide count, since IECEE certifies separately, but the number remains small relative to an industry comprising several thousand equipment suppliers.

How Beacon Security Can Help

Beacon Security specialises exclusively in operational technology and industrial control system security. We have completed multiple product certification programmes for manufacturers of industrial equipment, supporting organisations from the point at which a requirement first appears in a customer specification through to the issue of the certificate.

Requirement definition and gap assessment: We establish the applicable customer, market and regulatory requirements, then measure the development process against the Part 4-1 practices and the product against the Part 4-2 requirements.
Security level strategy and roadmap: We establish a target security level appropriate to the process risk, the regulatory position and the intended markets, and produce a sequenced roadmap.
Process and lifecycle development: We establish threat modelling, secure design review, security testing, vulnerability handling and security update management as operating practice, structured so that the required evidence is generated by the engineering activity itself.
Product engineering support: We translate component requirements into design decisions within the device, covering authentication, integrity protection, secure update mechanisms, logging and the removal of unnecessary services.
Resource deployment: Where an organisation lacks the capacity to conduct a certification programme alongside its development commitments, our specialists are deployed within the team for its duration.
Evidence preparation and assessment support: We assemble the documentation the assessor requires and support the team through the assessment to the closure of findings.

For asset owners we apply the same knowledge in the opposite direction, establishing target security levels for zones, writing product security requirements into procurement specifications, and reviewing supplier submissions to determine what a certificate covers and what remains for the plant.

Next Steps

Whether you are a manufacturer preparing for a customer requirement or an asset owner assessing the coverage of a supplier's certificate, the initial step is to establish your present position against the two parts. To discuss that, please use the Book a Free 15-Minute 1:1 Call button on this page, at no cost and without obligation.

This is a general awareness guide and not a substitute for the IEC 62443 standards, which are the copyright of the International Electrotechnical Commission and take precedence, or for the guidance of an accredited certification body. Beacon Security assists manufacturers in achieving IEC 62443-4-1 and 4-2 conformance at a defined security level, and asset owners in specifying and evaluating product security in procurement.