IEC 62443 product security

Structure of the series

IEC 62443 is organised into parts addressing different stakeholders and concerns: general concepts and models, policies and procedures for asset owners, system-level requirements for integrators, and product/component-level requirements for suppliers. For product suppliers, the two most directly relevant parts are IEC 62443-4-1, which specifies secure development lifecycle requirements for the organisation producing the product, and IEC 62443-4-2, which specifies technical security requirements for the product itself, differentiated by component type.

Security levels

Security Levels (SL 0 to SL 4) express the capability of the attacker a system or component is designed to resist, from no specific protection (SL 0) through casual or coincidental violation (SL 1), intentional violation using simple means (SL 2), intentional violation using sophisticated means (SL 3), to intentional violation using sophisticated means with extended resources (SL 4). Security levels can be expressed as a target (what is required for the application), a capability (what a product or system can achieve as delivered) and an achieved level (what is actually demonstrated in a specific deployment) — distinguishing these three is important because a product capable of SL 3 does not automatically achieve SL 3 in a deployment configured below its capability.

IEC 62443-4-1: the secure development lifecycle

IEC 62443-4-1 defines process requirements across practices including 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 documentation for the product's users. Certification against 4-1 assesses the supplier's development process across a product's lifecycle, not a single product release, which is a distinction organisations new to the standard often miss.

IEC 62443-4-2: technical requirements for components

IEC 62443-4-2 specifies technical requirements grouped into foundational requirement areas — identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability — applied differently depending on component type (software application, embedded device, host device, or network device). A component's achieved security level depends on which of these technical requirements it satisfies and to what degree.

• Identification and authentication control: verifying the identity of users, software processes and devices before granting access.
• Use control: enforcing authorised actions once identity is established.
• System integrity: protecting the system and its communications from unauthorised manipulation.
• Data confidentiality: protecting information from unauthorised disclosure, at rest and in transit.
• Restricted data flow: segmenting the system to contain the effect of a compromise.
• Timely response to events: detecting and responding to security violations.
• Resource availability: ensuring the system remains available under degraded or adversarial conditions.

Common failure modes

A frequent mistake is pursuing 4-2 technical conformance without an underlying 4-1 secure development process, which produces a product that passes a point-in-time technical test but has no sustainable mechanism to maintain that posture through subsequent releases. A second is assuming a security level capability claim transfers automatically to a deployed system, ignoring that the surrounding system architecture, network segmentation and configuration determine the achieved level in practice. A third is treating security update management, one of the 4-1 practices, as an afterthought, which becomes a serious gap once a vulnerability is found in a fielded product.

What certification evidence looks like

For 4-1 certification, assessors expect documented processes covering each practice, evidence that the processes have actually been followed on a real product (not only described in a manual), and records such as threat models, security requirement specifications, verification test results and vulnerability handling records. For 4-2 certification, assessors expect the component's technical requirements to be verified through testing, with evidence mapped to the specific requirement and component type, and a clear statement of the claimed security level capability with supporting rationale.

Frequently asked questions