1. The System-Centric Blind Spot in IEC 62443
For almost two decades, both the IEC 62443 framework and the dominant analyst definitions—such as Gartner’s OT model—have shaped industrial cybersecurity around a system-centric architecture. This legacy has institutionalized a worldview where zones, conduits, and system roles dictate security design—combined with a focus on reducing attack surface and increasing attack distance. While these are valid security tactics, they reflect a perimeter mindset. This approach often ignores how control decisions propagate across layers and assumes that segmentation alone reduces process exposure—often divorced from the actual functional influence systems exert on the physical process.
But today’s environments are different. Process automation systems are no longer isolated, and security can no longer rely on static network boundaries or platform segregation. It’s time to question this model—and to reclaim a security approach that reflects how modern industrial systems actually operate.
This article is part practice, part analysis, part revolt: a call to move beyond system boundaries and rethink exposure from the ground up, using process-centric logic. Control proximity becomes the starting point for that shift.
The IEC 62443 framework was built around a system-centric worldview. It assumes that defining zones and conduits—and applying perimeter security—provides a sufficient foundation for cyber risk management in industrial automation systems. That might have been appropriate when control systems were isolated and static. But it doesn’t hold in today’s connected industrial environments.
Modern industrial architectures are no longer closed-loop systems protected by a handful of network barriers. We are operating in converged environments where diagnostic systems, business logic, cloud services, and optimization engines interact directly with traditional control layers. Many of these interactions bypass or blur zone boundaries, embedding implicit trust paths deep into the process.
The problem is not just that these perimeters are porous. More fundamentally, IEC 62443 lacks constructs to describe how control functions influence each other across layers and domains. Instead, it focuses on controlling access rather than evaluating operational influence.
Control proximity—the degree to which a function can directly or indirectly influence physical process behavior—is key to understanding risk in modern industrial systems. It captures what static system location or user role designation often miss: how a function actually affects safety, quality, or operability if compromised. Unlike system location or role designation, control proximity captures the real-world ability of a system to affect safety, quality, and operability.
Understanding exposure through control proximity shifts the conversation from infrastructure protection to operational consequence. In this context, the Controllability-Observability-Operability (COO) model is more suitable than the traditional CIA triad for cyber-physical risk, as it directly ties compromise to impact on process behavior.
2. Where IEC 62443 Falls Short in Converged Environments
While IEC 62443 offers a structured approach to cybersecurity in industrial systems, its foundation remains system-centric—tied to static boundaries, predefined roles, and isolated control logic. While IEC 62443 indeed revolves around zones and conduits for a foundational architecture, the broader set of documents (particularly IEC 62443-2-1 and 62443-3-2) encourage risk-based approaches that can be adapted to process-critical issues. However, the standard provides no explicit mechanisms for modeling functional influence, control proximity, or trust paths between systems. It does not prohibit process-centric techniques, but neither does it prescribe or formalize them in a way that ensures consistent implementation. As a result, many integrators default to interpreting the standard as a directive to “enforce perimeters.” Some more advanced implementers attempt nuanced adaptations—but these remain the exception, not the norm.
This creates significant blind spots in converged environments where IT, OT, and business functions interact fluidly across domains—where traditional perimeter definitions no longer align with functional influence and trust relationships.
IEC 62443-3-3: Gaps in Security Requirement Allocation
62443-3-3 defines security requirements for systems, but it does not explicitly incorporate the concept of control proximity or functional authority into its security level (SL) definitions. For example, while SL 3 and SL 4 demand increasing levels of resistance to sophisticated threats, they could be more effective if tailored to reflect how much process influence a function holds. A function with high control proximity—such as one capable of altering setpoints or actuator commands—may require SL 3 even if its network exposure is minimal.
Similarly, foundational requirements (FRs) such as FR1 (Identification and Authentication Control) and FR2 (Use Control) are already part of the model, focused on who is allowed to access or use a function. However, a more process-aware approach would extend FR4 (Information Flow Control), FR5 (Response to Events), and FR7 (Resource Availability) to address not only technical permissions but also functional authority—whether a system is contextually allowed to act based on its process role and the current state. This distinction matters: traditional security controls enforce access, while functional authority governs influence. A system might be permitted to send data or commands, but it should only be allowed to do so when it is process-relevant, safe, and appropriate to the operational context. This means verifying whether a function should influence the process in its current state, not just whether it has network or system access rights.
- It applies them based on architectural location—primarily defined by zones and conduits—not process impact.
- It does not require explicit differentiation between functions that only observe the process and those that can influence it.
- It lacks sensitivity to control proximity—how close a function is to actuating physical process changes.
Security levels are set by zone and conduit definitions, not by functional influence.
This reinforces the shortcomings of a system-centric approach, where static boundaries and architectural assumptions take precedence over dynamic process relationships and operational relevance. As a result, security priorities may be misaligned with actual process risk. A process-centric model would prioritize protections based on where in the control chain a function resides and how it affects process and safety dynamics.
IEC 62443-3-2: Gaps in Risk Identification
IEC 62443-3-2 defines a risk assessment process for industrial control systems, but it is rooted in a system-centric structure and oriented around architectural segmentation. While it offers a structured methodology, the process does not include analysis of functional influence, control proximity, or process-critical trust relationships. The risk assessment process in 62443-3-2 relies on asset identification, zone modeling, and threat scenario evaluation. However:
- It treats communication links (conduits) as technical paths, not functional relationships.
- It lacks mechanisms to map trust assumptions embedded across domains.
- It misses risk arising from convergence points and control influence from outside traditional OT zones.
- It does not account for dynamic, cross-layer control paths.
This results in risk models that reflect static network visibility but miss functional exposure. They offer clarity on where systems reside and how they are connected, but not on how process behavior can be influenced through those connections. A process-centric approach, where control proximity plays a central role, helps reveal these overlooked risks by examining how external functions interface with and affect process and safety dynamics—regardless of architectural segmentation. by tracing how external functions can affect process and safety dynamics—regardless of zone boundaries or system classifications.
3. From Technical Boundaries to Functional Exposure
Security in cyber-physical systems should be understood as a combination of three interrelated dimensions: exposure, robustness, and resilience. Exposure determines the likelihood and ease with which a system can be targeted or misused. Robustness defines how well a system withstands adverse conditions or attacks. Resilience reflects how effectively it can recover or continue operating under degradation.
In this model, exposure becomes the front line—it defines the entry points and influence paths that attackers can exploit. And exposure itself must be seen as a function of three critical factors:
Modern cyber-physical risk requires a shift from static architecture to dynamic influence mapping. Exposure must be redefined as a function of:
- Attack surface — how many interfaces or services are reachable
- Attack distance — how far an attacker must penetrate
- Control proximity — how much process influence a system holds
This triad produces a realistic view of cyber-physical exposure. Reachability can be viewed as the combined effect of attack surface and attack distance: surface defines how many opportunities an attacker has to initiate contact, while distance reflects how many steps or barriers must be overcome. Evaluating them separately allows us to recognize tradeoffs—like functions that are easy to find but hard to reach, or close to the core but tightly shielded.
Example – Comparing Field Device Reachability: A field device directly connected to a controller’s I/O card has very low attack surface—it exposes no network interface—and short attack distance, since it is physically and functionally close to the control logic.
In contrast, a field device on a Foundation Fieldbus or Profibus network that is integrated via a network-connected gateway has a larger attack surface due to the exposed interface of the gateway. Its attack distance also increases, since an attacker would need to traverse the network layers to reach the gateway and then access the fieldbus device.
From an exposure perspective, the hardwired device is reachable only through the controller it’s wired to, while the fieldbus device may be reachable through network paths—even if those paths are segmented. Moreover, the attack distance to the fieldbus device can become even shorter if field device management or asset management functions are implemented that allow configuration changes or firmware updates over the network. These systems—regardless of whether they’re labeled as asset management, device integration, or diagnostic support—may reside in different zones but have implicit trust relations that bypass normal segmentation. This effectively reduces the effort required by a threat actor to influence process behavior through the device.
Yet both may have similar control proximity if they perform the same process actuation. However, the importance of securing the directly connected field device may diminish if the controller itself becomes compromised. Once the controller is under the attacker’s control, it typically has unrestricted access to all connected field devices and the logic that governs them. This means the attacker no longer needs to manipulate individual devices—they can operate through the controller to influence multiple actuators simultaneously, alter control parameters, or override normal control behavior, amplifying the impact across the system.
This shows how attack surface and distance define reachability, while control proximity defines potential consequence. Reachability itself can be understood as a combination of attack surface and attack distance: attack surface defines how many opportunities exist for initiating contact or intrusion, while attack distance defines how far an attacker must move through the architecture to reach the target. Evaluating them separately allows us to express distinct risk tradeoffs—such as high surface with deep protection, or low surface but close to critical assets. Importantly, cyber-physical risk increases with control proximity, because functions that directly influence process behavior pose greater consequence if compromised—even if they are harder to reach or narrowly scoped. However, it is important not to confuse control proximity with criticality. A function can have high control proximity without being process-critical in all scenarios, and vice versa. Control proximity informs how exposed a function is to misuse, not necessarily how essential it is to process continuity or safety under normal conditions., because functions that directly influence process behavior pose greater consequence if compromised—even if they are harder to reach or narrowly scoped. It reveals which systems are in a position to cause harm, not just which ones are reachable. Among these, control proximity is the most neglected yet most critical parameter—it directly connects functional role to consequence. Some example:
A function with high attack distance and high control proximity should be treated as critical—because while it may be harder to reach, its potential to impact process integrity once compromised is significant.
Also a function with a small attack surface and high control proximity represents high exposure—because despite limited entry points, its influence over critical control pathways creates significant risk. The key issue is not how much the function does or how often it is accessed, but how deep it is embedded in the process.
2oo3 Exposure Rule
**Exposure increases significantly when any two of the following are high: attack surface, attack distance, or control proximity—regardless of the system’s intended complexity, location, or apparent isolation. **
This is because each factor represents a distinct and independent path to risk: attack surface defines how easily something can be reached, attack distance how close an attacker already is, and control proximity how much impact the system has once compromised. The rule draws inspiration from safety logic, where a two-out-of-three (2oo3) configuration is used to increase reliability—here, it marks the threshold where exposure becomes critical. When two of these align, even a moderately protected system becomes operationally exposed. when any two of the following are high: attack surface, attack distance, or control proximity—regardless of the system’s intended complexity, location, or apparent isolation. This is because each factor represents a distinct and independent path to risk: attack surface defines how easily something can be reached, attack distance how close an attacker already is, and control proximity how much impact the system has once compromised. When two of these align, even a moderately protected system becomes operationally exposed.—even if it performs a narrow or simple task—because it can become a conduit for manipulation. The complexity of the function doesn’t matter as much as the privilege it holds in the control chain.
4. The Need for a Functional Trust Model
IEC 62443 provides authentication (FR1) and use control (FR2), but these are technical. They govern access based on credentials, roles, and permissions. What remains missing is a model that evaluates whether a system should influence another—based on its role in the process, not just its credentials.
Traditional OT security risk analysts typically trace attack paths confined to the digital automation system—mapping how an attacker might traverse through zones, interfaces, and access points. In contrast, cyber-physical risk analysts extend this view by also tracing control influence paths—chains of functional trust through which one function affects another. These paths may not follow network hops, but they do follow implicit trust, role delegation, and data dependency. Modeling these paths is essential to understanding real control proximity in converged systems.
Adding the analysis of control influence paths is a relatively new advancement. ROPA 2.0 is not an official standard—it is an optional, advanced methodology built on top of existing ICS risk-assessment frameworks such as those defined in IEC 62443. It enhances the standard’s system-level perspective with process-aware modeling of influence and consequence. The original version of the Rings Of Protection Analysis (ROPA) methodology focused solely on aggregating risk along multiple attack paths. In contrast, ROPA 2.0 extends this by incorporating control influence paths, enabling analysts to compute an overall Probability of Failure if Attacked (PFA). This allows for assigning a likelihood of defense failure for a specific process hazard—not just based on reachability, but also on the functional influence of each path. Since ROPA assesses each process hazard individually, control proximity is not a fixed attribute of a function. It varies depending on the specific hazard being analyzed. A function may exhibit high control proximity in one hazard scenario—where it directly influences the initiating event or propagation path—but low proximity in another, where its influence is indirect or irrelevant. This hazard-specific framing ensures that exposure is evaluated in relation to the functional context of the process risk, not just system topology. It also highlights a core limitation of static architectural models: zone definitions are fixed, while control proximity is dynamic. Only a process-centric approach can account for how influence and exposure shift with each unique operational context. Since ROPA assesses each process hazard individually, control proximity is not a fixed property of a function but depends on the specific hazard being analyzed. A function may have high control proximity in one hazard scenario and low in another, depending on how directly it can influence the initiating cause or consequence of that hazard.
Example: Misuse Through Implicit Functional Trust
An external optimization platform—residing on the corporate network or in the cloud—supplies calculated setpoints to an advanced process control (APC) function to improve energy efficiency. The APC function may apply strategies such as setpoint control (SPC), where it adjusts the setpoint of the process controller, or direct digital control (DDC), where it directly drives the controller’s output value based on the optimizer’s recommendations. While the APC function executes the control actions, the optimizer influences it by providing process recommendations. Traditionally, such external connections were advisory—where operators reviewed the recommendations before implementing them manually. Increasingly, however, this data is fed directly into APC functions or process controllers without operator validation, relying solely on trust relationships between systems. The optimizer is authenticated, authorized, and connected via a secure conduit.
But what if a threat actor compromises the optimizer? If its commands are accepted without process-aware verification, it can:
- Gradually shift setpoints out of safe limits
- Destabilize a reactor or pressure control loop
- Cause safety systems to engage unnecessarily or too late
All while being technically compliant with 62443.
What’s missing is runtime enforcement of functional authority—not just whether the optimizer is authenticated and authorized in general, but whether it is allowed to influence this part of the process under current conditions. IEC 62443 does not account for such contextual constraints. Yet these constraints are not optional—they act as risk controls that must meet the same level of scrutiny and assurance as any formal security requirement. Talking about this type of control reveals a distinct shift from the traditional perimeter-focused mindset toward one that evaluates functional authority in the context of process dynamics and operational impact. Without enforcing them, the system permits legitimate-looking commands that can bypass the intent of the control strategy.
Control proximity helps detect and evaluate these latent exposures that arise from trusted systems misused outside their intended role or scope.
The optimizer has credentials, not authority. Credentials confirm its identity and grant it general access in accordance with classical security concepts—such as authentication and role-based permission. Functional authority, however, refers to whether the system is contextually permitted to influence specific process behavior, considering operating mode, safety constraints, and its intended function. These are two fundamentally different concepts. Traditional authority models answer who is allowed to access, while functional authority addresses who is allowed to act—in a process-specific and condition-dependent way. Conflating the two leads to overlooked risks in dynamic control environments. It is authenticated, authorized, and connected via a secure conduit.
5. From Perimeters to Control: Evolving Toward Operationally Aligned Cybersecurity
In modern industrial systems, security must be tied to operational integrity. That means:
- Mapping not just access rights, but functional roles, control proximity, and trust boundaries
- Enforcing functional legitimacy—ensuring that systems not only have access, but are contextually allowed to act
- Applying exposure modeling that combines attack surface, attack distance, and control proximity
- Tracing both attack paths and control influence paths across layers and domains
This control-centric view enables cyber-physical risk analysts to assess exposure based on operational consequence, not just system isolation or compliance checklists. It reveals how cyber threats can translate into process risk, even when classical security controls are in place.
The introduction of functional authority and the analysis of control influence paths—as now supported in ROPA 2.0—adds a missing layer to traditional assessments. These tools allow us to quantify the probability of failure if attacked (PFA) for each process hazard, tying exposure directly to the dynamics of the control environment.
Importantly, this shift redefines what constitutes a valid risk control. Constraints on control influence must be explicitly designed, implemented, and validated. They are not optional safeguards, but critical elements of the security architecture. And since their necessity depends on process context, they can only be identified through a process-centric risk assessment.
This represents a fundamental departure from the perimeter-based logic that underpins much of IEC 62443 today. While the standard provides a strong foundation for structuring technical defenses, it lacks the functional perspective needed to secure modern, converged industrial environments.
Control proximity is not an add-on; it is the axis along which cyber access becomes physical consequence. Without it, the model is blind to the paths where risk actually materializes.
To move forward, industrial cybersecurity must evolve: from securing systems to securing control.
What You Can Do Next
- Analyze existing ICS designs for control influence paths — see Section 4 for discussion on functional trust and the importance of modeling control influence beyond attack paths
- Assess process-level trust relationships — outlined in Section 4, especially the example involving the optimizer and APC function
- Incorporate dynamic hazard scenarios into your risk modeling — ROPA 2.0 (Section 4) enables evaluation of control proximity per hazard scenario to compute Probability of Failure if Attacked (PFA)
- Re-express access controls in terms of functional authority — discussed in Section 4, distinguishing between credentials and process legitimacy
- Extend IEC 62443 implementations to consider control proximity when setting SLs and mapping foundational requirements (e.g., FR4, FR5, FR7) — see Section 2 for a detailed proposal on tailoring 62443-3-3 and 62443-3-2, not just technical connections
- Assess process-level trust relationships, especially for external systems influencing control decisions
- Incorporate dynamic hazard scenarios into your risk modeling, using techniques like ROPA 2.0 to evaluate exposure and probability of failure if attacked (PFA)
- Re-express access controls in terms of functional authority, validating not just who can act, but whether they should act in a given context
- Extend IEC 62443 implementations to consider control proximity when setting SLs and mapping foundational requirements (e.g., FR4, FR5, FR7)
