Connect981 – Content Dev

RSC Cluster: IEC 62443 Industrial Cybersecurity for Manufacturing and OT

  • secure development lifecycle

    The secure development lifecycle (SDL) is a structured process for designing, building, testing, releasing, and maintaining software or firmware with security activities integrated into each phase. It commonly refers to how organizations embed security practices into product development so that vulnerabilities are identified and addressed systematically, rather than as an afterthought.

    Key characteristics

    An SDL typically includes:

    • Security requirements and threat modeling: Identifying security objectives, regulatory expectations, and likely threats early in the design phase.
    • Secure design and coding practices: Applying secure coding standards, design patterns, and architecture reviews to reduce common weaknesses.
    • Security testing: Using static and dynamic analysis, dependency checks, fuzzing, and targeted penetration testing throughout development and before release.
    • Vulnerability management: Tracking identified issues, assigning severity, and verifying that fixes are implemented and re-tested.
    • Release and maintenance controls: Applying change control, version governance, and documented build processes, including handling of security patches over the product lifecycle.
    • Security training and roles: Ensuring developers, testers, and product owners understand relevant security practices and responsibilities.

    Use in industrial and regulated environments

    In industrial operations, control system vendors, MES/ERP providers, and device manufacturers often describe their SDL as part of security documentation for plants and regulated facilities. It is used to show how security considerations are built into:

    • OT components such as PLCs, controllers, and embedded devices
    • Manufacturing software like MES, historian, and SCADA platforms
    • Interfaces and APIs connecting OT systems with IT, quality, or ERP systems

    The SDL is typically supported by documented procedures, design and test records, change control logs, and vulnerability handling workflows. These artifacts help customers assess supplier practices, but they do not in themselves guarantee compliance, safety, or fitness for a specific installation.

    Operational meaning

    From an operations or engineering perspective, a vendor or internal team with an SDL will usually be able to provide:

    • Security-related release notes and version histories for software and firmware
    • Documented processes for reporting, triaging, and fixing vulnerabilities
    • Evidence of security testing as part of product qualification
    • Structured approaches to hardening guides and configuration baselines

    For asset owners, understanding a supplier’s SDL helps with risk assessments, procurement specifications, and ongoing patch and change management in production environments.

    Common confusion

    • SDL vs. general software development lifecycle (SDLC): SDLC describes the overall process of building software. SDL is a security-focused lifecycle that may overlay or be integrated into an existing SDLC.
    • SDL vs. security certification: An SDL describes internal processes. It is not the same as a product or system certification and does not by itself prove security or regulatory compliance.

    Relation to the source context

    When vendors in industrial or regulated settings describe how they demonstrate the security level of their components, they often reference their secure development lifecycle alongside standards alignment, test reports, and third-party assessments. Customers can review evidence of the SDL as one input into their own security evaluation, validation, and change control processes.

  • Security documentation

    Security documentation is the structured set of written records that describe how an organization defines, implements, maintains, and verifies security controls for its systems, data, and operations. In industrial and manufacturing environments, it commonly covers both IT and OT assets, including production networks, MES, PLCs, SCADA, and related business systems.

    What security documentation includes

    Security documentation typically includes:

    • Policies that state high-level security expectations and responsibilities, such as acceptable use, access control, and incident response.
    • Standards and baselines that specify required configurations or control levels for systems, networks, and applications.
    • Procedures and work instructions that define step-by-step methods for implementing and operating security controls, such as user provisioning, patch deployment, or backup routines.
    • Architectures and diagrams that describe network zoning, data flows, trust boundaries, and system interfaces across IT and OT.
    • Risk and assessment records, including vulnerability assessments, threat models, and risk registers related to production systems.
    • Incident and change records that document security events, investigations, corrective actions, and security-relevant changes to systems.
    • Training and awareness records that show how personnel are informed about security expectations and procedures.
    • Access, configuration, and audit logs that provide evidence of how controls are used and monitored in daily operations.

    In regulated manufacturing, security documentation is often integrated with broader document control and quality management systems so that versions, approvals, and retention are managed consistently.

    Operational role in industrial environments

    In operations and manufacturing systems, security documentation commonly supports:

    • Design and engineering of secure OT and IT architectures for plants, lines, and equipment.
    • Commissioning and change management by defining how new equipment, MES integrations, and control system modifications are evaluated and documented from a security perspective.
    • Routine operations through documented procedures for account management, remote access, firmware and patch handling, and removable media usage on the shop floor.
    • Audit readiness by providing traceable evidence that security controls are defined, implemented, and periodically reviewed.
    • Incident handling via documented response plans, escalation paths, communication templates, and post-incident review forms.

    What security documentation is not

    Security documentation is not the security controls themselves. It does not guarantee that systems are secure or compliant, but instead describes:

    • What controls should exist and how they should work.
    • Who is responsible for implementing and operating them.
    • How activities and results are recorded and reviewed.

    It also differs from general IT or engineering documentation by focusing specifically on confidentiality, integrity, and availability concerns, as well as regulatory and contractual security requirements that affect manufacturing operations.

    Common confusion

    • Security documentation vs. cybersecurity program: The program is the overall set of activities and governance for security. Security documentation is the recorded description and evidence of that program.
    • Security documentation vs. safety documentation: Safety documentation addresses risks to people and equipment (for example, machine guarding and lockout/tagout). Security documentation addresses protection of systems and data from unauthorized access, change, or disruption, though both may reference the same assets in industrial settings.
    • Security documentation vs. system manuals: Vendor system manuals describe how to operate a product. Security documentation records how that product is configured and controlled within the organization’s specific security framework.

    Relation to compliance and audits

    In regulated or audited manufacturing environments, security documentation commonly serves as:

    • Evidence that security responsibilities, processes, and technical measures are defined and communicated.
    • Reference material for auditors and internal reviewers to understand how security is integrated with MES, ERP, and plant systems.
    • Supporting records for change control, deviation handling, and corrective or preventive actions with a security component.

    Organizations often align security documentation with recognized frameworks or standards while maintaining it under formal document control to keep records current and traceable.

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

  • OT network

    An OT network is the communication infrastructure that connects operational technology systems used to monitor and control physical processes in industrial environments. It typically links devices such as PLCs, DCS controllers, SCADA systems, HMIs, sensors, actuators, and industrial robots, and is distinct from the corporate IT network that supports business applications.

    In manufacturing, the OT network carries time-sensitive control signals, status data, and process measurements between shop-floor equipment and supervisory systems. It often uses industrial fieldbuses and real-time Ethernet protocols, and may connect through gateways to higher-level systems such as MES, historians, and edge or cloud services.

    Key characteristics of an OT network

    • Process-focused: Designed to support reliable and deterministic control of physical equipment and production processes.
    • Real-time behavior: Often requires predictable latency and high availability, especially for safety and control functions.
    • Use of industrial protocols: Commonly relies on protocols such as Modbus, PROFINET, EtherNet/IP, OPC UA, and various fieldbuses.
    • Integration with IT: Frequently segmented and connected to IT networks via firewalls, DMZs, and secure gateways to exchange data with ERP, MES, quality, and analytics systems.
    • Long-lived assets: Includes equipment with long lifecycles, meaning legacy systems and mixed generations of technology often share the same network.

    Security and regulated manufacturing context

    In regulated manufacturing environments, the OT network is a critical part of the overall cybersecurity posture. It commonly falls within the scope of information security and industrial control system security programs.

    Organizations may align OT network security with standards and frameworks, such as ISO 27001 for information security management, ISO 27002 for security controls, and industrial control system guidance. Typical practices include network segmentation, access control, monitoring of industrial protocols, and controlled connectivity between OT and IT networks.

    Operational role in manufacturing systems

    From an operational perspective, the OT network:

    • Connects field devices to controllers and supervisory systems for continuous process control.
    • Provides data to MES, batch systems, historians, and quality systems for traceability, deviation analysis, and compliance reporting.
    • Supports remote diagnostics, maintenance, and firmware updates for production equipment, subject to access controls and change management.

    Common confusion

    • OT network vs IT network: An IT network supports business applications (email, ERP, office tools, file services), while an OT network supports industrial control and automation. In modern plants they are interconnected but typically segmented for security and reliability.
    • OT network vs OT systems: The OT network is the communication layer. OT systems include the hardware and software (PLCs, SCADA, HMIs, sensors) that use that network to perform control and monitoring.

    Relation to supplier and control standards

    When assessing suppliers that provide equipment or services connected to an OT network, organizations may request evidence of how information security and control standards are applied to that environment. This can include how specific security controls and good practices are implemented to protect industrial assets, interfaces to corporate IT, and any remote access paths into the OT network.

  • Can IEC 62443 replace ISO 27001 for my organization?

    IEC 62443 and ISO 27001 solve related but different problems. For most industrial and regulated manufacturers, IEC 62443 should be viewed as complementary to ISO 27001, not a direct replacement.

    Different scopes and intents

    ISO 27001 defines requirements for an information security management system (ISMS). It is:

    In practice, this connects to industrial security evidence when teams need to turn the answer into repeatable execution habits.

    • Scope: Enterprise-wide information security (IT, cloud, business systems, some OT if you include it in scope).
    • Focus: Governance, risk assessment, policies, suppliers, asset management, incident management, continuous improvement.
    • Usage: Often referenced in contracts and by customers; commonly used as a certifiable management standard.

    IEC 62443 is a series of standards focused on industrial automation and control systems (IACS):

    • Scope: OT networks, control systems, PLCs, SCADA, DCS, safety systems, and related engineering tooling.
    • Focus: Technical and organizational security for IACS, security levels, zones and conduits, system and component requirements.
    • Usage: Applied by asset owners, integrators, and product suppliers to harden OT environments and products.

    Because the scopes only partially overlap, IEC 62443 does not fully cover what ISO 27001 expects, especially around enterprise governance, information assets beyond OT, and formal management-system requirements.

    When IEC 62443 cannot replace ISO 27001

    IEC 62443 is unlikely to be a viable replacement for ISO 27001 if any of the following are true:

    • Customers, primes, or regulators explicitly expect ISO 27001 or equivalent ISMS evidence. IEC 62443, even if well implemented, does not automatically satisfy those expectations.
    • Your scope includes corporate IT, R&D data, ERP/MES/PLM/QMS, or SaaS platforms. IEC 62443 is not designed to be a full enterprise information security framework.
    • You rely on ISO 27001 certification for market access or as a differentiator. IEC 62443 does not provide a direct, broadly recognized certification at the organization level equivalent to ISO 27001.
    • You need a single, auditable, top-down security management system. IEC 62443 provides management and technical practices for IACS, but not a full ISMS structure as defined in ISO 27001.

    In these situations, dropping ISO 27001 in favor of IEC 62443 will leave gaps in governance and may create audit and customer issues.

    Where IEC 62443 can complement or partially substitute

    IEC 62443 can strengthen or partly substitute ISO 27001 controls in OT-heavy areas if you handle scope and mapping carefully:

    • For OT risk treatment. You can use IEC 62443 requirements and security levels as the primary control framework for OT within an ISO 27001 ISMS, documented as your selected control set for that domain.
    • For technical depth in OT security. IEC 62443 gives more precise OT control expectations than Annex A of ISO/IEC 27001 and ISO/IEC 27002, especially around zones, conduits, and IACS-specific hardening.
    • For internal alignment. You can have ISO 27001 govern the overall security management system and use IEC 62443 as the normative reference for OT engineering, architecture, and operations.

    In practice, many manufacturers use ISO 27001 (or similar) to frame governance, risk, and management processes, and use IEC 62443 as the technical and process reference for OT environments.

    Brownfield and system coexistence realities

    In brownfield plants with mixed IT/OT stacks, simply “replacing” one standard with another usually fails for practical reasons:

    • Legacy MES/ERP/PLM/QMS systems. These are usually governed by enterprise security policies aligned with ISO 27001-style controls. IEC 62443 does not fully cover cloud, SaaS, access to engineering data, or office IT.
    • Long equipment lifecycles. OT assets may be 10–25 years old. Aligning them with IEC 62443 takes staged hardening, risk acceptance, and careful change control, not a one-time standard swap.
    • Integration complexity. IT/OT interfaces (e.g., MES to PLCs, historian to ERP) sit in a gray zone. You generally need both ISO 27001-type governance and IEC 62443-type architecture and controls.
    • Validation and qualification. In regulated sectors, changes to OT controls, network zones, and authentication schemes can trigger revalidation of equipment or processes. Shifting to IEC 62443 must be managed via formal change control.

    Given these constraints, the more realistic approach in brownfield, regulated environments is coexistence and mapping, not replacement.

    Risk, audit, and evidence considerations

    If you decide to emphasize IEC 62443 in your security program, you should still address the following:

    • Document scope and rationale. Be explicit about where IEC 62443 applies (e.g., plant OT networks) and where ISO 27001 or other controls govern (e.g., corporate IT, cloud platforms).
    • Maintain a control mapping. Map IEC 62443 requirements to ISO 27001 Annex A (or to your chosen control catalog) to show auditors and customers how OT risks are being managed.
    • Preserve traceability and change control. Treat adoption of IEC 62443 controls like any other controlled change: requirements, design, test, validation impact, and documented approvals.
    • Do not assume audit outcomes. Even strong IEC 62443 implementation does not guarantee favorable audit results if contractual or regulatory language points specifically to ISO 27001 or to an ISMS reference model.

    Practical answer

    IEC 62443 cannot be treated as a straightforward replacement for ISO 27001 for most organizations, especially in regulated manufacturing. It is better to:

    • Use ISO 27001 (or an equivalent ISMS approach) to govern enterprise-wide information security, and
    • Use IEC 62443 as the primary security framework for OT and industrial control systems within that broader management system.

    Only if your scope is narrowly limited to OT, and you have no external requirement or expectation tied to ISO 27001, could you consider relying primarily on IEC 62443. Even then, you should explicitly address management-system elements (policy, risk management, internal audit, continuous improvement) that IEC 62443 does not fully cover.

  • IEC 62443-3-2

    IEC 62443-3-2 is a part of the IEC 62443 series of international standards focused on cybersecurity for industrial automation and control systems (IACS). It addresses how to perform cybersecurity risk assessment for industrial systems and how to translate those results into a high-level system design and security requirements.

    The standard is intended for environments such as manufacturing plants, process facilities, utilities, and other operational technology (OT) settings where industrial control systems, SCADA, and distributed control systems are used. It provides a structured approach for analyzing cybersecurity risks to these systems and for defining appropriate security measures.

    What IEC 62443-3-2 covers

    IEC 62443-3-2 commonly includes:

    • Concepts and terminology for cybersecurity risk assessment in industrial automation and control systems
    • Methods to characterize the system, assets, and boundaries, including zones and conduits
    • Approaches for identifying threats, vulnerabilities, and potential consequences
    • Processes to estimate and evaluate cybersecurity risk for IACS
    • Guidance on defining target security levels based on risk
    • High-level requirements for system architecture and design in response to assessed risk

    In manufacturing and other industrial operations, IEC 62443-3-2 is often used to structure cybersecurity risk assessments when connecting shop-floor control systems with MES, ERP, quality systems, and remote support or cloud services. It helps align IT and OT stakeholders on how risk is defined and treated across the full system lifecycle.

    How it relates to the rest of IEC 62443

    IEC 62443-3-2 sits in the system-level part of the IEC 62443 series:

    • The series as a whole covers concepts, policies, system requirements, and component requirements for IACS cybersecurity.
    • IEC 62443-3-2 focuses on risk assessment and high-level system design.
    • Other parts in the series define more detailed technical requirements, security levels, and processes for implementation and maintenance.

    Operational meaning in industrial environments

    In practice, using IEC 62443-3-2 in industrial operations commonly involves:

    • Documenting the architecture of industrial control systems, including network segments, controllers, HMIs, historians, and interfaces to MES/ERP and cloud services
    • Classifying assets by criticality to safety, quality, production continuity, and regulatory obligations
    • Performing structured risk assessments that consider both cyber threats and process impacts (such as product quality issues, downtime, or environmental release)
    • Grouping assets into security zones and defining conduits between them
    • Defining target security levels and high-level controls that later guide detailed technical design and implementation

    The standard is often referenced in internal policies and vendor requirements when organizations align OT cybersecurity practices with recognized industrial frameworks.

    Common confusion

    • IEC 62443-3-2 vs. IEC 62443 as a whole: IEC 62443-3-2 is only one part of the broader IEC 62443 family. It does not, by itself, cover all aspects of OT cybersecurity management, detailed technical controls, or product requirements.
    • IEC 62443-3-2 vs. risk management frameworks in IT: While it addresses risk assessment, IEC 62443-3-2 is focused on industrial control systems and process impact, rather than general IT systems alone. It is usually applied alongside IT-focused frameworks, not as a replacement.

    Use in regulated and quality-critical manufacturing

    In regulated or quality-critical manufacturing settings, IEC 62443-3-2 is often used to:

    • Structure cybersecurity risk assessments that support internal governance, audits, and evidence of due diligence
    • Inform designs for secure integration of OT with MES, quality systems, data historians, and cloud analytics platforms
    • Support documentation of risk assessment methodology and outcomes in a form that is understandable to operations, engineering, and compliance teams

    The standard provides guidance on approach and structure. Actual implementation decisions, control selection, and any regulatory interpretations are typically handled within an organization’s broader risk management, engineering, and compliance processes.