# What Is IEC 62443? Industrial Cyber Security, OT/ICS Security and IEC 62443-4-1 Consulting Guide

**URL:** https://securesys.com.tr/en/learning/cyber-security-compliance-advisory/what-is-iec-62443-ot-security-and-consulting

![What Is IEC 62443? Industrial Cyber Security, OT/ICS Security and IEC 62443-4-1 Consulting Guide](/images/bilgi-merkezi/covers/cover-uyum-09.webp)

### What Is IEC 62443?

**IEC 62443 is an international family of standards developed to manage the cyber security of industrial automation and control systems (IACS).**

This family of standards addresses the security responsibilities of industrial facility operators, system integrators, product developers and service providers from different perspectives.

IEC 62443 does not focus solely on network security. It covers security requirements that extend from the design of industrial systems to their operation, and from product development to maintenance processes.

In manufacturing plants, energy systems, automation infrastructures, transportation systems and critical industrial processes, information technology (IT) and operational technology (OT) are increasingly integrated.

While this integration delivers operational efficiency, it can also expand the cyber attack surface.

**Short answer:** IEC 62443 is a body of standards that enables the risk-based protection of industrial systems, their design with secure architectures, the secure development of products, and the maintenance of security controls throughout operation.

### \1. Why Is Industrial Cyber Security Important?

The impact of cyber security incidents in industrial systems can differ from that in conventional office systems.

When a corporate information system becomes unavailable, business processes may be disrupted.

However, a security incident in an industrial control system can halt production, damage equipment or create physical safety risks.

#### Key risks in industrial environments

- Disruption of production continuity
- Modification of PLC configurations
- Unauthorised access to SCADA systems
- Manipulation of operator screens
- Spread of malware across industrial networks
- Abuse of remote maintenance connections
- Alteration of critical process data
- Impact on safety systems

#### Example scenario

A VPN account used for remote maintenance at a manufacturing plant may have been compromised.

If an attacker can reach the OT network through this account, there is a risk of unauthorised operations being performed on control systems.

For this reason, remote access, authentication, network segmentation and monitoring controls must be assessed together.

#### Critical point

In industrial cyber security, in addition to confidentiality, integrity and availability, **human safety, process integrity and operational continuity** must also be taken into account.

### \2. Differences Between IT and OT Security

IT and OT systems have different operational priorities.

| Criterion | IT Environment | OT Environment |
| --- | --- | --- |
| Primary purpose | Information processing and corporate services | Monitoring and control of physical processes |
| Priorities | Confidentiality, integrity, availability | Safety, process integrity, availability and other security objectives |
| System lifespan | Generally shorter | Long life cycles are common |
| Patch management | Regular maintenance windows | Depends on production and safety requirements |
| Network protocols | HTTP, DNS, TLS and similar | Modbus, OPC UA, PROFINET and others |
| Downtime tolerance | Varies according to the business process | May be very low for critical processes |
| Security testing | Controlled IT testing | Requires special planning because of process impact |

#### An important distinction

Not every security control used in IT environments can be applied directly to OT environments.

For example, active vulnerability scanning or aggressive network testing can cause unexpected behaviour in sensitive industrial devices.

For this reason, vendor constraints, maintenance windows and operational safety requirements must be taken into account in OT security assessments.

### \3. How Is the IEC 62443 Family of Standards Structured?

The IEC 62443 family of standards covers different areas of responsibility and application.

#### General structure

| Standard | Main subject | Target party |
| --- | --- | --- |
| IEC 62443-2-1 | Security programme requirements for IACS asset owners | Facility operators |
| IEC 62443-2-4 | Security programme requirements for IACS service providers | Integrators and service providers |
| IEC 62443-3-2 | Security risk assessment for system design | System designers and asset owners |
| IEC 62443-3-3 | System security requirements and security levels | System integrators and operators |
| IEC 62443-4-1 | Secure product development lifecycle | Product manufacturers and developers |
| IEC 62443-4-2 | Technical security requirements for IACS components | Product manufacturers |

Although all of these standards serve the same purpose, they answer different questions.

**IEC 62443-2-1:** How is a facility security programme managed?

**IEC 62443-3-2:** How are system risks assessed?

**IEC 62443-3-3:** Which technical security requirements must an industrial system meet?

**IEC 62443-4-1:** How should industrial products be developed securely?

**IEC 62443-4-2:** Which technical security capabilities must the developed component provide?

#### Critical point

Meeting the requirements of one standard does not mean compliance with the entire IEC 62443 family.

Every assessment must be carried out against a specific standard, version and scope.

### \4. What Is IEC 62443-2-1?

IEC 62443-2-1 focuses on the cyber security programme run by the asset owner for industrial automation and control systems.

#### Key assessment areas

Cyber security governance.

Roles and responsibilities.

Risk management.

Asset inventory.

Security policies.

Supplier relationships.

Incident management.

Operations and maintenance processes.

#### Example

A manufacturing plant has PLCs, HMIs, SCADA servers, engineering workstations and network devices.

An inventory of these assets is compiled.

Owners are assigned.

A risk assessment is carried out.

Appropriate security controls are defined.

#### Important point

IEC 62443-2-1 is concerned not only with the security of technical devices but with the organisation's approach to managing industrial security.

### \5. What Is IEC 62443-3-2?

IEC 62443-3-2 addresses the security risk assessment for the design of industrial automation and control systems.

#### Key topics

System definition.

Identification of zones and conduits.

Risk assessment.

Determination of target security levels.

Development of security requirements.

#### Example

There is communication between a facility's production control network and the corporate IT network.

The risk assessment establishes the business purpose for which this communication is used.

The communication channels are examined.

Unauthorised access scenarios are evaluated.

The necessary segmentation and access controls are defined.

### \6. What Is IEC 62443-3-3?

IEC 62443-3-3 addresses the technical security requirements and security levels for industrial automation and control systems.

#### The seven foundational requirement groups

| Code | Foundational requirement |
| --- | --- |
| 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 |

#### Example

User authentication in a SCADA system can be assessed under FR 1.

The operations that users are able to perform relate to FR 2.

Network segmentation can be associated with the requirements under FR 5.

#### Important point

These requirements are intended to assess the overall security of the system.

It should not be assumed that all system requirements are met by the security features of a single product.

### \7. What Are the IEC 62443 Security Levels?

Within IEC 62443, security levels are used to express the security resilience required against particular attacker capabilities and threat conditions.

#### Security level concepts

SL-T: Target security level.

SL-C: The security level that a component or system is capable of providing.

SL-A: The security level actually achieved by the implemented system.

These concepts must be assessed in the context of the relevant standards.

#### Security levels

**SL 1:** Protection against casual or coincidental violations.

**SL 2:** Protection against intentional attackers using simple means, low resources and generic skills.

**SL 3:** Protection against attackers using more sophisticated means, moderate resources and IACS-specific skills.

**SL 4:** Protection against attackers using sophisticated means, extended resources and high levels of IACS-specific skills.

#### Critical point

Automatically targeting SL 4 for all industrial systems may be neither necessary nor economically viable.

The target level must be linked to the risk assessment.

### \8. What Is the Zones and Conduits Approach?

In the IEC 62443 architecture, **Zones and Conduits** is the approach of grouping industrial systems according to their security requirements and controlling the communication between those groups.

#### Zone

A logical or physical area made up of assets with similar security requirements.

#### Conduit

Refers to the communication path between zones.

#### Example zones

Corporate IT zone.

Industrial DMZ.

SCADA zone.

PLC control zone.

Safety systems zone.

#### Example architecture

Corporate IT network → Industrial DMZ → SCADA network → Control devices.

In this architecture, the required protocols, access rules and security controls are assessed for each communication crossing.

#### Important point

The Zones and Conduits approach is not merely about creating VLANs.

Communication requirements, trust boundaries and risks must be assessed together.

### \9. What Is IEC 62443-4-1?

**IEC 62443-4-1 is the standard that defines lifecycle requirements for the secure development of products used in industrial automation and control systems.**

This standard does not focus only on testing the finished product.

It assesses processes that run from determining the product's requirements to its design, from development to security testing, and from release to maintenance.

#### Target organisations

PLC manufacturers.

Industrial software developers.

SCADA software vendors.

Industrial network device manufacturers.

IoT/IIoT product developers.

Industrial control component manufacturers.

#### Core objective

To turn product security from a one-off testing activity into a systematic part of the development lifecycle.

### \10. IEC 62443-4-1 Secure Product Development Processes

IEC 62443-4-1 is structured around eight practice areas.

| Code | Practice area | Description |
| --- | --- | --- |
| SM | Security Management | Management of security |
| SR | Specification of Security Requirements | Defining security requirements |
| SD | Secure by Design | Secure design |
| SI | Secure Implementation | Secure implementation |
| SVV | Security Verification and Validation Testing | Security verification and validation testing |
| DM | Management of Security-Related Issues | Management of security-related issues |
| SUM | Security Update Management | Security update management |
| SG | Security Guidelines | Security guidelines |

#### Important point

These areas should not be viewed as independent sets of documents.

Traceability must be established between security requirements, design decisions, test results and update processes.

### \11. How Is Security Management (SM) Implemented?

Security Management supports defining security responsibilities and the management approach within product development processes.

#### Assessment areas

Security policies.

Product security responsibilities.

Security competencies.

Training.

Process management.

Security records.

#### Example

A manufacturer develops three different industrial product families.

Security owners are assigned for each product family.

A central product security policy is established.

The security competencies of the development teams are assessed.

#### Expected approach

Security management must not depend on individuals.

It should be carried out through defined and sustainable processes.

### \12. How Are Security Requirements (SR) Determined?

Security requirements must be defined in the early stages of product development activities.

#### Example requirements

Authentication.

Authorisation.

Secure communication.

Secure updates.

Security logs.

Session management.

Error handling.

Cryptographic protection.

#### Example

An industrial network device has a remote management interface.

Security requirement:

“Access to the management interface must only be possible for authorised users.”

This requirement must be linked to the design, implementation and testing stages.

#### Critical point

Security requirements should not consist solely of generic statements.

They should be verifiable and traceable wherever possible.

### \13. What Is Secure by Design (SD)?

Secure by Design refers to building security into design decisions from the very start of the product development process.

#### Example design principles

Least privilege.

Secure default configuration.

Identification of trust boundaries.

Reduction of the attack surface.

Secure failure behaviour.

Secure update architecture.

#### Example

Rather than exposing a PLC management interface to the internet by default, it can be designed to be reachable only from authorised management networks.

#### Threat Modeling

Threat modelling helps identify possible attack scenarios in the product architecture.

For example:

Unauthorised administrator access.

Firmware manipulation.

Authentication bypass.

Use of insecure protocols.

#### Important point

Secure design work must be carried out while architectural decisions are being made, not after the product has been developed.

### \14. What Is Secure Implementation (SI)?

Secure Implementation aims to incorporate secure development practices into software and firmware development processes.

#### Technical practices

Secure coding rules.

Source code review.

Static code analysis.

Dependency security.

Secrets management.

Secure build processes.

#### Example

A hard-coded password in the firmware source code of an industrial device can create a security risk.

Controls to prevent such mistakes must be defined within the secure development process.

#### Critical point

Using a SAST tool alone does not mean that all of the IEC 62443-4-1 secure implementation requirements are met.

Tools must support defined development processes.

### \15. Security Verification and Validation Testing (SVV)

SVV covers the verification of security requirements and the processes for assessing the product from a security perspective.

#### Example tests

Security requirement tests.

Authentication tests.

Authorisation tests.

Communication security tests.

Input validation tests.

Vulnerability scanning.

Fuzz testing.

Penetration testing.

#### Example

The product requirement states that only authorised users can access the management interface.

During testing, access scenarios are evaluated with different user roles.

The results are recorded.

#### Critical point

Stating test results merely as pass or fail may not be sufficient.

Traceability must be established between the test scope, method, result and the required remediation.

### \16. Security-Related Issues Management (DM)

DM covers the management of security-related issues identified in products.

#### Example process

A security report is received.

The finding is verified.

Affected products are identified.

A risk assessment is carried out.

A fix is planned.

The necessary communication is carried out.

Closure is verified.

#### Example

A researcher identified an authentication vulnerability in the web interface of an industrial device.

The manufacturer evaluates the report.

It determines the affected versions.

It develops a corrective update.

It provides customers with appropriate security notifications.

#### Important point

Managing security issues should not amount to nothing more than the development team's internal bug-tracking system.

External reports and the product lifecycle must be taken into account.

### \17. Security Update Management (SUM)

Security update management supports the controlled remediation of security issues identified in products.

#### Assessment areas

Update development.

Update testing.

Version management.

Update integrity.

Distribution processes.

Customer notification.

#### Example

A security update has been prepared for an industrial device.

When planning the update's deployment in the production environment, operational downtime and compatibility risks must be assessed.

#### Critical point

For industrial products, update processes must be planned not only from a cyber security perspective but also in terms of operational continuity and safety.

### \18. Security Guidelines (SG)

Security Guidelines aim to provide the information needed for the secure installation, configuration, use and maintenance of the product.

#### Example guideline content

Secure installation.

Secure configuration.

Authentication settings.

Network access requirements.

Security update method.

Logging.

Backup.

Supported conditions for secure use.

#### Example

For the management interface of an industrial network device, the default security settings and recommended network segmentation can be documented.

#### Important point

Product security does not depend solely on the manufacturer's development process.

It is also important that customers are able to install and operate the product securely.

### \19. What Is IEC 62443-4-2?

IEC 62443-4-2 addresses the technical security requirements of components used in industrial automation and control systems.

#### Component types

Embedded devices.

Host devices.

Network devices.

Software applications.

#### Example products

PLC.

Industrial firewall.

SCADA software.

Industrial gateway.

HMI.

Industrial server.

#### An important distinction

While IEC 62443-4-1 focuses on the development process, IEC 62443-4-2 focuses on the technical security capabilities of the component.

A product being built under a secure development process does not mean that the technical requirements are automatically met.

### \20. The Difference Between IEC 62443-4-1 and IEC 62443-4-2

| Criterion | IEC 62443-4-1 | IEC 62443-4-2 |
| --- | --- | --- |
| Focus | Secure development lifecycle | Component security requirements |
| What is assessed | Processes | Product or component |
| Target | The manufacturer's development organisation | Industrial product |
| Evidence | Policies, processes, records | Technical specifications and tests |
| Core question | How is the product developed securely? | Which security capabilities does the product have? |

#### Example

A manufacturer may have established secure development procedures.

However, the authentication or secure communication features of the device it develops must be assessed separately.

#### Conclusion

The two standards can complement each other, but they do not represent the same conformity assessment.

### \21. What Does IEC 62443 Consulting Cover?

IEC 62443 consulting should be planned according to the standard and assessment scope that the organisation is targeting.

#### Consulting areas

Current state analysis.

Assessment of standard requirements.

Risk analysis.

Secure development processes.

Technical security controls.

Documentation.

Evidence management.

Internal assessment.

Certification readiness.

#### Critical point

The scope of IEC 62443 consulting may differ for a facility operator, a system integrator and a product manufacturer.

For this reason, the target standard and scope must be clearly defined at the start of the project.

### \22. How Is an IEC 62443 Gap Analysis Performed?

A gap analysis compares current practices against the requirements of the target standard.

#### Stage 1: Determining the target standard

IEC 62443-4-1?

IEC 62443-4-2?

IEC 62443-3-3?

More than one standard?

#### Stage 2: Defining the scope

Product families.

Development teams.

Locations.

Relevant processes.

Technical systems.

#### Stage 3: Assessing the evidence

Policies.

Procedures.

Development records.

Test reports.

Risk analyses.

#### Stage 4: Identifying the gaps

Missing requirements.

Partially met requirements.

Evidence gaps.

Process improvement needs.

#### Stage 5: Action plan

Owners.

Priorities.

Target dates.

Verification methods.

### \23. Product-Family-Based Pilot Implementation for IEC 62443-4-1

For organisations that develop multiple industrial products, a pilot implementation approach can be useful.

#### Example organisation

There are three different product families:

Industrial network devices.

Control systems.

Industrial software applications.

#### Recommended pilot approach

One representative product is selected from each product family.

The existing development processes are assessed across the three pilot products in total.

Security requirements are determined.

Threat modelling is carried out.

Secure development practices are assessed.

Testing processes are established.

Security issues and update management are examined.

#### Example pilot table

| Product family | Pilot product | Priority assessment |
| --- | --- | --- |
| Industrial network | Gateway | Secure communication and management access |
| Control systems | PLC | Firmware security and updates |
| Industrial software | SCADA application | Authentication and software security |

#### Benefits of the pilot implementation

Identifying common processes that can be applied across the organisation.

Understanding the differences specific to each product family.

Establishing the documentation approach.

Detecting improvement needs early.

#### Important point

Assessing three representative products does not mean that all products are automatically certified.

How the pilot translates into the certification scope must be determined according to the rules of the relevant assessment body.

### \24. How Is an IEC 62443-4-1 Consulting Project Planned?

The project can be carried out in phases.

#### Phase 1: Project Initiation

Scoping.

Stakeholder analysis.

Definition of product families.

Project plan.

#### Phase 2: Gap Analysis

Assessment of existing development processes.

Requirement mapping.

Gap report.

#### Phase 3: Process Design

Security management.

Security requirements.

Secure design.

Secure implementation.

Testing processes.

Update management.

#### Phase 4: Pilot Implementation

Selecting representative products.

Applying the processes.

Generating the evidence.

Technical verification.

#### Phase 5: Internal Assessment

Process audit.

Evidence review.

Identification of gaps.

#### Phase 6: Certification Readiness

Verifying the certification scope.

Organising the evidence.

Audit preparation.

#### Critical point

The certification decision is made not by the organisation providing the consulting service but by the relevant competent and independent assessment body.

### \25. Documents That Can Be Prepared for IEC 62443-4-1

#### Management documents

Product security policy.

Security roles and responsibilities.

Secure development procedure.

Training records.

#### Technical documents

Security requirements.

Threat modelling reports.

Secure design records.

Code review records.

Security test plans.

Test results.

#### Operational documents

Vulnerability reporting procedure.

Security issue tracking records.

Update management.

Security advisories.

Product security guidelines.

#### Important point

It is not enough for the documentation merely to exist.

There must be evidence showing that the defined processes are used in real product development activities.

### \26. How Is Threat Modeling Performed for IEC 62443?

Threat modelling enables the systematic identification of security risks in a product or system architecture.

#### Stages

Determining the system architecture.

Defining the assets.

Identifying the trust boundaries.

Developing threat scenarios.

Assessing the risks.

Determining the security controls.

#### Example

**Product:** Industrial gateway.

**Interface:** Web management panel.

**Threat:** Unauthorised administrator access.

**Possible consequence:** Modification of the network configuration.

**Controls:** Strong authentication, access restriction, secure session management and logging.

#### Critical point

Threat modelling should not be a one-off exercise carried out only at the start of development.

It must be updated whenever significant architectural changes occur.

### \27. Source Code Analysis for IEC 62443

Source code security analysis is one of the methods that support secure implementation processes.

#### Topics that can be examined

Unsafe memory operations.

Authentication flaws.

Authorisation gaps.

Input validation.

Secrets management.

Use of cryptography.

Insecure dependencies.

#### Analysis methods

SAST.

SCA.

Manual code review.

Secure coding checklists.

#### Example

A third-party library used in the firmware development process may contain a known vulnerability.

Dependency security processes help identify this risk.

#### Important point

Source code analysis alone does not amount to product security certification.

### \28. Security Testing for IEC 62443

Security tests must be planned according to the product's requirements and conditions of use.

#### Example tests

Authentication.

Authorisation.

Secure communication.

Firmware integrity.

Update security.

Protocol security.

Fuzz testing.

Vulnerability analysis.

#### OT test safety

Wherever possible, tests should be performed in a laboratory or isolated environment.

If testing is to be performed on live production systems, the operational impact must be assessed.

#### Critical point

Uncontrolled testing on industrial devices can create operational downtime or safety risks.

The test plan must take these risks into account.

### \29. How Is IEC 62443 Certification Obtained?

Within IEC 62443, there are conformity assessment mechanisms for different standards and assessment programmes.

#### General approach

Determining the target standard.

Defining the scope.

Selecting the conformity assessment programme.

Implementing the requirements.

Preparing the evidence.

Independent assessment.

Addressing nonconformities.

Certification decision.

#### Important point

It should not be assumed that there is a single general certificate model covering all the IEC 62443 standards.

The certificate type, scope and validity conditions must be verified through the relevant programme.

### \30. Differences Between IEC 62443 and ISO 27001

| Criterion | ISO/IEC 27001 | IEC 62443 |
| --- | --- | --- |
| Primary focus | Information security management system | Security of industrial automation and control systems |
| Field of application | Various sectors | Industrial systems |
| Risk management | ISMS (Information Security Management System) risks | Industrial system and product risks |
| Product development | Indirectly related controls | Direct process requirements through IEC 62443-4-1 |
| Technical system requirements | Risk-based control approach | Detailed requirements through IEC 62443-3-3 and 4-2 |

#### Conclusion

ISO 27001 supports corporate information security management.

IEC 62443, on the other hand, provides requirements specific to the security of industrial systems and products.

The two approaches can be applied together.

### \31. The Relationship Between IEC 62443 and NIS2

NIS2 regulates cyber security obligations for certain sectors and organisations in the European Union.

IEC 62443, in turn, contains technical and process-based standards for the security of industrial systems.

#### Common areas

Risk management.

Supply chain security.

Incident management.

Business continuity.

Security controls.

#### Important point

IEC 62443 compliance does not mean that all NIS2 obligations are automatically met.

The applicable legal requirements must be assessed separately.

### \32. The Most Common Mistakes in IEC 62443 Consulting

#### \1. Failing to determine the target standard

IEC 62443-4-1 and 3-3 contain different requirements.

#### \2. Preparing documentation only

The processes must be applied in real operations.

#### \3. Leaving the pilot product scope unclear

The relationship between the product family and the representative product must be clear.

#### \4. Substituting technical tests for process assessment

Product tests and secure development processes are different assessments.

#### \5. Disregarding OT safety

Tests must be carried out with operational risks in mind.

#### \6. Failing to trace security requirements

The relationship between requirements, design and testing must be established.

#### \7. Neglecting update management

Product security must be maintained throughout the lifecycle.

#### \8. Failing to establish a reporting process for security issues

External security reports must be managed.

#### \9. Failing to verify the certification scope

The rules of the assessment programme must be reviewed.

#### \10. Ignoring the differences between product families

Common processes and product-specific controls must be assessed separately.

### \33. A Sample 120-Day Roadmap for IEC 62443 Consulting

#### Days 1–20: Scope and Gap Analysis

The target standard is determined.

Product families are assessed.

Existing processes are reviewed.

A gap report is prepared.

#### Days 21–45: Process Development

Security management processes are established.

Security requirements are defined.

A threat modelling approach is prepared.

Secure development rules are determined.

#### Days 46–75: Pilot Implementation

Representative products are selected.

Requirements are applied.

Threat modelling is carried out.

Secure development evidence is generated.

#### Days 76–100: Technical Verification

Security tests are performed.

Finding management is applied.

Update processes are assessed.

Evidence is organised.

#### Days 101–120: Internal Assessment

Process compliance is assessed.

Gaps are identified.

Corrective actions are planned.

Certification readiness is reviewed.

#### Important disclaimer

This timeline is a sample project plan.

It does not guarantee certification within 120 days.

The number of products, technical complexity, process maturity and the assessment body's schedule all affect the duration.

### \34. IEC 62443-4-1 Readiness Checklist

#### Management

- Is there a product security policy?
- Have security owners been assigned?
- Have the competencies of the development teams been assessed?

#### Requirements

- Have security requirements been defined?
- Are the requirements traceable?
- Have the differences between product families been identified?

#### Design

- Is threat modelling being carried out?
- Are trust boundaries being identified?
- Are secure default configurations being evaluated?

#### Development

- Are there secure coding rules?
- Have source code review processes been defined?
- Are third-party dependencies being assessed?

#### Testing

- Are there security test plans?
- Are test results being recorded?
- Are findings being tracked?

#### Updates and maintenance

- Is there a reporting process for security issues?
- Has update management been defined?
- Are security guidelines being prepared?

### \35. SECURESYS IEC 62443 Consulting Services

SECURESYS provides consulting and technical assessment services in the field of industrial cyber security to help organisations improve their risk-based security processes.

#### IEC 62443 Gap Analysis

The organisation's current processes are compared against the requirements of the target standard.

#### IEC 62443-4-1 Consulting

Support is provided for establishing and improving secure product development lifecycle processes.

#### IEC 62443-4-2 Technical Readiness

Support can be provided for assessing industrial components against technical security requirements.

#### IEC 62443-3-3 System Security

Industrial system architectures and technical security requirements can be assessed.

#### OT/ICS Risk Analysis

Cyber security risks relating to industrial networks, control systems and operational processes are examined.

#### Secure Development and Source Code Analysis

Support can be provided for secure coding, source code security and dependency management practices in product development processes.

#### Industrial Security Testing

Security assessments of industrial products can be planned within suitable test environments and an appropriate authorisation framework.

#### Pilot Product Implementations

Support can be provided for applying secure development processes through representative products selected from the product families.

#### Certification Readiness

Documentation, process evidence, technical verification and internal assessment activities can be carried out.

#### The SECURESYS approach

**In IEC 62443 consulting, the goal is not merely certification readiness; it is to establish sustainable processes that support the secure development of industrial products and the secure operation of OT systems.**

SECURESYS's consulting and technical assessment activities are carried out separately from the independent certification decision.

#### Frequently Asked Questions (FAQ)

#### \1. What is IEC 62443?

It is an international family of standards for the cyber security of industrial automation and control systems.

#### \2. Who is IEC 62443 for?

There are relevant standards for industrial facility operators, system integrators, automation manufacturers and industrial product developers.

#### \3. What is IEC 62443-4-1?

It defines the process requirements for the secure development lifecycle of industrial products.

#### \4. What is IEC 62443-4-2?

It addresses the technical security requirements of industrial automation and control system components.

#### \5. What is IEC 62443-3-3?

It addresses industrial system security requirements and security levels.

#### \6. What is IEC 62443-2-1?

It addresses the requirements for the security programme of industrial system asset owners.

#### \7. Is IEC 62443 certification mandatory?

There is no single general requirement covering all sectors. Contractual, sector-specific or regulatory requirements must be assessed separately.

#### \8. Are IEC 62443-4-1 and ISO 27001 the same?

No. ISO 27001 focuses on the information security management system, whereas IEC 62443-4-1 focuses on secure industrial product development processes.

#### \9. What is an IEC 62443 security level?

It is a concept used to assess the security resilience of industrial systems or components against particular threat conditions.

#### \10. What does IEC 62443 SL 1–4 mean?

It denotes the protection levels targeted against different attacker capabilities and resource levels.

#### \11. Is a penetration test required for IEC 62443?

Technical security verification needs are determined by the target standard, the product and the risks. A penetration test alone does not satisfy all of the requirements.

#### \12. Should source code analysis be performed for IEC 62443?

Source code analysis can support secure development processes. Suitable methods should be selected according to the product's structure and requirements.

#### \13. How many products should be assessed for IEC 62443-4-1?

The assessment scope is determined by the rules of the target programme and the organisation's product development structure.

#### \14. Can a product-family-based pilot implementation be carried out?

Yes. Applying the processes through representative products can be useful. However, the certification scope must be verified separately.

#### \15. How long does IEC 62443 consulting take?

The duration varies according to the organisation's current process maturity, the number of products, technical complexity and the target requirements.

#### \16. Who issues the IEC 62443 certificate?

Certification can be carried out by competent and independent assessment bodies under the relevant conformity assessment programme.

#### \17. Are IEC 62443 and NIS2 the same?

No. NIS2 is a legal regulation, whereas IEC 62443 is a family of industrial cyber security standards.

#### \18. Is OT network segmentation necessary for IEC 62443?

Segmentation is one of the important control approaches assessed according to system risks and the relevant security requirements.

#### \19. Who should provide IEC 62443 consulting?

Support should be sought from teams that are competent in industrial system security, the target standards, secure development and technical assessment.

#### \20. Does an IEC 62443 certificate cover all products?

No. The scope depends on the relevant assessment programme and on the product, process or system boundaries defined in the certificate.

### Conclusion: Why Is IEC 62443 Important for Industrial Cyber Security?

The IEC 62443 family of standards supports the systematic management of the cyber security of industrial systems and products.

In a successful implementation, the organisation's role must be determined first.

Different requirements must be assessed for a facility operator, a system integrator and a product manufacturer.

The target standard and scope must be clearly defined.

A current state analysis must be carried out.

Risks must be identified.

Secure development or system security processes must be established.

Technical controls must be implemented.

Security tests must be planned.

Evidence and documentation must be organised.

Certification readiness must be pursued in line with the requirements of independent assessment.

**The core value of IEC 62443 lies not only in the certification process; it lies in making security sustainable across the design, development, operation and maintenance stages of industrial systems and products.**

### Official Sources and References

**International Electrotechnical Commission (IEC):** https://www.iec.ch

**IEC Webstore:** https://webstore.iec.ch

**ISA – International Society of Automation:** https://www.isa.org

**ISASecure:** https://isasecure.org

**NIST SP 800-82 – Guide to Operational Technology (OT) Security:** https://csrc.nist.gov/pubs/sp/800/82/r3/final

**CISA – Industrial Control Systems:** https://www.cisa.gov