Cybersecurity Architecture for OPA Systems

A reasonable first reaction to Open Process Automation, from anyone responsible for OT security, is suspicion. A traditional Distributed Control System is, for all its drawbacks, a closed and well-understood perimeter — one vendor, one set of components, one published guidance. An open architecture, assembling components from multiple suppliers across standardized and therefore public interfaces, sounds on its face like a larger attack surface and a harder thing to defend.

That reaction deserves a serious answer rather than reassurance. This paper is that answer. It is written for OT security engineers, IACS cybersecurity specialists, and the I&C leads who carry security responsibility for a control system — and it makes a specific argument: that an OPA system is not secured despite being built on standards, but through them. The same standard that defines how OPA components interoperate also defines that their security is built on IEC 62443, the international standard for industrial automation and control system cybersecurity. This paper explains how 62443 maps onto an OPA system in practice, and — just as importantly — where the standard's guarantees end and the system owner's continuing responsibility begins.

Why "open" is not the same as "exposed"

The intuition that an open architecture must be less secure than a closed one rests on an assumption worth examining: that the secrecy of a system's internals contributes to its security. In cybersecurity this assumption has a name — security through obscurity — and it has been understood for decades to be a weak foundation. A proprietary DCS is not secure because its internals are undisclosed. It is secure to the extent that its vendor engineered it well, and the operator largely has to take that on trust, because the evidence is not open to inspection.

An open architecture inverts the relationship. Because OPA components implement public interfaces and are built to a public security standard, their security properties can be specified, tested, and verified by parties other than the vendor. "Open" here does not mean the internals of a component are exposed to an attacker — it means the security requirements a component must meet are public, and conformance to them is independently checkable. That is a stronger position than obscurity, not a weaker one.

The standardized interface also does something concrete for defenders: it makes the system legible. A defender can reason about an OPA system because its structure — the components, the interfaces between them, the information that crosses each boundary — is defined rather than hidden. A system you can describe precisely is a system you can segment, monitor, and threat-model precisely. That legibility is a security asset.

None of this means an OPA system is automatically secure. It means the architecture is built so that security can be done properly. Doing it properly is what the rest of this paper is about.

The standard underneath: ISA/IEC 62443

O-PAS does not invent its own approach to cybersecurity. The O-PAS Standard states that security is built on the ANSI/ISA-62443 family of standards, and it treats security not as an optional add-on but as a property embedded in what it means for a component to conform. This is consistent with the "standard of standards" philosophy of O-PAS generally: where a mature, internationally recognized standard already exists for part of the problem, O-PAS adopts it.

IEC 62443 (also published as ANSI/ISA-62443) is the international standard for the cybersecurity of Industrial Automation and Control Systems. It is not a single document but a family, addressing the problem from several angles — general concepts, policies and procedures, system-level requirements, and component-level requirements. For an OPA system, four ideas from 62443 do most of the practical work, and an OT security engineer evaluating or implementing an OPA system should be fluent in all four.

Security Levels

IEC 62443 defines four Security Levels, and their purpose is to match the strength of a system's defenses to the strength of the adversary it must withstand. They are not a simple "more is better" scale — they describe who you are defending against:

• SL 1 — protection against casual or accidental violation: unintentional misconfiguration, an operator reaching something they should not, ordinary human error. No malicious actor is assumed.
• SL 2 — protection against intentional violation using simple means: an attacker with low resources, generic skills, and publicly available tools. This is the level most general process manufacturing realistically targets as a baseline.
• SL 3 — protection against intentional violation by an attacker with moderate resources, IACS-specific knowledge, and tools designed for control-system protocols. This is the level for systems whose compromise carries significant safety or financial consequences.
• SL 4 — protection against an attacker with extended resources, sophisticated means, and a strong, sustained motivation: the state-sponsored threat.

The essential point is that a facility does not pick one Security Level for everything. Different parts of a plant face different threats and carry different consequences, and 62443 is designed to let security be specified granularly — which leads directly to the next idea.

Zones and conduits

The organizing model of 62443 for system-level security is zones and conduits. A zone is a grouping of assets that share the same security requirements. A conduit is a defined communication path between zones, and it too has its own security requirements. The discipline is to partition the system into zones, identify every conduit that crosses a zone boundary, and assign each its appropriate Security Level — rather than treating the control system as one flat network defended by a single perimeter.

An OPA system is unusually well suited to this model, and the reason goes back to legibility. Because an OPA system's components and interfaces are defined by the standard, the zone-and-conduit map is something a defender can draw precisely: the components are known, the interfaces between them are known, and the information crossing each boundary is specified. Segmentation that has to be reverse-engineered from a proprietary system can be designed deliberately in an open one.

A worked illustration: an OPA system might place its core control components in a high-security zone targeted at SL 3, with operator-interface components in a separate zone at a lower level, and the conduit between them configured to permit only specific, expected interactions. A request that the conduit's policy does not anticipate — a configuration change arriving from a zone that should only be monitoring — is dropped and logged at the boundary. The zone-and-conduit structure is what turns "defense in depth" from a slogan into an enforced architecture.

The seven foundational requirements

IEC 62443 organizes its system-level security requirements into seven Foundational Requirements, and they are the checklist against which the security of any zone is reasoned about:

• FR 1 — Identification and Authentication Control: establishing and verifying the identity of users, devices, and software before granting access.
• FR 2 — Use Control: enforcing what an authenticated identity is actually permitted to do.
• FR 3 — System Integrity: ensuring the system and its data are not altered without authorization.
• FR 4 — Data Confidentiality: protecting information, in transit and at rest, from disclosure.
• FR 5 — Restricted Data Flow: enforcing the zone-and-conduit segmentation — controlling what information is allowed to move where.
• FR 6 — Timely Response to Events: detecting, logging, and responding to security events while they still matter.
• FR 7 — Resource Availability: ensuring the system remains available and resilient under attack.

The Security Level of a zone is, properly understood, a vector across these seven — a zone may require a high level for system integrity and use control while needing far less for data confidentiality, depending on what that zone does. Designing OPA security means working FR by FR, zone by zone, rather than reaching for a single global number.

Target, capable, achieved — and the gap

The fourth idea is the one that keeps a security program honest. IEC 62443 distinguishes three views of a Security Level. The Target SL (SL-T) is the level a zone is required to reach, determined by risk assessment. The Capable SL (SL-C) is the level the components and system are able to support if configured correctly. The Achieved SL (SL-A) is the level actually in effect in the deployed, operating system.

The distance between Target and Achieved is the security gap — and closing it is the real work of securing a system. A component being capable of SL 3 does not mean the deployed zone achieves SL 3; that depends on configuration, integration, operating practice, and maintenance over time. This distinction matters enormously for OPA, because it locates responsibility precisely: O-PAS conformance speaks to component capability, but the achieved security of the operating plant is determined by how the system owner designs, deploys, and maintains it.

What O-PAS conformance gives you — and what it does not

This is the crux of the paper, and it has to be stated with precision, because it is the point most easily misunderstood in either direction.

What conformance gives you. O-PAS embeds security into the conformance requirement itself. Under the standard's quality-attribute framework, security ("Securability") is a property a component must demonstrate to be conformant — and in practice this means an O-PAS-certified component is required to also carry component-level security certification under the ISA/IEC 62443-4-2 standard, at a defined Security Level baseline. The consequence is significant: in an OPA system, security at the component level is not a claim each supplier makes in its own words. It is a certified, independently verified property, expressed in the common language of 62443, for every conformant component regardless of which supplier built it. A proprietary DCS, however well secured, cannot offer that kind of uniform, independently verifiable, cross-vendor security evidence — because there is only one vendor and the evidence is internal.

What conformance does not give you. Component certification is necessary but not sufficient. The O-PAS Standard is explicit on the point: no interface standard can guarantee comprehensive security, and the responsibility for continuous security assessment rests with the system owner. Conformance certifies that a component is capable of a security baseline. It does not, and cannot, do the following:

• It does not design your zones and conduits. Partitioning the system and assigning Security Levels to zones and conduits is a risk-driven engineering decision specific to the facility.
• It does not set your Target Security Levels. SL-T comes from a risk assessment of your plant — its processes, its consequences, its threat environment — not from the standard.
• It does not close the gap between capable and achieved. Configuration, integration, secure deployment, monitoring, patching, and incident response across the system's life are the system owner's continuing work.
• It does not secure the conduits to non-conformant systems. A gateway to a legacy DCS is a security boundary that must be designed and defended deliberately — and during a phased migration, the coexistence period is a security architecture in its own right.
• It does not expire never. Security is maintained, not established once. As threats evolve and the standard advances, components are recertified and the system's posture is reassessed.

The honest summary is this: O-PAS conformance gives an OPA system a stronger, more transparent, more independently verifiable security foundation than a proprietary system can demonstrate. It does not hand the operator a secure plant. It hands the operator a system that can be secured properly, with verified components and a common standard to build on. The building is still the operator's to do.

Implementing 62443 on an OPA system: a practical sequence

For an OT security engineer carrying an actual OPA system, the work follows the logic of 62443 itself:

Establish the system under consideration and partition it into zones. Define what is in scope, then group assets by shared security requirements into zones, and identify every conduit between them. The legibility of an OPA architecture makes this more precise than it would be on a proprietary system.

Assess risk and assign Target Security Levels. For each zone and conduit, determine SL-T from the consequences of compromise and the credible threat. Expect a vector across the seven Foundational Requirements, not a single number, and expect different zones to land at different levels.

Confirm component capability against target. For each zone, check that the O-PAS-conformant components' certified 62443-4-2 capability (SL-C) meets the zone's SL-T. Where the target exceeds component capability, that gap is identified early, by design.

Engineer the achieved posture and measure the gap. Configure, integrate, and deploy to reach SL-T in practice, then assess SL-A honestly. The difference between SL-T and SL-A is the security gap, and the remediation plan is the plan to close it.

Treat the legacy boundary as a first-class security problem. Every conduit to a non-conformant system — above all the gateway to an existing DCS during migration — is a boundary requiring its own zone definition, its own Security Level, and its own deliberate defense.

Maintain continuously. Monitor, log, respond, patch, reassess as the threat environment and the standard both move. SL-A is a measurement of a moment; keeping it where it needs to be is ongoing work.

Where this leaves you

The suspicion an OT security engineer brings to Open Process Automation is healthy, and it should not be answered with reassurance. It should be answered with the structure of the thing. An OPA system is built on ISA/IEC 62443, the same standard that frames industrial cybersecurity across the field. Its security is embedded in conformance, so that every conformant component carries independently verified, component-level security certification in a common language. And its standardized, legible architecture makes the core disciplines of 62443 — zones and conduits, security-level targeting, the seven foundational requirements — more precisely applicable than they are on a proprietary system whose internals must be inferred.

What the architecture cannot do is discharge the system owner's responsibility. Zones, targets, the achieved posture, the legacy boundary, and the continuous maintenance of all of it remain the operator's work, for the life of the plant. That is not a shortcoming of the open model — it is true of every control system ever built. The difference is that an OPA system makes the work visible, standards-based, and verifiable, rather than opaque and vendor-internal. For a security engineer, a system you can inspect is a system you can defend.

This whitepaper is published by Collaborative Systems Integration (CSI). CSI is a vendor-independent systems integrator specializing in Open Process Automation. CSI's founding principal, Don Bartusiak, served as Co-Chair of the Open Process Automation Forum; CSI's Trevor Cusworth served as an OPAF Co-Chair for six years and leads marketing and outreach within the Forum's Business Working Group. CSI operates under a commercial license from The Open Group for the O-PAS Standard. O-PAS™ is a trademark of The Open Group; ISA/IEC 62443 is a standard of the International Society of Automation and the International Electrotechnical Commission. This paper is an educational overview and is not a substitute for the standards themselves. Views expressed here are CSI's and do not represent positions of The Open Group or the Open Process Automation Forum.