Connect981 – Content Dev

RSC Cluster: IEC 62443 Industrial Cybersecurity for Manufacturing and OT

  • IEC 62443-2-4

    IEC 62443-2-4 is a part of the IEC 62443 series that specifies cybersecurity requirements for service providers who design, integrate, operate, or maintain industrial automation and control systems (IACS). It focuses on how external providers must organize and execute their services so that industrial systems can achieve and maintain an appropriate security level.

    The standard commonly applies to vendors, system integrators, and managed service providers that deliver activities such as system integration, maintenance, remote support, patching, and monitoring for operational technology (OT) environments. It defines process and technical requirements the service provider should meet, including topics like secure configuration, change handling, vulnerability and patch handling, documentation, and incident response coordination.

    Scope and applicability

    IEC 62443-2-4 primarily addresses:

    • Service providers working on industrial control systems, safety systems, and related OT networks
    • Service arrangements such as projects, long-term service contracts, and remote operations support
    • Interfaces between the service provider and the asset owner, including responsibilities, information exchange, and access methods

    It does not define a complete security program for the asset owner, nor is it a product standard. Instead, it focuses on the requirements that apply to the way services are delivered and managed.

    Operational meaning in manufacturing and regulated environments

    In industrial and regulated operations, IEC 62443-2-4 is often used as a reference when qualifying and managing external providers who have access to OT systems. Typical applications include:

    • Writing contractual security requirements for system integrators and service partners
    • Defining expectations for remote access, account management, and change implementation on production systems
    • Requesting documented procedures, records, and technical controls related to cybersecurity activities
    • Aligning supplier audits or assessments with commonly recognized OT security practices

    Asset owners may map their internal supplier qualification, change control, and evidence collection practices to the requirements in IEC 62443-2-4 to better manage risk in brownfield, validated, or high-availability environments.

    Relationship to the broader IEC 62443 series

    IEC 62443-2-4 is part of the “2” series within IEC 62443, which focuses on security policies, procedures, and management system aspects. It complements other parts that address:

    • Overall security programs for asset owners and operators of IACS
    • System-level requirements for secure architectures
    • Component-level requirements for products used in OT environments

    Used together, these parts allow asset owners, product suppliers, and service providers to reference a shared framework when defining and coordinating cybersecurity responsibilities.

    Common confusion

    IEC 62443-2-4 is sometimes:

    • Mistaken for a product standard. It does not directly certify or qualify hardware or software products; it concentrates on service delivery processes and controls.
    • Assumed to be automatically met by all major vendors or integrators. Actual alignment typically requires explicit requirements, documented scope, and evidence-based assessment rather than default assumptions.
    • Used interchangeably with organization-wide security management standards. While related, it specifically targets service provider activities around industrial control systems.

    Context: service provider expectations

    In practice, organizations often use IEC 62443-2-4 as a reference when defining what they expect from external service providers that access production OT or validated systems. This can include specifying roles and responsibilities, required documentation, acceptable remote access patterns, and how security-relevant changes are requested, approved, implemented, and recorded over the life of the service relationship.

  • defense in depth

    Defense in depth is a security strategy that uses multiple, independent layers of controls to protect systems, data, and operations. Instead of relying on a single barrier, it assumes that individual controls can fail or be bypassed and therefore stacks technical, procedural, and physical safeguards so that a weakness in one layer is mitigated by others.

    Key characteristics

    In industrial and regulated environments, defense in depth commonly includes:

    • Multiple control types such as physical security (fences, locks, access badges), technical measures (network segmentation, firewalls, authentication, encryption), and administrative controls (policies, procedures, training).
    • Layered placement of controls at different points, for example at the perimeter, network zones, endpoints, applications, and data level.
    • Assumption of compromise, designing systems so that if one control is bypassed, subsequent layers still limit impact and maintain required operations.
    • Independence of layers where possible, so that a single failure mode does not disable multiple protections at once.

    Application in industrial and OT environments

    Within manufacturing, defense in depth is often applied to both IT and OT systems that support production, quality, and regulatory obligations. Examples include:

    • Using separate network zones for corporate IT, plant systems, and critical control networks, with controlled gateways between them.
    • Hardening servers, HMIs, MES, and PLCs individually, even when they sit behind firewalls.
    • Combining user access controls in MES/ERP with strong identity management, logging, and independent audit trails.
    • Supporting cybersecurity controls with procedures such as change management, backup and recovery practices, and incident response plans.

    Relation to ISMS and compliance

    Within an Information Security Management System (ISMS), defense in depth is one of the core design principles for protecting information assets and production systems. It is typically implemented as a coordinated set of controls across people, process, and technology, and is aligned with risk assessments and governance structures. The existence of multiple layers does not imply any specific compliance status; it is a design approach that can be evaluated within audits and risk reviews.

    Common confusion

    • Not the same as perimeter security only: Defense in depth includes perimeter controls but also assumes that threats may originate inside the network or bypass external defenses.
    • Not limited to cybersecurity: The principle can also apply to safety, quality, and continuity controls, for example using both automated interlocks and procedural checks to prevent unsafe operations.

  • zones and conduits

    In industrial and OT cybersecurity, zones and conduits commonly refer to a structured way of segmenting systems and controlling communications between those segments. The concept is widely associated with IEC 62443 and similar standards for securing industrial automation and control systems.

    Definition

    Zones are groupings of assets (such as controllers, servers, workstations, sensors, and applications) that share similar security requirements and risk profiles. A zone typically:

    • Represents a logical or physical segment of the system (for example, a plant floor control network, a DMZ, or an engineering workstation group)
    • Is defined by common security policies, such as required authentication, allowed services, or target security level
    • Can map to network segments, functional areas, or combinations of both

    Conduits are the controlled communication paths that connect zones. A conduit typically:

    • Represents the data flows between zones (for example, between a control network and a historian, or between OT and IT networks)
    • Implements security controls for those flows, such as firewalls, VPNs, demilitarized zones (DMZs), or data diodes
    • Defines which protocols, ports, and directions of traffic are permitted between zones

    How zones and conduits are used operationally

    In industrial environments, zones and conduits are used to:

    • Model the architecture of industrial automation and control systems at a security level
    • Support risk assessments by showing where critical assets reside and how they are interconnected
    • Guide design and configuration of network segmentation, access control lists, and security gateways
    • Document intended communication paths for change management, compliance reviews, and incident response

    For example, a manufacturing site might define separate zones for field I/O, control systems, safety systems, a site operations network, and enterprise IT. Conduits would then describe and restrict traffic between these zones, such as historian data flows from OT to IT or remote maintenance connections into control networks.

    Relationship to IEC 62443

    IEC 62443 commonly uses zones and conduits as core concepts for designing and documenting a secure industrial control system architecture. The standard encourages grouping assets into zones with defined target security levels and controlling inter-zone communication through conduits with appropriate technical and procedural safeguards. This approach supports lifecycle activities such as design, implementation, and ongoing verification of security controls in OT environments.

    Common confusion

    • Zones vs. VLANs or subnets: A zone is a security and risk construct, not strictly a network construct. A single zone can span multiple subnets, and one subnet can contain multiple zones if they have different security requirements.
    • Conduits vs. network devices: A conduit is the secured communication path and its policies, not just the physical device. A firewall, router, or gateway may implement part of a conduit, but the conduit includes the defined rules, monitoring, and documentation for that traffic.
    • Zones vs. physical areas: Physical plant areas (for example, a packaging line) and zones are not always the same. Zones are defined primarily by security needs and logical interactions, even though they often align with physical layouts.

    Manufacturing-relevant examples

    • A “Safety Instrumented System” zone separated from a “Basic Process Control System” zone, with a tightly controlled conduit allowing only specific diagnostic data.
    • A “Site Operations” zone containing MES and historian servers, connected via conduits to both control system zones (for process data) and the enterprise IT zone (for reporting and planning).
    • A remote access conduit that permits vendor maintenance connections to a specific control zone through a gateway with strong authentication and logging.

    Use in documentation and governance

    Zones and conduits are often documented in architecture diagrams, security plans, and procedures. They support coordination between OT, IT, engineering, and quality teams by providing a clear model of where critical functions reside and how information moves across the manufacturing environment.

  • security level

    A security level is a defined degree of protection against intentional or accidental threats to systems, data, or physical assets. In industrial and regulated environments, it commonly refers to a graded set of cybersecurity or physical security requirements that must be met for a system, zone, or asset.

    In industrial and OT cybersecurity

    In operational technology (OT) and industrial control system (ICS) contexts, a security level often refers to a formal, discrete rating that describes how resistant a system is to cyber attacks from defined types of adversaries. Frameworks such as IEC 62443 use numbered security levels to specify progressively stronger requirements for:

    • Access control and authentication
    • System integrity and hardening
    • Network segmentation and communication security
    • Monitoring, detection, and incident response
    • Maintenance and change management practices

    In this usage, the security level applies to defined scopes such as devices, systems, zones, or conduits. It is set based on a risk assessment, threat model, and impact analysis, then implemented through technical and procedural controls. The level itself does not guarantee security; it reflects the intended rigor of applied controls.

    Operational meaning in manufacturing

    Within manufacturing operations, security levels may be used to:

    • Classify production networks or cells (for example, segregated OT zones) according to required protection
    • Set minimum security expectations for equipment suppliers and system integrators
    • Drive requirements for user roles in MES, historians, or SCADA systems
    • Guide patching, remote access, and backup procedures based on the criticality of assets

    Security levels are typically documented in security policies, system specifications, or zone & conduit models and are used as a reference during design, implementation, and assessment activities.

    Common confusion

    • Security level vs. safety integrity level: A security level addresses protection against malicious or unauthorized actions. A safety integrity level (SIL) in functional safety addresses the reliability of safety functions against hazards, not cybersecurity.
    • Security level vs. security control: A security level is an overall target or rating. Security controls are individual technical or procedural measures used to achieve that level.
    • Security level vs. compliance status: A security level does not in itself confirm regulatory or standard compliance. It is a design and management construct that may be aligned with standards and then verified through separate assessments.

    Relation to IEC 62443 context

    In the context of IEC 62443, security levels are central to specifying cybersecurity requirements for industrial automation and control systems. The standard defines how asset owners, system integrators, and product suppliers can use graded security levels to scope, design, and assess controls over the full lifecycle. The chosen level is based on risk and threat assumptions and must be supported by appropriate technical and organizational measures.

  • ISA-99

    ISA-99 commonly refers to a series of standards developed by the International Society of Automation (ISA) that define cybersecurity concepts and requirements for industrial automation and control systems (IACS). The work originally published under the ISA-99 designation has been jointly developed and harmonized with the International Electrotechnical Commission (IEC) and is now largely known internationally as the IEC 62443 series.

    In manufacturing and other industrial environments, ISA-99 concepts are used to structure how plants identify, categorize, and protect operational technology (OT) systems, including DCS, PLCs, SCADA, MES interfaces, and associated networks. The standards describe models, terminology, and requirements for securing these systems over their lifecycle, from design and integration through operation and maintenance.

    Scope and key concepts

    Within industrial operations, ISA-99 / IEC 62443 commonly covers:

    • Foundational terminology and reference models for IACS cybersecurity
    • Segmentation concepts such as zones and conduits to structure networks and access control
    • Security levels and capability requirements for systems and components
    • Policies and procedures related to patching, remote access, account management, and monitoring
    • Lifecycle considerations such as secure design, integration, and maintenance of control systems

    In regulated manufacturing plants, ISA-99 aligned practices are often mapped against existing OT and IT controls, vendor capabilities, and site change-control and validation processes. The intent is to integrate cybersecurity into existing engineering, quality, and maintenance workflows rather than treat it as a standalone activity.

    Use in practice

    Operationally, ISA-99 may appear in:

    • Internal standards or policies that adopt ISA-99 / IEC 62443 terminology for zones, conduits, and security levels
    • System design specifications that call for certain security capabilities for controllers, HMIs, gateways, and MES interfaces
    • Vendor and integrator requirements for configuring, documenting, and maintaining OT assets
    • Risk assessments and mitigation plans focused on IACS and their supporting networks

    Organizations may still use the term “ISA-99” informally, even when the applicable documents are labeled IEC 62443, particularly in North America or where legacy documentation predates the harmonized numbering.

    Common confusion

    • ISA-99 vs IEC 62443: ISA-99 work products have been jointly developed with IEC and are published in the IEC 62443 series. In many contexts, references to “ISA-99” today effectively mean “the ISA/IEC 62443 series.” The specific numbering and publication format can differ between ISA and IEC.
    • ISA-99 vs IT security standards (for example, ISO/IEC 27001): ISA-99 focuses on industrial automation and control systems and their specific needs, while general IT security standards cover broader information security management. Plants often map requirements between these to avoid conflicting expectations on shared infrastructure.

    Relation to IEC and other standards

    ISA-99 originated within ISA and was later aligned with IEC through joint development, resulting in corresponding IEC 62443 parts. In practice, industrial sites may need to reconcile ISA-99 / IEC 62443 guidance with other standards and regulatory expectations, including those that govern quality systems, functional safety, or data integrity in regulated manufacturing.

  • incident response

    Incident response commonly refers to the organized set of processes, roles, and tools used to manage and resolve unplanned events that threaten normal operations, information security, safety, or regulatory compliance. In industrial and regulated environments, this typically focuses on cyber and operational technology (OT) incidents that could affect production systems, product quality, data integrity, or safety.

    Core elements of incident response

    Although specific models vary, incident response activities usually include:

    • Preparation: Defining policies, playbooks, communication paths, responsibilities, and technical tooling (logging, monitoring, forensics).
    • Detection and analysis: Identifying potential incidents from alerts, logs, user reports, or process anomalies, then triaging and confirming scope, impact, and severity.
    • Containment: Limiting further impact, for example by isolating affected OT/IT assets, disabling user accounts, or switching to manual or degraded operating modes.
    • Eradication: Removing root causes, such as malware, unauthorized changes, or misconfigurations, and restoring systems to a known-good state.
    • Recovery: Safely returning systems and processes to normal operation, validating that they are stable, and monitoring for reoccurrence.
    • Post-incident review: Capturing lessons learned, updating procedures, and improving controls, training, and system designs.

    Incident response in industrial and regulated environments

    In manufacturing, incident response must coordinate across OT, IT, quality, and compliance functions. Typical concerns include:

    • Security incidents affecting PLCs, SCADA, MES, ERP, data historians, or network segments that control or monitor production lines.
    • Events that may compromise data integrity in batch records, device history records, electronic logs, or quality systems.
    • Incidents that could trigger deviation management, CAPA, or regulatory reporting, such as suspected tampering, unauthorized changes, or prolonged system outages.
    • Maintaining safe states and verifying that any return to production does not bypass required checks, interlocks, or approvals.

    Incident response processes are often integrated with change management, business continuity, disaster recovery, and quality management systems. Evidence collection and documentation are usually emphasized to support audits, investigations, and continuous improvement.

    Relationship to cyber threat intelligence (CTI)

    Cyber threat intelligence feeds, especially tactical and technical CTI, frequently inform incident response. Indicators such as malicious IPs, domains, file hashes, and TTPs (tactics, techniques, and procedures) can be used to:

    • Improve detection rules and alert triage for OT and IT environments.
    • Guide scoping, containment, and hunting activities during an active incident.
    • Support post-incident analysis of adversary behavior and potential future exposure.

    Common confusion

    • Incident response vs. disaster recovery: Incident response covers the immediate handling of a specific event, including analysis and containment. Disaster recovery focuses on restoring IT/OT services after a major disruption, often using backups and alternate sites.
    • Incident response vs. business continuity: Business continuity planning defines how to maintain critical operations during disruptions. Incident response is the concrete set of steps taken to address a specific incident that may trigger those plans.
    • Incident response vs. problem management: In service management frameworks, problem management aims to find and address root causes to prevent recurring issues. Incident response deals with the active, time-sensitive handling of one incident, even when the root cause is not yet fully understood.

  • zone and conduit

    In the context of industrial cybersecurity, especially IEC 62443, zone and conduit refers to a structured way of segmenting operational technology (OT) environments and controlling communication between those segments.

    Zones

    A zone is a logical or physical group of assets that share similar cybersecurity requirements, such as security level, trust level, or functional role. A zone can include:

    • Control systems and controllers (PLCs, DCS nodes)
    • SCADA servers, HMIs, engineering workstations
    • Network equipment associated with those systems
    • In some cases, supporting IT systems that have aligned risk and protection needs

    Zones are usually defined during risk assessment and architecture design. Each zone typically has:

    • Clear boundaries
    • Documented assets
    • Assigned security level targets or comparable cybersecurity objectives

    A zone does not have to be a single VLAN, room, or cabinet, although it may map to these. It is primarily a grouping concept based on security requirements, not just topology.

    Conduits

    A conduit is a defined communication path that connects two or more zones. It represents:

    • The logical communication flow between zones
    • The controls that protect that flow, such as firewalls, data diodes, VPNs, or protocol break devices
    • The policies applied to that traffic, such as allowed protocols, ports, and directions

    Conduits are designed to enforce the required cybersecurity posture between zones. In many architectures, critical functions such as remote access, cross-site replication, or MES/ERP integration are modeled as conduits between a control zone and a higher-level business or DMZ zone.

    Operational use in industrial environments

    In regulated manufacturing and other industrial operations, defining zones and conduits is a common step in:

    • Cybersecurity risk assessments for OT and industrial control systems
    • Network segmentation and defense-in-depth architecture design
    • Documenting how MES, historians, and ERP systems connect to plant-floor equipment
    • Supporting security procedures for remote support, vendor access, and data exchange

    Zones and conduits are usually captured in network and security architecture diagrams, and referenced in site standards, operating procedures, and change control documentation.

    Relation to IEC 62443

    IEC 62443 introduces the concepts of zones and conduits as core elements of secure industrial automation and control system architecture. The standard uses them to:

    • Structure the allocation of cybersecurity requirements to groups of assets
    • Define where security controls should be applied to communication paths
    • Support risk-based segmentation between systems with different security levels

    While implementations vary, using zones and conduits aligns with IEC 62443-style approaches to designing and documenting OT cybersecurity controls.

    Common confusion

    • Zone vs. VLAN or subnet: A zone may be implemented with one or more VLANs or subnets, but it is defined by common cybersecurity requirements, not only by IP addressing.
    • Conduit vs. physical link: A conduit is about the logical and controlled communication path, which may traverse multiple physical links, switches, or service providers.
    • Zone and conduit vs. safety zones: Process safety zones or functional safety partitions are different concepts, although they may influence how cybersecurity zones are defined.

    Link to the source context

    In the context of IEC 62443 guidance for asset owners, zoning and conduits are typically introduced when applying parts such as IEC 62443-3-2, where sites identify industrial control system assets, group them into zones with defined security levels, and specify conduits that manage and protect communications between those zones.

  • industrial automation and control system

    An industrial automation and control system (IACS) is the integrated set of hardware, software, networks, and supporting infrastructure used to monitor, control, and automate industrial processes. It typically spans from field devices in the plant to supervisory and sometimes enterprise interfaces, and is treated as a system from both operational and cybersecurity perspectives.

    Core characteristics

    An industrial automation and control system commonly includes:

    • Field instrumentation, sensors, and actuators connected to the process or equipment
    • Programmable logic controllers (PLCs), remote terminal units (RTUs), and other controllers that execute control logic
    • Supervisory systems such as SCADA servers, DCS workstations, and historians
    • Human-machine interfaces (HMIs) and operator stations
    • Industrial communication networks and protocols (for example, fieldbuses, industrial Ethernet)
    • Supporting servers, gateways, and sometimes application software that link OT systems with IT or MES/ERP

    In manufacturing, the IACS is what runs production lines, utilities, packaging systems, and other automated operations, often in continuous coordination with quality systems and higher-level planning or execution systems.

    Scope and boundaries

    The term usually refers to the operational technology (OT) environment responsible for real-time or near real-time control. It focuses on:

    • Reliable process control and interlocks
    • Acquisition and transmission of process and equipment data
    • Execution of automation logic, recipes, and sequences

    It typically excludes purely business IT systems such as email, office productivity tools, and non-industrial enterprise applications, even though those may connect to the IACS through defined interfaces.

    Operational use in regulated manufacturing

    In regulated or high-consequence manufacturing environments, the IACS is a central system of record for:

    • Capturing process parameters and setpoints used to demonstrate control of critical operations
    • Executing automated steps that must align with validated processes or documented work instructions
    • Exchanging data with MES, quality systems, or batch/recipe management systems for traceability and review

    From a security and reliability standpoint, organizations treat the IACS as a distinct system, often with its own lifecycle management, change control, and risk assessment processes.

    Relation to IEC 62443 and cybersecurity

    Within the IEC 62443 series, industrial automation and control systems are the primary focus of security requirements and models. The standard defines IACS as the collection of systems used for industrial automation, including control, monitoring, and related support systems.

    For example:

    • IEC 62443-3-3 addresses security requirements at the IACS (system) level, considering the deployed architecture, zones, and conduits.
    • IEC 62443-4-2 addresses technical security requirements for components that make up an IACS, such as PLCs, HMIs, gateways, and software.

    In practice, security levels and requirements are often defined for the IACS as a whole, then allocated down to individual components during design, procurement, and integration.

    Common confusion

    • IACS vs. SCADA/DCS: SCADA and DCS are specific types of control architectures or systems. An IACS may include SCADA, DCS, or both, as well as other components like stand-alone PLC cells.
    • IACS vs. OT: OT (operational technology) is a broader category that covers all industrial control and field systems. An IACS is usually a defined subset of OT, representing a particular integrated control system or automation domain.
    • IACS vs. MES: MES manages production execution and information flow above the control layer. The IACS interfaces with MES but is focused on direct control and monitoring of equipment and processes.

  • defense-in-depth

    Defense in depth is a cybersecurity strategy that uses multiple, independent layers of protection so that no single failure, misconfiguration, or breach results in uncontrolled access to systems or data. In industrial and manufacturing environments, it commonly refers to applying layered technical and procedural controls across operational technology (OT), industrial control systems (ICS), and supporting IT systems.

    Key characteristics

    In an industrial context, defense in depth typically includes:

    • Network segmentation and zoning such as separating corporate IT, DMZ, and control networks, and limiting traffic between them
    • Multiple security controls per pathway for example, firewalls plus access control plus monitoring on the same communication route
    • Technical and procedural layers combining tools (firewalls, endpoint protection, system hardening) with policies (access management, change control, incident response)
    • Device, system, and enterprise levels controls at field devices and controllers, control room systems, site infrastructure, and central IT/OT services
    • Detection as well as prevention such as logging, intrusion detection, and anomaly monitoring in addition to blocking measures

    The intent is that if one control is bypassed or fails, other controls still limit the impact and help maintain safe and reliable operations.

    How it appears in operations

    In regulated manufacturing or critical infrastructure, defense in depth may affect:

    • System architecture use of security zones and conduits aligned with standards like IEC 62443
    • Access management role-based access, multi-factor authentication, and separate accounts for engineering, operations, and vendors
    • Engineering and maintenance controlled remote access, change management, and secure configuration of PLCs, HMIs, and MES/SCADA systems
    • Monitoring and response centralized log collection, OT-aware security monitoring, and documented incident handling procedures
    • Lifecycle activities security considerations in system design, procurement, commissioning, and decommissioning

    Relation to IEC 62443

    IEC 62443, focused on industrial automation and control systems cybersecurity, commonly references and structures requirements around the principle of defense in depth. It uses concepts such as security zones, conduits, and layered technical and organizational measures to realize defense in depth across systems and components. Specific implementations depend on the role of the organization and which parts of the standard are applied.

    Common confusion

    • Not the same as perimeter security only: Defense in depth includes perimeter controls but also internal layers such as host hardening, application security, and monitoring.
    • Not a specific product or tool: It is an overall design and governance approach that can be implemented with different technologies and processes.