A family of standards for industrial automation and control system security, structured into general, policy and procedure, system, and component groups. It provides the vocabulary of zones, conduits and security levels that most industrial security programmes use, whether or not they pursue formal certification.

What are zones and conduits?

A zone is a grouping of assets sharing a common security requirement. A conduit is the controlled pathway carrying communication between zones. Together they turn segmentation from a diagram into a policy that observed traffic can be checked against.

What is the difference between SL-T, SL-C and SL-A?

The target security level is what a zone requires given its consequence. The capability level is what the deployed equipment can support. The achieved level is what is genuinely in place today. Programmes get into trouble by recording a target and reporting against it as though it had been achieved.

Which parts of IEC 62443 can a monitoring platform evidence?

Most directly, restricted data flow, through observed zone-to-zone conformance; system integrity, through continuous program, configuration and firmware baselines; timely response to events, through the detection record; and identification and authentication control, through collected authentication telemetry.

Does IEC 62443 replace NERC CIP?

No. IEC 62443 is cross-sector and voluntary in most jurisdictions. NERC CIP is a mandatory regulatory standard for bulk electric system operators in North America. Many operators align their programme to 62443 and report compliance against NERC CIP, and Signal reports evidence against both.

Do we need certification to benefit from the standard?

No. The majority of the value is in the vocabulary and the structure: defining zones, being explicit about conduits, and separating target from achieved security levels. Certification is a separate exercise with its own cost, and it is mainly relevant to product suppliers and to asset owners with a contractual requirement.

IEC 62443: Zones, Conduits and Security Levels

How the standard is organised

IEC 62443 is a family rather than a single document, arranged in four groups. The general group covers concepts and terminology. The policies and procedures group addresses the security programme run by the asset owner and by service providers. The system group covers system-level design and requirements. The component group covers what a product supplier must build into a device.

For an asset owner securing an existing estate, 62443-3-3 usually carries the most weight, because it defines system security requirements grouped into seven foundational requirements and assigns them to security levels. That is the part a monitoring platform can produce evidence against.

Zones and conduits

A zone is a grouping of assets that share a common security requirement. A conduit is the controlled pathway carrying communication between zones. The idea is deliberately simple: decide what belongs together, then be explicit about what is permitted to cross between groupings and by what route.

The value is that it turns segmentation from a network diagram into a policy statement that can be checked. Once zones are defined and conduits are declared, any observed communication either conforms to the policy or does not, and the difference is measurable rather than a matter of opinion.

This is where most estates discover their real posture. The designed diagram and the observed traffic rarely match, because conduits accumulate: a temporary link for a commissioning task, a historian connection added for a reporting project, a vendor route opened during an outage.

Zones and conduits are only useful if you can compare them against what the network actually does. A zone model that is never checked against observed traffic is documentation, not a control.

Security levels, and the distinction that gets missed

Security levels run from SL 0 to SL 4 and describe resistance to progressively more capable adversaries: casual exposure at the bottom, then intentional violation using simple means with low resources, then sophisticated means with moderate resources, and at the top sophisticated means with extended resources and specific motivation.

The distinction that matters in practice is between the target level, the capability level and the achieved level. The target is what a zone requires given its consequence. The capability is what the deployed equipment can support. The achieved is what is genuinely in place today. Programmes get into difficulty by recording a target and then reporting against it as though it were achieved.

Being explicit about the gap between target and achieved, per zone, is more useful than a single overall rating, because it tells you where to spend.

The seven foundational requirements

62443-3-3 organises system requirements under seven foundational requirements. They are worth knowing by name because they structure most industrial security conversations, whether or not the standard is cited explicitly.

Identification and authentication control: knowing which humans, devices and software are acting
Use control: enforcing what an authenticated party is permitted to do
System integrity: ensuring the system and its information have not been altered
Data confidentiality: protecting information from unauthorised disclosure
Restricted data flow: segmentation into zones and conduits
Timely response to events: detecting, reporting and acting on security events
Resource availability: ensuring the control system remains available

What continuous monitoring can evidence directly

Compliance in an industrial estate is usually reconstructed by hand shortly before an audit, which is expensive and produces a snapshot rather than an assurance. A monitoring platform changes that for a meaningful subset of requirements, because it already holds the underlying data as a by-product of operations.

Restricted data flow is the clearest case. Signal builds the observed zone-to-zone matrix from real conversations and compares it against declared zones and conduits, so segmentation conformance is a live measurement rather than a design assertion.

System integrity is similarly direct: program logic hashes, configuration drift and firmware versions are tracked continuously against baselines, which is exactly the evidence the requirement asks for. Timely response to events is evidenced by the detection and alerting record itself, and identification and authentication control by the collected authentication telemetry.

Signal reports continuous evidence against IEC 62443-3-3 alongside NERC CIP, NIST SP 800-82r3 and AWWA G430, with each control carrying a score, a status and a drill-through to the data behind it.

Where a certification-based approach still applies

Not everything in the standard can be evidenced by observation. Requirements about the supplier's development process, or about capabilities a component must possess, are matters for product certification and procurement rather than for network monitoring.

The practical division is that monitoring evidences what the system does, and certification evidences what the components and the processes are capable of. A programme needs both, and conflating them produces either an over-claim about what a monitoring tool proves or an under-use of the evidence it genuinely provides.