IEC 62443 gap analysis: the OT exposures that compliance reviews do not reach
Julian ThorneApril 29, 2026
Key takeaways
IEC 62443 gap analysis that relies on documentation review and interviews will confirm that zones are defined — it will not confirm that zone boundaries hold. In Vulnox OT assessments, flat network access from IT-side endpoints into defined OT zones was present in the majority of engagements where network segmentation was documented as implemented.
Security level targets in IEC 62443 are assigned during gap analysis and rarely retested. The distance between SL-T (target) and SL-A (achieved) is the actual exposure — and most organizations do not measure it after the initial assignment.
IEC 62443-3-3 (system security requirements) is where the gap between documented compliance and operational security is widest: FR 1 (Identification and Authentication) and FR 3 (System Integrity) are the foundational requirements most frequently documented as satisfied and most frequently failing technical validation in production environments.
The zone and conduit model creates a useful framework for gap analysis but produces a specific failure mode: organizations map zones based on current network topology rather than threat-based functional groupings, which means the zones are accurate and the security boundaries are wrong.
A logistics company running OT equipment on a flat network that shares a VLAN with corporate endpoints is structurally positioned for an IT-to-OT lateral movement event — the zone documentation will not show this because the zone was defined around the equipment, not around the network path to it.
Prediction: IEC 62443 certification bodies will begin requiring evidence of SL-A validation through technical testing rather than documentation review within 24 months, driven by the pattern of SL-T to SL-A divergence that assessors are observing across industrial sectors.
TL;DR
IEC 62443 is the right framework for ICS and OT security. The gap analysis process it supports is where organizations consistently produce documents that satisfy an auditor and do not represent the environment. Zone boundaries that exist on diagrams but not in network configurations. Security levels assigned to match business risk appetite rather than measured against actual attacker capability. This article is about the distance between those two states and what it takes to close it.
The zone that existed on paper
A mid-sized manufacturing operation in Central Europe completes an IEC 62443 gap analysis as part of a cybersecurity insurance renewal requirement. The analysis documents their OT network in three zones: a control zone with PLCs and HMIs, an operations zone with SCADA servers, and a demilitarized zone handling IT-OT data exchange. Zone boundaries are defined, conduit controls are documented, and the security level targets are assigned at SL2 for the control zone and SL1 for peripheral systems. The gap analysis report is clean. The insurer is satisfied.
Six months later, during a Vulnox external attack surface and segmentation assessment, a researcher establishes a network session from a corporate Windows endpoint — on the same flat Layer 2 segment as the operations zone SCADA servers — and reaches a PLC directly. The zone boundary existed in the IEC 62443 documentation. It did not exist in the network.
The zone and conduit model works by defining security boundaries and then enforcing them with controls. The gap analysis had documented the zones. It had not tested whether the controls enforcing the conduit boundaries were actually in place. That is the structural gap in how most IEC 62443 assessments are conducted — and it is the gap that determines whether the compliance posture reflects reality or describes an intention.
Why OT gap analysis produces clean reports and porous environments
IEC 62443 is organized into four parts: general concepts and terminology (Part 1), policies and procedures for asset owners and integrators (Part 2), system-level technical requirements (Part 3), and component-level requirements for products (Part 4). A gap analysis typically focuses on Parts 2 and 3 — the organizational and system requirements where most compliance questions are answered.
Part 3-3 defines the foundational requirements (FRs) for system security: identification and authentication (FR 1), use control (FR 2), system integrity (FR 3), data confidentiality (FR 4), restricted data flow (FR 5), timely response to events (FR 6), and resource availability (FR 7). Each FR is addressed at security capability levels (SL 1-4), with SL corresponding to the attacker capability the control is meant to resist.
The assessment methodology most commonly used for IEC 62443 gap analysis mirrors what gets used in IT compliance: interview the system owner, review the documentation, check that zone diagrams exist and conduit controls are described. If the documentation says FR 5 (restricted data flow) is implemented through the zone and conduit model, and the zone diagram shows defined boundaries, that control is marked as meeting its target security level.
What this methodology does not do is test whether the conduit controls enforce the boundaries described in the diagram. Network segmentation can be documented without being implemented. A firewall rule set that has not been validated can contain permit-any entries that contradict the zone model entirely. A VLAN configuration that was set up for IT traffic can have been extended into the OT zone at some point by a network administrator who did not understand the security implications.
OT environments make this worse in a specific way. Change management in industrial settings is constrained by availability requirements — you cannot take a production line offline to test firewall rules. So the firewall gets configured, the documentation gets written, and the test that would validate the configuration does not happen until an assessor asks for evidence. By then, the configuration may have drifted from what was originally intended.
Example
In a Vulnox engagement with a water treatment facility, the IEC 62443 gap analysis documentation showed FR 5 as fully implemented across all zones. The conduit between the corporate network and the control zone was documented as passing through a firewall with a defined rule set. Technical review of the firewall configuration showed that a rule added during a maintenance window 14 months earlier permitted all traffic from a specific IT subnet — a subnet that had since been expanded to include 40 additional endpoints — to the control zone on port 102 (S7 protocol). The zone boundary was in the documentation. The conduit control was not enforcing it.
The foundational requirements most frequently failing technical validation in Vulnox OT assessments: FR 1 (Identification and Authentication) — default credentials on PLCs and HMIs that passed documentation review because password policies existed; FR 3 (System Integrity) — firmware versions below vendor security patch level on field devices not captured in asset inventories; FR 5 (Restricted Data Flow) — firewall rule drift on conduit enforcement points, as described above. These are the three FRs where the documented security capability level and the tested capability level diverge most consistently.
What the assessment data shows about IEC 62443 compliance posture
Flat IT-to-OT access
In the majority of Vulnox OT segmentation assessments where organizations had completed an IEC 62443 gap analysis and documented zone boundaries as implemented, technical validation found direct Layer 2 or Layer 3 access from IT-side endpoints to at least one OT zone asset. The zone documentation was accurate. The network enforcement was not. (Vulnox assessment data, 2024-2025)
Default credentials
In every Vulnox engagement involving PLC and HMI asset review against IEC 62443 FR 1 requirements, at least one device was found running vendor default credentials. In most cases, the device appeared in the asset inventory and the gap analysis had documented FR 1 as implemented for the zone containing it. The password policy existed. It had not been applied to that device. (Vulnox assessment data, 2024-2025)
SL-T to SL-A divergence
IEC 62443 distinguishes between the target security level (SL-T, what the organization decides it needs) and the achieved security level (SL-A, what technical testing shows is actually in place). Most gap analyses document SL-T. Fewer measure SL-A. In Vulnox assessments where both were evaluated, SL-A was below SL-T for the control zone in every engagement — not by one level, typically, but by enough that the gap had operational consequences.
What OT assessments found that documentation review did not
Assessment base: Vulnox OT and ICS assessments, 2024-2025, across manufacturing, water treatment, and energy sector environments in Europe and Southeast Asia.
Zone boundaries documented, conduit enforcement absent
The zone and conduit model defines security zones and specifies that communication between zones passes through controlled conduits with defined protections. In IEC 62443 gap analyses, zone boundary documentation is the deliverable that gets reviewed — the diagram, the zone descriptions, the conduit control specifications. What gets reviewed less frequently is whether the firewall or network device enforcing each conduit boundary is actually configured to match the specification. In Vulnox OT assessments, the gap between conduit specification and conduit enforcement was present in the majority of engagements. The most common cause: firewall rule drift, where administrative changes added permit rules that contradicted the zone model without updating the IEC 62443 documentation.
An attacker who has compromised any IT endpoint in the organization and who understands that OT network boundaries are documented but unenforced has a predictable lateral movement path. The IEC 62443 gap analysis report will show the zone and conduit model as implemented. The network will not enforce it.
Security level targets assigned to match business risk tolerance, not attacker capability
IEC 62443 security levels are defined in terms of attacker capability: SL 1 protects against inadvertent or coincidental threats, SL 2 against intentional simple-means attackers, SL 3 against sophisticated-means attackers with moderate resources, SL 4 against state-level actors with extended resources. In practice, security level assignments in gap analyses are often driven by what the organization believes it can implement within budget and operational constraints, not by what attacker capability the system actually faces. A manufacturing operation targeted by ransomware groups — which qualify as SL 2 to SL 3 threat actors — may assign SL 1 targets to systems that process production data because SL 2 controls are more disruptive to implement.
The gap analysis confirms that the organization meets its security level targets. The security level targets do not match the actual threat. The compliance posture is clean. The risk posture has not been evaluated. This is the most common structural problem in IEC 62443 assessments that Vulnox encounters: the framework is applied correctly, but the inputs to the framework are optimistic.
Asset inventories that excluded field devices from IEC 62443 scope
IEC 62443-3-3 applies to systems. IEC 62443-4-2 applies to components — individual devices. Most gap analyses focus on the system level (Part 3-3) because that is where the zone and conduit model lives and where most compliance questions are answered. Field devices — PLCs, RTUs, sensors, actuators — often receive a documentation note that they are covered by the zone they belong to rather than individual assessment. In multiple Vulnox engagements, field devices that were in scope for the zone were running firmware versions with published CVEs and had not been patched because the asset inventory did not track individual device firmware versions.
A device-level vulnerability in a PLC running in a zone documented as SL 2 is an SL 2 vulnerability that the SL 2 assessment did not find. The zone compliance posture and the device vulnerability exist simultaneously. The gap analysis addressed one and not the other.
The zone and conduit model creates a specific failure mode it was designed to prevent
Common belief
The zone and conduit model reduces exposure by creating clearly defined security boundaries. Organizations that have implemented zone segmentation have reduced their lateral movement risk.
What we found
In post-gap-analysis assessments — organizations assessed 12-18 months after completing an IEC 62443 gap analysis — zone boundary violations introduced through operational changes were present in every engagement. None of those changes had been reviewed against the IEC 62443 zone documentation before implementation.
The model does reduce exposure when the boundaries are enforced. The specific failure mode it creates is a false confidence effect: once zones are defined and documented, the compliance question about network segmentation is answered. The ongoing question — whether the enforcement mechanisms are still configured correctly — stops being asked with the same regularity.
IT environments manage firewall rule drift through change management processes, rule review cycles, and automated configuration management tools. OT environments have fewer of these mechanisms in place. Change management in OT is driven by operational continuity requirements, not security requirements. A network change that keeps a production line running gets approved and documented in the operational change log. It may not trigger a review of whether the change is consistent with the IEC 62443 zone documentation.
The zone diagram becomes the authoritative reference for zone boundaries. The network configuration becomes the thing that drifts away from the zone diagram. And the IEC 62443 gap analysis validates the zone diagram, not the network configuration.
This failure mode is not a criticism of the zone and conduit model. It is a description of what happens when a structural security control is treated as a documentation artifact rather than an operational state that needs continuous validation.
What industrial organizations said, and what was underneath it
''We completed an IEC 62443 gap analysis two years ago and addressed all the findings. Our zone model is current.''
Root cause:The gap analysis addressed the findings that existed two years ago. The zone model reflected the network architecture two years ago. Twenty-three network changes had been made since the gap analysis — documented in operational change records, not reviewed against the IEC 62443 zone documentation. Four of those changes had introduced conduit boundary violations. The zone model was current as of the gap analysis date. The network had moved on.
''Our security level targets are appropriate for our threat profile. We''re a parts manufacturer, not critical infrastructure.''
Root cause:The organization had been targeted by a ransomware group 18 months earlier (the incident was contained before encryption). The ransomware group''s TTPs matched SL 2 to SL 3 threat actor characteristics — intentional, targeted, using commodity tools adapted for the environment. The security level targets were SL 1 across the majority of the OT network. The threat profile assessment had not been updated after the incident. The gap analysis confirmed conformance to the SL 1 targets. The SL 1 targets did not match the demonstrated threat.
''Our PLCs and field devices are covered by the zone assessments. We don''t need to assess them individually.''
Root cause:IEC 62443-4-2 (component requirements) and IEC 62443-3-3 (system requirements) address different security objectives. Zone-level assessment does not capture device-level vulnerabilities — firmware versions, hardcoded credentials, protocol-level weaknesses in Modbus or DNP3 implementations. Three PLCs in the assessed zone were running firmware versions with published CVEs. The zone met its documented security level. The devices in the zone did not.
IEC 62443 alongside other OT and IT security frameworks
IEC 62443
OT-native. Designed specifically for industrial control systems, with security levels calibrated to attacker capability and operational constraints built into the framework. The zone and conduit model provides a segmentation methodology that accounts for OT availability requirements. Coverage spans asset owner obligations (Part 2), system requirements (Part 3), and component requirements (Part 4). The framework explicitly addresses the IT-OT boundary problem that general IT frameworks treat as an edge case.
The right framework for ICS and OT environments. The gap analysis process it supports is where the execution risk concentrates: organizations that apply IEC 62443 as a documentation exercise rather than an operational assessment will produce clean compliance postures and unvalidated security boundaries.
NIST SP 800-82 (Guide to ICS Security)
US government guidance rather than an international standard. More prescriptive in some areas — specific configuration guidance for OT protocols, detailed network architecture recommendations — and less structured in others. Does not have the security level framework that IEC 62443 uses to calibrate controls to attacker capability. Federal agencies and US defense contractors tend to reference 800-82; international industrial organizations tend to reference IEC 62443. The two frameworks are complementary rather than competing.
Organizations operating in US federal or defense supply chains will encounter 800-82 requirements. The gap analysis methodology translates between them reasonably well. The key difference is that IEC 62443''s security level structure provides a more systematic way to map controls to threat scenarios — 800-82 provides the implementation detail that IEC 62443 sometimes lacks.
NIST CSF (Cybersecurity Framework)
Designed for general use across IT and OT. The Identify-Protect-Detect-Respond-Recover structure maps well to ICS environments at the organizational level but does not address OT-specific constraints: availability-first security priorities, proprietary industrial protocols, legacy device limitations. Organizations using CSF as their primary framework for OT environments will have governance coverage and control gaps at the technical level — particularly around protocol-specific controls and zone enforcement.
CSF is useful for organizational-level OT governance and for aligning OT security programs with IT security governance structures. It does not substitute for IEC 62443 gap analysis at the system and component level. Organizations that report CSF compliance for OT environments without IEC 62443 assessment have answered the organizational question and left the technical question open.
What most IEC 62443 gap analyses are not examining
Remote access paths introduced outside change management
OT remote access for vendor maintenance and remote monitoring is the most common IT-to-OT entry point in incident investigations. The IEC 62443 gap analysis documents the approved remote access conduit. It typically does not enumerate all the remote access paths that exist — including vendor-installed remote access software, cellular modems added to PLCs for diagnostic access, and IT remote desktop tools left running on OT-adjacent systems. These paths exist outside the zone and conduit model because they were not in the model when it was created.
Firmware vulnerability coverage at the device level
IEC 62443-4-2 component requirements address device-level security. Most gap analyses focus on system-level requirements (Part 3-3) and treat field devices as members of zones rather than subjects of individual assessment. Firmware versions on PLCs, RTUs, and smart sensors are rarely inventoried with the granularity needed to identify published CVEs. The device is in the zone. The zone meets its security level target. The device firmware has a known remote code execution vulnerability.
Protocol-level weaknesses not captured in zone documentation
Industrial protocols — Modbus, DNP3, EtherNet/IP, Profinet — have well-documented security weaknesses: lack of authentication, cleartext transmission, no session management. IEC 62443 zone documentation captures that these protocols are in use. It does not typically document the specific weaknesses of each protocol or the compensating controls needed to address them. An FR 5 (restricted data flow) implementation that filters at IP level but permits unauthenticated Modbus commands within the zone has met the conduit specification and left a significant exploitation surface open.
Supply chain and vendor access to OT components
Vendor access to OT environments — for maintenance, updates, and remote diagnostics — introduces supply chain risk that IEC 62443 addresses in Part 2 but that most gap analyses treat at a policy level. The technical question — what access does Vendor X actually have to Zone Y, through what mechanism, with what logging — is rarely answered with evidence in OT gap analysis deliverables. The policy says vendor access is controlled. The technical reality of how it is controlled, and whether that control is currently enforced, is a separate question.
Where IEC 62443 gap analysis is heading
IEC 62443 certification bodies will begin requiring technical evidence of SL-A validation — measured security level achieved, not just targeted — for at least the control zone within 24 months, driven by a pattern of SL-T to SL-A divergence that assessors and insurers are both observing.
Cyber insurance underwriters have been increasing their scrutiny of OT security posture claims following a series of manufacturing sector ransomware incidents where IEC 62443 gap analyses had documented compliant security postures. The underwriter community is beginning to distinguish between documented compliance and tested compliance in how they price OT risk. Certification bodies face the same pressure from the same incidents. The shift from ''document your security level targets'' to ''demonstrate your achieved security levels'' is already happening informally in how sophisticated assessors conduct engagements. Formal requirement from certification bodies is the structural next step. The observable signal is a revision to IEC 62443-2-1 or -3-2 assessment methodology guidance requiring technical testing evidence for SL-A determination.
Confidence: highNo IEC 62443 certification body publishes SL-A technical validation requirements within 24 months of publication.Ransomware groups will develop OT-specific lateral movement tooling that exploits the documented-but-unenforced zone boundary pattern, moving from IT to OT environments through conduit violations that IEC 62443 compliance documentation obscures rather than prevents, within 18 months.
The IT-to-OT lateral movement capability exists today in sophisticated threat actor toolkits. What has not been operationalized at scale is the automation of zone boundary enumeration and exploitation — identifying which documented conduit controls are actually enforced and which are paper boundaries. The reconnaissance pattern is straightforward: identify the OT network presence, identify the zone documentation (often accessible on corporate file shares), map the documented boundaries against the actual network configuration, and exploit the delta. The technical barrier to this is low. The observed gap between documented and enforced zone boundaries is consistent enough that it constitutes a reliable exploitation target. The observable signal is the first public incident report attributing OT compromise to deliberate exploitation of a gap between IEC 62443 zone documentation and network enforcement.
Confidence: mediumNo public incident report attributes OT compromise to zone boundary documentation-enforcement gaps within 18 months.
What IEC 62443 gap analysis needs to be
The standard itself is sound. The zone and conduit model is the right conceptual framework for OT security segmentation. The security level structure gives organizations a coherent way to calibrate controls to threat scenarios. The problem is not IEC 62443. The problem is that the gap analysis process most organizations use to assess conformance against it stops at documentation.
A gap analysis that tests whether zone boundaries hold — actually runs traffic across documented conduit boundaries, validates firewall rule sets against zone specifications, enumerates remote access paths against the documented conduit model — takes longer and produces findings that are harder to close than a documentation review. It also produces a compliance posture that reflects the actual environment rather than the intended one.
The industrial organizations that have the most at stake in this are not the ones that will be targeted by sophisticated threat actors. They are the mid-sized manufacturers and utilities whose OT environments are targeted by ransomware groups operating at SL 2 to SL 3 capability — attacker profiles that the IEC 62443 security level framework was specifically designed to address, and that documented-but-untested zone boundaries do not actually defend against.
The gap between a clean IEC 62443 gap analysis report and a defended OT environment is a technical validation gap. It is closable. It requires treating the zone and conduit model as an operational state that needs testing, not as a compliance artifact that needs documentation.
Counterargument
The counterargument is that OT environments have legitimate constraints that make technical validation difficult. Taking a production line offline to test firewall rules is not a neutral cost. The availability requirements that define OT security trade-offs are real, and a gap analysis methodology that ignores them produces findings that cannot be implemented without operational disruption. Documentation-based gap analysis is a rational accommodation to those constraints. This is a valid argument. What it does not change is that an untested conduit boundary is not a functioning conduit boundary — it is a documented intention. Organizations that accept the constraint should at least name it accurately.
The test worth running before the next gap analysis closes
Before the current IEC 62443 gap analysis cycle closes, run one technical check on each documented conduit boundary: enumerate the actual firewall rules enforcing the boundary and compare them against the conduit specification in the zone documentation.
This does not require taking anything offline. It requires reviewing a configuration file against a document. If the rules match the specification, the conduit boundary is enforced as documented. If they do not match — and in most OT environments, at least one conduit will show drift — you have found the category of gap that determines whether the zone model reflects the network or just describes an intention about it.
The IEC 62443 gap analysis will be more useful if it answers that question than if it confirms that the zone diagram exists.
Further Reading
Gap Analysis
IEC 62443 gap analysisnetwork security
network security strategiesNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideOWASP Web Security Testing Guide
OWASP security testing guideNational Vulnerability Database Home
National Vulnerability Database
Frequently Asked Questions
What does an IEC 62443 gap analysis actually validate about OT security?
Most IEC 62443 gap analyses validate that zones are defined, security level targets are assigned, and conduit controls are documented. They typically do not test whether conduit boundaries hold under technical validation. In Vulnox OT assessments, direct access from IT-side endpoints into documented OT zones was found in the majority of engagements where zone segmentation was marked as implemented in gap analysis documentation.
What is the difference between SL-T and SL-A in IEC 62443?
SL-T (target security level) is what the organization decides it needs to achieve based on risk assessment. SL-A (achieved security level) is the security level demonstrated through technical testing. Most IEC 62443 gap analyses document SL-T. Fewer measure SL-A. In Vulnox assessments where both were evaluated, SL-A was below SL-T for the control zone in every engagement — meaning the compliance documentation described a security posture that technical testing did not confirm.
What is the most common failure in IEC 62443 zone and conduit model implementation?
Conduit enforcement drift: firewall and network configurations that were correct at the time the zone documentation was written and have since diverged through operational changes. IEC 62443 gap analysis validates the zone documentation. It does not continuously validate whether network configurations still enforce the boundaries the documentation describes. Administrative changes made to keep production running frequently introduce permit rules that contradict the zone model.
How does IEC 62443 compare to NIST SP 800-82 for OT security gap analysis?
IEC 62443 is an international standard with a structured security level framework that calibrates controls to attacker capability — more systematic for mapping controls to threat scenarios. NIST 800-82 is US government guidance with more prescriptive configuration detail for specific OT protocols and architectures. The two are complementary: IEC 62443 provides the framework structure; 800-82 provides implementation specifics. US federal and defense contractors typically encounter 800-82 requirements; international industrial organizations typically reference IEC 62443.
Why do IEC 62443 security level targets often not match actual attacker capability?
Security level targets are assigned during gap analysis based on what the organization believes it can implement within budget and operational constraints, not always based on rigorous threat actor profiling. Ransomware groups targeting manufacturers typically operate at SL 2 to SL 3 attacker capability — intentional, targeted, using adapted commodity tools. Organizations that assign SL 1 targets because SL 2 controls are operationally disruptive have produced compliant documentation against a threat model that does not match the actual threat.
What OT device-level gaps does IEC 62443 Part 3-3 zone assessment miss?
IEC 62443-3-3 system requirements and Part 4-2 component requirements address different security objectives. Zone-level assessment covers system security requirements but does not substitute for device-level assessment of PLCs, RTUs, and field devices. Firmware versions with published CVEs, vendor default credentials, and protocol-level weaknesses in Modbus or DNP3 implementations are device-level issues that zone compliance documentation does not capture.
What should an OT organization do immediately after completing an IEC 62443 gap analysis?
Review the actual firewall rule sets enforcing each documented conduit boundary and compare them against the conduit specifications in the gap analysis documentation. This does not require taking anything offline. If the rules do not match the specifications — a common finding — the gap analysis has confirmed compliance against a zone model that the network does not enforce. That is the finding the gap analysis missed and the one that determines whether the zone model is operational or documentary.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.