The standard for securing the systems where cyber meets physical consequence — zones, conduits, security levels, and roles, decoded into the four ideas that do all the work.
IEC 62443 is the international standard series for securing industrial automation and control systems (IACS) — the PLCs, SCADA systems, and operational technology that IT frameworks were never designed for. Its core ideas are four: divide the environment into zones and conduits, assign each zone a target Security Level (SL 1–4) based on the threat it must withstand, meet seven foundational requirements within each zone, and assign responsibilities across asset owners, integrators, and product suppliers. It's the framework regulators, insurers, and customers reach for wherever cyber meets physical consequence.
Manufacturing and energy organizations usually arrive at IEC 62443 from one of three directions: a customer or regulator asked for it, an insurance review flagged OT as unassessed, or an incident somewhere in the sector made the board ask "could that happen to us?" The standard has a reputation for impenetrability — a multi-part series with numbering only a committee could love — but its logic is straightforward once decoded.
The parts group into four layers: 62443-1-x (concepts and terminology), 62443-2-x (policies and programs — what the asset owner's security program must do), 62443-3-x (system-level — including 3-2's risk assessment and zoning methodology and 3-3's system security requirements), and 62443-4-x (component-level — secure development and technical requirements for the products themselves). Most organizations engage primarily with 2-1, 3-2, and 3-3; product manufacturers add the 4-x parts.
OT environments invert IT's assumptions: availability outranks confidentiality, patch windows are measured in annual maintenance shutdowns, devices run for decades, and "just scan it" can halt a production line. That's why generic IT control checklists produce OT assessments that are simultaneously burdensome and useless. A real 62443 assessment is architecture-grounded: it starts from what's actually connected to what — the zones, the conduits, the data flows — and evaluates achieved security levels against targets.
That's the assessment PRISM is built to perform: model the OT architecture — tiers, zones, data flows — then map it against IEC 62443's requirements alongside whatever else applies (NIST CSF for the board, 800-171/CMMC for defense-adjacent manufacturers, NERC CIP context for utilities). We've done exactly this in practice: an energy technology company used PRISM's visual system modeling for its IEC 62443 compliance assessment — the case study is here. And because the architecture model and the evidence are the same pool Foundations draws on, the OT risk picture arrives with dollars attached — which is what turns a zoning diagram into a board conversation.
Three moves, in order: inventory what's actually on the OT network (the discovery phase humbles everyone), run the 3-2 risk assessment to set zone boundaries and target SLs, and resist the urge to buy tools before the gap between target and achieved SLs tells you what to buy. The standard's whole value is that it sequences the work — skipping to procurement re-creates the tool sprawl it exists to prevent.
PRISM models your zones, conduits, and data flows visually, then maps the architecture against IEC 62443 and every other framework that applies. Proven in the field.