For years, the ritual after a CISA ICS advisory dropped was predictable. Someone in plant IT pulls the affected CVE list, cross-references it against the asset inventory, and reports back on patch status. Insurers asked similar questions at renewal: what’s your patch cadence, do you have EDR on the OT network, when did you last update firmware on that PLC line. That ritual is breaking down, and it’s breaking down on purpose.
The critical manufacturing sector advisories coming out of CISA have been leaning harder on IEC 62443 language — zones, conduits, security levels target versus achieved (SL-T/SL-A) — as the framework for describing exposure and mitigation, rather than treating a CVE match as the whole story. Insurers writing OT/ICS cyber policies have followed the same path, because a patch list tells you almost nothing about how far an exploited device can actually reach. A zone and conduit model tells you that. If your plant’s compliance posture is still organized around patch tickets, you have a real gap to close before the 2026 renewal and audit cycle, not a theoretical one.
Why the patch list stopped being enough
A patch list answers “is this vulnerability present.” It says nothing about “what can this vulnerability reach if it’s exploited before you patch it” — and in OT, you often can’t patch on the vendor’s timeline anyway, because the PLC or HMI is running a validated process and taking it offline means a shutdown, not a maintenance window. IEC 62443’s zone and conduit model exists precisely because the standard’s authors assumed unpatched, long-lived assets are the normal case in industrial environments, not the exception.
A zone is a grouping of assets that share a security requirement — think a specific production cell, a safety system, a historian segment. A conduit is the communication path between zones, and it’s the conduit, not the zone, where you actually enforce control: firewall rules, unidirectional gateways, protocol breaks, jump hosts. SL-T is the security level you’ve decided a zone needs based on consequence of compromise; SL-A is what you can actually demonstrate the zone achieves today. The gap between SL-T and SL-A is, in plain language, your risk exposure — and it’s exactly the number CISA advisories and insurers now want you to be able to produce on request.
What actually changes operationally
When an advisory names a CVE affecting a controller or protocol you run, the old response was “are we patched.” The new response has two parts: are we patched or otherwise mitigated, and can we show which zone the affected asset sits in, what conduits touch that zone, and whether those conduits enforce controls consistent with the zone’s SL-T. That second part is the one most plants can’t currently answer without a scramble, because the information exists — scattered across network diagrams, firewall configs, and a controls engineer’s institutional memory — but it’s never been assembled into something you can hand to an auditor or an incident response team.
Cyber insurance renewal is following the same logic. Underwriters increasingly want evidence of segmentation architecture and documented security levels as a condition of coverage terms, not just a checkbox for “do you have a firewall between IT and OT.” A plant that can produce a conduit register with SL-T/SL-A gaps identified is a materially easier underwriting conversation than one that can only describe its network verbally.
The gap that gets plants in trouble
The most common failure mode isn’t lack of segmentation — most mature plants have some. It’s the absence of a living document that maps assets to zones to conduits to the controls actually enforced at each conduit. Network diagrams show topology. They don’t show security intent. A firewall diagram tells you two subnets are separated; it doesn’t tell you what security level that separation was designed to achieve, or whether it still achieves it after six firmware updates and two vendor remote-access requests since the diagram was drawn.
Building a conduit register from what you already have
You don’t need a green-field IEC 62443 assessment to start. Most plants already have the raw material — it’s just never been organized around zones and conduits as the unit of analysis. A practical build-out looks like this:
- Start from your existing network diagram, not a blank page. Every VLAN, subnet, or logically separated segment on that diagram is a zone candidate. Group by process function and consequence of compromise — a safety PLC segment and a plant-floor printer segment should never be the same zone even if they’re on the same switch today.
- Name every conduit explicitly. Any firewall rule, VPN tunnel, data diode, or router ACL that lets traffic cross a zone boundary is a conduit. List it with source zone, destination zone, protocol, and the specific control enforced (stateful firewall rule, unidirectional gateway, application allow-list — be specific, not “firewall”).
- Assign SL-T per zone based on consequence, not aspiration. A zone containing a batch control system that could cause a safety event if compromised gets a higher SL-T than a zone holding a production dashboard. Don’t inflate targets to look rigorous — inflated SL-T with no SL-A evidence is worse than a modest target you can actually prove.
- Assess SL-A honestly against each conduit’s actual enforcement. If the “firewall” between zones is a flat rule allowing any-to-any on a commonly used port because someone needed it working during a commissioning rush, your SL-A on that conduit is low regardless of what the diagram implies.
- Tie the register to change management. Every time a vendor gets temporary remote access, a new device gets added to a cell, or a firewall rule changes, the register needs an owner who updates it. A register that’s accurate on the day it’s created and stale six months later is not evidence — it’s a liability, because it demonstrates you knew the framework and stopped maintaining it.
None of this requires new tooling. A structured spreadsheet or a lightweight table in your CMMS/EAM system is enough to start, and honestly enough to survive most audits — the standard doesn’t mandate a specific software platform, it mandates that you can demonstrate the analysis was done and is current.
What to do before the next advisory lands
The plants that will handle the 2026 cycle calmly are the ones treating the conduit register as a living artifact now, not a project to start after the next advisory names a CVE in their control system. Pick your highest-consequence production cells first — the ones where a compromise would mean a safety incident or an extended outage — and get zones, conduits, and SL-T/SL-A gaps documented there before you touch the lower-stakes segments. When the advisory comes in asking not just “are you patched” but “show me the zone this sits in and what’s between it and everything else,” you want an answer that already exists, not one you’re building overnight for an auditor or an underwriter who’s already asking the question a different way than your last renewal cycle.
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.
