IEC 62443-3-3 is where architecture becomes testable. It takes the zones you drew in 3-2 and states, per zone, what the system has to do. Two things about it are routinely misread, and both cost money later.
Seven foundational requirements, and everything hangs off them
The whole technical half of the series rolls up to seven FRs. Learn these and the requirement numbering stops being arbitrary:
- FR 1 — Identification & Authentication Control (IAC). Who or what is this, and can it prove it?
- FR 2 — Use Control (UC). Given a proven identity, what is it permitted to do?
- FR 3 — System Integrity (SI). Has anything been altered that should not have been?
- FR 4 — Data Confidentiality (DC). Who can read it, at rest and in transit?
- FR 5 — Restricted Data Flow (RDF). What may talk to what — the architecture requirement.
- FR 6 — Timely Response to Events (TRE). Do you find out, and can you act?
- FR 7 — Resource Availability (RA). Does it keep running under stress?
3-3 states these as system requirements (SR 1.x through SR 7.x). Its component sibling 4-2 states the same seven as component requirements (CR 1.x through CR 7.x). Same skeleton, different subject.
Security level is a vector, not a number
This is the misreading that causes contract disputes. Each FR has base requirements plus requirement enhancements — RE(1), RE(2) and so on. The standard maps, per FR, which base requirements and which enhancements are needed at SL 1, 2, 3 and 4. A higher level means the base requirement plus more enhancements.
Because the mapping is per FR, a system’s capability is properly written as a vector across the seven: SL-C = {2, 2, 1, 1, 3, 2, 1}. Not “SL 2”. A product strong on restricted data flow and weak on data confidentiality is a normal, honest result — and a single number hides exactly the part a customer needs to know.
The three SLs, kept straight
- SL-T (target) — what a zone or conduit needs, decided during the 3-2 risk assessment.
- SL-C (capability) — what a system or component can deliver if correctly configured.
- SL-A (achieved) — what the installation actually delivers, as built and configured.
Vendors sell SL-C. Assessors measure SL-A. The gap between them is configuration, integration and operational discipline, and it is where most real findings live. An SL-C 3 component dropped into an SL-T 2 zone with default credentials achieves SL-A 1, and the certificate on the datasheet does not change that.
Where the requirements actually come from
3-3 does not tell you which level to aim for. That comes out of IEC 62443-3-2 and its zone-and-conduit risk assessment workflow, which runs from identifying the system under consideration through partitioning, risk comparison, the detailed per-zone assessment where SL-T is assigned, and finally the Cyber Security Requirements Specification the asset owner approves.
Which is why starting at 3-3 feels like a wall of requirements with nothing to attach them to. Do 3-2 first. The requirements then arrive with a reason attached, and “why is this in scope” has an answer you can point at.
Reading a claim critically
When a supplier says “62443 compliant”, three questions settle it: which part, capability or achieved, and what is the vector across the seven FRs. A supplier who can answer all three has done the work. One who answers with a single number has usually read the marketing copy rather than the mapping table.
We assess systems against 3-3 and run the 3-2 workflow that decides the targets. If a customer has just sent you a security level requirement and you are not sure what you are being asked to prove, that is a short conversation.