Product security evidence
What security capabilities, development processes, limitations, versions and certifications apply to the exact offered component?
Home › O-PAS Cybersecurity Requirements
IEC 62443 · Architecture · Procurement · Verification · Operations
O-PAS cybersecurity requirements Secure the integrated system, not only its components
An Open Process Automation project needs cybersecurity requirements that cross product and supplier boundaries. The owner must define the risk basis, architecture, identity, trust, lifecycle and acceptance evidence that turn secure-capable components into a defensible operating system.
The short answer
O-PAS product evidence does not by itself establish that an integrated Open Process Automation system is secure. The project still has to define its ISA/IEC 62443-based risk and responsibility model, zones and conduits, target security requirements, identity and certificate architecture, secure configuration, logging, vulnerability and patch process, backup and recovery, remote access, incident response, acceptance testing and lifecycle governance.
In a multi-vendor architecture, the hardest security problems often sit between products: shared identity, trust establishment, cross-supplier patch effects, coordinated vulnerability response, system-wide monitoring and recovery. Those boundaries must be engineered, contracted and tested explicitly.
01 · Evidence
Product capability, system implementation and operating posture are different claims
Security discussions fail when evidence from one level is used as proof for another. Each level answers a different question.
Implemented security controls
How are the selected products configured and integrated to satisfy the project's zones, conduits, identities, trust, monitoring, recovery and other requirements?
Maintained security posture
How does the owner keep inventories, access, certificates, patches, backups, monitoring, supplier coordination and incident readiness effective over time?
The evidence rule
A component certificate can support product selection. It cannot prove that the selected products are securely integrated, that the configured system meets the owner's risk requirements, or that the operating organisation can maintain the posture after handover.
02 · Governing framework
Use ISA/IEC 62443 across the complete project lifecycle
The ISA/IEC 62443 series provides requirements and processes for industrial automation and control system security. Its shared-responsibility model is particularly important when an OPA project distributes products and services across several organisations.
Risk and consequence
Define system scope, tolerable risk, threat assumptions, consequence, critical functions and the detailed requirements needed to reduce risk.
Zones and conduits
Group assets with common security requirements and define every communication path crossing a zone boundary.
Target requirements
Translate the risk assessment into system, component, integration, service-provider and operating requirements.
Defence in depth
Configure identity, use control, system integrity, confidentiality, restricted data flow, event response and resource availability as required.
Achieved controls
Inspect configuration and execute tests that demonstrate the implemented architecture meets its specified requirements.
Lifecycle security
Operate vulnerability, patch, access, certificate, monitoring, backup, recovery, incident and reassessment processes.
Primary reference: ISA/IEC 62443 Series of Standards ↗. Apply the specific standards, owner policies and regulatory requirements relevant to the facility and project.
03 · Accountability
Multi-vendor security needs one integrated responsibility model
Every supplier can fulfil its own product scope while the system still has gaps between contracts. The project must name who owns the integrated security result.
Risk and acceptance authority
Defines risk criteria, policies, zones, operating constraints, access principles, incident obligations and the evidence required for acceptance.
Contract and project coordination
Carries requirements into packages, aligns suppliers, controls deliverables and schedule, manages change and closes acceptance obligations.
Integrated security engineering
Designs and configures the system across products, maintains the baseline, develops integrated tests and resolves cross-supplier issues.
Secure-capable component
Provides exact product evidence, hardening guidance, vulnerability notices, patches, support, configuration requirements and defect correction.
Controlled lifecycle services
Meets requirements for access, personnel, tools, maintenance, remote support, incident handling, records and change control.
Day-two control
Owns accounts, certificates, monitoring, backups, patches, exceptions, incidents, supplier escalation and periodic reassessment after handover.
Allocate these activities in the O-PAS Responsibility Matrix. The critical row is the authority accountable for security across the integrated system.
04 · Specification
Ten cybersecurity requirement areas for an OPA project
Each area needs a stated requirement, responsible party, design deliverable, verification method, acceptance authority and lifecycle owner.
Risk basis, scope and security architecture
Define the IACS boundary, critical functions, risk assessment method, threat assumptions, zones, conduits, security objectives, interfaces to retained systems and required design records.
Asset identity and inventory
Require unique asset identification, product and software versions, configuration state, ownership, location, support status and an update process that remains accurate after commissioning.
Human and machine identity
Define accounts, roles, least privilege, authentication, service identities, shared-console treatment, privileged access, joiner-mover-leaver processes and periodic review.
Trust and certificate lifecycle
Specify trust architecture, certificate authorities, issuance, distribution, renewal, revocation, expiry monitoring, time synchronisation, ownership and recovery from trust failure.
Secure communications and restricted data flow
Name permitted services, protocols, endpoints, directions, security policies, encryption requirements, zone-boundary enforcement, denied paths and evidence that the implemented flows match the design.
Hardening and system integrity
Define secure baselines, disabled services, removable media, application control, malware protection where appropriate, configuration integrity, secure boot or signing expectations, audit records and exception control.
Monitoring, logging and time
Specify events, audit sources, timestamps, retention, central collection, health monitoring, alert ownership, diagnostic access and how multi-vendor records will be correlated during an incident.
Vulnerability, patch and obsolescence management
Require disclosure channels, severity and response commitments, patch information, qualification responsibility, regression scope, compensating controls, emergency process, support period and end-of-life notice.
Backup, recovery and resource availability
Define protected backups, restore points, configuration recovery, redundancy, capacity, denial-of-service considerations, recovery order, recovery time, offline assets and witnessed restoration tests.
Remote access, incident response and supplier coordination
Specify approval, authentication, session control, monitoring, time limits, emergency access, supplier obligations, evidence preservation, communication, containment, recovery and post-incident learning.
Specification stop condition: the package lists security features but does not identify who configures them, who proves them, who coordinates suppliers when a boundary fails, and who owns them after handover.
05 · Supplier evidence
Ask for evidence tied to the exact product and service offered
A general product-family statement cannot close a requirement allocated to a specific version, configuration or supplier service.
| Evidence | Bid requirement | Project question |
|---|---|---|
| Product identity | Exact model, software, firmware, version, options and dependencies. | Is the offered baseline the baseline covered by the evidence? |
| Certification and assessment | Certificate, scheme, scope, security level or capability, edition, laboratory, date and exceptions. | Which allocated requirements are independently supported, and which remain project work? |
| Secure development evidence | Development-lifecycle position, vulnerability process, disclosure route and maintenance commitments. | How will defects be handled throughout the required service life? |
| Hardening guidance | Secure configuration, required services, ports, accounts, certificates, logging, backups and limitations. | Can the integrator build a reviewable and repeatable baseline? |
| Patch position | Release method, cadence, prerequisites, rollback, qualification support and known-impact process. | Who tests a supplier patch against the integrated system? |
| Bill of materials | Required software and component inventory at the granularity established by owner policy. | Can affected assets be identified when a vulnerability is disclosed? |
| Remote support model | Tools, identities, connection path, approvals, logging, data handling and emergency access. | Does the support method fit the owner's zone, identity and monitoring architecture? |
| Support lifecycle | Support term, end-of-life notice, upgrade path, replacement position and response escalation. | Can security obligations be maintained for the required operating period? |
Use the O-PAS Procurement Specification Checklist to carry cybersecurity requirements, evidence, deviations and lifecycle obligations into the RFQ and bid comparison.
06 · Verification
Cybersecurity FAT and SAT should test failure paths deliberately
Document review confirms intent. Configuration inspection and controlled testing show whether the integrated system behaves as required.
| Test area | Representative demonstration | Evidence |
|---|---|---|
| Identity and access | Valid, invalid, expired, disabled and excessive-privilege scenarios across selected components. | Configuration, access result, audit trail and approved role mapping. |
| Certificate and trust failure | Untrusted, expired, revoked or replaced certificate and recovery of approved trust. | Observed denial, alarm or log, renewal process and restored operation. |
| Zone-boundary enforcement | Permitted flows succeed and prohibited paths are denied under representative configuration. | Ruleset, flow record, denial evidence and architecture cross-reference. |
| Hardening baseline | Required services, accounts, ports, software, settings and exceptions match the approved baseline. | Automated or manual inspection record and exception approval. |
| Logging and monitoring | Selected events are generated, timestamped, collected, retained and visible to the responsible role. | Source log, central record, alert, timing and ownership confirmation. |
| Backup and recovery | Restore component and system configuration from protected backups in the required order. | Backup identity, recovery time, restored baseline and functional confirmation. |
| Patch and rollback | Apply an approved update in the test environment, execute regression scope and restore the prior baseline if required. | Change record, test results, updated inventory and rollback evidence. |
| Remote access | Request, approve, establish, monitor, terminate and review a supplier session. | Approval, identity, session record, actions, termination and audit review. |
| Incident workflow | Detect a defined event, escalate it, coordinate suppliers, contain the affected scope and recover service. | Timeline, decisions, communications, evidence preservation and closure record. |
Prove configuration and integrated behaviour before site exposure.
Close site infrastructure, identity, monitoring and retained-system conditions.
Transfer baseline, procedures, access, records and unresolved risks.
Retain the tests needed after patches, replacements and architecture changes.
Connect cybersecurity scenarios to the wider integrated programme using the O-PAS FAT and Interoperability Testing Guide.
07 · Migration
Coexistence creates a temporary architecture with permanent security obligations
During brownfield migration, the legacy DCS and target architecture may operate together for months or years. The hybrid state must be secured as a production system, not treated as a short exception.
Legacy interfaces
Document data direction, permitted services, translation, authentication, failure behaviour, ownership and monitoring at every retained-system interface.
Two access models
Resolve how legacy accounts, target identities, shared consoles, suppliers and maintenance teams are governed during coexistence.
Certificate introduction
Plan trust infrastructure, certificate enrolment, time, renewal and recovery before dependent communications become operational.
Cross-system visibility
Correlate events across old and new environments so a security or operating issue is not hidden at the transition boundary.
Cutover and rollback
Keep backups, trusted baselines, access and security controls aligned with the control-system restoration sequence.
Secure decommissioning
Revoke identities and trust, remove access paths, preserve required records and dispose of data and equipment under owner policy.
Place these controls inside the transition sequence with the Brownfield OPA Migration Strategy.
08 · Day two
A secure design decays unless the operating model maintains it
Versions change, people move, certificates expire, vulnerabilities appear and suppliers release updates. Operations must control that change across the complete system.
Know the approved baseline
Maintain assets, software, firmware, applications, interfaces, accounts, certificates, configurations, exceptions and support status.
Review identities and privilege
Control onboarding, role changes, departures, service accounts, privileged activity, emergency access and supplier access.
Operate certificate lifecycle
Monitor expiry, renew before outage risk, revoke compromised trust, protect authorities and rehearse restoration.
Coordinate vulnerabilities
Receive notices, identify affected assets, assess consequence, obtain supplier positions, select treatment and record residual risk.
Qualify patches and upgrades
Assess dependencies, test integrated effects, approve windows, retain rollback and update every affected baseline record.
Rehearse incidents and recovery
Exercise detection, decision authority, supplier coordination, containment, evidence, restoration and safe plant operation.
09 · Handover
The owner cybersecurity handover package
Acceptance should leave the owner with the records, access, tools and competence required to operate and change the system securely.
| Deliverable | Required content |
|---|---|
| Security requirements and traceability | Risk source, requirement, allocated party, design reference, verification method, result, deviation and approval. |
| As-built zone and conduit architecture | Assets, boundaries, communications, enforcement points, retained systems, remote paths and approved exceptions. |
| Integrated baseline manifest | Products, versions, software, firmware, applications, configurations, certificates, identities and dependencies. |
| Hardening and configuration records | Approved settings, disabled functions, rules, accounts, logging, backup position and deviations. |
| Identity and trust records | Roles, account ownership, privileged access, certificate inventory, authorities, renewal and revocation procedures. |
| Supplier security evidence register | Exact product, evidence, scope, date, limitation, review result, support term and remaining project obligation. |
| Executed test and defect records | Procedures, results, witnesses, defects, corrections, regression, exceptions and acceptance decisions. |
| Operational procedures | Monitoring, access review, vulnerability triage, patching, backup, restore, remote support, incident and escalation. |
| Lifecycle responsibility map | Owner, integrator, product and service-supplier obligations, contacts, response expectations and change authority. |
10 · Continue the work
From requirements to architecture and operating capability
White paper
Cybersecurity Architecture for OPA Systems
Read the longer treatment of ISA/IEC 62443, security levels, zones, conduits and the system-security boundary.
Practitioner courseCybersecurity in Open Architectures
Work through architecture, OPC UA security, PKI, identity, networks, procurement, testing and secure operations.
Decision hubOPA for Owner-Operators
Connect cybersecurity to architecture, procurement, integration, governance and lifecycle strategy.
11 · FAQ
O-PAS cybersecurity questions
Is an O-PAS-based system automatically secure?
No. Product requirements and evidence provide inputs to a secure design. The project must still perform its risk assessment, define zones and conduits, configure and integrate controls, verify the implemented system and operate the cybersecurity lifecycle.
Does product certification replace a project cybersecurity risk assessment?
No. Product evidence addresses a defined product scope. The project risk assessment considers facility consequence, threats, architecture, interfaces, configuration, operating practices and compensating controls across the complete system.
Who owns cybersecurity in a multi-vendor OPA system?
Responsibility is shared, but accountability must be explicit. The owner retains risk and acceptance authority. A named EPC or integrator should be accountable for integrated delivery, while product and service suppliers fulfil defined product, support and lifecycle obligations.
What should be added to FAT for cybersecurity?
Inspect the implemented baseline and test identity, authorisation, trust failure, certificate renewal, zone-boundary enforcement, hardening, logging, backup and recovery, patch and rollback, remote access and selected incident workflows.
How should patches be managed across multiple suppliers?
Maintain an integrated baseline and responsibility model. For each update, identify affected products and interfaces, collect supplier positions, assess consequence, test the required regression scope, approve the change, preserve rollback and update all baseline records.
What makes certificate management an operational requirement?
Certificates expire, are replaced and may need revocation. The owner needs inventory, authority ownership, enrolment, renewal, revocation, time, monitoring, backup and recovery processes that work across every dependent component.
How should cybersecurity be handled during brownfield migration?
Secure the coexistence state as a production architecture. Define legacy interfaces, identities, trust, monitoring, remote access, recovery, rollback and decommissioning for every migration increment.
Cybersecurity requirements and verification
Close the gaps between products, suppliers and lifecycle owners
CSI helps owner-operators and EPC teams turn O-PAS, ISA/IEC 62443 and owner security objectives into architecture, procurement requirements, responsibility boundaries, acceptance tests and a supportable operating model.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard. This guide is a project-requirements framework, not a substitute for the applicable standards, facility risk assessment, owner policies, laws, regulations or competent cybersecurity engineering.