IEC 62443 — Industrial Automation and Control Systems Security
How IEC 62443 zones, conduits, security levels, and foundational requirements relate to NexoGraph.
IEC 62443 (also known as ISA/IEC 62443, developed by the ISA99 committee) is the multi-part international standard for cybersecurity of Industrial Automation and Control Systems (IACS). It covers operational technology (OT) environments including manufacturing execution systems, SCADA, DCS, PLCs, and the networks that connect them.
In the automotive context, IEC 62443 is relevant to vehicle manufacturing plants, test bench infrastructure, and connected factory environments where vehicles or their components are produced. It also applies to vehicle-adjacent infrastructure such as charging networks and fleet management systems.
Standard Structure
IEC 62443 is organized into four series, each targeting a different audience:
| Series | Target audience | Scope |
|---|---|---|
| 1 — General | All | Concepts, terminology, metrics, security lifecycle |
| 2 — Policies and procedures | Asset owners / operators | IACS security management programs |
| 3 — System requirements | Integrators | System-level security requirements, zones and conduits |
| 4 — Component requirements | Product suppliers | Component-level security requirements |
NexoGraph is most relevant to Series 3 (system requirements that produce traceable security specifications) and Series 2 (policy requirements that define organizational obligations).
Zone and Conduit Model
The core architectural concept in IEC 62443 is the division of an IACS into zones and conduits:
| Concept | Definition |
|---|---|
| Zone | A logical or physical grouping of assets with a common security requirement profile — all assets in a zone share the same Security Level target |
| Conduit | A communication channel (path, link, or set of links) that connects zones and carries data between them |
| Security Level (SL) | A measure of the confidence that the zone or component resists cyberattacks, rated SL 1–4 |
SL-T (Target Security Level) is what the design intends. SL-A (Achieved Security Level) is what testing confirms. The gap between SL-T and SL-A is tracked throughout development.
Security Levels
| SL | Attack resistance | Attacker profile |
|---|---|---|
| SL 1 | Casual or coincidental violation | Untargeted, no specific knowledge |
| SL 2 | Intentional violation using simple means | Low resources, generic skills |
| SL 3 | Sophisticated attack using IACS-specific means | Moderate resources, domain expertise |
| SL 4 | State-sponsored / highly sophisticated attack | Extended resources, nation-state level |
Foundational Requirements
IEC 62443-3-3 defines seven Foundational Requirements (FR) that every zone must address. Each FR is further subdivided into System Requirements (SR) with component-level requirements (CR) in 62443-4-2:
| FR | Name | Scope |
|---|---|---|
| FR 1 | Identification and Authentication Control (IAC) | Identity verification for all users and devices |
| FR 2 | Use Control (UC) | Authorization enforcement — least privilege |
| FR 3 | System Integrity (SI) | Protection from unauthorized modification |
| FR 4 | Data Confidentiality (DC) | Encryption in transit and at rest |
| FR 5 | Restricted Data Flow (RDF) | Network segmentation and conduit control |
| FR 6 | Timely Response to Events (TRE) | Monitoring, alerting, and incident response |
| FR 7 | Resource Availability (RA) | Resilience against denial-of-service and faults |
NexoGraph Alignment
| IEC 62443 concept | NexoGraph implementation |
|---|---|
| Asset owner (obligated party) | Stakeholder (category: INTERNAL) |
| Supplier / integrator | Stakeholder (category: SUPPLIER/PARTNER) |
| Regulatory / certification body | Stakeholder (category: REGULATORY) |
| Security requirement (SR) | Requirement (reqCat: SECURITY) |
| FR classification | tags field (e.g., FR1, FR5) — no structured FR attribute |
| SL-T target | Gap — no Security Level field on Package or Requirement |
| Zone as system scope | Package — can represent a zone boundary in the hierarchy |
| Rationale and source | rationale, source fields on Requirement |
| Requirement lifecycle | Lifecycle service governs draft → review → approved states |
| Bidirectional traceability | REFINES_INTO links needs to stakeholder requirements; SATISFIED_BY links requirements to capabilities |
Gap Analysis
| Gap | IEC 62443 clause | Status |
|---|---|---|
| Zone entity type | 62443-3-2, §5 | Not modelled — Package provides approximate grouping |
| Conduit entity type | 62443-3-2, §5 | Not modelled |
| Security Level (SL-T / SL-A) attribute | 62443-3-2, §4.5 | Planned — field on Package and/or Requirement |
| FR classification on Requirement | 62443-3-3, §5 | Partial — can use tags but no structured enum |
| IACS risk assessment artefacts | 62443-3-2, §8 | Not modelled — IACS risk analysis records have no entity type |
| Patch and vulnerability management records | 62443-2-3 | Not in scope for current MVP |
| Supplier security requirement (CSR) | 62443-2-4 | Not modelled |
Relationship to ISO/SAE 21434 and ISO/IEC 27001
| Standard | Domain | Common ground with 62443 |
|---|---|---|
| ISO/SAE 21434 | Automotive product cybersecurity | Both address attack-driven risk; 62443 covers manufacturing OT, 21434 covers the vehicle itself |
| ISO/IEC 27001 | Information security management (IT) | 27001 governs the ISMS for the organization; 62443 governs OT/IACS security within that org |
In practice, automotive manufacturers apply all three: 27001 for corporate IT, 62443 for factory/test OT, and 21434 for the vehicle product. NexoGraph can host requirements from all three in separate Package trees, with stakeholder and traceability relations linking them where obligations intersect.