Penetration Testing in OT Environments according to IEC 62443

The IEC 62443 series defines cybersecurity requirements for industrial automation and control systems (IACS / OT security). Compared with traditional information security standards such as ISO/IEC 27001, IEC 62443 places particular emphasis on availability, integrity, and the protection of physical processes and potential safety impacts.

Within the standard series, penetration testing is addressed from two perspectives: the manufacturer’s secure development process and the technical security requirements placed on the system.

Distinction from Operational Practice

IEC 62443 does not require undifferentiated black-box penetration tests in production industrial environments. Instead, the standard series distinguishes between the manufacturer’s process-related obligations during product development and the technical security requirements for the deployed control system.

1. IEC 62443-4-1: The Secure Product Lifecycle

Part 4-1 defines requirements for the development process of component and system manufacturers. Security testing is an integral part of Practice 5: Security verification and validation testing (SVV). The standard requires the establishment and documented application of processes within the Secure Product Development Lifecycle, rather than the isolated provision of a single test report.

Relevant process requirements include in particular:

• SVV-3: Vulnerability Testing: A structured process is required to identify and characterize potential security vulnerabilities in the product. This includes, among other things, abuse-case testing, testing with unexpected or malformed inputs, such as fuzzing, attack surface analysis, scans for known vulnerabilities, Software Composition Analysis (SCA), and dynamic tests for resource and runtime issues.
• SVV-4: Penetration Testing: This process is used to identify and characterize security-related issues through test methods specifically aimed at discovering and exploiting vulnerabilities. Unlike vulnerability testing, the focus is on the attacker’s perspective. This includes examining whether multiple vulnerabilities can be chained to compromise the confidentiality, integrity, or availability of the product.
• Independence Requirements for SVV-4: For penetration testing, the standard defines formal criteria for the testing body. A purely personnel-based separation within the immediate project team is not sufficient. According to the standard, these tests must be performed by an independent department within the manufacturer’s organization or by an external organization, such as a specialized security service provider.
• Context-Based Test Planning: Test planning and test case design should not be generic. To provide meaningful results, the test plan should consider the specific product context, the underlying threat model, the concrete attack surface, and the intended operating conditions of the product. A generic penetration test that does not take into account the specific characteristics and attack surface of the respective OT component is of only limited value in the regulatory context of the standard.
• Process-Based Vulnerability Tracking: Identified security vulnerabilities must be documented, assessed, treated based on risk, and tracked through the defined processes for Security Defect Management (Practice 6) and Security Update Management (Practice 7). The standard does not require all identified vulnerabilities to be remediated before every product release. Handling and prioritization are differentiated based on the assessed risk, severity, available compensating measures, and the final release decision.

2. IEC 62443-3-3: System Security Requirements

Part 3-3 addresses the technical security requirements for the control system or the system under consideration (SuC) within an IACS and defines the security levels (SL) to be achieved. This part of the standard does not require penetration testing as a standalone or mandatory measure. However, it specifies which technical capabilities the control system must provide to support security verification and strengthen resilience against defined threats.

The most relevant reference point for penetration-testing methods and security validation in this part of the standard is SR 3.3 (Security Functionality Verification):

• SR 3.3 – Security Functionality Verification: The control system must be designed to support verification that security features operate as intended. It must also be able to report anomalies or deviations during factory acceptance testing (FAT), site acceptance testing (SAT), and planned maintenance. Penetration-testing methods may serve as a means of evidence in this context, provided they are planned based on risk and are compatible with the requirements for availability and functional safety.

Further relevant system requirements, or Foundational Requirements (FR), in the context of security testing include:

• FR 2 – Use Control: FR 2 governs access control and authorization at the system level. In a security assessment, this may include validating the enforcement of privilege assignments, mechanisms such as session locks and remote session termination, and the proper recording of security-relevant events. The latter also provides an important basis for the requirements under FR 6.
• FR 6 – Timely Response to Events: This requirement focuses on timely response to security-relevant events, controlled access to audit information, and continuous monitoring. A security assessment can be used to evaluate the effectiveness, coverage, and escalation chain of the corresponding monitoring systems in practice.
• FR 7 – Resource Availability: This requirement addresses the availability of system resources in order to protect the control system against resource exhaustion, for example due to potential denial-of-service risks. Since automated testing tools can generate high network load, resource availability must be considered and protected during testing. Hardening network components against anomalies, such as incomplete or malformed network packets, can be a practical example of implementation, but it is not an explicit normative quotation.

The Role of the Target Security Level (SL-T)

Higher target security levels (SL 3 and SL 4) require the system to provide increased resilience against intentional attacks. The distinction between the levels is based on the assumed attacker profile, which at higher security levels is characterized by increasing resources, more advanced capabilities, IACS-specific knowledge, higher motivation, and increased attack complexity.

System integrators use methodical security assessments and penetration-testing methods during factory acceptance testing (FAT) or site acceptance testing (SAT) as supporting evidence. However, performing such tests does not automatically demonstrate that a specific security level has been achieved; it is only one component within a broader conformity and validation process.

Relevance for Penetration Testing Practice (Key Takeaways)

When planning and performing penetration tests in the regulatory context of IEC 62443, the following aspects should be considered:

1. Define the assessment scope precisely: It must be determined in advance at which level the security assessment is being performed:
2. Product assessment at the manufacturer: Focus on IEC 62443-4-1, in particular systematic attacker-perspective testing under SVV-4.
3. Assessment of an Automation Solution / IACS: Focus on IEC 62443-3-3, including verification of technical security functions and compliance with system-wide security requirements.
4. Minimize risk during system testing: Testing in production-like or operational OT environments under Part 3-3 is only justifiable after an explicit risk assessment, close coordination with the operator, and the use of methods that are as non-disruptive as possible. Precisely coordinated, risk-minimized test windows and predefined abort criteria are essential to prevent unintended impacts on plant operation.
5. Ensure traceability for conformity assessment: For a conformity assessment, the test report alone is not sufficient. The documentation must demonstrate the underlying process, the organizational independence of the testing body, the traceable derivation of test cases while taking context and threat model into account, and the defined handling of identified findings.

Conclusion

The IEC 62443 series differentiates penetration testing according to the specific context of use. While IEC 62443-4-1 explicitly anchors penetration testing as SVV-4 within the Secure Product Development Lifecycle, IEC 62443-3-3 does not require a blanket penetration test during live operation. Instead, Part 3-3 describes technical system requirements that can be used to plan, implement, and verify the security functions, resilience, and monitorability of an IACS.