Connect981 – Content Dev

RSC Topic: Security levels (IEC 62443)

  • 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.

  • 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.

  • 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.

  • Target Security Level (SL-T)

    Target Security Level (SL-T) is a specified cybersecurity strength that an industrial system, zone, or communication conduit is intended to achieve. It expresses the desired level of protection against a defined set of threats, taking into account risk assessments, regulatory expectations, and operational constraints.

    The term is commonly used in industrial control system and operational technology (OT) security frameworks, such as those aligned with IEC 62443. In those contexts, SL-T is a design and planning objective that guides how security controls are selected, implemented, and validated across control systems, networks, and related assets.

    What Target Security Level includes

    In regulated and industrial environments, SL-T typically:

    • Is expressed as a discrete level (for example, 1 through 4) where higher levels reflect stronger protection against more capable or better resourced attackers.
    • Is defined per security requirement or per group of requirements (such as identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability).
    • Applies to a defined scope, such as a process cell, production line, network segment, or application (for example, a PLC network, MES interface zone, or remote access conduit).
    • Is derived from risk analysis, considering threats to safety, product quality, system availability, environmental impact, and regulatory compliance.

    SL-T is a planning target. It does not in itself prove that the system currently meets that level; it describes what the system should be designed, implemented, and maintained to achieve.

    How Target Security Level is used operationally

    In manufacturing and other industrial operations, SL-T is typically used to:

    • Guide architecture and design decisions for OT networks, safety systems, MES/ERP interfaces, and remote access paths.
    • Determine which technical and procedural controls are required, such as authentication methods, network segmentation, logging, and change control.
    • Support security requirement specifications in equipment procurement and system integration projects.
    • Provide a baseline for assessing current security posture, identifying gaps, and planning remediation activities.
    • Align security expectations between operations, engineering, IT/OT security teams, and external suppliers or service providers.

    When a system is evaluated, the actually achieved security level is often compared against the Target Security Level to identify discrepancies and plan improvements.

    Common confusion

    • Target Security Level (SL-T) vs. Achieved Security Level (often SL-A): SL-T is the intended or required level of security; SL-A refers to the level actually demonstrated in an assessment. They should not be treated as the same thing.
    • Target Security Level vs. generic “security maturity”: SL-T is usually defined against a structured set of technical and organizational requirements, not a broad qualitative maturity model.
    • Target Security Level vs. safety integrity level (SIL): Although both use levels and appear in industrial risk discussions, SL-T focuses on cybersecurity resistance to threat actors, while SIL focuses on functional safety performance of safety-related systems.

    Context in industrial and regulated environments

    In regulated manufacturing, defining a Target Security Level helps coordinate cybersecurity expectations across OT, IT, and engineering functions. It is often applied to control systems, data acquisition infrastructure, and interfaces to systems such as MES, LIMS, QMS, and ERP. Clear SL-T definitions support consistent design, documentation, and audit evidence for cybersecurity-related controls without themselves constituting a formal certification.

  • ISA/IEC 62443

    ISA/IEC 62443 is a family of international standards that defines terminology, concepts, and requirements for securing industrial automation and control systems (IACS). It covers the full lifecycle of operational technology (OT) environments, including design, implementation, operation, and maintenance of industrial control systems in sectors such as manufacturing, energy, and aerospace.

    The standards are jointly developed by the International Society of Automation (ISA) and the International Electrotechnical Commission (IEC). They are structured into multiple parts that address different stakeholders and layers, including asset owners, system integrators, and product suppliers.

    Key concepts

    Across the series, ISA/IEC 62443 commonly addresses:

    • Industrial automation and control systems (IACS): Control systems, SCADA, PLCs, DCS, safety systems, and supporting networks used to monitor and control industrial processes.
    • Security levels (SLs): Graduated target levels of cybersecurity robustness defined against different attacker capabilities, used to set requirements for systems, zones, and conduits.
    • Zones and conduits: A segmentation model that groups assets with similar security needs into zones and manages communications between them through controlled conduits.
    • Defense in depth: Layered technical and procedural controls across network, system, and application layers.
    • Lifecycle approach: Requirements for security spanning development, integration, operation, maintenance, and decommissioning of OT assets.

    Scope in manufacturing and regulated environments

    In industrial and manufacturing contexts, ISA/IEC 62443 commonly applies to:

    • Plant control networks, PLCs, DCS, SCADA, and safety instrumented systems.
    • Interfaces between OT and IT, including connections to MES, ERP, historians, and remote access solutions.
    • Engineered test equipment and automated test stands used for production or qualification of regulated hardware, such as aerospace components.
    • Supplier-developed automation components that must be integrated into a secure plant architecture.

    Organizations often use ISA/IEC 62443 to define security requirements for new systems, assess existing installations, specify vendor expectations, and align with internal or external cybersecurity programs.

    Relationship to other frameworks

    ISA/IEC 62443 focuses specifically on industrial and OT environments. It is frequently mapped or aligned with broader cybersecurity frameworks such as NIST 800-53, NIST Cybersecurity Framework, or sector-specific guidance. In practice, many regulated manufacturers use ISA/IEC 62443 to define OT-specific controls that complement enterprise IT security requirements.

    Operational use

    In day-to-day operations, ISA/IEC 62443 commonly informs:

    • Risk assessments for control systems and connected test equipment.
    • Network segmentation and access control design for production lines.
    • Security requirements in equipment procurement and supplier contracts.
    • Procedures for patching, remote access, account management, and system hardening in OT environments.

    Common confusion

    • Not a single standard: ISA/IEC 62443 is a series of documents, not one standalone specification. Different parts target policies, system requirements, and product development practices.
    • Not limited to one industry: While widely used in manufacturing and process industries, the series is intended for any industrial automation and control environment, including infrastructure and aerospace test and ground systems.
    • Security levels vs. maturity levels: ISA/IEC 62443 security levels describe technical robustness against types of attackers, which is different from organizational maturity models that rate processes or governance.

    Link to the provided context

    In scenarios such as flight hardware test equipment, ISA/IEC 62443 is often referenced to set cybersecurity expectations for test stands and associated control networks. Asset owners may use its security levels and zoning concepts to determine appropriate protections for mission-critical, safety-relevant test systems while considering connectivity, data sensitivity, and existing controls.

  • security zones and conduits

    Security zones and conduits is a core concept in industrial cybersecurity, particularly in the IEC 62443 series of standards. It provides a structured way to segment operational technology (OT) and related IT systems and to control how they communicate.

    Security zones

    A security zone is a logical grouping of assets that share similar security requirements and risk characteristics. In an industrial or manufacturing environment, a zone typically contains systems that:

    • Have similar criticality (for example, safety-critical control vs. monitoring only)
    • Require similar security levels or protections
    • Are under a common administration or trust boundary

    Zones commonly include combinations of:

    • Controllers and I/O (PLCs, RTUs, safety systems)
    • Engineering workstations and HMIs
    • Plant historians, MES interfaces, and local servers
    • Network devices that primarily serve that zone

    Zones do not have to match physical areas or existing network subnets, although they are often aligned for practicality. A single production line might contain multiple zones, such as a safety instrumented system zone and a basic process control zone.

    Security conduits

    A security conduit is a defined communication path that connects two or more zones and provides the necessary protection for traffic that crosses zone boundaries. It is not just a cable or a single device; it is the combination of:

    • Communication channels (for example, specific VLANs, routes, or links)
    • Security functions (for example, firewalls, VPNs, application proxies)
    • Rules and configurations that constrain and monitor traffic

    In practice, conduits often correspond to:

    • Firewall rule sets between the control network and the corporate network
    • VPN tunnels used for remote vendor access to OT assets
    • Strictly controlled links between a process control zone and a safety system zone

    Each conduit is designed and documented so that the risks of inter-zone communication are understood and addressed.

    How zones and conduits are used

    Within IEC 62443 and similar approaches, security zones and conduits are used to:

    • Structure risk assessments around groups of assets instead of individual devices
    • Assign required security levels to zones based on consequence and threat
    • Define which communications are allowed between zones, and under what controls
    • Support lifecycle management, change control, and documentation for OT networks

    For example, a plant may define separate zones for field I/O, basic control, safety systems, MES integration, and corporate IT, with conduits handling specific flows such as production reporting from control to MES or remote maintenance from vendor networks into a dedicated support zone.

    Common confusion

    • Zones vs. VLANs or subnets: A security zone is a logical and risk-based construct. It may map to one or more VLANs or subnets, but they are not synonymous.
    • Conduits vs. single devices: A conduit is the secured path and its configuration, not just the firewall or router. Multiple devices and rules can participate in a single conduit.
    • Perimeter-only thinking: Zones and conduits apply inside the plant network as well as at the enterprise perimeter. They are not limited to a DMZ or a single “OT boundary”.

    Link to risk methodologies

    In risk assessment approaches aligned with IEC 62443, security zones and conduits are used as the reference objects for identifying threats, evaluating consequences, and selecting controls. Existing corporate or enterprise IT risk methodologies often need to be extended to incorporate zone/conduit modeling for OT and industrial control systems.

  • SL-T

    SL-T is the abbreviation for Target Security Level in the IEC 62443 series of industrial cybersecurity standards. It represents the risk-based security objective that a given zone or conduit in an industrial control system (ICS) or operational technology (OT) environment is expected to achieve.

    What SL-T represents

    Within IEC 62443, SL-T is used to describe the desired or required security level for a group of assets (a zone) or communication paths (a conduit), based on threat scenarios and risk analysis. It is:

    • A target state, not a description of what is currently implemented
    • Defined per security requirement and often per foundational requirement (such as access control, use control, system integrity)
    • Used as a design and planning benchmark for architecture, controls, and procedures

    In regulated manufacturing environments, SL-T values are typically assigned during cybersecurity risk assessments or OT security design activities. They help determine what technical and procedural safeguards should be in place for production lines, utilities systems, quality systems, and related infrastructure.

    How SL-T is used operationally

    Operationally, SL-T commonly appears in:

    • Zone and conduit design: Assigning an SL-T helps specify how strictly networks should be segmented, what access controls are needed, and what monitoring should be in place.
    • System and component selection: SL-T provides a target that components, systems, and compensating controls must collectively satisfy.
    • Risk documentation: When actual capabilities do not meet the SL-T, the gap is documented and managed through architecture, additional controls, or formal risk acceptance.

    Relation to SL-C

    SL-T is often discussed together with SL-C (Capability Security Level):

    • SL-T: The required or target security level based on risk for a zone or conduit.
    • SL-C: The security capability that a particular component, product, or system can technically provide.

    In brownfield plants, the SL-T for a zone or conduit may be higher than the SL-C of installed equipment. In such cases, organizations typically use network architecture, procedures, and other compensating controls to help align the overall system to the SL-T, and document any residual risk.

    Common confusion

    • SL-T vs SL-C: SL-T is a risk-based target for a zone or conduit; SL-C is the technical capability of a component or system. They describe different aspects and are not interchangeable.
    • SL-T vs current security posture: SL-T is not a direct measure of what is currently implemented. It is a design and risk management objective that the current posture is measured against.

    Context: IEC 62443

    IEC 62443 uses security levels, including SL-T, as a structured way to describe cybersecurity requirements for industrial automation and control systems. In manufacturing, this supports consistent discussion of security expectations across OT, IT, engineering, and quality functions without implying specific certification or audit outcomes.

  • Security Level (SL)

    Security Level (SL) commonly refers to a defined, measurable degree of cybersecurity protection required or achieved by a system, device, network zone, or process. In industrial and manufacturing environments, it is usually expressed as an ordinal scale (for example SL0 to SL4) that describes how resistant an asset or zone is to specific types of cyber threats.

    Core meaning in industrial and OT environments

    In operational technology (OT) and industrial control system contexts, a Security Level is typically used to describe:

    • The strength of technical and procedural protections applied to an asset or zone
    • The type of attacker or threat the protections are intended to withstand (for example casual misuse vs. highly skilled, well-resourced attackers)
    • A target or achieved state used in risk assessments, security design, and validation activities

    Standards and guidance documents often define Security Level scales with descriptions such as:

    • SL0: No specific security requirements beyond basic functionality
    • SL1: Protection against casual or coincidental violation
    • SL2: Protection against intentional violation using simple means
    • SL3: Protection against intentional violation using sophisticated means
    • SL4: Protection against intentional violation using sophisticated means and resources

    The exact wording varies by standard, but the intent is to have a consistent way to express how robust a system’s security controls are expected to be.

    How Security Levels are used operationally

    In manufacturing and other regulated operations, Security Levels may be used to:

    • Classify network zones or conduits, such as separating office IT, MES, and safety-critical control networks and assigning each an SL target.
    • Specify security requirements for systems like PLCs, HMIs, data historians, MES, and ERP interfaces (for example “the control network must achieve SL2”).
    • Guide design and selection of controls, including authentication, authorization, encryption, logging, and physical protections needed to reach the target SL.
    • Support risk assessments, by linking threat scenarios and consequence assessments to an appropriate SL target.
    • Provide a basis for verification, where tests, reviews, or assessments check whether implemented controls are consistent with the stated Security Level.

    Security Levels can apply to individual components (for example a firewall or controller) or to a system or zone as a whole. In practice, many organizations use SLs at the zone/conduit level for clarity.

    Relationship to standards

    Several industrial cybersecurity standards and frameworks use the concept of Security Levels or very similar graded scales. While names and exact definitions differ, they share the idea of mapping:
    threat capability → required protection strength → assigned Security Level.

    Examples include standards focused on industrial automation, control systems, and their integration with higher-level systems such as MES, historians, and enterprise IT. These standards typically define:

    • Target SLs for different use cases or risk scenarios
    • Capabilities or requirements associated with each SL for controls like identification, authentication, use control, system integrity, and data confidentiality

    Organizations then map their system architecture (field devices, controllers, OT networks, DMZs, MES, cloud connectors) to those target Security Levels as part of a structured cybersecurity program.

    What Security Level (SL) does and does not include

    Typically includes:

    • An ordinal scale (for example 0 to 4) describing strength of cybersecurity protections
    • Assumptions about the skills, motivation, and resources of potential attackers
    • A set of control expectations linked to each level

    Typically does not include:

    • A guarantee of safety or compliance outcomes
    • A direct measurement of residual risk or likelihood of incident
    • A detailed implementation design for specific products or vendors

    Common confusion

    • Security Level vs. Safety Integrity Level (SIL): SIL is used in functional safety to describe the reliability required of safety functions. Security Level is used for cybersecurity protection strength. They address different risk dimensions, even though both use tiered levels.
    • Security Level vs. network classification labels: Labels such as “trusted”, “untrusted”, “DMZ”, or corporate sensitivity labels are descriptive categories. A Security Level is usually a more formal, standards-aligned scale tied to threat capabilities and defined control sets.
    • Security Level vs. maturity level: Security Levels describe the strength of protections for a system or zone, while security maturity models assess how developed an organization’s overall security processes and governance are.

    Context in manufacturing and regulated operations

    In regulated manufacturing environments, Security Levels are often referenced when defining security requirements for systems that handle production control, batch records, quality data, traceability, and other critical information flows. Assigning and documenting SL targets can help align engineering, IT, OT, and quality teams when designing architectures, selecting controls, and planning assessments for MES, SCADA, and plant-floor networks.

  • SL-C (Capability Security Level)

    SL-C, or Capability Security Level, is a measure used in industrial and operational technology (OT) cybersecurity to describe the maximum security level that a product, system, or component is designed, engineered, and validated to support. It expresses the capability of the technology itself, independent of how it is actually deployed or configured at a specific site.

    What SL-C includes

    SL-C commonly refers to:

    • The highest security level the product or system can support, based on its design and verified features (for example, authentication, access control, logging, secure communication).
    • The result of a structured assessment of security capabilities, often aligned with industrial cybersecurity standards such as ISA/IEC 62443.
    • A basis for selecting and specifying devices, applications, or systems that are suitable for environments requiring a given security level.

    In manufacturing and other industrial environments, SL-C is typically assigned to items such as PLCs, DCS components, field devices, HMIs, engineering workstations, or OT network devices. It helps integrators and site engineers understand what level of threat the product is intended to withstand when correctly applied and configured.

    What SL-C does not represent

    • It does not represent the actual security level achieved at a specific site or in a specific installation.
    • It is not a guarantee of cybersecurity performance under all conditions.
    • It is not a formal certification result unless explicitly tied to a recognized assessment program.

    The actual security posture of a plant or system depends on how products with a given SL-C are integrated, configured, operated, and maintained, as well as on network architecture, procedures, and governance.

    Operational meaning in industrial environments

    In regulated and high-criticality manufacturing, SL-C is used in several ways:

    • Design and specification: System architects specify minimum SL-C requirements for components that will connect to safety systems, MES, historians, or ERP interfaces.
    • Procurement: Vendor documentation for OT devices and software may state SL-C to support risk assessment and vendor comparison.
    • Risk analysis and zoning: When defining security zones and conduits, engineering teams consider the SL-C of equipment to determine where it can be placed and what compensating controls may be needed.
    • Lifecycle management: As systems are upgraded, SL-C values can inform decisions on replacement of legacy components with insufficient security capabilities.

    Relationship to other security level concepts

    Within frameworks such as ISA/IEC 62443, different security level concepts are often distinguished:

    • SL-C (Capability Security Level): The inherent, validated security capability of a product, component, or system design.
    • SL-T (Target Security Level): The security level required for a specific zone or application, based on risk assessment.
    • SL-A (Achieved or Implemented Security Level): The security level actually realized in a particular installation, given configuration, procedures, and controls.

    In practice, engineers compare SL-C of candidate products with SL-T for a zone or function, then design and verify controls so that the SL-A in operation is acceptable for the identified risks.

    Common confusion

    • SL-C vs. overall plant security: SL-C applies to a component or system capability, not to the entire plant or enterprise. A plant can have strong or weak overall security regardless of individual components’ SL-C values.
    • SL-C vs. compliance: An SL-C value does not by itself show that a system or site complies with any particular regulation, standard, or certification program.
    • SL-C vs. safety integrity level (SIL): SL-C relates to cybersecurity capability, while SIL relates to functional safety performance. They address different risks, even though both may be evaluated for the same equipment.

    Manufacturing-relevant example

    A manufacturer evaluating a new programmable controller for a regulated production line reviews vendor documentation indicating an SL-C corresponding to protection against deliberate misuse by network-aware attackers. The engineering team then verifies whether this capability is sufficient for the plant’s target security level for that cell, and designs network segmentation, access control, and monitoring accordingly.

  • virtualization

    Virtualization is the abstraction of physical computing resources into logical instances so that multiple isolated workloads can run on the same underlying hardware. It is commonly implemented through a hypervisor that creates and manages virtual machines (VMs), each with its own operating system and applications, sharing CPU, memory, storage, and network interfaces.

    Key characteristics

    In industrial and manufacturing environments, virtualization commonly refers to:

    • Server virtualization: Running multiple virtual servers (for MES, historians, batch systems, engineering workstations, or domain controllers) on a single physical host or host cluster.
    • Desktop or application virtualization: Providing operator stations, engineering clients, or specialized tools as virtual desktops or remote applications instead of dedicated PCs.
    • Network and security virtualization: Using virtual firewalls, routers, and network segments to separate OT and IT traffic or isolate zones and conduits defined by security standards.
    • Storage virtualization: Presenting pooled or abstracted storage resources to hosts as logical disks or volumes.

    Virtualization does not change the logical functions of applications or operating systems; it changes how and where they are hosted and how resources are allocated and isolated.

    Operational meaning in regulated and industrial environments

    In regulated or security-sensitive manufacturing environments, virtualization is used to:

    • Host OT and IT workloads with defined separation and controlled resource sharing.
    • Segment systems into different security zones by running separate virtual machines, each mapped to specific network segments and security policies.
    • Support lifecycle management tasks such as snapshots, backups, test environments, and disaster recovery scenarios.
    • Maintain legacy operating systems or applications on modern hardware by encapsulating them inside VMs.

    From an operational perspective, virtualization introduces additional layers to document and manage: the physical host infrastructure, the hypervisor, and each virtual machine or virtual network component. In regulated environments, changes, configurations, and access controls at each layer typically need clear governance and traceability.

    Relation to security zoning (e.g., IEC 62443)

    When applying security zoning concepts, such as those in IEC 62443, virtualization allows a single physical device to host multiple logical entities (for example, several virtual machines or virtual network interfaces) that belong to different zones. Each virtual instance can be assigned:

    • Its own security policies and firewall rules.
    • Separate network interfaces or VLANs mapped to defined conduits.
    • Distinct user and role configurations aligned with zone-specific requirements.

    This approach requires careful architectural design, clear documentation of which virtual components belong to which zones, and strong enforcement of isolation at the hypervisor and network levels to avoid ambiguous trust boundaries.

    Common confusion

    • Virtualization vs. containerization: Virtualization typically provides full virtual machines with their own operating systems. Containerization shares a single OS kernel and isolates applications at the process level. Both can appear similar from an application perspective, but they have different isolation and management models.
    • Virtualization vs. cloud computing: Cloud services are often built on virtualization, but virtualization itself is the underlying technology for abstracting hardware. It can be used on-premises without any public cloud components.
    • Virtual machines vs. physical segmentation: Virtual separation on a single host is not the same as physically distinct hardware. Security or availability requirements may still call for physical separation even when virtualization is used.