Teaching Operational Technologies

ISA/IEC 62443 is a series of standards and technical reports — not a single document — covering the security of Industrial Automation and Control Systems (IACS) across their full lifecycle. It was developed by the ISA99 committee and is jointly published with the International Electrotechnical Commission as IEC 62443, through IEC Technical Committee 65, Working Group 10.

The ISA99 committee formed in the early 2000s as it became clear that IT security standards didn't fit control systems — a firewall rule that's fine for a database server can break a real-time control loop. Growing high-profile incident awareness through the 2000s and 2010s (Stuxnet chief among them) accelerated adoption, and the standard has been continuously expanded and revised since its first parts were published.

62443 is unusual among the Core Frameworks in that its entire structure is organized around three distinct audiences: asset owners who operate the plant, system integrators who design and deploy it, and product suppliers who build the PLCs, HMIs, and network gear that go into it. Each audience gets its own series of the standard, written in language and at a level of abstraction that fits their job.

It's the only framework in this set that is both written specifically for control systems (rather than adapted from IT or general risk management) and formally certifiable — a product, a development process, or an asset owner's security program can all earn a verifiable third-party certification against it. NIST SP 800-82 is guidance; ATT&CK for ICS is descriptive; CIP-008 is a legal mandate for one sector. 62443 is a design standard you can build to and prove you built to.

Verifying the identity of users, software processes, and devices before granting access. Covers human authentication, software-process authentication, and device authentication as three distinct requirements.

Enforcing what an already-authenticated identity is actually allowed to do — authorization, session control, and audit logging of use.

Protecting against unauthorized manipulation of hardware, software, configuration, and information — including malware protection and input validation.

Protecting information from unauthorized disclosure, at rest and in transit — the requirement most similar to what IT usually ranks first, here ranked fourth.

Segmenting the network into zones and controlling exactly what crosses a conduit — the requirement that operationalizes zones and conduits themselves.

Detecting security events and responding fast enough to matter for a real-time process — logging, alerting, and incident-response capability.

Keeping the system operating and able to recover — backup, redundancy, and resilience against denial-of-service, reflecting OT's availability-first priority.

Defines the core vocabulary — zones, conduits, security levels, and the reference models the rest of the series builds on. This is the part to read first if you're only reading one.

Describes how certification bodies actually verify conformance to the standard — the process behind an ISASecure certification.

What a plant operator's security management program must actually contain — policy, risk management, and organizational requirements, loosely modeled on the same management-system logic as ISO/IEC 27001.

A process specifically for the reality Lesson 7 already covers — patch windows that don't open on IT's schedule — rather than assuming IT's usual patch cadence applies.

The same kind of program requirements as 2-1, but for the integrators and maintenance contractors an asset owner hires — the standard's answer to third-party risk in OT.

Where zones actually get drawn and assigned a Target Security Level (SL-T) — the methodology that turns a network diagram into a documented security architecture.

Maps specific, testable requirements under each of the seven Foundational Requirements to each Security Level — the part that turns "SL 3" from a label into an actual checklist.

Process requirements for how a vendor builds the product in the first place — secure design, threat modeling, vulnerability handling, and patch delivery over the product's life.

The component-level counterpart to 3-3 — concrete technical requirements a PLC, HMI, or network device must meet to support a given Security Level once it's deployed.