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

IEC 62443-4-1 and IEC 62443-4-2 appear in the technical requirements of industrial tender documents, and manufacturers are asked to demonstrate conformance with them. This guide sets out what the two standards contain, how they relate to each other, and what a certificate issued against them states.

What Product Security Means

Product security refers to the security capability built into an industrial component during its development, as distinct from the controls applied around it after installation.

The distinction matters because of how industrial equipment is procured and operated. A component is specified once and remains in service for a long period, and its security functions are fixed at the point of manufacture. Where a device does not support user authentication, firmware verification or configuration logging, those functions cannot be added later, and the operator provides equivalent protection through network and procedural controls instead. The capability available to a plant is therefore set before the equipment is delivered.

The Two Standards

The IEC 62443 series assigns requirements to three roles: the asset owner, who operates the environment; the service provider, who integrates and maintains it; and the product supplier, who manufactures the equipment. Parts 4-1 and 4-2 apply to the product supplier.

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 covers how a manufacturer designs, builds, tests, releases and maintains a product, and 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 components. It covers the security functions the delivered device provides, and it is assessed against a specific product version.

The two are used together. Part 4-1 addresses the manufacturer's development process, and Part 4-2 addresses the capability of a specific product. Part 4-2 also requires the component to be developed under a process conforming to Part 4-1, so a component assessment normally includes an examination of the development process.

IEC 62443-4-1: The Development Process

Part 4-1 applies to the developer and maintainer of a product. Its scope states that its requirements do not apply to the integrator or to the user.

The standard assesses a process rather than a product. A certificate issued against it records a process capability assessment and names the development process to which it applies, not a product line.

The standard organises the development lifecycle into eight practices.

Security management: This practice defines the scope of the development lifecycle and the organisational arrangements that support it. It covers the assignment of roles and responsibilities, the competence of the personnel performing security work, the identification of the products and components to which the process applies, the security requirements placed on the supply chain, and the arrangements by which the organisation verifies that its own process is being followed.
Specification of security requirements: This practice requires the security requirements for a product to be derived, documented and reviewed rather than assumed. The requirements account for the intended operating environment, the product's expected security context, and the threats identified for it, and they form the basis against which the design and the subsequent testing are assessed.
Secure by design: This practice applies defence in depth principles to the product architecture and requires the design to be reviewed against the security requirements. Threat modelling is performed on the design so that the mitigations are identified during architecture rather than after implementation.
Secure implementation: This practice requires the manufacturer to define secure coding standards and to review the implementation against them. It addresses the classes of defect introduced during coding and establishes that the implementation reflects the reviewed design.
Security verification and validation testing: This practice requires the product to be tested against its security requirements. It covers testing that each requirement has been met, testing that the identified threat mitigations function as designed, vulnerability testing, and penetration testing of the product.
Management of security-related issues: This practice establishes how security defects and vulnerabilities are handled once identified, whether internally or by a customer or external researcher. It covers receiving reports, triage, assessment of severity and impact, and disclosure to affected parties.
Security update management: This practice covers the delivery of security patches to products already installed. It requires updates to be qualified before release, documented for the user, and delivered within a defined timeframe, and it addresses the dependencies a manufacturer carries where third-party components are used.
Security guidelines: This practice requires the manufacturer to provide the user with the documentation needed to operate the product securely. It covers hardening guidance, secure operation and account management, and guidance for the secure disposal of the product at the end of its life.

Two features of this structure are relevant when a manufacturer plans a certification programme.

Three practices apply after release: Defect management, security update management and security guidelines concern products already installed. They are continuing responsibilities rather than activities completed at the end of a development project.
Conformance is assessed by maturity: Each practice is measured against a maturity model of four levels, covering processes that exist informally, processes that are documented, processes that are demonstrably followed with supporting evidence, and processes whose effectiveness is measured and improved. Evidence that a documented process was applied to a specific release is assessed separately from the existence of the document.

IEC 62443-4-2: The Product Capability

Part 4-2 specifies the technical security requirements for components. It defines four component types, and each type carries a set of additional requirements appropriate to its function alongside the requirements common to all components.

Embedded devices: Special purpose devices running embedded software, designed to directly monitor, control or actuate an industrial process. This category includes programmable logic controllers, remote terminal units, intelligent electronic devices and safety controllers.
Host devices: General purpose devices running an operating system capable of hosting one or more software applications. This category includes engineering workstations, operator stations, human machine interfaces and servers such as historians.
Network devices: Devices that provide the transmission of data between other components, or that enforce the boundaries between them. This category includes switches, routers, firewalls and virtual private network terminators.
Software applications: Software running on a host device that provides part of the control or monitoring function, including engineering configuration software and supervisory applications.

The requirements themselves are organised under the seven foundational requirements used across the IEC 62443 series. Because the same seven categories are used at system level in other parts of the series, a component assessment can be aligned with the requirements defined for the system into which the component is integrated.

Identification and authentication control: This requirement covers the component's ability to establish and verify the identity of the users, software processes and devices that interact with it. It addresses the management of accounts, identifiers and authenticators, and the strength of the authentication mechanisms the component supports.
Use control: This requirement covers the enforcement of what an authenticated identity is permitted to do once its identity has been established. It addresses the assignment of privileges, the restriction of functions to authorised identities, and the recording of the actions taken.
System integrity: This requirement covers the detection of unauthorised change to the firmware, software and data held on the component. It addresses code signing, the verification of software and firmware integrity, and the protection of the update mechanism itself.
Data confidentiality: This requirement covers the protection of information held on the component and information transmitted from it, including the cryptographic protection of data in transit and the handling of any keys involved.
Restricted data flow: This requirement covers the component's support for the zone and conduit boundaries in which it is deployed, including its ability to restrict the communications it accepts and to operate correctly within a segmented architecture.
Timely response to events: This requirement covers the generation of security records by the component and their availability for analysis. It addresses what events are recorded, the content of the records, and the means by which they are transferred to a system that reviews them.
Resource availability: This requirement covers the continued operation of the component under abnormal conditions, including network stress, resource exhaustion and denial of service conditions, together with backup and restoration of the component's configuration.

The standard also places a set of constraints above these requirements. The first of them establishes that a security measure must not compromise the essential functions of the process, so a control that improves the security posture of a device while introducing risk to safe operation does not satisfy the standard. A further constraint requires the component to have been developed under a process conforming to Part 4-1, which is the provision that links the two standards.

Security Levels

IEC 62443 expresses security capability as a security level from 1 to 4. Each level describes a class of adversary rather than a grade of quality, and the levels are cumulative, so each includes the requirements of those below it.

Security Level 1: Protection against coincidental or casual access, misuse or manipulation of the component. This level addresses accidental conditions and unintentional misuse, and it does not address deliberate attack.
Security Level 2: Protection against intentional attack by an adversary with low resources, generic skills and low motivation. ISASecure has published a paper making the case for Security Level 2 as a minimum for industrial components.
Security Level 3: Protection against intentional attack by an adversary with moderate resources, skills specific to industrial control systems, and moderate motivation. The distinguishing factor at this level is that the adversary is assumed to understand control systems and to target them deliberately.
Security Level 4: Protection against an adversary with extended resources and high motivation. This level addresses a well resourced actor pursuing a specific objective.

The number of applicable requirements increases with each level, because each level adds both new base requirements and enhancements to requirements already present at the level below. Figures published by ISASecure indicate approximately 50 requirements at Security Level 1, approximately 93 at Security Level 2 once the additional base requirements and requirement enhancements are counted, and in excess of 120 at Security Level 4.

Two consequences follow for anyone writing or reading a specification. A requirement for IEC 62443 certification that does not state a security level does not define what is being asked for, because components certified at different levels have been assessed against different classes of adversary. A certificate also applies to a defined product scope and a specific product version, so the scope stated on the certificate determines what has actually been assessed.

Capability, Target and Achieved

A security level is used in three different ways, and the three answer different questions.

SL-C, capability: What the product can do. This is the level a component provides when it is correctly configured, and it is the level stated on a Part 4-2 certificate.
SL-T, target: What the plant needs. This is the level required for a given zone, and the asset owner sets it through the risk assessment and zone design process defined in IEC 62443-3-2.
SL-A, achieved: What the installation delivers. This is the level actually reached once the equipment is deployed, configured and maintained.

The practical points are straightforward. A certificate states the capability of a product, and it does not state the security level of any plant, because that depends on how the equipment is installed and operated. Where a product's capability level is below the level a customer requires, this is not a fault in the product. It identifies the controls the asset owner needs to provide around the device, and a supplier that can state that difference clearly is easier to specify against.

What Certification Provides

Conformance serves six purposes for a manufacturer.

Tender eligibility: Where a tender names IEC 62443-4-1 or 4-2, conformance determines whether a bid is technically compliant.
Regulatory readiness: Conformance establishes most of the engineering and documentation practice that product security regulation requires.
Independent evidence: A certificate from an accredited body replaces supplier assertion with an assessed statement of capability.
Documented artefacts: The process produces threat models, traceable requirements, test evidence and a vulnerability handling route, all of which are reused on later releases.
Earlier defect correction: Defects found during development are closed in the development cycle rather than through coordinated disclosure and patch delivery to installed equipment.
Reuse across the range: The certified process applies to the manufacturer's other products, so the process work is done once.

Two regulatory dates are worth noting. The EU Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. Reporting obligations for actively exploited vulnerabilities apply from 11 September 2026, and the obligations covering essential requirements, conformity assessment and CE marking apply from 11 December 2027.

The Act does not cite IEC 62443 in its legal text, and no harmonised standard has been published in the Official Journal, so conformance does not currently confer presumption of conformity with the Act. A joint analysis by the European Commission's Joint Research Centre and ENISA nonetheless found that Part 4-2 contained concrete requirements where other standards were abstract, and identified Part 4-1 as prescribing security testing of the product where other standards did not.

In India, the Central Electricity Authority's approach to the power sector accepts a signed self-declaration of conformance to the IEC 62443-4 standards from the manufacturer, with certification specifiable in the tender for critical systems.

The Certification Routes

Two routes are available, and they are separate schemes.

ISASecure: Operated by the ISA Security Compliance Institute, this scheme offers SDLA certification for the development process against Part 4-1 and CSA certification for components against Part 4-2. Certificates are issued by accredited certification bodies including exida, TÜV Rheinland, TÜV SÜD, FM Approvals and UL Solutions.
IECEE: The IEC conformity assessment system operates a route governed by operational document OD-2061, issuing a certificate of conformity for industrial cyber security capability through national certification bodies and accredited testing laboratories, with mutual recognition between members.

Under the ISASecure scheme the process assessment is a prerequisite for component certification. A manufacturer may hold the process certification already or pursue both together. The component evaluation examines the development artefacts for that component, assesses its security capabilities against the requirements of the target level, and tests it for known vulnerabilities.

Published registries list fewer than fifty development organisations worldwide holding Part 4-1 process certification, against an industry of several thousand equipment suppliers.

How Beacon Security Can Help

Beacon Security works exclusively in operational technology and industrial control system security. We have completed multiple product certification programmes for manufacturers of industrial equipment, and we support organisations from the initial requirement through to the certificate.

Requirement definition and gap assessment: We establish the applicable customer, market and regulatory requirements, measure the development process against the Part 4-1 practices and the product against the Part 4-2 requirements, and report the current position, including the maturity level evidenced.
Security level strategy and roadmap: We set a target security level appropriate to the process risk, the regulatory position and the intended markets, and produce a sequenced roadmap with defined milestones.
Process and lifecycle development: We establish threat modelling, secure design review, security testing, vulnerability handling, security update management and end-of-life guidance as working practice, structured so that the required evidence is produced by the engineering work.
Product engineering support: We translate the component requirements into design decisions in the device, covering identification and authentication, integrity protection, secure update mechanisms, logging, and the removal of unnecessary services and interfaces.
Resource deployment: Where an organisation does not have the internal capacity to run a certification programme alongside its development commitments, our specialists work within the development team for the duration of the programme.
Evidence preparation and assessment support: We assemble the documentation required by the assessor in the expected structure, and support the team through the independent assessment to the closure of findings.

For asset owners, we apply the same basis of knowledge to setting target security levels for zones, writing product security requirements into procurement specifications, and evaluating supplier submissions to establish what a certificate covers.

Next Steps

If you are a manufacturer preparing for a customer requirement or a regulatory deadline, or an asset owner evaluating what a supplier's certificate covers, use the Book a Free 15-Minute 1:1 Call button on this page. It is a conversation with a senior consultant, at no cost.

This is a general awareness guide and it is 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 helps industrial manufacturers achieve IEC 62443-4-1 and 4-2 conformance at a defined security level, and helps asset owners specify and evaluate product security in procurement. Contact us to discuss a gap assessment, a security level strategy, or a certification roadmap for your product.