Everybody’s drawn the zone diagram by now. Firewalls at the boundaries, a DMZ between IT and OT, maybe a nicely color-coded Visio file showing Level 0 through Level 4 per the ISA-95 hierarchy. If your plant did a CISA-aligned asset inventory push, you probably also have a spreadsheet — sometimes a genuinely good one — listing every PLC, HMI, engineering workstation, and managed switch on the floor. That’s real progress. It’s also not security architecture yet. It’s the raw material for security architecture.
The piece almost nobody runs, and the piece IEC 62443-3-3 was actually written to force, is the system requirement (SR) verification at the zone and conduit level: taking a target security level (SL-T) you’ve assigned to a zone, comparing it against what that zone can actually demonstrate today (SL-A), and documenting the gap requirement by requirement. Not “we have a firewall.” Not “we segmented OT from IT.” A structured answer to “does this zone meet SL-T 2 against FR 1 through FR 7, and if not, where exactly does it fall short.”
Why component certification never closed this loop
IEC 62443-4-2 component certification tells you a specific PLC or gateway was evaluated against defined capability security levels in isolation, on the bench, by a lab. It’s useful information for procurement. It is not a statement about your zone. A 4-2 certified controller sitting on a flat network with shared credentials and no conduit filtering contributes essentially nothing to that zone’s achieved security level, because SL-A is a system property, not a component property. This is the distinction that keeps getting lost when vendors market a certified component as if it discharges your 62443 obligations. It doesn’t. 62443-3-3 is the part of the standard that operates at the system level — the zone — and it’s the part that actually maps to how auditors and increasingly insurers are starting to ask the question.
What SL-T vs SL-A actually means in practice
Security Level Target is the level of protection a zone needs, based on the consequence of compromise — think safety impact, production loss, environmental release, regulatory exposure. You set SL-T through a risk assessment, typically landing zones at SL 1 (protection against casual or coincidental violation) through SL 4 (protection against sophisticated, well-resourced attackers). Most manufacturing zones outside of safety-critical or highly regulated processes land at SL-T 2 or SL-T 3.
Security Level Achieved is what the zone actually delivers today, measured against the seven foundational requirements (FRs) baked into 62443-3-3: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. Each FR has system requirements (SRs) with enhancements that step up as the target level rises. SL-A isn’t a vibe or an auditor’s gut feeling — it’s derived by checking, SR by SR, whether the zone’s actual controls satisfy the requirement at that level.
The gap assessment is simply the delta between the two, documented per FR, per zone. That document is what an auditor or underwriter is starting to ask for instead of the diagram.
Running the assessment with what you already have
The good news is that a solid asset inventory gets you most of the way to an SL-A baseline without new tooling.
- Start from your zone boundaries, not your asset list. If your zones were drawn purely by physical area or by convenience, revisit them. A zone should share a common SL-T. If one “zone” contains both a safety PLC and a data historian with wildly different consequence profiles, split it.
- Walk FR 1 (identification and authentication) first. Your inventory already tells you which devices support individual accounts versus shared or default credentials, and which sit behind a jump host or PAM tool versus direct network access. That’s most of SR 1.1–1.3 answered from data you already collected.
- Walk FR 5 (restricted data flow) using your firewall rule sets and switch configs. This is where most plants discover the real gap: rules that permit “any-any” between subnets, flat VLANs pretending to be zones, or conduits with no filtering at all — just a router doing NAT.
- Walk FR 3 (system integrity) against your patch and change records. If you can’t show patch cadence or configuration baselines for a zone’s assets, you don’t have SR 3.4 or 3.8, regardless of what’s sitting at the perimeter.
- Score each SR as met, partially met, or not met — resist the urge to average up to a tidy overall number. A zone that’s strong on authentication and weak on data flow restriction is not “SL 2 on average.” It’s SL-A 1 for practical purposes, because attackers exploit the weakest FR, not the mean.
Translating SL-T into controls people can actually build
SL-T 2 for a zone generally implies things like unique user authentication for all human and software users, role-based use control, basic malware protection at the conduit, and event logging that actually goes somewhere reviewable. SL-T 3 adds multi-factor authentication for remote and often local access, network-based intrusion detection at conduits, more rigorous session integrity, and stronger segmentation with explicit deny-by-default conduit rules rather than permissive ones with exceptions bolted on.
The translation work is where most consultants earn their fee, but you don’t need one to get started: for each unmet SR, write down the specific control that would satisfy it — a jump server with logging for FR 1, a Sparkplug-aware firewall rule replacing an any-any for FR 5, a syslog forwarder feeding a SIEM for FR 6 — and you’ve turned an abstract standard clause into a project line item.
Prioritizing when SL-A comes up short — which it will
Almost every plant that runs this exercise honestly finds SL-A trailing SL-T by at least one full level in at least one zone. That’s normal, not alarming, and it’s exactly the information you need to prioritize spend instead of guessing.
- Fix conduits before zones. A conduit gap (FR 5, restricted data flow) affects every asset behind it. Segmentation and explicit-allow firewall rules typically deliver more risk reduction per dollar than endpoint hardening inside a zone that’s already reasonably contained.
- Fix authentication before monitoring. Detecting an intrusion you couldn’t have prevented with basic access control is solving the wrong problem first.
- Treat safety-adjacent zones as non-negotiable. If a zone’s SL-T was driven by safety consequence, don’t let it sit in the same remediation queue as a zone whose worst case is a production delay.
- Re-run the assessment on a cadence, not once. SL-A degrades as devices get added, firewall rules get “temporarily” opened for a vendor and never closed, and default credentials creep back in during outages. An SL-T/SL-A gap document that’s two years old is a historical artifact, not evidence of current posture.
The zone diagram was never the deliverable. It was the map you needed before you could ask the harder question: does this zone actually do what its risk level demands? That question has a standard-defined answer, most plants have simply never sat down and worked it out FR by FR. The ones that do end up with something an auditor, an insurer, and — more to the point — an incident responder can actually use.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
