For the last few years, IEC 62443-4-1 has done most of the heavy lifting in vendor conversations. It’s a process certification — it tells you a vendor has a secure development lifecycle, and RFP writers have gotten comfortable asking for the certificate number and moving on. That’s a reasonably clean ask. The vendor either has it or doesn’t, and a third-party auditor already checked the paperwork.
IEC 62443-3-3 is a different animal, and the industry is only now catching up to how different. It’s a system-level standard, which means the obligation doesn’t sit with a vendor — it sits with whoever architected and integrated the plant network. There’s no certificate to wave around. There’s a target security level (SL-T) you assigned to a zone, and there’s an achieved security level (SL-A) that reflects what the deployed system actually does. Those two numbers are supposed to match. In a lot of plants, they don’t, and until recently nobody was checking closely enough to notice.
Why this is surfacing in mid-2026 renewal cycles specifically
Cyber-insurance underwriters and corporate audit teams have started asking a more pointed question than they used to. Instead of “do you follow IEC 62443,” they’re asking which SL each zone in your architecture actually achieves, and what evidence supports that claim. That’s a meaningful escalation. A standard citation is a compliance posture. A per-zone SL-A claim backed by evidence is an engineering claim, and engineering claims get tested.
This tracks with a broader pattern in OT risk underwriting: insurers have been burned often enough by paper-compliant plants that got compromised through a segmentation gap nobody had actually validated. Corporate audit functions are following the same logic. If your architecture review binder cites 62443-3-3 but nobody can produce firewall rule exports, port lists, or account inventories that support the claimed level, that binder is now a liability rather than an asset in the conversation.
Where the SL-T to SL-A gap actually opens up
SL-T is a design decision. You look at a zone — say, the cell/area zone running your line PLCs and HMIs — and you decide it needs to resist, for example, an SL 2 threat actor: someone with moderate resources, low motivation, IEC 62443-specific tools. That’s a judgment call based on consequence of compromise, and it’s usually defensible on paper.
SL-A is what you can prove the deployed system resists, evaluated against the seven foundational requirements in -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 capability levels within it, and your zone’s SL-A is effectively the weakest link across all seven — not the average, not the best one you happened to nail.
That last part is where most plants overclaim. It’s common to find a zone with strong network segmentation and a well-configured firewall (good marks on restricted data flow, FR 5) sitting next to shared local administrator credentials across every HMI in the cell (a failure on identification and authentication control, FR 1). The zone gets labeled SL 2 in the architecture document because the network design looks like SL 2. The achieved level, honestly assessed, is SL 1 — because an attacker doesn’t need to beat your firewall if every operator workstation logs in with the same password that’s been unchanged since commissioning.
The other common overclaim is conduit-level, not zone-level. Teams document zones carefully and then wave at the conduits between them — the historian pull from the process control network, the remote access path for the integrator’s support contract, the wireless link to a mobile HMI. Conduits carry their own SL-T and need their own evidence. A zone with a genuinely strong internal posture can still fail an audit because the conduit connecting it to the level 3 network has no compensating controls at all.
Common failure points worth checking before an auditor finds them
- Shared or vendor-default credentials on HMIs, engineering workstations, or remote access jump boxes — an automatic ceiling on FR 1 regardless of network design.
- Flat conduits between zones assigned different SL-Ts, where a single VLAN or unmanaged switch does the work a properly configured firewall with restricted rule sets should be doing.
- Remote access paths added after the original architecture review — integrator VPNs, cellular gateways for OEM support — that were never re-evaluated against the zone’s SL-T.
- Patch and account drift since commissioning: the SL-A assessment reflects day-one configuration, but nobody has re-verified it against current firmware versions or the current user account list.
- Logging that exists but isn’t monitored, which fails FR 6 (timely response to events) even when the technical capability to log is present.
A practical reconciliation worksheet
When an insurer or auditor questionnaire lands, resist the urge to answer it from the architecture diagram. Work zone by zone instead, and for each one, build a simple table with three columns: the FR (1 through 7), the SL-T you assigned, and the actual evidence available today — not evidence that could exist, evidence that exists right now in a form you could hand to a third party.
For FR 1, that evidence is an account inventory: who has access, whether accounts are individual or shared, whether multi-factor authentication applies to remote paths. For FR 5, it’s the actual firewall rule export and a description of what’s allowed between this zone and its neighbors, not just an arrow on a diagram. For FR 6, it’s proof that logs generated actually reach a monitoring capability someone looks at, not just that a syslog server is technically running.
Once that table exists per zone, the SL-A becomes obvious and honest: it’s the lowest capability level you can actually document across the seven FRs. Where that number is lower than the SL-T you originally assigned, you have two options, and pretending isn’t one of them. Either invest in closing the specific gap — often the cheapest fixes are identity and account hygiene, not new hardware — or formally revise the SL-T downward and document the accepted risk with sign-off from whoever owns that risk decision. Auditors and underwriters both respond far better to a documented, honest SL 1 with a remediation plan than to an undocumented, aspirational SL 3 that collapses under five minutes of questioning.
What to do before the next renewal cycle, not during it
The plants that will struggle in mid-2026 audit cycles are the ones treating this as a document exercise to hand to a consultant right before renewal. The zone/conduit model and SL-T assignments from your original architecture review are the right starting point, but they age. Every network change, every new remote access path, every integrator contract that adds a jump box needs to trigger a re-look at whether the SL-A claim still holds.
Treat the FR-by-FR evidence table as a living artifact, not a one-time deliverable. It’s the difference between an audit that takes an afternoon because you can pull the evidence on request, and one that takes months because you’re reconstructing account inventories and firewall rules under deadline pressure while an underwriter waits on the other end of the questionnaire.
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.
