Somewhere in the last couple of procurement cycles, IEC 62443-3-3 stopped being a standard your cybersecurity team cited in a policy document and started being a line item a purchasing agent copies into an RFP without fully understanding it. If you’re a controls engineer or plant IT lead who’s recently seen “vendor shall demonstrate conformance to IEC 62443-3-3” buried in a bid package for a new PLC, HMI, or MES gateway, you’re not imagining a trend. You’re watching a standard graduate from audit artifact to purchasing gate, and most of the people writing and answering those RFP lines don’t actually know how to use the SL/SR framework correctly.
That gap is the problem worth solving. Get the SL/SR mapping wrong and you either lock out perfectly good vendors over paperwork, or worse, you wave through a vendor whose datasheet mentions “62443” once in a footnote and calls it done.
Why this is happening now
Three forces are converging. Secure-by-design guidance from CISA and similar bodies has pushed device manufacturers to publish more formal security claims. Software bill of materials (SBOM) expectations are spreading from IT into OT procurement, forcing vendors to disclose what’s actually running on their controllers and gateways. And OT/IT convergence — MES systems pulling live data off PLCs, historians talking OPC UA or MQTT Sparkplug B straight to the cloud — means a compromised edge device is no longer an isolated plant-floor problem. It’s a path into the MES, the ERP, and beyond.
Insurers and large OEM customers have noticed. It’s increasingly common for a Tier 1 or Tier 2 manufacturer to inherit security requirements from their own customers’ supply-chain security programs, and IEC 62443-3-3 is the most mature, most referenceable standard available for system-level control requirements. It’s not that everyone suddenly loves the standard. It’s that everyone needs a citable bar, and this is the one that exists.
What SL-1 through SL-4 actually mean for a real cell
Security Levels in 62443-3-3 aren’t a maturity score or a certification grade — they describe the sophistication of the adversary a system is designed to resist, and each level maps to a specific combination of means, resources, skills, and motivation.
- SL-1 protects against casual or coincidental violation — an operator fat-fingering a setpoint they shouldn’t have access to, not a targeted attacker. Most standalone legacy PLCs with no authentication at all don’t even clear this bar cleanly.
- SL-2 assumes an intentional attacker with simple means and low resources — someone using known vulnerabilities and generic tools. This is a realistic baseline for most manufacturing cells today: a disgruntled contractor, a curious insider, malware that happened to land on the network.
- SL-3 assumes moderate resources, OT-specific skills, and moderate motivation — think a competent attacker who understands industrial protocols and has done some reconnaissance. This is the level most MES-connected controllers in regulated or critical-infrastructure-adjacent industries should be targeting.
- SL-4 assumes sophisticated means, extended resources, control-system-specific skills, and high motivation — nation-state or organized-crime-grade adversaries. Very few commercial manufacturing cells legitimately need SL-4 across the board, and vendors who claim it blanket-wide across an entire product line without zone-specific justification should raise your eyebrows, not your confidence.
The critical point most RFPs miss: SL is assigned per zone and per requirement, not per product. A PLC can be capable of SL-3 for access control (SR 1) while only achieving SL-1 for resource availability (SR 7) because it has no rate-limiting on network requests. A vendor claiming “our device is SL-3” without specifying against which of the seven requirement families is telling you almost nothing.
The seven foundational requirements, translated out of standard-speak
SR 1 through SR 7 are the backbone of 3-3, and here’s what they actually ask of a device or system sitting on your floor:
- SR 1 — Identification and authentication control. Can the device tell individual users and devices apart, or is it one shared operator login for the whole shift? Shared HMI credentials are the single most common failure here.
- SR 2 — Use control. Once authenticated, does the system enforce what that user or role is actually allowed to do? A maintenance tech account that can also push firmware changes to safety logic fails this.
- SR 3 — System integrity. Can you detect if firmware, configuration, or communications have been tampered with? This is where code signing and configuration checksums live.
- SR 4 — Data confidentiality. Is data at rest and in transit protected against unauthorized disclosure — recipe data, process parameters, anything with IP value?
- SR 5 — Restricted data flow. Does the architecture enforce zone and conduit segmentation, or can traffic hop freely between the controller network and the MES layer?
- SR 6 — Timely response to events. Does the device generate usable logs and alerts, or is a security event invisible until something breaks?
- SR 7 — Resource availability. Does the device degrade gracefully under load or attack, or does a flood of malformed packets take the PLC offline? This is the one that ties most directly to safety and uptime, and it’s the one legacy devices fail most often.
Mapping your existing stack without hiring a consultant
You don’t need a formal assessment firm to get a useful first pass. Pull your current PLC, HMI, and MES-connected gateway inventory and score each device, honestly, against each SR on a simple scale: not met, partially met, met at SL-1, met at SL-2, met at SL-3. You’ll find most brownfield PLCs cluster at SL-1 on SR 1 and SR 2 (basic or no access control), often fail SR 5 outright because there’s no real network segmentation between the cell and the plant network, and fail SR 7 because nobody has stress-tested the controller’s network stack. That’s not a failure of your engineering — it’s the honest state of most fielded OT equipment, and naming it precisely is what lets you prioritize remediation instead of guessing.
The output of this exercise is a gap list, zone by zone, that becomes your real requirement — not “we want 62443,” but “this zone needs SL-2 on SR 1 through SR 4, and here’s what’s missing.”
Writing RFP language that actually filters vendors
Most RFP language today says something like “vendor products shall conform to IEC 62443-3-3.” That sentence filters nothing — nearly every OT vendor will check that box, because there’s no specificity to fail against. Better language does three things.
First, name the target Security Level per requirement family, not a single blanket number: “Device shall demonstrate SL-2 conformance for SR 1, SR 2, and SR 5 as defined in IEC 62443-3-3, with documented evidence.” Second, ask for evidence, not assertion — request the vendor’s actual capability documentation mapped against SR 1 through SR 7, or a third-party certification report if one exists, rather than accepting a sales engineer’s verbal confirmation. Third, ask a disqualifying question directly: “Provide the specific SL achieved for each of the seven foundational requirements, and identify which requirements are not met.” A vendor who can answer that in writing, requirement by requirement, has clearly done the work. A vendor who responds with a general statement that their product “is built to IEC 62443 standards” without a breakdown almost certainly hasn’t.
That single question — SR by SR, not a yes/no — is the whole trick. It costs you nothing to ask and it’s nearly impossible for a vendor to fake convincingly without either doing real engineering work or getting caught in the follow-up conversation.
What this means for your next purchase
If you’re specifying a new controller, HMI, or MES edge gateway in the next procurement cycle, assume the SL/SR conversation is coming whether your purchasing team knows to have it or not. Do the gap-mapping exercise on your current stack first — it costs you an afternoon, not a consulting engagement — and use it to write SR-specific language instead of citing the standard’s name and hoping. The vendors who’ve actually engineered to 62443-3-3 will welcome the specificity. The ones who haven’t will hand you a datasheet with the standard’s name printed on it and nothing underneath. Learning to tell those two apart is now, functionally, part of the job.
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.
