Connect981 – Content Dev

RSC Cluster: IEC 62443 Industrial Cybersecurity for Manufacturing and OT

  • industrial automation and control systems

    Industrial automation and control systems (IACS) are the combined hardware, software, networks, and related infrastructure used to monitor, control, and automate industrial processes and equipment. They are central to operational technology (OT) environments in manufacturing, energy, utilities, and other industrial sectors.

    IACS typically include sensors, actuators, controllers, human-machine interfaces, engineering workstations, and the communication networks that connect them. They may operate as stand-alone systems or be integrated with higher-level systems such as MES, SCADA, ERP, and quality management systems.

    Typical components of IACS

    While specific architectures vary, industrial automation and control systems commonly include:

    • Field devices such as sensors, transmitters, drives, and actuators that measure process conditions and execute control actions.
    • Controllers such as PLCs, DCS controllers, and RTUs that execute control logic and sequencing.
    • Supervisory systems such as SCADA, HMI, and historian servers that visualize, log, and coordinate process data and alarms.
    • Engineering and maintenance workstations used to configure control logic, update firmware, and manage system configuration.
    • Industrial networks and communication protocols that connect devices, controllers, and supervisory systems.
    • Supporting infrastructure including time synchronization, authentication services, and sometimes interfaces to IT systems.

    Use in manufacturing and regulated environments

    In manufacturing plants and other regulated operations, IACS are used to control production lines, utilities, and supporting processes. They influence product quality, equipment performance, data integrity, and worker safety. Example uses include:

    • Automated control of mixing, filling, packaging, and assembly operations.
    • Monitoring of critical parameters such as temperature, pressure, and flow.
    • Interlocks, safety functions, and shutdown logic at the control level.
    • Data collection for batch records, traceability, and audit trails when integrated with MES or quality systems.

    Because IACS directly affect physical processes, changes to configuration, software, or topology are often subject to formal change control, validation, and documented testing, especially in regulated industries.

    Relationship to cybersecurity and IEC 62443

    Industrial automation and control systems are a primary focus of industrial cybersecurity standards such as IEC 62443. In that context, IACS are treated as cyber-physical systems that require:

    • Identification and segmentation of control system assets and zones.
    • Defined roles and responsibilities for asset owners, integrators, and product suppliers.
    • Controls for secure development, configuration, operation, and maintenance over the system lifecycle.

    Cybersecurity for IACS considers not only confidentiality and integrity of data, but also availability and correct, timely control of the physical process.

    Scope and boundaries

    The term industrial automation and control systems commonly includes:

    • Process control systems (PCS) and distributed control systems (DCS).
    • Programmable logic controllers (PLCs) and their associated networks.
    • Supervisory control and data acquisition (SCADA) systems.
    • Building automation or utility control systems when they are part of industrial operations.

    It typically excludes general office IT systems (email, office productivity tools), business-only applications (CRM, HR), and consumer automation devices, even when they share similar technologies.

    Common confusion

    • IACS vs IT systems: IACS are focused on controlling physical processes in real time; IT systems are focused on information processing, storage, and business workflows. In many plants, the two are interconnected but governed differently.
    • IACS vs SCADA/PLC: SCADA or PLCs are specific system types or components. IACS is a broader term that covers the full set of industrial control equipment, software, and networks.
    • IACS vs OT: OT (operational technology) is a broad category of technologies that monitor or control physical devices and processes. IACS are a major subset of OT, focused specifically on automation and control.

  • PLCs

    Core meaning

    PLCs (programmable logic controllers) are industrial digital computers designed for reliable control, sequencing, and monitoring of machinery and processes, typically in manufacturing and other industrial environments.

    They execute control logic in real time, reading inputs (for example sensors and switches) and driving outputs (for example valves, motors, relays) according to a user-defined program.

    Typical characteristics

    Common characteristics of PLCs in industrial operations include:

    – **Industrial hardening**: Designed to operate in harsh conditions (temperature, vibration, electrical noise) typical of shop floors.
    – **Deterministic control**: Run cyclic scan-based programs to provide predictable control behavior.
    – **Specialized I/O**: Support for discrete and analog inputs/outputs, and often motion, safety, or high-speed counters.
    – **Programming model**: Typically programmed using IEC 61131-3 languages such as ladder diagram (LD), function block diagram (FBD), structured text (ST), instruction list (IL), or sequential function chart (SFC).
    – **Real-time communication**: Connect to higher-level systems (SCADA, DCS, MES, historians) via industrial networks (for example EtherNet/IP, PROFINET, Modbus/TCP).

    Role in manufacturing systems

    In manufacturing and regulated environments, PLCs commonly:

    – Control production equipment such as filling lines, packaging machines, reactors, and conveyors.
    – Enforce basic **interlocks and safety-related logic** (often in conjunction with dedicated safety PLCs or relays).
    – Provide **process and event data** (states, counts, alarms, setpoints, process values) to OT and IT systems.
    – Support **recipe and parameter management** when integrated with MES or SCADA.
    – Participate in **batch and continuous control** under a supervisory system or as standalone controllers.

    PLCs typically operate at or near the ISA-95 level 1–2 layers (sensing, manipulation, and area control), feeding data to level 3 systems such as MES.

    Boundaries and exclusions

    In this site context, “PLCs” generally **includes**:

    – Classic rack-based controllers and compact/micro PLCs.
    – Safety-rated PLCs used for functional safety, when clearly identified as such.
    – PLC-like programmable automation controllers (PACs) when they are used for discrete and process control in similar ways.

    It generally **excludes**:

    – Simple, fixed-function logic modules or relay logic that cannot be user-programmed.
    – General-purpose industrial PCs that do not implement deterministic control logic in a PLC-like runtime.
    – High-level systems such as DCS or SCADA, which orchestrate or supervise PLCs rather than replace them.

    Common confusion and related terms

    – **PLCs vs. PACs**: Programmable automation controllers (PACs) are often more powerful, with richer data handling and networking. In many plants the term “PLC” is used informally to cover both.
    – **PLCs vs. DCS**: A DCS (distributed control system) is a higher-level, integrated control platform typically used in process industries. It may include PLCs or PLC-like controllers as field devices.
    – **PLCs vs. SCADA**: SCADA (supervisory control and data acquisition) provides visualization, alarming, and supervisory control. PLCs perform the low-level real-time control that SCADA supervises.
    – **PLCs vs. MES**: MES (manufacturing execution systems) manage production workflows, orders, and genealogy at the operations level. They consume and contextualize data coming from PLCs but do not replace them on the control layer.

    Use in predictive maintenance and analytics (site context)

    For predictive maintenance and related analytics:

    – PLCs are often the **primary source of time-series equipment data**, such as run/stop status, cycle counts, faults, and basic process values.
    – They may provide data to **historians**, **condition monitoring systems**, or **CMMS** via OPC servers or other protocols.
    – When integrated with an **MES**, PLC data can be linked to product, route, and operator information, allowing more contextualized analysis (for example, fault patterns per product or per line).

    In many architectures, predictive models do not run on the PLC itself but use data originating from PLCs, combined with MES or historian data, for analysis and anomaly detection.

  • indicator of compromise

    An indicator of compromise (IOC) is a technical artifact, pattern, or data point that suggests a system, device, or network may have been breached, misused, or otherwise affected by malicious activity. In industrial and regulated environments, IOCs are used by OT and IT security teams to detect, investigate, and respond to potential cyber incidents affecting production systems, corporate networks, and connected equipment.

    What an indicator of compromise includes

    IOCs commonly refer to observable items such as:

    • Network indicators, for example suspicious IP addresses, domains, URLs, or unusual traffic patterns involving control networks
    • Host-based indicators, such as unknown executables, malware file hashes, modified binaries, unusual services, or unexpected user accounts
    • Log or event patterns, such as repeated failed logins, abnormal protocol use on OT networks, or unexpected configuration changes
    • Email and identity indicators, such as known phishing sender addresses or abused user credentials
    • Industrial-specific signals, such as unauthorized firmware versions on PLCs, unexpected changes to recipes, or unauthorized remote access sessions to HMIs or engineering workstations

    In cyber threat intelligence, IOCs are typically considered a form of technical or tactical intelligence, because they can be directly consumed by tools such as firewalls, IDS/IPS, SIEMs, endpoint protection, and OT monitoring platforms.

    What an indicator of compromise does not include

    The term usually does not refer to:

    • Business-level impacts (for example production downtime metrics or financial loss)
    • High-level threat narratives or adversary motivations, which are more strategic intelligence
    • Vulnerabilities themselves (such as unpatched software) unless there is evidence they are being actively exploited

    Operational use in manufacturing and OT

    In industrial and regulated environments, IOCs are often:

    • Ingested into monitoring systems to alert on known bad IPs, domains, or file hashes relevant to OT and IT assets
    • Correlated with plant logs (for example historian, MES, or engineering station logs) to identify possible compromise of production equipment
    • Used during incident response to scope which lines, sites, or systems may be affected
    • Maintained in allow/deny or watch lists that are periodically reviewed and updated as threats change

    Common confusion

    Indicator of compromise vs. indicator of attack (IOA): An indicator of compromise usually reflects evidence that a compromise may have already occurred (for example a known malware hash found on a system). An indicator of attack focuses more on behaviors and sequences of actions that suggest an attack is in progress, even before a clear compromise artifact exists. Many operational security programs use both IOCs and IOAs together.

    Relation to cyber threat intelligence (CTI)

    Within cyber threat intelligence, IOCs are one of the main outputs of tactical and technical CTI. They translate higher-level knowledge about adversaries and campaigns into concrete, machine-readable items that OT and IT teams can deploy in sensors, gateways, and monitoring tools across industrial environments.

  • What is the difference between SL-T and SL-C in IEC 62443?

    In IEC 62443, SL-T and SL-C represent different but related concepts in how you plan and implement cybersecurity for industrial control systems.

    Core difference

    • SL-T (Target Security Level): The security level you need for a specific zone or conduit based on risk assessment and overall system requirements.
    • SL-C (Capability Security Level): The security level a specific component or product is technically able to support, as demonstrated by design, testing, and (where applicable) certification.

    In practice: SL-T is defined top-down from risk and system context; SL-C is defined bottom-up from what equipment, software, and systems can actually do.

    Where they come from in the IEC 62443 series

    • SL-T is set during system and risk engineering activities (e.g., IEC 62443-3-2 and -3-3) when you define zones, conduits, and required protections.
    • SL-C is established in the product and component context (e.g., IEC 62443-4-1 and -4-2), focusing on individual devices, applications, or systems and what they can demonstrably support.

    How SL-T is determined

    SL-T is driven by:

    • Risk assessment for safety, quality, production continuity, IP protection, and regulatory exposure.
    • Zone and conduit definition: which assets are grouped and how they communicate.
    • Threat environment: expected adversary capability, motivation, and potential impact.
    • Organizational policies and industry norms (for example, typical expectations for safety-critical or GxP-related systems).

    SL-T is not a property of a device. It is a requirement placed on a zone or conduit that may consist of many devices, networks, and applications.

    How SL-C is determined

    SL-C is typically established by:

    • Vendor design and documentation for a controller, PLC, gateway, MES, DCS, or network component.
    • Testing and evaluation against IEC 62443-4-2 (for components) or related parts of the standard.
    • Sometimes third-party evaluations or certificates that show capability up to a particular security level for specific requirement families.

    SL-C is a technical capability. It does not guarantee that a deployed system actually achieves that level in your plant. That depends on configuration, integration, and operational discipline.

    How SL-T and SL-C interact in real projects

    In a realistic industrial deployment, you will see these patterns:

    • SL-C >= SL-T: Components can meet or exceed the required target. You may still need correct configuration, hardening, and procedures to actually reach SL-T.
    • SL-C < SL-T: The component is not capable of meeting the target on its own. This is common in legacy or vendor-locked systems.

    When SL-C is lower than SL-T, you usually have to:

    • Add compensating controls (for example, firewalls, one-way gateways, network segmentation, enhanced monitoring).
    • Adjust zone boundaries so that lower capability components are isolated and protected by higher capability infrastructure.
    • Apply procedural and administrative controls where technical controls are not feasible.
    • Document residual risk acceptance when you cannot practically close the gap, especially in highly regulated environments.

    Brownfield and regulated environment realities

    In brownfield plants with long-lived assets, it is normal for existing controllers, HMIs, or legacy MES to have SL-C values that lag the SL-T you would choose on a clean sheet. Full replacement to close the gap is often not viable due to:

    • Validation and qualification burden for safety, quality, and regulatory approval.
    • Downtime constraints and production risk when replacing core control or execution systems.
    • Integration complexity with MES, ERP, historians, QMS, and vendor-specific tools.
    • Traceability and change control requirements that slow major platform changes.

    As a result, many programs focus on:

    • Using SL-T to prioritize zones and conduits where higher security is most critical.
    • Mapping current assets to their SL-C and identifying gaps by requirement family (e.g., identification & authentication, use control, data integrity).
    • Designing architectural and procedural compensating controls rather than trying to immediately replace non-compliant components.
    • Maintaining traceable documentation of SL-T, SL-C, compensating controls, and residual risks for internal governance and external audits, without implying that this guarantees compliance outcomes.

    How to use SL-T and SL-C in your program

    For a typical industrial or manufacturing organization, a practical workflow is:

    1. Define zones and conduits and perform risk assessment to establish SL-T for each.
    2. Inventory components and determine SL-C per component or per group of similar components, using available vendor information and internal testing where needed.
    3. Compare SL-T vs SL-C for each zone/conduit and requirement family to identify gaps.
    4. Plan mitigations: architecture changes, network controls, system hardening, and procedures to help the overall zone reach its SL-T, even if individual components have limited SL-C.
    5. Implement under change control and document assumptions, dependencies, and known limitations as part of your cybersecurity management and quality systems.

    IEC 62443 is structured so that SL-T drives what you need, and SL-C describes what you have. Effective programs manage the gap deliberately instead of assuming they will match by default.

  • What is the difference between IEC and ISA?

    IEC and ISA are two separate standards organizations that often work on similar topics in industrial automation and control, but they differ in scope, governance, and how their standards are used in plants.

    Who they are

    IEC (International Electrotechnical Commission):

    • Global standards organization focused on electrical, electronic, and related technologies, including industrial automation.
    • Publishes international standards such as IEC 61508 (functional safety) and IEC 62443 (industrial cybersecurity).
    • National bodies (e.g., ANSI in the US, DIN in Germany, BSI in the UK) participate in IEC committees and adopt IEC standards nationally, sometimes with modifications.

    ISA (International Society of Automation, now part of ISAGCA/ISA):

    • Professional society focused on automation practitioners (engineering, operations, vendors).
    • Develops standards, technical reports, and practices such as ISA-5.1 (instrumentation symbols), ISA-18.2 (alarm management), and the original ISA-99 (cybersecurity for IACS).
    • Historically strong influence in North America and in process industries (chemicals, oil & gas, life sciences), but used globally.

    Scope and role of their standards

    IEC standards typically aim to be formal international references:

    • Used by multiple regions as a baseline for regulation, conformity assessment, and supplier specifications.
    • More likely to be referenced in regional regulations or harmonized industry guidance (for example, IEC 61511 for process safety, IEC 62443 for OT cybersecurity).
    • Often broader and more formal in structure, with defined parts and families.

    ISA standards tend to be more practitioner- and implementation-focused:

    • Often developed first as best practices emerging from operating companies, system integrators, and vendors.
    • Commonly embedded in internal engineering standards, P&ID conventions, alarm philosophy documents, and DCS/MES design specifications.
    • Sometimes become the technical input to IEC working groups, then partially harmonized.

    Example: cybersecurity and IEC 62443 vs ISA/IEC 62443

    The most visible overlap is in industrial cybersecurity:

    • ISA-99 was the original series on security for industrial automation and control systems.
    • That work was taken into IEC and harmonized, resulting in the IEC 62443 series.
    • Today, you will often see the series referenced as ISA/IEC 62443, reflecting joint development and aligned content.

    In practice, this means:

    • The technical concepts (zones & conduits, security levels, requirements for asset owners/integrators/product suppliers) are aligned between ISA and IEC versions.
    • Adoption and enforcement still vary by country, regulator, and industry. Some jurisdictions reference the IEC numbering and some internal corporate standards still reference the historic ISA designations.
    • Plants must map vendor claims, internal controls, and assessment checklists explicitly to the correct document and part number to avoid confusion in audits or customer reviews.

    How this plays out in regulated, brownfield plants

    In real facilities, you rarely “pick IEC” or “pick ISA” as a binary choice. Instead, you end up with a layered, sometimes messy coexistence:

    • Legacy plant standards may be written around older ISA documents (for example, ISA-5.1 symbols, ISA-88 for batch structures) while corporate policies or customers now reference IEC numbers.
    • Vendors and OEMs might certify or advertise alignment to IEC documents but provide engineering documentation still structured around ISA practices.
    • MES, DCS, and PLC programs may encode ISA concepts (batch phases, alarm priorities) while cybersecurity or functional safety programs are driven by IEC series.

    For regulated industries with long equipment lifecycles, replacing existing systems just to “align to IEC” is rarely feasible. Qualification and validation burdens, downtime risk, and integration complexity usually make big-bang standard migrations impractical. Instead, plants typically:

    • Perform a standards mapping exercise between the ISA-based legacy design rules and the targeted IEC framework.
    • Update governance documents (for example, cybersecurity policies, alarm philosophy, batch recipe standards) to reference both ISA and IEC identifiers where necessary.
    • Implement changes incrementally through normal change control, tying each change to specific clauses in the chosen IEC and/or ISA standards.

    Key differences in practice

    Summarizing the practical distinctions:

    • Organization type: IEC is a formal international standards body; ISA is a professional society that also develops standards.
    • Scope: IEC spans broad electrotechnical domains; ISA focuses tightly on automation, measurement, and control.
    • Adoption pattern: IEC documents are more often cited as international reference standards; ISA documents often appear first as practitioner-driven best practices and internal corporate standards.
    • Plant reality: Most regulated, brownfield plants use a combination, and the work is in mapping, reconciling, and documenting how ISA-derived practices align with the IEC frameworks referenced by regulators, customers, and corporate policies.

    The net result is that IEC and ISA are not competing “certifications” or interchangeable labels; they are distinct but partially harmonized sources of standards that must be understood, mapped, and integrated into your existing systems and change-control processes.

  • How do IEC 62443-3-3 and IEC 62443-4-2 differ?

    IEC 62443-3-3 and IEC 62443-4-2 address different layers of industrial cybersecurity in an automation and control environment. They are related, but they do not serve the same purpose.

    Core difference

    IEC 62443-3-3 defines system-level security requirements for an industrial automation and control system (IACS) as a whole. It is focused on how a system is architected, integrated, and operated to achieve a target security level.

    IEC 62443-4-2 defines technical security requirements for individual components of that system, such as PLCs, remote I/O, HMIs, engineering workstations, gateways, or software applications.

    Scope and viewpoint

    • 62443-3-3 (System perspective)
      • Scope: An entire IACS or security zone, including networks, servers, controllers, operator stations, and interfaces with higher-level systems (MES, ERP, historians).
      • Viewpoint: What security capabilities the overall system must provide to reach a given security level (SL 1–4).
      • Concerned with: Zoning and conduits, access control policies, system hardening, secure communications between zones, monitoring, and how components are combined and configured.
    • 62443-4-2 (Component perspective)
      • Scope: Products and components that may be used within an IACS, such as embedded devices, network components, host devices, and software applications.
      • Viewpoint: What security functions a single component must implement to support a target security level when integrated into a system.
      • Concerned with: Secure boot, user authentication and authorization on the device, logging, secure protocols, cryptography support, and secure update mechanisms.

    Who typically uses each part

    • 62443-3-3 users
      • System integrators and OT/IT architecture teams designing or upgrading control systems.
      • Operations and engineering leadership defining target security levels for plants or zones.
      • Security and risk teams assessing whether the deployed system meets defined security objectives.
    • 62443-4-2 users
      • Product vendors designing PLCs, drives, gateways, and control software.
      • Procurement and engineering teams specifying minimum security capabilities for new equipment and software.
      • Validation and qualification teams confirming that procured components meet declared security requirements before deployment.

    Relationship between 3-3 and 4-2

    The two standards are intended to be complementary:

    • 3-3 sets the system-level target: You determine required security levels for different zones and conduits (for example, SL 2 for packaging lines, SL 3 for sterile filling, SL 1 for utilities).
    • 4-2 supports that target at component level: You select or specify components whose capabilities, when configured correctly, enable the system to achieve those security levels.

    3-3 does not assume that every component in the system individually meets all higher security levels. Instead, security can be achieved by a combination of component capabilities, network design, and compensating controls. 4-2 helps ensure that components you buy or build can support the controls you intend to implement.

    Content differences

    • IEC 62443-3-3
      • Organizes requirements into system-level foundational requirements such as identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability.
      • Applies security levels to zones and conduits and looks at how the system behaves as a whole under attack scenarios.
      • Focuses on architecture, segmentation, secure configuration, and operational controls (monitoring, backup, recovery, etc.).
    • IEC 62443-4-2
      • Maps similar foundational requirements to specific technical functions at the component level (for example, support for unique user IDs, secure time synchronization, cryptographic services).
      • Distinguishes between different types of components (embedded devices, host devices, network devices, software applications) with tailored requirements.
      • Focuses on what must be built into the product so that, when integrated and configured, it can participate in a compliant system.

    Implications for brownfield, regulated environments

    In long-lifecycle, regulated manufacturing environments, the distinction matters in practice:

    • Full system replacement to “meet 3-3” is rarely feasible due to validation burden, downtime limits, and integration complexity. 3-3 is more useful as a roadmap for incremental improvements in zones and conduits.
    • Existing components may not fully satisfy 4-2. You may need compensating controls (for example, external firewalls, jump hosts, monitoring) and documented risk acceptance, especially for legacy PLCs and HMIs that cannot be upgraded without requalification.
    • Vendor claims need verification. A component “designed according to 4-2” does not, by itself, make a system compliant with 3-3. Actual benefit depends on integration quality, configuration, and your operational processes.
    • Change control and validation dominate timelines. Even if 4-2-capable components are available, deploying them into GMP, aerospace, or other regulated lines usually requires documented impact assessment, qualification/validation, and traceable configuration management.

    How to use them together in planning

    • Use 62443-3-3 to:
      • Define target security levels for each zone and conduit in your plants.
      • Identify architectural gaps (for example, flat networks, shared accounts, missing event monitoring).
      • Prioritize projects that can be executed within realistic downtime and validation constraints.
    • Use 62443-4-2 to:
      • Write security requirements for new equipment and control software in specifications and RFQs.
      • Evaluate vendor offerings against concrete, testable security capabilities.
      • Guide internal product development if you build custom control applications or appliances.

    Neither part guarantees compliance, safe operation, or any particular audit outcome. They provide structured requirements that must be interpreted in the context of your specific systems, constraints, and regulatory obligations, then implemented and maintained under robust change control.

  • Do we need formal IEC 62443 certification for our industrial products?

    In most cases, you are not legally required to obtain formal IEC 62443 certification for industrial products. IEC 62443 is a voluntary standard. However, it is increasingly used as a de facto benchmark for cybersecurity in industrial control systems, so the real question is whether your customers, contracts, or sector effectively require it.

    When IEC 62443 certification is typically optional

    Formal third-party certification is usually optional when:

    • No contracts, RFQs, or framework agreements explicitly mandate IEC 62443 certification or equivalent.
    • You sell into mixed or legacy plants where customers focus more on general security controls than on named standards.
    • Your products are components inside a larger automation stack, and the system integrator owns most of the cybersecurity responsibility.

    In these cases, aligning your design and processes with IEC 62443 requirements (e.g., secure development lifecycle, access control, network segmentation, vulnerability management) is often more important than holding a certificate.

    When certification may be expected or strongly incentivized

    Formal IEC 62443 certification becomes more relevant when:

    • Customer contracts require it: Some large operators (oil & gas, chemicals, critical infrastructure, high-end pharma) now specify IEC 62443-4-2 or IEC 62443-3-3 certification in procurement or supplier security requirements.
    • Market access depends on it: Certain programs, sector schemes, or government buyers may treat certification as a prerequisite for being on an approved vendor list.
    • You provide core control/SCADA products: PLCs, DCS, safety systems, or SCADA platforms that sit at the center of an industrial network are more likely to be scrutinized against IEC 62443.
    • You want a standardized external assessment: Certification can provide a structured third-party review instead of ad hoc customer audits for every large account.

    Even in these cases, what is required is usually demonstrable conformity to IEC 62443. Formal certification is one way to prove this, but not the only way. Always read the exact contract wording.

    What you must have regardless of certification

    Whether or not you pursue formal IEC 62443 certification, most industrial and regulated customers will expect you to be able to show:

    • Risk-based security design: Clear threat and risk assessments for your products in realistic deployment scenarios.
    • Secure development and maintenance: Documented secure SDLC practices, code review, vulnerability scanning, and patch/update processes.
    • Configuration and hardening guidance: Installation and operations documentation that explains secure configuration, network zones, and recommended access controls.
    • Vulnerability management: A structured process to receive, assess, remediate, and communicate vulnerabilities (e.g., product security incident response).
    • Traceability and change control: Versioned firmware/software, documented changes, and a way for customers to tie specific builds to security claims.

    These elements are core to IEC 62443 and will be scrutinized during supplier assessments regardless of whether you hold a certificate.

    Tradeoffs in pursuing formal IEC 62443 certification

    Pursuing certification is a business and risk decision, not a default requirement. Typical tradeoffs include:

    • Cost: Third-party audits, test labs, documentation preparation, and internal time can be substantial, especially for diverse product lines.
    • Scope and coverage: Certifying one product family or one system configuration does not automatically cover variants, integrations, or legacy releases.
    • Lifecycle impact: Maintaining certification as you patch vulnerabilities, add features, or modify architectures requires ongoing alignment between engineering change control and the certifying body.
    • Brownfield compatibility: Many customers have legacy networks and controls. Designing only for an idealized IEC 62443 architecture can make deployment harder in real plants, so you must balance robustness with interoperability and migration paths.

    For long-lived industrial products, the maintenance burden (recertification, regression evidence, documentation updates) often matters more than the initial certificate.

    Brownfield and regulated environment realities

    In regulated and long-lifecycle environments, customers typically operate heterogeneous stacks of legacy and modern systems. Full replacement of existing automation to achieve a textbook IEC 62443 architecture is rarely feasible due to:

    • Downtime constraints for critical manufacturing assets.
    • Validation and qualification costs for regulated processes.
    • Integration complexity across MES, ERP, QMS, and control systems.

    When you design products and security controls, you should assume your solution will need to coexist with non-compliant or partially compliant components. IEC 62443 alignment is still valuable, but you will need to provide:

    • Clear migration paths and secure-by-default settings.
    • Configurable features to integrate with older protocols and systems without forcing plant-wide redesigns.
    • Documentation that distinguishes between “optimal” IEC 62443 deployments and “minimal” secure configurations in constrained brownfield installations.

    How to decide for your products

    A pragmatic decision process usually includes:

    1. Review customer and regulatory drivers: Examine top customer contracts, RFQs, and sector guidance for explicit IEC 62443 references or equivalent cybersecurity requirements.
    2. Assess your current alignment: Compare your development practices, product features, and documentation with relevant IEC 62443 parts (often 4-1, 4-2, and 3-3).
    3. Quantify business impact: Identify which bids or markets you might lose without certification vs. what you can credibly claim with documented conformity and internal assessments.
    4. Pilot a focused scope: If you proceed, start with a high-impact product family or a reference system configuration rather than your entire portfolio.
    5. Plan for lifecycle management: Integrate IEC 62443 requirements into your change control, release planning, regression testing, and documentation processes.

    This approach lets you gain the benefits of IEC 62443 (clear structure, shared language with customers, repeatable security practices) without assuming that formal certification is universally mandatory.

    Bottom line

    You usually do not need formal IEC 62443 certification by default. What you do need is a defensible, documented cybersecurity posture that aligns with IEC 62443 principles and can withstand scrutiny from experienced, risk-aware customers. Formal certification is a targeted tool to meet specific customer or market demands, not a guarantee of compliance or security on its own.

  • Do all systems need to aim for SL 3 or SL 4?

    No. Not all systems should aim for Security Level (SL) 3 or SL 4. In most regulated industrial environments, trying to push every asset to SL 3/4 is not realistic, not necessary for risk reduction, and often not achievable for legacy equipment.

    What SL 3 and SL 4 actually imply

    In the IEC 62443 family, higher SLs imply stronger, more comprehensive security controls and tighter assurance around them. In practice:

    • SL 1: Protect against casual or coincidental violations (basic hardening).
    • SL 2: Protect against intentional misuse with basic resources and low skills.
    • SL 3: Protect against attackers with moderate resources, IACS knowledge, and skills.
    • SL 4: Protect against highly resourced, sophisticated attackers (e.g., nation-state level).

    SL 3/4 require stronger authentication, more granular authorization, deeper monitoring, stricter change control, and tighter network segmentation, as well as confidence (through testing, evidence, and sometimes certification) that controls perform as intended.

    Why “everything SL 3 or SL 4” is usually the wrong goal

    For most plants, aiming for SL 3 or SL 4 everywhere conflicts with real operational constraints:

    • Legacy controls and equipment: Many PLCs, drives, and tools cannot technically meet SL 3/4 requirements (e.g., no modern authentication, encryption, or logging). Replacing them purely for cybersecurity is rarely viable.
    • Validation and qualification burden: In regulated environments, changing control systems or adding security components (gateways, agents, monitoring) can trigger requalification, revalidation, and documentation updates.
    • Downtime and cutover risk: Upgrading to architectures that fully support SL 3/4 can require extended outages, complex migration steps, and rollback plans, which may not be acceptable for high-utilization or safety-critical assets.
    • Integration complexity: Higher SL requirements across OT/IT boundaries expose issues with MES/ERP/QMS integrations, shared accounts, legacy OPC, and flat networks that are expensive and slow to remediate.
    • Cost vs. risk reduction: The marginal risk reduction from forcing SL 3/4 for low-impact systems often does not justify the cost, especially where compensating controls can adequately reduce risk.

    How to decide what SL to target

    In practice, target security levels should be defined by risk and criticality, not by a blanket policy. A typical approach:

    1. Segment by zone and conduit
      Use IEC 62443 zoning: group assets into zones with similar function, criticality, and trust, then define conduits between them. You set target SLs at the zone/conduit level, not per individual device.
    2. Assess impact and threat
      For each zone, consider safety impact, product quality impact, regulatory exposure, and business continuity if the zone is compromised. Combine that with credible threat scenarios (e.g., ransomware spreading through remote access, insider abuse, third-party vendor connection).
    3. Map feasible controls
      Evaluate what controls are technically and operationally possible: authentication, logging, segmentation, allow-listing, system hardening, and monitoring. For legacy or vendor-locked systems, document constraints explicitly.
    4. Set a target SL that can be justified and maintained
      Choose an SL that is proportional to the risk and can be implemented, validated, and sustained over the asset lifecycle. This may mean:
    • SL 3 near safety-critical or product-critical control systems that are modern enough to support it.
    • SL 2 for supporting systems or mixed-legacy zones where SL 3 controls are not technically feasible, but where network and procedural controls still reduce risk.
    • SL 1 with strong perimeter and monitoring around truly constrained, legacy islands.

    Typical SL patterns in brownfield, regulated plants

    In most brownfield environments with long-lived equipment and heavy qualification requirements, a more realistic pattern is:

    • Core safety and critical control zones: Target SL 2+ or SL 3 where feasible, with strong segmentation from corporate IT and external networks, strict change control, and detailed logging.
    • Manufacturing applications (MES, QMS, historians): Often aim for SL 2 or “SL 2 with some SL 3 controls,” because many commercial products have partial IEC 62443 alignment but still rely on legacy protocols or shared services.
    • Legacy islands (older PLCs, test stands, CNCs): Declare constraints, then protect with compensating measures such as locked cabinets, one-way data flows, jump hosts, and restricted remote access, instead of forcing device-level SL 3.
    • Enterprise IT systems: Typically do not map directly to IEC 62443 SLs, but their security posture still influences OT risk through interfaces, credentials, and shared infrastructure.

    This zoned approach allows higher SL where it matters most, without forcing wholesale replacement of validated equipment or destabilizing running lines.

    Regulatory and audit considerations

    Regulators and auditors typically expect risk-based justification, not a particular SL number everywhere. You should be able to show:

    • How zones and conduits are defined and why.
    • How you chose target SLs for each zone, based on risk and constraints.
    • What compensating controls you use when you cannot meet a target SL at the device or application level.
    • How changes to security controls are managed under configuration/change control, with traceability.

    Stating that “everything must be SL 3/4” and then failing to achieve it in practice is usually worse, from an audit perspective, than a documented, defensible SL strategy that reflects real plant constraints.

    When to genuinely consider SL 3 or SL 4

    You should explicitly consider SL 3 or SL 4 for:

    • Safety-critical control systems where compromise could cause serious harm.
    • High-value or highly sensitive production (e.g., defense, aerospace, certain pharmaceutical operations) where disruption or data theft has strategic impact.
    • Externally connected zones with many third-party connections or remote access paths, where threat exposure is higher.
    • New builds or major greenfield expansions where designing for higher SL is easier before validation and integration debt accumulate.

    Even in these cases, reaching full SL 4 across a complex mixed-vendor stack is unusual; the focus is often on achieving a pragmatic subset of SL 3/4 controls where they reduce concrete risks.

    Key takeaway

    Not every system should target SL 3 or SL 4. In regulated, brownfield manufacturing, security levels need to be:

    • Set by risk and impact, not by aspiration.
    • Assigned at the zone/conduit level, not blindly per device.
    • Aligned with what is technically feasible and sustainable given validation, downtime, and integration constraints.

    A documented, risk-based mix of SL 1, SL 2, and selective SL 3 controls, with compensating measures for legacy systems, is usually more realistic and defensible than a blanket SL 3/4 mandate.

  • What kind of documentation do asset owners expect with IEC 62443-aligned components?

    Asset owners usually expect that any component claimed to be aligned with IEC 62443 comes with security-relevant documentation that is specific, versioned, and usable in their own risk, validation, and change-control processes. A generic marketing datasheet is not sufficient.

    1. Scope, assumptions, and intended use

    Asset owners expect clear statements on:

    • Which part(s) of IEC 62443 the component is designed to align with (for example 62443-3-3, 62443-4-1, 62443-4-2), without implying formal certification if it does not exist.
    • The intended role of the component in an industrial automation and control system (IACS), for example field device, PLC, gateway, HMI, engineering workstation, or security appliance.
    • Expected deployment context and assumptions, for example required network zoning, external protections (firewalls, DMZs), physical access control, or dependence on external monitoring.
    • Security level assumptions, for example which IEC 62443 security level (SL) the design is targeting under specified conditions, and which threats are explicitly out of scope.

    Asset owners use this information to assess fit for their own zones and conduits and to avoid overestimating the component’s security properties.

    2. Security feature and capability description

    Beyond basic functional datasheets, asset owners typically expect a security-focused description that is detailed enough to support architecture and risk assessments, including:

    • Authentication and authorization capabilities, for example account models, role-based access control, supported identity providers, password policies, and local vs centralized account handling.
    • Communication protections, for example supported protocols and versions, encryption options, certificate handling, key lengths, and any use of insecure or legacy protocols.
    • Data protection features, for example protection of security parameters, secure storage of secrets, logging of access to sensitive functions, and options for data at rest protection if present.
    • System hardening features, for example services that can be disabled, unused ports that can be closed, configurable security policies, and protections against unauthorized firmware or configuration changes.
    • Monitoring and logging, for example what events are logged, where logs can be sent, supported formats, time synchronization expectations, and log retention constraints within the component.

    This material is typically consumed by engineering, OT security, and IT security teams during design reviews and during security level allocation for zones and conduits.

    3. Secure configuration and hardening guidance

    Asset owners usually expect product-specific hardening guidance that can be incorporated into site standards and validated procedures, such as:

    • Step-by-step instructions for enabling and verifying security-relevant settings (for example user management, disabling unused services, enabling encrypted protocols).
    • Network placement recommendations that align with zone and conduit concepts, including any restrictions on direct internet connectivity, remote access models, and segmentation needs.
    • Guidance on integrating with existing identity, logging, and backup systems where applicable, with clear statements when certain integrations are not supported.
    • Default settings and their security implications, including what must be changed before use in production and what cannot be changed.
    • Example configurations or reference architectures for common use cases in industrial networks, with notes on what is illustrative rather than prescriptive.

    In regulated plants, this guidance is often used as an input to local hardening standards, standard work instructions, and validated configuration baselines.

    4. Vulnerability, patch, and lifecycle information

    Because component lifecycles in industrial environments are long, asset owners expect clarity about how security issues will be handled over time, including:

    • A documented vulnerability disclosure and response process, including how asset owners can report issues and how advisories are published.
    • Patch and update practices, for example release cadence, how security fixes are communicated, dependencies or prerequisites, and whether security fixes are ever withheld for unsupported versions.
    • Supported versions and end-of-life timelines, including how long security support is expected and what happens after end-of-support.
    • Any constraints on applying updates in running plants, for example reboot requirements, compatibility considerations, and test recommendations prior to production deployment.

    Asset owners need this to plan their own validation, change control, and maintenance windows. Lack of clarity here is often a reason components are not accepted or are isolated with additional controls.

    5. Evidence of secure development and testing (as applicable)

    For components claiming alignment with IEC 62443 secure development and technical requirements, asset owners may request evidence that can be reviewed under non-disclosure where needed, such as:

    • High-level description of the secure development lifecycle (SDL) used, mapped at least conceptually to IEC 62443-4-1 practices, without exposing proprietary details.
    • Information on security testing approaches used during development, for example static analysis, fuzzing, penetration testing, and regression testing around security functions.
    • Summaries of how third-party components and libraries are tracked and updated from a security standpoint.
    • If available, references to third-party assessments or certifications, with clear scope and limitations, and without implying that these guarantee regulatory compliance.

    In more heavily regulated or safety-critical environments, this material often feeds into supplier qualification, risk assessments, and design assurance activities.

    6. Operational and incident-handling guidance

    Asset owners also look for operational documentation that explains how to manage the component securely in a live plant:

    • Procedures for secure commissioning and decommissioning, including secure disposal or sanitization of data and credentials.
    • Backup and restore methods for configurations and data, with notes on what is and is not included in backups, and how integrity is verified.
    • Guidance on detecting and responding to suspected compromise or misconfiguration, including log locations, key indicators, and safe recovery approaches.
    • Dependencies on external services (for example NTP, DNS, certificate authorities) and the impact if they are degraded or compromised.

    This material should be explicit about operational limits and failure modes so that plant procedures can realistically account for them.

    7. Versioning, traceability, and change documentation

    In regulated and audit-prone environments, asset owners rely heavily on version control and traceability. They typically expect:

    • Clear version identifiers for firmware, software, and hardware revisions, and which documentation set applies to which versions.
    • Change histories or release notes that highlight security-relevant changes, deprecated settings, and new risks introduced by updates.
    • Checksums or other mechanisms that allow verification that downloaded firmware and software have not been altered.
    • Stable document identifiers and revision histories so documents can be referenced in internal procedures, qualification records, and validation reports.

    Without this, asset owners struggle to maintain traceability between approved configurations, deployed assets, and the vendor’s stated security properties.

    8. Brownfield and coexistence considerations

    Most asset owners operate brownfield plants with mixed vendors and legacy stacks. They expect documentation to address coexistence topics such as:

    • Known interoperability constraints or incompatibilities with common industrial protocols or legacy systems.
    • Minimum supported protocol versions and operating systems, where relevant, and any security risks if older versions are used.
    • Impact of enabling security features on latency, throughput, or compatibility with existing MES, SCADA, or historian systems.
    • Guidance for incremental deployment, for example running secure and legacy modes in parallel, and limitations of such transitional configurations.

    Asset owners rarely perform wholesale replacement of existing systems because of validation burden, downtime risk, and integration complexity. Documentation that acknowledges and supports phased adoption is generally better received.

    9. Constraints and variability across sites

    The exact set of documents expected will vary by industry, regulator, and plant maturity. Some sites will request detailed evidence packages, others will focus on practical hardening guides and lifecycle information. Vendors should avoid implying that providing this documentation guarantees compliance or successful audits. Instead, documentation should be explicit about:

    • Which security properties the component can realistically support, under which conditions.
    • Where the asset owner is expected to provide compensating controls.
    • What is not addressed by the component or its documentation, especially where IEC 62443 places responsibilities on the integrator or asset owner.

    Asset owners will then integrate this material into their own risk assessments, validation activities, and operational procedures.

  • Can truly legacy PLCs ever be compliant with IEC 62443?

    In practice, a truly legacy PLC is very unlikely to be individually compliant with IEC 62443, because the standard assumes security capabilities that these devices generally do not have. However, it can still be part of an IEC 62443-aligned system if it is appropriately segmented, monitored, and controlled, and if the residual risk is explicitly assessed and accepted.

    What IEC 62443 actually applies to

    IEC 62443 is a family of standards that covers:

    • System-level requirements for industrial automation and control systems (IACS)
    • Component-level requirements for products such as PLCs, RTUs, and network devices
    • Security lifecycle and processes (for asset owners and integrators)

    When people ask whether a PLC is “compliant,” they are usually mixing two ideas:

    • Product conformance: The PLC itself implements the relevant technical security requirements for a target security level (e.g., 62443-4-2).
    • System compliance/alignment: The overall IACS architecture, including compensating controls, meets the intent of 62443-3-3 for identified zones and conduits.

    Legacy PLCs almost always fail the product conformance test if evaluated directly against 62443-4-2. But they can still exist inside a system that is engineered to meet 62443-3-3 objectives as far as reasonably practicable.

    Why legacy PLCs usually cannot be directly compliant

    Typical limitations of older PLCs include:

    • No native user authentication or only a shared password
    • No role-based access control or fine-grained authorization
    • No encryption for engineering, HMI, or SCADA traffic
    • No secure boot, firmware signing, or integrity protection
    • No event logging suitable for modern security monitoring
    • Vendor no longer providing security patches or firmware updates

    Many IEC 62443 technical requirements assume these capabilities are available. If the PLC simply cannot implement them, you cannot truthfully claim that the device by itself meets the relevant component standard.

    In regulated environments, there is also the added constraint that changing firmware or replacing hardware triggers validation, requalification, and documentation updates. This often locks in older devices for long periods, even when they are security-weak.

    What “compliance” usually looks like in brownfield plants

    For most aerospace, pharma, and other regulated plants with long-lived assets, IEC 62443 alignment is achieved at the system level, not by upgrading every PLC to a modern, certifiable platform. Common patterns include:

    • Network segmentation and zoning: Placing legacy PLCs in tightly controlled security zones with minimal and well-defined conduits.
    • Compensating controls: Using firewalls, data diodes, jump servers, VPNs, and application proxies to enforce authentication, access control, and logging around the PLC.
    • Configuration hardening: Disabling unused ports/protocols, read-only configurations where possible, and removing or locking down programming access in production.
    • Restricted engineering workflows: Strict procedures for who can connect to the PLC, from where, and under what change control, often with dual control or approvals.
    • Monitoring and detection: Network-based intrusion detection, baseline traffic profiles, and alerting for unexpected changes or communications.
    • Physical security: Locked panels, controlled access to cabinets, and managed use of removable media to compensate for weak logical security.

    Under IEC 62443, this is acceptable only if:

    • The risk is formally assessed (e.g., SL-T vs SL-A gap is documented).
    • Compensating controls are designed, justified, and validated.
    • Residual risk is explicitly accepted by the appropriate risk owner.
    • Controls and assumptions are captured in configuration, design, and change records.

    When the honest answer is simply “no”

    There are situations where even with compensating controls, the correct answer is that the legacy PLC cannot be made acceptably aligned with the intended IEC 62443 security level for its zone:

    • If the PLC is directly exposed to routable networks and cannot be adequately isolated without breaking required functionality.
    • If there is no practical way to control or authenticate programming access.
    • If the asset’s criticality (e.g., safety impact, product quality impact) demands a higher security level than compensating controls can realistically provide.

    In these cases, you may need to:

    • Lower the target security level for the zone and explicitly document the risk and rationale, or
    • Plan a controlled migration to a more secure PLC, with appropriate validation and downtime planning.

    In regulated environments, any migration usually involves:

    • Change control and impact assessment
    • Revalidation or requalification of equipment and processes
    • Retesting of critical functions and failure modes
    • Traceability updates to design, maintenance, and cybersecurity documentation

    These burdens are why many sites choose to live with legacy PLCs under strong compensating controls rather than pursue immediate replacement.

    How to approach legacy PLCs under IEC 62443

    A pragmatic approach is usually:

    1. Inventory and classify
      Identify all legacy PLCs, firmware levels, communication paths, and process criticality. Treat missing information as a risk item.
    2. Perform a threat and risk assessment
      Use IEC 62443 risk methodologies to define target security levels for zones and identify where legacy PLCs fall short.
    3. Design compensating controls
      Layer network, system, and procedural controls to address the most impactful gaps. Validate that they work and are maintainable with existing staff and tools.
    4. Document residual risk and justification
      Capture assumptions, limitations, and risk acceptance decisions in your cybersecurity, quality, and engineering documentation.
    5. Plan gradual modernization
      Where risk or obsolescence is unacceptable, plan staged replacements aligned with outages, validation cycles, and capital planning.

    Trying to “rip and replace” all legacy PLCs at once rarely succeeds in regulated, long-lifecycle environments, due to downtime constraints, integration complexity, qualification burden, and the risk of introducing new, insufficiently understood failure modes.

    Bottom line

    Truly legacy PLCs are almost never directly compliant with IEC 62443 as standalone products. In most brownfield, regulated plants, the realistic goal is to:

    • Use zoning, compensating controls, and strict procedures to bring the system into reasonable alignment with IEC 62443 expectations.
    • Be transparent about gaps, residual risks, and risk acceptance decisions.
    • Prioritize and plan replacements where the risk or obsolescence cannot be managed by architecture and process alone.

    Any claim of full IEC 62443 compliance for legacy PLCs without this level of analysis, documentation, and control is likely misleading and will not stand up to a rigorous technical or regulatory review.