BLOG

As operational technology becomes more connected, industrial organizations face a difficult security challenge.

They must protect increasingly interconnected control systems without compromising safety, availability, production quality, or process reliability. Security controls that work well in traditional IT environments may be unsuitable for industrial systems that cannot be restarted, patched, scanned, or isolated without careful planning.

The ISA/IEC 62443 standards provide a structured way to address this challenge.

Rather than treating OT cybersecurity as a collection of individual technical controls, the standards establish requirements for managing cyber risk throughout the industrial automation and control system lifecycle. They address the responsibilities of asset owners, system integrators, service providers, and product suppliers.

ISA describes the series as a comprehensive, consensus-based framework for implementing and maintaining secure industrial automation and control systems, or IACS. It covers people, processes, and technology while connecting cybersecurity with operational reliability and process safety.

This guide explains what ISA/IEC 62443 compliance means, how the standards are structured, and how OT cybersecurity leaders can build a practical compliance program.

What Is ISA/IEC 62443 Compliance?

ISA/IEC 62443 compliance means satisfying the requirements of the parts of the ISA/IEC 62443 series that apply to an organization, system, service, or product.

That definition is important because IEC 62443 is not a single checklist.

The series contains multiple standards and technical publications addressing different participants in the industrial cybersecurity lifecycle. An asset owner operating a manufacturing facility has different responsibilities from a system integrator designing an automation solution or a supplier developing an industrial controller.

A credible compliance program must therefore begin with three questions:

1. What is being assessed?
2. Which stakeholder is responsible?
3. Which parts of ISA/IEC 62443 apply?

For an asset owner, compliance may involve establishing an OT security program, conducting system-level risk assessments, defining zones and conduits, managing access, monitoring security events, responding to incidents, and maintaining controls over time.

For a service provider or system integrator, compliance may focus on the security processes used to design, commission, maintain, and support an automation solution.

For a product supplier, it may involve secure product development processes and the technical security capabilities built into industrial components.

Compliance is therefore not achieved simply by purchasing a certified firewall, controller, or software platform. A secure component can support compliance, but the way it is selected, configured, integrated, operated, and maintained also matters.

Why ISA/IEC 62443 Matters for OT Security

Industrial environments have operating conditions that make cybersecurity particularly complex.

Many facilities depend on equipment with lifecycles measured in decades. Some systems use legacy operating platforms, proprietary protocols, vendor-specific engineering tools, or components that are no longer supported.

Maintenance windows may be limited. Changes may require safety reviews, validation, vendor involvement, or production shutdowns. Even a technically successful security update can create operational risk if it disrupts deterministic communication or changes a validated process.

ISA/IEC 62443 addresses these realities by providing requirements specifically designed for industrial automation and control systems. ISA states that the standards apply across industries using automation and control technologies, including power, transportation, building automation, chemicals, oil and gas, and other process environments.

For cybersecurity leaders, adopting the OT security standard IEC 62443 can help:

• Establish consistent security expectations across sites
• Clarify responsibilities between IT, OT, engineering, and suppliers
• Integrate cybersecurity into industrial project lifecycles
• Improve security requirements in procurement
• Prioritize controls according to operational risk
• Create defensible evidence for customers and assessors
• Reduce dependence on informal or site-specific security practices

The goal is not to add every possible control. It is to implement appropriate protections based on system risk, operational consequences, and stakeholder responsibilities.

How the ISA/IEC 62443 Standards Are Structured

The ISA/IEC 62443 series is generally organized into four primary groups.

General concepts: ISA/IEC 62443-1-x

The 62443-1-x publications establish the terminology, concepts, models, and foundational principles used throughout the series.

IEC TS 62443-1-1 defines the core terminology and models for IACS security and establishes the basis for the other standards.

This group helps organizations develop a common language for concepts such as:

• Industrial automation and control systems
• Asset owners
• Automation solutions
• Zones and conduits
• Security levels
• Product suppliers
• Service providers
• Cybersecurity lifecycles

A shared vocabulary matters because OT cybersecurity programs often involve engineers, operators, IT teams, product suppliers, contractors, safety specialists, and executives.

Security programs and procedures: ISA/IEC 62443-2-x

The 62443-2-x standards focus primarily on security programs, policies, procedures, and service-provider processes.

IEC 62443-2-1:2024 specifies security-program policy and procedure requirements for asset owners and operators of IACS environments. The 2024 edition reorganized requirements into security program elements and added a maturity model for evaluating how effectively requirements are implemented.

Other publications in this group address areas such as:

• IACS security protection schemes
• Patch management
• Integration and maintenance service providers
• Coordination between asset owners and suppliers

IEC 62443-2-4:2023, for example, specifies security-related processes that service providers can offer during the integration and maintenance of an automation solution.

System security: ISA/IEC 62443-3-x

The 62443-3-x standards apply to the design and security of complete industrial systems.

IEC 62443-3-2:2020 establishes requirements for defining the system under consideration, dividing it into zones and conduits, assessing risk, determining target security levels, and documenting security requirements.

IEC 62443-3-3 defines system security requirements associated with seven foundational requirements and establishes system capability security levels.

These standards are especially relevant to:

• Asset owners
• OT architects
• Control system engineers
• System integrators
• Cybersecurity engineering teams
• Project and modernization teams

Product and component security: ISA/IEC 62443-4-x

The 62443-4-x standards address the suppliers and developers of industrial products.

IEC 62443-4-1 specifies secure product development lifecycle requirements for products used in industrial automation and control systems.

IEC 62443-4-2 defines technical security requirements for IACS components, including component requirements associated with the seven foundational requirements.

These standards help product suppliers answer two different questions:

• Was the product developed and maintained through a secure process?
• Does the product provide the necessary technical security capabilities?

A product may have strong security features but still be developed through an immature process. Conversely, a supplier may follow a secure development lifecycle while producing components with different capability levels.

Both process assurance and technical capability must be considered.

Core Concepts Behind the OT Security Standard IEC 62443

Understanding a few central concepts makes the standards easier to apply.

Shared responsibility

ISA/IEC 62443 treats cybersecurity as a shared responsibility.

Asset owners cannot transfer all cyber risk to a supplier. Product suppliers cannot control how their products are configured and operated. Integrators cannot compensate indefinitely for weak product capabilities or missing asset-owner governance.

The standards define responsibilities across asset owners, product suppliers, integrators, and service providers throughout the control system lifecycle.

In practice, shared responsibility should be reflected in:

• Contracts
• Statements of work
• Security requirements
• Support agreements
• Remote-access procedures
• Vulnerability disclosure processes
• Patch responsibilities
• Incident-notification requirements
• End-of-support planning

Unclear responsibility creates gaps. Each party may assume another organization is monitoring vulnerabilities, approving patches, reviewing access, or maintaining secure configurations.

Risk-based security

ISA/IEC 62443 does not require every system to receive identical protection.

Controls should be selected according to risk, including the possible safety, operational, environmental, financial, and business consequences of compromise.

This is especially important in OT because the most visible vulnerability is not always the most important risk.

A legacy controller with limited connectivity may represent less immediate risk than a newly deployed remote-access pathway connected to a critical process. Similarly, an unpatched workstation may require compensating controls if patching would interrupt production or invalidate a supported configuration.

Risk-based decision-making allows security teams to prioritize improvements without ignoring operational constraints.

The system under consideration

Before assessing risk, the organization must define the system under consideration, often abbreviated as SUC.

The SUC establishes the boundary of the assessment.

It should identify:

• Included industrial assets
• Relevant networks
• Control and supervisory systems
• Safety-related dependencies
• Engineering workstations
• Remote-access infrastructure
• Connected business or cloud services
• Third-party connections
• External systems upon which the process depends

An unclear boundary produces an unreliable risk assessment. Security teams may overlook vendor connections, shared infrastructure, wireless networks, historian interfaces, or systems managed by other business units.

IEC 62443-3-2 explicitly places definition of the SUC before zone-and-conduit partitioning and risk assessment.

Zones and conduits

Zones group assets that share common security requirements.

A zone may represent a production area, control function, safety system, supervisory environment, remote-access service, or another logical grouping. Assets should not be placed in the same zone merely because they are physically close or connected to the same switch.

Conduits represent controlled communication pathways between zones.

A conduit should define:

• Which systems may communicate
• Which protocols and services are allowed
• How connections are authenticated
• How traffic is restricted
• How events are monitored
• Who owns and approves the communication path

IEC 62443-3-2 requires organizations to partition the SUC into zones and conduits, assess their risk, and assign target security levels.

A network diagram alone is not a complete zone-and-conduit model. The model must connect architecture decisions with risk and security requirements.

Security levels

Security levels provide a structured way to express the security capabilities required from a system, zone, conduit, or component.

A target security level, or SL-T, represents the security level required based on the risk assessment.

A capability security level, or SL-C, represents the security capability supported by a system or component. IEC 62443-3-3 addresses system capability levels, while IEC 62443-4-2 applies capability requirements to IACS components.

A higher security level should not be selected simply because it sounds more secure. Requirements must be proportionate to risk, technically feasible, and sustainable throughout the system lifecycle.

The target may also vary by foundational requirement. A zone could require stronger identification and authentication controls than data-confidentiality controls, depending on its function and risk profile.

The seven foundational requirements

IEC 62443 organizes technical system and component requirements around seven foundational requirements:

1. Identification and authentication control: Verify the identity of users, devices, and software processes.
2. Use control: Restrict authorized users and systems to permitted activities.
3. System integrity: Protect systems and information from unauthorized manipulation.
4. Data confidentiality: Protect sensitive information from unauthorized disclosure.
5. Restricted data flow: Limit unnecessary or unauthorized communication.
6. Timely response to events: Detect, report, and respond to cybersecurity events.
7. Resource availability: Protect essential system resources from disruption or exhaustion.

These foundational requirements form the basis for control-system security capability levels in IEC 62443-3-3 and component requirements in IEC 62443-4-2.

How to Build an ISA/IEC 62443 Compliance Program

ISA/IEC 62443 compliance should be treated as a managed program rather than a one-time assessment.

1. Define the business objective

Begin by documenting why the organization is adopting the standards.

Common objectives include:

• Reducing risk to critical operations
• Meeting customer requirements
• Improving supplier assurance
• Supporting regulatory alignment
• Preparing for an independent assessment
• Standardizing OT security across multiple facilities
• Embedding security into engineering projects

The objective will influence the scope, evidence requirements, budget, and implementation schedule.

2. Identify organizational roles

Determine whether the organization acts as an:

• Asset owner
• Operator
• System integrator
• Service provider
• Product supplier

Document all applicable roles. Do not assume the company is only an asset owner because it operates facilities.

3. Select the applicable standards

Map each role and objective to the relevant parts of the series.

Record:

• Standards selected
• Editions being used
• Organizational units in scope
• Facilities or products in scope
• Exclusions
• Justification for applicability decisions

Because the series continues to evolve, organizations should verify the current edition before beginning a formal assessment. Recent publications include IEC 62443-2-1:2024 for asset-owner security programs, IEC PAS 62443-2-2:2025 for security protection schemes, IEC PAS 62443-1-6:2025 for applying the series to IIoT, and IEC TS 62443-6-1:2024 for evaluating service providers against IEC 62443-2-4.

4. Establish governance

Assign an executive sponsor and a clearly accountable OT security program owner.

Governance should define the roles of:

• Operations
• Control engineering
• IT security
• Network engineering
• Safety teams
• Procurement
• Legal
• Risk management
• Facility leadership
• Product and service suppliers

A RACI matrix can help prevent confusion, but accountability must extend beyond documentation. Owners need authority, resources, and defined escalation paths.

5. Build or validate the OT asset inventory

The inventory should cover more than IP addresses.

Useful records include:

• Hardware model and serial number
• Software and firmware version
• Operating system
• Physical and logical location
• System owner
• Vendor
• Support status
• Criticality
• Communication relationships
• Remote-access methods
• Backup requirements
• Safety or production dependencies

The inventory must be maintained through change-management processes. A spreadsheet produced for an audit will quickly become inaccurate if project, maintenance, and procurement workflows do not update it.

6. Define systems, zones, and conduits

Document the system under consideration and divide it into defensible security zones.

Then identify every approved conduit between those zones.

For each conduit, record:

• Business or operational purpose
• Source and destination
• Permitted protocols
• Required security controls
• Monitoring expectations
• Responsible owner
• Approval authority

This creates the foundation for risk assessment, segmentation, firewall policy, access control, and security monitoring.

7. Conduct the cybersecurity risk assessment

Assess risk for each relevant zone and conduit.

The assessment should consider:

• Threat scenarios
• Existing vulnerabilities
• Potential consequences
• Existing safeguards
• Required security level
• Additional controls
• Residual risk
• Risk acceptance authority

Avoid relying only on generic vulnerability scores. A vulnerability’s importance depends on exploitability, exposure, process function, existing safeguards, and the consequences of compromise.

8. Perform a requirements-based gap assessment

Compare the current environment with the applicable ISA/IEC 62443 requirements. Assess both documentation and operational effectiveness.

Typical review areas include:

• Security governance
• Account management
• Authentication
• Privileged access
• Remote access
• Network segmentation
• Secure configuration
• Malware protection
• Patch management
• Vulnerability management
• Logging and monitoring
• Incident response
• Backup and recovery
• Physical security
• Supplier management
• Change management
• Workforce competency

A policy is not sufficient evidence if employees do not follow it. Likewise, a technical control is difficult to defend if no approved requirement, owner, or review process exists.

9. Build a risk-based remediation roadmap

Prioritize findings using operational risk rather than simple control counts.

The roadmap should distinguish among:

• Immediate risk-reduction actions
• Planned engineering improvements
• Controls requiring shutdown windows
• Long-term modernization
• Supplier-dependent actions
• Accepted risks
• Compensating controls

Every action should have an owner, target date, required resources, validation method, and dependency record.

10. Validate and maintain compliance

Compliance must be maintained as systems, threats, suppliers, and operating conditions change.

Useful triggers for reassessment include:

• Major architecture changes
• New remote connections
• Equipment upgrades
• Supplier changes
• Security incidents
• New vulnerabilities
• Plant expansions
• Mergers or acquisitions
• End-of-support announcements
• Changes to applicable standards

Periodic management reviews should evaluate whether the program remains effective, adequately funded, and aligned with operational risk.

Evidence Needed to Demonstrate Compliance

A strong compliance program produces traceable evidence.

Governance evidence

Examples include:

• Approved OT cybersecurity policies
• Defined roles and responsibilities
• Applicability assessments
• Management-review records
• Risk-acceptance approvals
• Training and competency records
• Security objectives and metrics

Technical evidence

Examples include:

• Asset inventories
• Architecture diagrams
• Zone-and-conduit models
• Firewall configurations
• Access-control records
• Secure configuration baselines
• Monitoring configurations
• Backup test results
• Vulnerability assessment reports

Operational evidence

Examples include:

• Account reviews
• Remote-access approvals
• Patch decisions
• Change records
• Incident exercises
• Recovery tests
• Security-alert investigations
• Remediation tickets
• Maintenance records

Supplier evidence

Examples include:

• Contractual security requirements
• Product security documentation
• Vulnerability disclosure policies
• Patch and advisory processes
• Secure development lifecycle evidence
• Support and end-of-life commitments
• Independent product certifications

Evidence should show more than the existence of a control. It should demonstrate approval, implementation, ownership, operation, review, and correction when the control fails.

Common ISA/IEC 62443 Compliance Mistakes

Treating the series as one checklist

Attempting to implement every requirement without considering stakeholder role or applicability creates unnecessary work and weakens focus. Start with scope and role mapping.

Copying corporate IT controls into OT

Controls designed for office systems may cause unacceptable disruption in industrial environments. OT controls often require testing, vendor coordination, compensating measures, and deployment during planned maintenance windows.

Defining zones only through network equipment

A VLAN is not automatically a security zone. Zones should reflect risk, function, criticality, trust relationships, and security requirements. The network configuration should implement the zone model, not define it by accident.

Setting the same security level everywhere

A plant-wide security-level declaration rarely reflects the actual risk of individual systems and communication paths. Target security levels should be supported by documented risk assessments.

Confusing certification with complete compliance

Product or system certification can provide valuable assurance, but it does not transfer responsibility for secure architecture, configuration, operation, or maintenance.

ISASecure operates conformity-assessment schemes for industrial control products, systems, and supplier development processes based on ISA/IEC 62443. These certifications support assurance decisions but do not automatically establish compliance for the asset owner’s complete operating environment.

Collecting evidence only before an audit

Evidence assembled at the last minute is often incomplete, inconsistent, or disconnected from normal operations. The strongest evidence is created automatically through routine workflows.

Treating compliance as a completed project

OT environments continue to change. New equipment, software updates, vendor access, engineering changes, and business requirements can alter risk. Compliance must therefore be maintained through governance, monitoring, reassessment, and continuous improvement.

Measuring Program Effectiveness

Executives need more than vulnerability totals.

Useful ISA/IEC 62443 program metrics may include:

• Percentage of critical assets with validated inventory records
• Percentage of systems with approved zone-and-conduit models
• Percentage of critical zones with completed risk assessments
• Number of unauthorized communication paths
• Percentage of privileged accounts reviewed
• Percentage of remote sessions using approved controls
• Backup restoration success rate
• Open high-risk findings by age
• Percentage of critical suppliers assessed
• Percentage of accepted risks past their review date
• Mean time to revoke unnecessary access
• Percentage of remediation actions completed on schedule

Metrics should help leaders understand whether risk is decreasing and whether the organization can sustain its controls.

Avoid presenting large numbers without context. A count of missing patches does not explain which systems are exposed, what consequences are possible, or which safeguards are already in place.

ISA/IEC 62443 Compliance Versus Certification

Compliance and certification are related but different.

Compliance generally means that the applicable requirements have been identified, implemented, and supported by evidence.

Conformity assessment evaluates whether defined requirements have been satisfied.

Certification is a formal attestation performed under a specific certification scheme.

IEC states that adoption and use of its international standards are voluntary. However, standards can be referenced in contracts, procurement requirements, organizational policies, legislation, or regulation, which can make specific obligations mandatory in a particular context.

Organizations should determine:

• What must conform
• Which standard and edition apply
• Whether self-assessment is acceptable
• Whether a customer assessment is required
• Whether independent certification is needed
• Which certification scheme is recognized by relevant stakeholders

A professional training certificate is also different from product, process, system, or organizational conformity. It demonstrates that an individual completed defined training or examinations, not that an industrial facility is compliant.

A Practical 12-Month IEC 62443 Roadmap

First 90 days

• Confirm executive sponsorship
• Define the business objective
• Identify applicable stakeholder roles
• Select the relevant standards
• Establish program governance
• Define the initial scope
• Inventory critical assets and remote connections
• Address urgent access and segmentation risks

Months three to six

• Define systems under consideration
• Build zone-and-conduit models
• Conduct risk assessments
• Establish target security levels
• Complete the initial gap assessment
• Define evidence requirements
• Begin supplier assessments

Months six to twelve

• Implement prioritized remediation
• Formalize security procedures
• Improve logging and monitoring
• Validate backup and recovery processes
• Strengthen remote-access controls
• Integrate security into procurement
• Establish executive metrics
• Conduct internal readiness reviews

Beyond twelve months

• Expand the program across facilities
• Integrate requirements into capital projects
• Improve supplier and product assurance
• Automate evidence collection
• Conduct independent assessments
• Review certification objectives
• Maintain continuous improvement

The timeline should reflect the size, complexity, and maturity of the organization. A small facility and a global industrial enterprise will require different levels of effort.

Questions OT Cybersecurity Leaders Should Ask

Leaders can use the following questions to assess program readiness:

• Which ISA/IEC 62443 standards apply to our organization?
• Have we documented every role we perform?
• Is the system under consideration clearly defined?
• Are zones and conduits based on risk or only network topology?
• Have target security levels been justified?
• Can we demonstrate that our controls operate as documented?
• Who owns residual OT cybersecurity risk?
• Are supplier responsibilities defined contractually?
• Can we quickly revoke third-party remote access?
• Are compensating controls formally approved and tested?
• Which legacy risks cannot currently be remediated?
• What evidence would an assessor be unable to verify today?

These questions move the discussion away from isolated security products and toward measurable operational assurance.

Frequently Asked Questions

What is ISA IEC 62443 compliance?

ISA IEC 62443 compliance means meeting the applicable requirements of the ISA/IEC 62443 standards for an industrial organization, system, service, product, or development process.

The specific requirements depend on the stakeholder’s role and the scope of the assessment.

Is ISA/IEC 62443 mandatory?

IEC standards are voluntary by default. However, ISA/IEC 62443 requirements may become mandatory when incorporated into contracts, procurement specifications, organizational policies, legislation, or regulatory requirements.

Which standard applies to asset owners?

IEC 62443-2-1 addresses security-program requirements for IACS asset owners and operators.

Asset owners also commonly use IEC 62443-3-2 for system risk assessment and IEC 62443-3-3 for system security requirements.

What is the difference between IEC 62443-3-3 and IEC 62443-4-2?

IEC 62443-3-3 defines security requirements and capability levels for complete control systems.

IEC 62443-4-2 defines technical security requirements and capability levels for individual IACS components.

What is the difference between IEC 62443-4-1 and IEC 62443-4-2?

IEC 62443-4-1 focuses on the processes used to develop and maintain secure industrial products.

IEC 62443-4-2 focuses on the technical security capabilities of the components themselves.

Does using certified products make a facility compliant?

No.

Certified products may provide valuable assurance and help satisfy selected requirements. The asset owner must still address architecture, risk assessment, configuration, operations, access, monitoring, incident response, maintenance, and governance.

How often should an IEC 62443 assessment be repeated?

The organization should establish a periodic review schedule and reassess whenever material changes affect the system or its risk.

Relevant triggers include architecture changes, new connectivity, major upgrades, incidents, supplier changes, and newly identified threats or vulnerabilities.

Conclusion

ISA/IEC 62443 compliance is not a paperwork exercise and should not be reduced to a product checklist.

It is a structured approach to managing industrial cybersecurity risk throughout the lifecycle of automation and control systems.

A successful program begins by identifying stakeholder roles, selecting the applicable standards, defining the system under consideration, and assessing risk. It then translates those findings into zones, conduits, security requirements, governance processes, technical controls, and verifiable evidence.

For OT cybersecurity professionals, the standards provide a common engineering framework.

For leaders, they provide a way to connect cybersecurity investment with operational resilience, safety, supplier accountability, and business risk.

The most practical starting point is not to implement every control immediately. It is to establish a defensible scope, determine which ISA/IEC 62443 requirements apply, and build a risk-based roadmap that the organization can sustain.