IEC 62443: where the standard meets a hardware switch

IEC 62443 organizes industrial security around zones (groups of assets that share security requirements) and conduits (the network paths that connect them). Each conduit is assigned a target security level (SL-T) that drives what controls it should carry. The standard is explicit that conduits can be physical, logical, or both.

This is useful for talking about AirGapNet, because the device is unambiguously a conduit-level control. A relay on a line between two zones is the line itself — there is no abstraction between the standard's term and the physical reality.

Several System Requirements (SRs) under 62443 describe controls that physical isolation contributes to directly. Network segmentation SRs explicitly accommodate physical separation as one fulfilment path. Zone boundary protection is where a default-closed relay does the most direct work. Audit log accessibility is supported by the device's own state-transition log.

The contribution is conduit-shaped: the relay enforces the existence of the path during defined windows, and the device's audit log records the state transitions. The integrator's job is to map that into the zone/conduit document and the SL-T justification — the device does not do that mapping itself.

62443 covers a wide surface, most of which lives above the conduit. Identification and authentication of human users live in the asset and the integrator's IAM. Use control is application-layer. System integrity is on the assets in the zone, not on the conduit.

The conservative read is: the relay contributes to network-segmentation and zone-boundary SRs, and the device log contributes to audit-trail SRs. Everything else is somewhere else in the architecture — and the device does not pretend to address it.

When integrators document a 62443 conformity assessment, the zone-and-conduit map is the central artefact. AirGapNet appears in that map as a conduit-level control with an associated SL-T and a referenced device log. The integrator's narrative explains why the chosen control is sufficient for the target security level on that conduit.

We publish the per-SR mapping on /compliance for the same purpose: so the integrator does not have to reverse-engineer what AirGapNet contributes against the standard. The mapping is a starting point, not the entire compliance answer — but it removes the most time-consuming part of writing it from scratch.