- 01OT environments fail IT-centric audits in predictable ways: latency-sensitive protocols cannot tolerate active scans, asset lifecycles span 20 years, 'patch monthly' conflicts with safety integrity levels.
- 0262443 is a family. The four parts that matter most: 2-1 (asset-owner program), 3-2 (zones-and-conduits design), 3-3 (system requirements per Security Level 1–4), 4-1 / 4-2 (secure product development).
- 03The zones-and-conduits diagram is the most useful artifact you produce. Update it every time a new device, vendor, or remote-access path is introduced — otherwise it becomes wallpaper.
- 04Security Levels (SL-T 1–4) translate target rigor into testable technical and procedural requirements. Auditors love this model because every requirement is concrete and falsifiable.
Industrial control system (ICS) and operational technology (OT) environments fail IT-centric audits in predictable ways: latency-sensitive protocols cannot tolerate active scans, asset lifecycles span 20 years, and 'patch monthly' is incompatible with safety integrity levels. IEC 62443 was built around those realities.
The four parts that matter
- 0162443-2-1 — Security program for asset owners (the operator's playbook)
- 0262443-3-2 — Security risk assessment for system design (zones and conduits)
- 0362443-3-3 — System security requirements and security levels (SL 1–4)
- 0462443-4-1 / 4-2 — Secure product development and component requirements
Zones and conduits in practice
62443-3-2's zones-and-conduits model is the most useful artifact you will produce. A zone is a grouping of assets with shared security requirements; a conduit is the controlled communication path between zones. Done well, the diagram becomes the source of truth for segmentation, monitoring, and incident scoping.
Done badly, it becomes wallpaper. The discipline is to update the zones diagram every time a new device, vendor, or remote-access path is introduced.
Security Levels: a defensible bar
Each zone gets a target Security Level (SL-T) from 1 (casual) to 4 (nation-state). The standard then dictates the technical and procedural requirements for that level. Auditors love this model because it is concrete: SL-2 means specific authentication, encryption, and monitoring requirements that are testable, not aspirational.