IEC 62443-3-2 and 3-3: what asset owners and integrators must prove

32 min read #compliance #security #industrial #iec-62443

The OEM-side piece in this series unpacks the two standards a product supplier has to live with: IEC 62443-4-1 (how a product is built) and IEC 62443-4-2 (what the product can actually do) — for the detailed walk-through see IEC 62443-4-1 and 4-2: what an OEM must actually prove . Those are vital, but they are only half the story. Buying certified components is one thing; turning them into a functioning industrial control system that is sized correctly to the actual threats, partitioned sensibly between zones, and delivered with hard evidence that the finished plant is as secure as the design intended, is a different discipline altogether. That discipline is governed by two more parts of the same IEC 62443 family: IEC 62443-3-2 and IEC 62443-3-3.

These two standards sit one tier above 4-1 and 4-2. They live at the system layer rather than the component layer, and they answer two different but tightly coupled questions. IEC 62443-3-2 asks "how do I work out what level of security I actually need in each part of my industrial system?" IEC 62443-3-3 asks "if I have decided I need a particular level of security in a part of the system, what must that part of the system actually do to deliver it?" One produces the brief; the other defines what counts as fulfilling the brief. Together they sit between the asset owner's risk picture and the OEM's certified components, and this is also where the EU regulatory chain — NIS2 for the asset owner side, the Cyber Resilience Act for the product side — most often lands in real procurement contracts.

The aim is the same as last time. Anyone can claim "compliance with IEC 62443"; the question that matters is what they must objectively demonstrate to back the claim up. The standards are formal and structured enough that the answer is genuinely knowable — provided you know what to ask for.

You can purchase the official standards from the IEC Webstore: IEC 62443-3-2:2020 and IEC 62443-3-3:2013 .

A quick orientation in the IEC 62443 family

To see where 3-2 and 3-3 fit, it helps to remember the four-tier shape of the whole IEC 62443 series. Part 1 establishes terminology and concepts. Part 2 covers policies and procedures, principally for the asset owner and their service providers — covered separately in IEC 62443-2-x: the management system behind a secure industrial plant . Part 3 — where today's two standards live — covers the system level. Part 4 covers the individual components that get integrated into the system.

flowchart TB
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef tier fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;
    classDef focus fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:2px;
    classDef dim fill:#f4f4f4,stroke:#888,color:#444,stroke-width:1px;

    A[IEC 62443 series
Cybersecurity for IACS]:::entry

    A --> G[Part 1 — General
Concepts, terminology]:::tier
    A --> P[Part 2 — Policies & Procedures
Asset owner & service provider]:::tier
    A --> S[Part 3 — System
Asset owner & system integrator]:::tier
    A --> C[Part 4 — Component
Product supplier / OEM]:::tier

    S --> S1[62443-3-2
Security Risk Assessment
for System Design
METHODOLOGY]:::focus
    S --> S2[62443-3-3
System Security Requirements
& Security Levels
REQUIREMENTS]:::focus

    C --> C1[62443-4-1
SDL — process]:::dim
    C --> C2[62443-4-2
Component capability]:::dim

The two standards in the spotlight today are squarely in Part 3, and they are jointly the responsibility of the asset owner (the operator of the plant) and the system integrator (the engineering organisation that designs and builds the integrated system). The OEM's standards from Part 4 are relevant here because the components they supply must be able to combine into a system that meets 3-3, but the OEM is not themselves the audience for 3-2 and 3-3.

The extended building analogy

Before either standard goes under the microscope, an analogy will help — the rest of the article leans on it. Constructing an industrial control system is not unlike constructing a hospital. There are several distinct trades involved, each with their own discipline, and each must produce evidence appropriate to their role.

IEC 62443-3-2 is the architect's brief and the structural engineer's calculations. Before a single brick is laid, somebody decides what loads the building must bear, where the fire compartments belong, what kind of glazing the windows need given the local climate, whether the operating theatres need redundant electrical supplies, and how patient flows separate from staff flows. The output is a set of design decisions with risk-justified targets attached: this corridor must be a fire compartment boundary; this room must have positive pressure; this electrical feed must have a backup. These decisions are made by people qualified to make them and signed off by the building's owner. They are not yet a building — they are the brief against which the building will be constructed.

IEC 62443-3-3 is the building code. It is the rule book that says, given the type of building you are constructing and the design choices that flow from it, here are the specific things that must be true of the finished structure. Fire doors of a certain class must have rated hinges and self-closing mechanisms. Emergency exits must be of a minimum width. Operating theatres in this category of facility must have such-and-such air-change rate. The code is generic — it does not know your specific hospital — but it tells the contractor what they must achieve to satisfy the design brief.

IEC 62443-4-2 is the kitemark on each brick, fire door and circuit breaker. Each individual building component has been independently tested and rated. When the contractor specifies a fire door rated to FD60, they pick a door with a certificate to that rating.

IEC 62443-4-1 is the brick factory's quality management system. It is what gives you confidence that the certified product on site is actually the same as the product that was tested for the kitemark.

Together, the four standards form a chain in which each link has a clear owner and clear evidence requirements. The asset owner produces the brief (3-2). The contractor builds against the building code (3-3) using certified components (4-2) made by quality-controlled suppliers (4-1). The asset owner inspects, certifies and operates the finished building. Each handover is a defined artefact, and each party is accountable for a defined scope.

With the analogy in place, the two standards themselves come next.

What IEC 62443-3-2 actually is

IEC 62443-3-2:2020, formally titled "Security risk assessment for system design", is the methodology standard for the asset owner. It does not tell you what your industrial system must look like; instead, it tells you how to figure that out for yourself, in a structured and repeatable way, based on actual risk in your actual operating context.

The standard's central contribution is a workflow — usually referred to as the Zone and Conduit Requirements (ZCR) process — that takes a description of the system you intend to protect and produces, as its output, a partitioned design with Target Security Levels (SL-T) allocated to each part. That output is the formal input to the next stage: selecting and integrating components that can meet those targets, which is where IEC 62443-3-3 takes over.

The primary audience for 3-2 is the asset owner, although they will almost always engage external help. The work demands both deep process knowledge of the plant (which the asset owner has) and specialist cybersecurity expertise (which is usually contracted in, often through a system integrator or an independent risk consultant). The ultimate accountability, however, remains with the asset owner. If a system integrator runs the ZCR workshops for you, that does not transfer accountability for the resulting design to them — it transfers responsibility for the quality of the analysis, but the decisions are yours to make and to sign off.

What 3-2 is not matters as much as what it is. It is not a risk-assessment methodology in the prescriptive sense — it does not tell you whether to use a NIST SP 800-30 approach, an ISO 31000 approach, a HAZOP-derived approach or anything else. It tells you what your risk methodology must cover and what it must produce, but it leaves the choice of underlying technique to your organisation. This makes 3-2 admirably flexible across sectors — process industries can plug it into their existing HAZOP/LOPA culture, while discrete manufacturing or utilities can use methods more familiar to them — but it also means that "compliance with 3-2" requires more than picking a methodology off a shelf. It requires demonstrating that whatever methodology you chose actually does what 3-2 asks of it.

What 3-2 means practically: the seven-step workflow

The heart of IEC 62443-3-2 is a numbered workflow. Although the standard expresses it more formally, in practice it boils down to seven steps that flow from a description of "what we are protecting" through to "here is the documented design with risk-justified security levels".

flowchart TD
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef step fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;
    classDef decision fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:1px;
    classDef output fill:#ffe0b2,stroke:#e65100,color:#3d1e00,stroke-width:2px;

    Step1[Step 1
Identify the System
Under Consideration SUC]:::entry
    Step2[Step 2
Initial high-level
risk assessment]:::step
    Step3[Step 3
Partition SUC
into Zones and Conduits]:::step
    Step4{Step 4
Is initial risk below
tolerable risk?}:::decision
    Step5[Step 5
Detailed risk assessment
per zone and conduit
Determine SL-T values]:::step
    Step6[Step 6
Document Cybersecurity
Requirements Specification CRS]:::step
    Step7[Step 7
Asset owner approval
and sign-off]:::output

    Step1 --> Step2 --> Step3 --> Step4
    Step4 -->|Yes — acceptable| Step6
    Step4 -->|No — deeper analysis needed| Step5
    Step5 --> Step6
    Step6 --> Step7

The first step is to identify the System Under Consideration (SUC). This sounds trivial but rarely is. The SUC description must be specific enough that anyone reading it later — an auditor, a successor, a regulator — can understand exactly what was assessed and what was not. In practice this means a high-level architecture diagram, an inventory of the major equipment and software in the SUC, a network map, an explicit statement of the business and safety functions the SUC supports, a list of external interfaces, and a clear note of what is out of scope. An SUC scoped too narrowly leaves dangerous assumptions about the boundary; an SUC scoped too broadly produces analyses too coarse to be useful.

The second step is an initial high-level risk assessment of the SUC as a whole. This is a coarse-grained, qualitative pass that asks the simple question: if the worst-case credible cybersecurity event happened to this SUC, what would the consequences be for safety, environment, production, regulatory standing and revenue? The output is usually a single "worst-credible" risk rating and an indication of whether the SUC as a whole warrants the more granular analysis that follows. In nearly every real industrial setting it does — but having the initial assessment on file makes the case for the deeper work and provides a baseline against which residual risk can later be compared.

The third step is the central design act of 3-2: partitioning the SUC into zones and conduits. A zone is a grouping of assets that share the same security requirements — typically because they have similar function, similar consequence-of-failure, similar trust level, or similar operational environment. A conduit is the controlled communication channel between zones. Drawing the zones and conduits is what turns an undifferentiated network diagram into a security-aware architecture. To continue the building analogy, this is the moment when the architect decides "these rooms form the operating theatre suite, this corridor connects them to the recovery ward, and the swing doors at this point will be the fire compartment boundary." The decision is consequential because everything downstream — SL-T allocation, component selection, conduit protection mechanisms — flows from where you draw these lines.

The fourth step asks whether the initial risk assessed in step two, viewed through the lens of the proposed partitioning, already falls below the asset owner's tolerable risk threshold. If it does — perhaps because the SUC is small, isolated and low-consequence — the process can move directly to documentation. In most real industrial situations, however, it does not, and the workflow moves into the heart of the analysis at step five.

Step five is the detailed risk assessment, performed per zone and per conduit. This is where threats, vulnerabilities and consequences are systematically analysed for each zone and conduit using whatever risk methodology the organisation has adopted. The crucial output of this step is the Target Security Level (SL-T) for each zone and conduit. SL-T is expressed in the standard one-to-four scale used elsewhere in 62443 and, importantly, is usually expressed per Foundational Requirement — so a single zone may have an SL-T vector such as (3, 2, 3, 2, 2, 2, 2) across FR1 to FR7. Different zones will usually have different vectors. A zone containing the safety-instrumented system of a refinery, for example, will typically demand a higher SL-T for FR3 (System Integrity) than the engineering office's general-purpose IT network sitting in another zone.

Step six is documentation. The output of the whole process must be captured in a formal artefact, conventionally called the Cybersecurity Requirements Specification (CRS). The CRS records the SUC description, the zones and conduits, the SL-Ts, the assumptions made (for instance "we assume the corporate firewall blocks all inbound SMB traffic to the control network"), the constraints recognised (for instance "the legacy PLC family in use does not support multi-factor authentication, so compensating controls are applied at the conduit"), and any residual risks that have been knowingly accepted. The CRS is more than internal documentation — it is the contractual bridge between asset owner and system integrator. It is what the integrator must deliver against under 3-3.

The seventh and final step is approval by the asset owner. The standard is explicit that the asset owner is accountable: an integrator or consultant may have produced the document, but the asset owner must consciously accept its conclusions and the residual risk implied by them. In practice this usually means sign-off at a defined seniority level — often by someone in the operations or asset-management line who can be held responsible for the cybersecurity posture of the plant.

What the asset owner must objectively demonstrate for 3-2

When an asset owner claims compliance with IEC 62443-3-2, they should be able to produce, on request, the documentary record of having done the work properly. Compliance with 3-2 is not about a certificate on the wall — there is no widely used third-party certification scheme for asset-owner compliance with 3-2, in the way that ISASecure SDLA and CSA exist for OEMs. Instead, demonstration is about the evidence pack.

A credible evidence pack starts with the SUC description in enough detail that an external assessor could retrace what was assessed and what was deliberately excluded. It includes the methodology used — the explicit risk-assessment framework chosen, with its scoring rules and risk thresholds. It includes the threat sources considered, ideally referencing a current threat catalogue such as ENISA's ICS threat reports, MITRE ATT&CK for ICS, sectoral information sharing and analysis centres (such as the E-ISAC for electric utilities), or national CSIRT advisories. It includes the risk register that resulted from steps four and five, with each zone and conduit's pre-control risk and residual risk written down. It includes the zone and conduit diagram itself — typically a network-style schematic overlaid with coloured zone boundaries and labelled conduits. And it culminates in the Cybersecurity Requirements Specification, signed off at an appropriate level of the asset owner's organisation.

The standard does not prescribe how often this exercise must be repeated, but good practice is to review the CRS whenever the SUC changes materially, whenever the threat landscape shifts significantly, or on a fixed cycle of typically three to five years. Evidence of this review cadence — meeting minutes, version-controlled CRS revisions, a documented change-control process — is itself a useful demonstration of compliance.

There is a subtlety worth dwelling on. Compliance with 3-2 is not the same as having "low risk" in the resulting system. An asset owner can fully comply with 3-2 and still consciously accept a relatively high residual risk in some zones — provided that decision is documented, justified by business context, and approved by someone with authority to do so. What 3-2 demands is evidence of having reasoned about it properly, not a particular outcome. The standard is procedural in spirit, not prescriptive about results. This is sometimes uncomfortable for auditors who expect to see a "pass/fail" verdict, but it is the right design for a standard that has to serve everything from a wastewater treatment plant to a nuclear power station.

What IEC 62443-3-3 actually is

If 3-2 asks "what level of security do I need where?", then IEC 62443-3-3:2013 asks "what must a system at a given security level actually be able to do?" It is titled "System security requirements and security levels", and it is the requirements-catalogue standard for the system layer.

3-3 defines System Requirements (SRs) grouped under the same seven Foundational Requirements used elsewhere in IEC 62443 — Identification and Authentication Control, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response to Events, and Resource Availability. Each SR is a capability that an integrated industrial automation and control system must support, expressed in a way that is largely independent of any particular vendor's products. Many SRs have one or more Requirement Enhancements (REs) that apply at higher Security Levels — the same idea as in 4-2, where a basic SR is augmented at SL 3 or SL 4 with additional rigour. The standard contains in the order of fifty-plus SRs, with the total count climbing well above one hundred once REs are included; the exact tally depends on how you count.

The audience for 3-3 is principally the system integrator — the engineering organisation that takes the asset owner's CRS and turns it into a delivered integrated system. The product supplier indirectly cares about 3-3 because their components, certified to 4-2 , need to combine in such a way that the system as a whole can meet 3-3's system-level requirements. The asset owner cares because they need to be able to verify that the delivered system actually achieves what was specified.

A useful mental model is that 3-3 is to the system what 4-2 is to the component. Both standards use the same seven Foundational Requirements as their organising spine. Both express requirements in a vendor-neutral way. Both grade those requirements by Security Level 1 to 4. The difference is the level of integration at which the requirement applies. A 4-2 requirement might be "the component shall support unique user authentication". The corresponding 3-3 requirement might be "the system shall enforce unique user authentication across all of its components, including federation of identities where multiple components participate in a single user session, with audit logging of authentication events that can be correlated centrally". The component might be capable, but the integration is what makes the capability real.

What 3-3 means practically

A good way to grasp what 3-3 actually demands is to look at a few of its System Requirements through the lens of what they translate into for the engineering team building the system.

Under Foundational Requirement 1 (Identification and Authentication Control), 3-3 expects the system to provide unique account identification across all of its users and devices, to support strong authentication mechanisms appropriate to the SL, and — at higher SLs — to require multi-factor authentication for sensitive operations such as engineering changes or safety system modifications. In practical terms, this means a system at SL-T 3 cannot rely on shared logins, generic operator accounts or hard-coded device passwords; identity must be unique, traceable and cryptographically backed.

Under FR 2 (Use Control), the system must enforce role-based access, must restrict mobile-code execution, must protect audit information from tampering, and must support continuous monitoring of who did what when. This translates into a system whose engineering workstations log every parameter change to a tamper-evident audit trail, whose operator screens limit what an operator can do based on a defined role, and whose programming devices cannot run arbitrary code by accident or by a malicious USB stick.

Under FR 3 (System Integrity), the system must protect itself against unauthorised changes to firmware, configuration and data, both in motion and at rest. Communication channels between zones (the conduits identified during 3-2) must protect message integrity, and the system must support cryptographic verification of the software and firmware running on its components. At higher SLs, this expands to include continuous integrity monitoring and automated detection of unauthorised changes.

Under FR 4 (Data Confidentiality), sensitive information in transit and at rest must be protected. At lower SLs this might mean transport-layer encryption for engineering sessions; at higher SLs it includes protection of credentials in storage, encryption of stored configuration data, and protection against side-channel disclosure on shared infrastructure.

Under FR 5 (Restricted Data Flow), the system must operationally support the zones-and-conduits architecture mandated by 3-2. It must support enforcement of the conduit boundaries (typically via firewalls, unidirectional gateways or data diodes in higher-SL zones), it must prevent unauthorised lateral traffic between zones, and at higher SLs it must include mechanisms to detect and alert on violations of the conduit policy.

Under FR 6 (Timely Response to Events), the system must produce, store, protect and make available a coherent set of security-relevant events — logs that allow detection, investigation and recovery. At higher SLs, this includes integration with security information and event management (SIEM) systems, the ability to support near-real-time alerting, and forensic-quality retention of evidence.

Under FR 7 (Resource Availability), the system must be resilient to denial-of-service conditions, must support backup and restore of all critical configuration and data, and must be capable of operating safely when degraded. This is where industrial-specific concerns — graceful failure modes, deterministic behaviour, prioritised emergency operations — meet generic cybersecurity availability requirements.

A useful way to picture 3-3 as a whole is as a checklist of system capabilities, indexed by SL. At SL-T 1, the bar is "protect against casual or coincidental violation"; at SL-T 4, the bar is "protect against intentional violation using sophisticated means with extended resources, IACS-specific skills and high motivation" — broadly nation-state-class threats. The list of SRs is the same across all four SLs; what changes is the depth, rigour and resourcing of each capability. The standard is meticulous about this — for each SR, the body of the standard sets the SL 1 baseline, and the REs ratchet that up explicitly at SL 2, 3 and 4.

The most important diagram: SL-T, SL-C and SL-A

Of all the concepts in IEC 62443, the relationship between the three types of Security Level is the one most often muddled — and the one that does the most damage when misunderstood. The three are deceptively similar in their abbreviations, and procurement documents routinely conflate them. Internalising the distinction is, in my experience, the single most useful thing a buyer or operator can do when they start working with this standards family.

flowchart TB
    classDef demand fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:2px;
    classDef supply fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:2px;
    classDef reality fill:#1e8e3e,stroke:#0b3d20,color:#ffffff,stroke-width:2px;
    classDef arrow fill:#f4f4f4,stroke:#666,color:#222,stroke-width:1px;

    SL_T[SL-T
TARGET Security Level
What the zone NEEDS
From IEC 62443-3-2
Owner: Asset Owner]:::demand

    SL_C[SL-C
CAPABILITY Security Level
What the COMPONENTS can provide
From IEC 62443-4-2
Owner: Product Supplier]:::supply

    SL_A[SL-A
ACHIEVED Security Level
What is ACTUALLY delivered
once installed and configured
Owner: System Integrator
and Asset Owner operations]:::reality

    SL_T -->|drives selection of components with sufficient| SL_C
    SL_C -->|when integrated and configured produces| SL_A
    SL_A -.must be at least equal to.-> SL_T

SL-T, the Target Security Level, comes out of IEC 62443-3-2. It expresses what the asset owner has decided is needed in each zone, based on the risk assessment. It is a statement of demand. It belongs to the asset owner.

SL-C, the Capability Security Level, comes out of IEC 62443-4-2 . It expresses what a particular product is technically able to provide when properly configured. It is a statement of supply. It belongs to the product supplier.

SL-A, the Achieved Security Level, applies to the delivered system. It expresses what the integrated, installed, configured and operationalised system actually does in the live plant. It is a statement of reality. It is jointly the responsibility of the system integrator (for as-built) and the asset owner (for as-operated).

Three rules govern how these relate, and they are rules I would recommend committing to memory. First, no zone can achieve an SL-A greater than the lowest SL-C of any component sitting in that zone — your zone is only as strong as its weakest link, and a single SL-C 1 component in an otherwise SL-C 3 zone drags the achievable SL-A back to 1 for whichever FR that component is weak in. Second, an SL-A short of the SL-T means the design has not delivered against requirements; either additional compensating controls are needed (perhaps at the conduit, perhaps procedurally), the SL-T must be re-evaluated against revised risk acceptance, or the residual risk must be formally accepted by the asset owner. Third, SL-C is a capability, not a guarantee: a component certified at SL-C 3 deployed with the security features disabled contributes nothing more than SL-C 1 to the zone, and the most common way for an SL-A to fall short of an SL-T is for SL-C-capable features to be left switched off in the field.

This three-letter trio is the backbone of any defensible 62443-based design. When a vendor brochure says "SL 3 certified", the first question must be "SL-what 3?" When a procurement specification says "the system shall be SL 2", the next question must be "SL-T 2, SL-C 2 or SL-A 2?" — because each implies a different obligation on a different party. A well-written tender separates them explicitly: "the system shall be designed and delivered to achieve an SL-A of at least 2 across FR1 to FR7, using components with documented SL-C of at least 2, in support of an SL-T of 2 as determined in the attached Cybersecurity Requirements Specification." That single sentence — combining all three SLs, naming the relevant standards, and pointing back to the CRS — collapses a great deal of potential ambiguity.

What the system integrator must objectively demonstrate for 3-3

When a system integrator claims compliance with IEC 62443-3-3 for a delivered system, the asset owner should expect a coherent evidence pack that traces from the CRS produced under 3-2, through the design and procurement decisions, to the as-built system and its commissioning tests. This evidence pack is rarely a single document; it is more usually a structured collection of artefacts that, taken together, form an auditable trail.

The integrator must demonstrate traceability between every SL-T in the CRS and the System Requirements of 3-3 that have been applied in the design. For each zone, the integrator must show which SRs at the relevant SL were considered, which were implemented, which were compensated for by other means, and which were formally noted as not applicable with a written justification. This is usually captured in a requirements-traceability matrix that runs alongside the design documentation and is maintained throughout the project lifecycle. The matrix is the single document an auditor will most often ask for first.

The integrator must demonstrate the component selection rationale: that the components chosen for each zone have an SL-C at least as high as the SL-T of that zone, for every relevant Foundational Requirement. This evidence is typically drawn from the components' own 62443-4-2 certificates (ISASecure CSA, IECEE CB Scheme, or equivalent) cross-referenced to the integrator's bill of materials. Where a chosen component does not have third-party 4-2 certification, the integrator must justify the choice and show how the corresponding 3-3 SRs are met through architectural or compensating measures — perhaps by placing the component behind a higher-SL gateway, by isolating it in a sub-zone, or by applying procedural controls.

The integrator must demonstrate that the system has been verified and validated. This includes design reviews against the SRs, factory acceptance testing (FAT), site acceptance testing (SAT), and security-specific testing such as configuration audits, vulnerability scanning of the as-built system, and — where the SL-T justifies it — penetration testing of representative attack paths. Test reports must be linked back, via the traceability matrix, to the SRs they verify. A pen-test that produces a hundred-page report which cannot be tied to the requirements it tested is much less useful than a tightly-scoped engagement targeting the SRs that matter.

The integrator must demonstrate that the delivered system is handed over with the documentation needed for the asset owner to operate it securely. This means hardening guides, security configuration baselines, account inventories, log and SIEM integration documentation, backup and restore procedures, incident response runbooks tailored to the specific system, and a security operations manual that explains how each Foundational Requirement is monitored and maintained in service. The handover documentation is where SL-A becomes sustainable rather than a one-day snapshot at the end of commissioning.

The third-party certification route for systems is ISASecure SSA (System Security Assurance), which certifies a specific system implementation against IEC 62443-3-3. Like CSA for components, SSA carries the prerequisite that the supplier has an underlying SDLA-certified process for any components they produce in-house. SSA is materially less common than CSA in part because every system installation is bespoke, but it is the closest thing to a "kitemark" for integrated systems in the 62443 world, and worth asking for when the system in question is one of a vendor's standard product offerings (a packaged SCADA solution, for instance) rather than a one-off integration.

There is also an emerging companion scheme — ISASecure SDA (Site Deployment Assurance) — which is intended to cover the deployed installation in a way SSA does not. As of writing, SDA is at varying stages of pilot across the industry. Asset owners should watch this space because it potentially closes the assurance gap between "the supplied system" (SSA) and "the system as actually operating on my site" (SL-A in its truest sense).

How 3-2, 3-3, 4-1 and 4-2 all fit together

A clean way to visualise the relationship between all four standards is to think of four parties handing each other defined artefacts, with each party accountable for a defined scope and each handover backed by evidence that an outside assessor could check.

flowchart TB
    classDef ao fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef si fill:#1e8e3e,stroke:#0b3d20,color:#ffffff,stroke-width:1px;
    classDef ps fill:#e65100,stroke:#3d1e00,color:#ffffff,stroke-width:1px;
    classDef art fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:1px;

    AO[Asset Owner]:::ao
    SI[System Integrator]:::si
    PS[Product Supplier OEM]:::ps

    AO --> Art1[IEC 62443-3-2
Cybersecurity Requirements
Specification CRS
with SL-T per zone]:::art
    Art1 --> SI

    SI --> Art2[IEC 62443-3-3
Delivered System
achieving SL-A meeting SL-T
with traceability matrix]:::art
    Art2 --> AO

    PS --> Art3[IEC 62443-4-2
Certified Components
with SL-C vector]:::art
    Art3 --> SI

    PS -.governed by.-> Art4[IEC 62443-4-1
SDLA-certified
development process]:::art

The asset owner does the risk assessment under 3-2 and produces the CRS. The system integrator takes the CRS and delivers a system that complies with 3-3, using components certified to 4-2 by product suppliers whose development processes are certified to 4-1. Each party hands the next a defined artefact — a CRS, an SL-C vector with a certificate, a system with traceability — and each party is accountable for a defined scope.

A useful test of any specific deployment is to ask, for any given control objective, three questions in sequence: who owns this, what standard governs it, and what evidence proves it? If any of those three answers is fuzzy, the chain has a weak link. If all three answers are crisp, you have a defensible position whether you are looking at it as the asset owner, the integrator, the regulator, or the insurer.

Two other parts of 62443 also sit alongside these four. IEC 62443-2-1 governs the asset owner's broader cybersecurity management system — the policies, procedures, training and governance that wrap around the technical work covered in 3-2 and 3-3. IEC 62443-2-4 governs the security capabilities of service providers (typically system integrators and maintenance contractors) — the people, processes and competencies they bring to bear on your site. Both are covered in detail in IEC 62443-2-x: the management system behind a secure industrial plant . A complete picture for any single industrial site usually demands evidence under several of these parts simultaneously, with 3-2 and 3-3 forming the technical core of the design and delivery story.

The EU regulatory backdrop also bears mentioning here. Under NIS2 , asset owners in scope of Annex I sectors (energy, transport, water, manufacturing, etc.) are required to implement supply-chain security measures under Article 21(2)(d); a documented 3-2 CRS with SL-T allocation is the most defensible way to evidence that the supply-chain demands are risk-justified rather than arbitrary. Under the Cyber Resilience Act , industrial products with digital elements placed on the EU market must meet Annex I essential requirements, which in practice are most easily evidenced through 4-2 certification with the corresponding 4-1 development process — exactly the upstream of the chain that 3-3 then integrates.

Common pitfalls and red flags

The most frequent pitfall in 3-2 work is doing the partitioning before the risk assessment. The temptation is enormous: take the existing network diagram, draw some boxes around what is already segmented at Layer 3, and call those the zones. This produces a zone map that reflects historical wiring decisions rather than current risk, and it tends to under-protect new high-consequence assets while over-protecting low-consequence legacy ones. The risk assessment must drive the partitioning, not the other way round. A useful diagnostic is to look at the zone boundaries and ask: do these boundaries align with consequence categories, or with VLAN tags? If the latter, the zoning has been done backwards.

A second common pitfall is conflating SL-T with SL-C in procurement documents. A specification that says "the system shall be SL 3" without qualification leaves the supplier to interpret whether that means components capable of SL 3 (SL-C 3), an as-built system that achieves SL 3 (SL-A 3), or a target driven by risk (SL-T 3). These imply quite different cost structures and quite different obligations. As discussed earlier, the discipline of separating the three SL types in tender language pays back many times over in the clarity of the resulting deliverable.

A third pitfall is assuming that 4-2-certified components automatically yield a 3-3-compliant system. They do not. The integration matters at least as much as the components. Insecure conduit choices, badly configured authentication systems, unprotected jump hosts, unmonitored logging, shared service accounts created during commissioning and never removed — any of these can drag an SL-C 3 component set down to an SL-A 1 reality. The presence of certified components is necessary but not sufficient.

A fourth red flag is claims of "IEC 62443 compliant" without a part number. The standard has many parts, each with a defined audience. A claim of compliance from a system integrator should name 62443-3-3 (and probably 62443-2-4 for their service-delivery practices). A claim from a product supplier should name 62443-4-1 and 62443-4-2 . A claim from an asset owner should name 62443-2-1 and 62443-3-2. Any claim that does not name a part is, at best, imprecise — and usually a signal that the speaker is not familiar with how the standards family is organised.

A fifth pitfall is stale CRS documents. A CRS produced ten years ago for an SUC that has since added a new plant, two new control networks and a fleet of remote-access laptops is no longer a credible document. Refresh cycles matter, and the evidence pack should show them. A CRS without a version history or a defined review schedule is a CRS in name only.

A sixth and more subtle pitfall is the zone scope drift: zones that were defined narrowly during the 3-2 analysis but which, through the lifetime of the plant, have quietly absorbed additional assets through small change orders that individually seemed reasonable. The total effect is that the SL-T originally allocated to the zone no longer covers everything in the zone. Healthy asset management practice — change control that explicitly references the CRS, re-assessment when assets cross zone boundaries — is what prevents this.

A checklist for procurement and audit

The following can be used as a contract annex, a supplier questionnaire, or an internal audit checklist.

For the asset owner's own 3-2 evidence pack

  • A current, version-controlled System Under Consideration (SUC) description with scope explicitly stated.
  • An explicit risk assessment methodology document referencing the framework chosen (NIST SP 800-30, ISO 31000, sector-specific, or other) with scoring rules.
  • A threat catalogue drawn from credible sources (ENISA, MITRE ATT&CK for ICS, sectoral ISACs, national CSIRT advisories) with a stated date of currency.
  • A zone and conduit diagram showing the partitioning, with zones and conduits unambiguously labelled.
  • A risk register capturing pre-control and residual risk per zone and per conduit.
  • A Cybersecurity Requirements Specification (CRS) containing the SL-T vector for each zone and conduit, the assumptions, the constraints and any compensating measures relied upon.
  • Asset-owner sign-off of the CRS at a defined seniority level, with date.
  • A review cadence for the CRS, with evidence of past reviews and the date of the next scheduled review.

For the system integrator's 3-3 deliverable evidence pack

  • A requirements-traceability matrix linking each SL-T in the CRS to specific System Requirements of 62443-3-3 and to the design elements that satisfy them.
  • A bill of materials with each component's 62443-4-2 certificate referenced (or, where a component is uncertified, a written justification and the compensating controls applied).
  • A design documentation set showing zone implementation, conduit protection mechanisms, authentication architecture, logging architecture, backup and restore architecture, and operational interfaces.
  • Factory Acceptance Test (FAT) reports with security-specific test cases linked to the SRs they verify.
  • Site Acceptance Test (SAT) reports including configuration audit, vulnerability scan output, and any penetration testing performed.
  • A handover pack including hardening guides, configuration baselines, account inventories, SIEM/logging integration documentation, backup and restore procedures, and a security operations manual.
  • A change management process for the as-built system, defining how subsequent modifications will preserve the achieved SL-A and how the CRS will be re-consulted.
  • Where applicable, an ISASecure SSA certificate for the system or its core platform, with scope, level and validity date.

Questions to put to a system integrator in writing

  • Which version of IEC 62443-3-3 has the proposed system been engineered against?
  • For each zone in our CRS, what is the proposed SL-C profile of the components selected, and how does it map onto our SL-T?
  • Which components in your proposed bill of materials hold a current third-party 62443-4-2 certificate? For each, what is the certificate number, the issuing body, the certified firmware/software version, and the expiry date?
  • For any component without third-party 62443-4-2 certification, what compensating measures will deliver the relevant System Requirements?
  • Will the deliverable include a traceability matrix linking SL-T to SR to design element to verification test? Can we see a sample from a previous project?
  • What change-management process will apply to the system after handover so that modifications do not erode the achieved SL-A?
  • Are your service-delivery practices certified or assessed against IEC 62443-2-4 ?

IEC 62443-3-2 is the standard that tells the asset owner how to figure out, in a structured and defensible way, what security level each part of their industrial system actually needs. IEC 62443-3-3 is the standard that tells the system integrator what an integrated system at that security level must actually do. Together, they sit between the asset owner's risk picture and the OEM's certified components, and they are where the chain of evidence either holds together or breaks.

Treat 3-2 as the document that justifies the entire downstream programme. A clear CRS, signed off at the right level and reviewed on a sensible cadence, is the single most important artefact an asset owner can produce — because it is the lens through which every subsequent procurement, every system upgrade, every security audit and every incident response is interpreted. Treat 3-3 as the spec against which an integrator's work is judged. A traceability matrix from CRS through to SR through to verified test result is the integrator's defence in any future dispute about whether the system was delivered as specified. And remember always that components with the right SL-C, integrated into the right zones and conduits, only become a real SL-A when somebody operates the system day after day with the security features switched on. Standards bodies cannot enforce that part — only good operations can.

This is part 3 of 6 in the IEC 62443 series. The pack collects every part — PDF for printing or citation, EPUB sized for phones and e-readers.

PDF · 589 KB EPUB · 248 KB

Also available in Norsk →