ISA/IEC 62443 keeps OT security responsibility role-specific
ISA describes shared responsibility across asset owners, product suppliers, integrators, and service suppliers while assigning different requirements across the 62443 series. A product mapping or certificate cannot transfer the facility's operating, engineering, safety, and risk decisions.
Editorial figure by OT Defense Review. Source context: ISA — ISA/IEC 62443 series of standards.
Shared responsibility is not interchangeable responsibility
The ISA overview names four stakeholder groups because each controls different evidence and actions. The asset owner operates the physical mission and security program. Product suppliers control development and product records. Integrators assemble and maintain solutions. Service suppliers support operation. One organization can hold several roles, but the duties do not merge merely because the same contract or platform connects them.
An OT architecture record should therefore identify the facility and system boundary, lifecycle stage, stakeholder role, supplied component or service, decision rights, change authority, evidence, and unresolved dependency. A generic 62443-aligned field is too broad to show which part, edition, role, and scope a claim addresses.
Series structure matters more than a standards logo
ISA's public list separates program requirements for IACS asset owners and service providers from system risk assessment, system security requirements, secure product-development lifecycle requirements, and component requirements. Those records answer different questions. Evidence for a supplier's development process does not establish a site's risk assessment or security program.
Procurement teams should ask for the exact standard part, edition, claim type, assessment or certification scheme, product or system scope, exclusions, and current status. They should also identify the customer configuration, compensating controls, integration, operation, monitoring, maintenance, and recovery evidence that remains outside the supplier's record.
The buyer test crosses a product, integration, and operating change
Use an authorized non-production scenario involving one component, its supplied security documentation, the integrator's design, the owner's zone and conduit context, a service-provider access path, and a later product update. The demonstration should show which party owns each decision and how assumptions, approvals, exceptions, verification, and rollback evidence survive the change.
Do not turn that demonstration into live-system scanning or reconfiguration. Active queries, access changes, enforcement, patching, isolation, and recovery require site authorization, engineering and safety review, vendor support, change control, and a tested recovery plan. The useful output is a responsibility and evidence map, not operational instructions.
A mapping does not establish a secure or safe facility
ISA presents the series as a holistic lifecycle approach spanning operations, information technology, process safety, and cybersecurity. That breadth makes it useful for organizing diligence. It does not let a publication or vendor conclude that a facility is secure, safe, reliable, compliant, or adequately protected.
OT Defense Review will keep product, system, service, integrator, and asset-owner evidence separate. Certification scope, adoption, applicability, operating context, residual risk, and physical consequence need qualified review against the exact standards records and authorized site facts.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
OT Defense Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.