What 'system integrator for L0/L1' actually means under 62443
A design coordination meeting between the manufacturer's L0/L1 engineering team and the asset owner's L2-and-above architecture team. The asset owner's architect explains the immediate question: in order to specify the conduit firewall between the manufacturer's process zone and the upstream plant network, the architect needs the manufacturer's zone and conduit risk assessment. Without that document, the conduit specification has nothing to anchor to — no defined Target Security Level on the manufacturer's side of the conduit, no documented risk that the firewall is mitigating, no mapping between the system requirements in IEC 62443-3-3 and the actual configuration that needs to be implemented.
The manufacturer's team confers briefly. They ask which document, specifically, is being requested. They are familiar with the IEC 62443 series in the way most engineering teams are familiar with standards they have heard cited but never authored — they know the number, they know it concerns industrial cybersecurity, they have not previously been asked to produce documents under it.
The asset owner's architect explains. The manufacturer's team takes notes. The meeting ends with an action item: the manufacturer will revert with a plan for producing the requested deliverables. Two weeks later, the response comes through procurement. The manufacturer would like to understand whether the deliverables can be supplied as a separate, costed scope item, on the basis that they are not part of the equipment supply agreement as currently drafted.
This is not an unusual conversation. It is the conversation. The asset owner's L2-and-above design assumes that the L0/L1 integrator has produced specific cybersecurity documentation, because IEC 62443-3-2 — the standard that governs system risk assessment and zone-and-conduit design — explicitly places the responsibility for that documentation on the party performing the integration. When the equipment manufacturer also acts as the L0/L1 integrator, which is normal for wind turbine, solar inverter, battery and hybrid plant suppliers, the integrator obligations flow to them. They do not go away because the standard is unfamiliar.
The two standards that bear on this role
Two parts of the 62443 series are operationally relevant.
IEC 62443-2-4 is the security programme requirements for IACS service providers. It defines what a system integrator's own security management programme must contain — staffing, awareness, change management, patch management, audit log management, several other process areas — and what evidence is expected to demonstrate conformance. A manufacturer acting as integrator is, for the purposes of this standard, a service provider, and is expected to maintain a security programme aligned to it.
IEC 62443-3-2 is the security risk assessment and system design standard. It defines the process by which the integrator analyses the system under consideration (SuC), partitions it into zones and conduits, conducts a risk assessment, assigns Target Security Levels to each zone, and produces the documented outputs that downstream engineering depends on. This is the standard that produces the deliverables the asset owner needs.
Two further parts of the series sit alongside these and are referenced rather than authored.
IEC 62443-3-3 specifies the system requirements organised by foundational requirement (FR1 through FR7) and security level (SL 1 through 4). The integrator does not author 62443-3-3 — it is a published standard — but they apply it. The Target Security Levels assigned in the 3-2 risk assessment become demands on the system, which are then mapped to the 3-3 system requirements that must be met at each level.
IEC 62443-4-2 specifies the technical security requirements for the components themselves, organised the same way as 3-3 but addressed to the component supplier rather than the system. A component's Capability Security Level — SL-C — is a property of the component, certified by independent test where possible. The components a manufacturer delivers into the project must have SL-C values at least equal to the Target Security Level (SL-T) of the zone they sit in. Where they do not, compensating controls must be designed and documented.
The relationship between these four parts is the architecture of the entire conversation. 2-4 says what the integrator must do as an organisation. 3-2 produces the risk assessment and the zone-and-conduit design. 3-3 defines the system requirements at each Security Level. 4-2 defines the component capabilities that allow the system to meet them. The L0/L1 integrator sits in the middle of all four.
The documents an L0/L1 integrator produces
The 3-2 process produces a series of artefacts the asset owner expects to receive and review. The IEC 62443 evidence pack post lists the asset-owner-side counterparts; the integrator-side artefacts below feed those packs.
The System under Consideration definition. A scoping document that states clearly what is included in the integrator's L0/L1 system — which assets, which interfaces, which protocols, which physical and logical boundaries — and what sits outside, particularly the boundary at which the integrator's responsibility ends and the asset owner's begins. The SuC is the foundation; if it is wrong, everything downstream is wrong.
The high-level risk assessment. A first-pass analysis determining whether the SuC presents sufficient risk to warrant detailed assessment. For an L0/L1 system in a utility-scale renewable energy plant, the answer is always yes, but the high-level assessment documents the reasoning and supports the initial zoning decisions.
The initial system partitioning. The first cut at zones and conduits, identified from the SuC. Zones group assets that share a common security level and exposure profile; conduits are the controlled communication paths between zones. For a typical wind turbine, the zoning might include the per-turbine controller zone, the turbine cluster network zone, the plant SCADA zone, and the boundary to the upstream IDMZ — with conduits between each. For a solar plant, similar with inverters in place of turbine controllers; for a battery system, similar with the BMS in the role of the controller.
The detailed risk assessment per zone and conduit. For each zone, an analysis of the threat scenarios that could affect it, the likelihood of those scenarios, the consequences (operational, safety, financial, environmental), and the residual risk after the planned controls. For each conduit, an analysis of the communication that crosses it, the threats specific to that communication path, and the controls applied to mitigate them.
The Target Security Level assignment. For each zone, an SL-T value of 1, 2, 3 or 4, applied independently to each of the seven foundational requirements. A turbine controller zone in a utility-scale plant might be assigned SL-T 3 for system integrity (FR3) and timely response to events (FR6), SL-T 2 for use control (FR2) and restricted data flow (FR5), and lower levels for the remainder. The SL-T values quantify what the zone must be able to defend against and direct the choice of components and configurations.
The Cybersecurity Requirements Specification. The output document that captures all of the above and serves as the input to detailed design. It states the SuC, the zones, the conduits, the SL-T per zone per foundational requirement, the threats considered, the controls required, and the residual risk accepted by the asset owner. It is the document that the asset owner's L2 design references when specifying conduit firewalls, IDMZ rules, monitoring requirements and incident response procedures.
The SL-C mapping. For each component the integrator delivers into the SuC, a statement of the Capability Security Level it provides per foundational requirement, with evidence — typically a certification or evaluation report — supporting the claim. Where the SL-C is lower than the SL-T of the zone, compensating controls are documented in the Cybersecurity Requirements Specification and the residual risk is formally addressed.
These are not optional artefacts. They are the design basis for everything downstream. Without them, the asset owner cannot specify the L2-and-above architecture, the lender cannot evidence cybersecurity due diligence, and the project cannot demonstrate 62443 conformance to any independent assessor.
What Security Levels actually mean
The four-level scale in 62443 is not a generic risk rating. It corresponds to specific threat capabilities, defined in 62443-1-1 and applied consistently across the series.
Security Level 1 is protection against casual or coincidental violation. Default credentials changed, basic access control, basic logging. The floor of any responsible deployment.
Security Level 2 is protection against intentional violation using simple means with low resources, generic skills and low motivation. The threat actor in scope is an opportunistic insider or external party using widely available tools.
Security Level 3 is protection against intentional violation using sophisticated means with moderate resources, IACS-specific skills and moderate motivation. The threat actor is a serious adversary with industry-specific knowledge — disgruntled former employees with privileged knowledge, organised criminal groups targeting industrial control systems, regional state-affiliated groups.
Security Level 4 is protection against intentional violation using sophisticated means with extended resources, IACS-specific skills and high motivation. The threat actor is a peer state intelligence service, an advanced persistent threat with multi-year campaigns, organised crime operating at nation-state scale.
For utility-scale renewable energy plants in EU-financed projects, particularly in regions of geopolitical exposure, SL-T 3 is the typical floor for the foundational requirements that bear on system integrity, restricted data flow and timely response to events. SL-T 2 may be acceptable for some lower-criticality zones. SL-T 4 is rarely required outside specific national infrastructure designations or against named threat actors.
The translation matters because it determines what the integrator must deliver and what the asset owner must build around it. SL-T 3 components have particular capability requirements — strong identity and authentication, integrity-protected communication, comprehensive audit logging, hardened configurations, support for centralised key management — that are simply not present in components designed for less demanding markets. A manufacturer whose products are well-suited to an SL-T 2 deployment in a domestic market may need different components, or substantial additional engineering and compensating controls, to deliver into an SL-T 3 deployment in an EU-financed project.
When and how this work happens
The 62443-3-2 process is not a final-acceptance deliverable. It is a design basis, which means it must exist before downstream design depends on it.
The typical sequence runs as follows.
Pre-final-investment-decision, during bid and conceptual design: an initial scoping exercise. The System under Consideration is sketched, the high-level risk assessment is conducted, the initial zoning is proposed. This is sufficient for the lender's early due diligence and for the asset owner's L2 conceptual design.
Post-final-investment-decision, in early detailed engineering: the detailed risk assessment is conducted, the zones and conduits are finalised, the SL-T values are assigned and signed off. The Cybersecurity Requirements Specification reaches its first formal version. The asset owner's L2 design begins to firm up around this baseline.
Through detailed engineering and procurement: the SL-C evidence is assembled for each component, the Cybersecurity Requirements Specification is updated as design decisions are made, the conduit specifications are finalised. The L2 firewall rule base, IDMZ configuration and monitoring infrastructure are designed against the document.
At factory acceptance test: the components are verified against the SL-C claims and the Cybersecurity Requirements Specification expectations. Findings result in non-conformances or accepted residual risks; either way they are documented.
At site acceptance and commissioning: the integrated system is verified against the Cybersecurity Requirements Specification, the operational controls are demonstrated, the residual risks are formally accepted by the asset owner.
Typical duration from kick-off to a signed-off baseline Cybersecurity Requirements Specification is six to ten weeks of focused work for a single utility-scale plant. Less if the manufacturer has produced 62443-3-2 documentation for previous projects and has templates and prior examples to start from. Considerably more if the manufacturer has never produced one and is starting from a standing position.
Review parties typically include the asset owner's security architect (the primary internal reviewer), the asset owner's engineering and operations teams (for the operational consequences), the project's IEC 62443-conformant cybersecurity consultant if one is engaged, the lender's technical and cybersecurity adviser, and where independent assurance is required, a third-party certification body. ISASecure CSA is the most common scheme path to SL-C evidence; assessment services for the 62443 series are offered by TÜV SÜD and exida among others, with DNV and Bureau Veritas also active in specific market segments.
At proposal stage
A manufacturer's bid that arrives with the 62443 deliverables already accounted for — that names the integrator role explicitly, that proposes a 3-2 work plan with timeline and review gates, that lists the SL-C evidence for the components being offered, that identifies any gaps between component SL-C and likely zone SL-T and proposes how those gaps will be closed — is a bid that demonstrates the manufacturer has done this before, or at least knows what doing it looks like. The conversation that follows is about scope, schedule and resourcing, not about whether the work is required.
A manufacturer's bid that does not mention 62443 at all, or that mentions it as a future deliverable to be scoped separately, signals one of two things. Either the manufacturer is not yet equipped to take on the L0/L1 integrator role under EU-financed terms, or they intend to take it on but have not yet recognised the work that role entails. Both are surmountable. The first is the work of months, beginning with a 62443-2-4 service-provider programme; the second is the work of weeks, beginning with a project-specific 3-2 work plan and an accredited consultant alongside the engineering team. But both must be addressed before contract signature, because nothing in the L2-and-above design proceeds without the 3-2 deliverables, and the project schedule does not pause to wait for them.
The recurring observation throughout this series is that EU cybersecurity expectations are not as forbidding as they sometimes appear in the first conversation. The 62443 documentation is the clearest case. The process is well-defined. The deliverables are clear. The standards exist. Consultants accredited to assist exist. The work, once understood, is routine engineering of a kind the manufacturer's organisation already does for other purposes — risk assessment, system architecture, requirements traceability — under a different name and a different framing.
The next article moves to a topic the manufacturer's organisation may find more cultural than technical: the public-facing vulnerability disclosure programme that the Cyber Resilience Act will require, and why "email us if you find a problem" is not a programme.
This article reflects the IEC 62443 series at publication. The standard continues to evolve; in particular 62443-3-2 and 62443-4-2 have been subject to revision discussion through the IEC technical committee. References to commercial certification bodies are illustrative rather than endorsements. Specific arrangements should be reviewed by qualified legal counsel rather than against this article. If a citation has rotted or a clause has moved, LinkedIn is the way to flag it.