Who should own IEC 62443 compliance when asset owners, service providers, and suppliers all have responsibilities?

How IEC 62443 splits accountability across owner, provider, and supplier

IEC 62443 uses a role-based compliance model, so ownership is not a single blanket assignment. The asset owner carries the overall security outcome for the installation or system, while service providers and product suppliers own the controls inside their respective scopes. That division only works when each party can show clear boundaries, named responsibilities, and evidence that its part of the control chain is actually operating.

The practical question is not who “cares most,” but who can be held accountable for each decision point. In a well-run program, the asset owner sets the target security posture and accepts risk decisions, the service provider secures integration and maintenance, and the supplier designs and builds components to the required security expectations.

That separation matters because many IEC 62443 failures happen at the seams: integration work that weakens a supplier’s secure design, maintenance access that bypasses owner policy, or ambiguous handoffs that leave no one responsible for a gap. A useful way to read the standard is as a map of obligations that must survive procurement, commissioning, operations, and change control.

What each party must be able to prove

Asset owner responsibility is strongest where the standard expects governance, risk acceptance, and target security level decisions. That includes defining the intended security level, establishing the security program, and making sure the system is operated within an accepted risk envelope. If the owner cannot show those decisions, compliance becomes a paper exercise rather than a defensible operating model.

Service providers are accountable where secure delivery and operational execution matter most. Their responsibilities typically include secure integration, configuration, maintenance, and support activities that do not undermine the owner’s security posture. For outsourced or hybrid industrial environments, this is where managed response and provider access boundaries become relevant, because the provider must not gain unchecked operational authority simply by being a third party.

Product suppliers own the security of what they build and ship, including secure development practices, component integrity, and product-level security expectations. Their compliance evidence should be product-centric: security requirements, development assurance, vulnerability handling, and the security characteristics of the component itself. If the supplier’s part is weak, no amount of downstream tuning by the owner or integrator fully compensates for it.

In practice, the best ownership model is one that is written into contracts, test plans, and acceptance criteria. If a responsibility cannot be tested, audited, or attributed to a named party, it is not yet assigned well enough for IEC 62443 purposes.

Why role clarity becomes a control issue, not just a governance issue

IEC 62443 is built to make industrial security responsibilities auditable, which means unclear ownership is itself a control weakness. The standard expects that roles and obligations are explicit enough that auditors and engineers can trace a requirement from policy to implementation to operation.

This is especially important in environments where integration and operation are split across multiple organisations. If the asset owner sets requirements but the service provider controls access paths, or if the supplier delivers a secure component that is later deployed insecurely, the overall result can still fail compliance even though each party believes it has “done its part.”

The same issue appears in broader industrial security programs, where segmentation, remote access, and maintenance pathways can quietly erode the original security intent. NHIMG’s OT Security Guide is useful context here because IEC 62443 ownership only makes sense when zones, conduits, and operational boundaries are also understood.

Role clarity also reduces dispute during incidents. When an event occurs, the organisation should already know whether the failure sits in ownership, integration, product assurance, or maintenance execution. That speeds containment and avoids the common problem of vendors and owners passing blame while exposure remains active.

Risk and Threat Considerations

When ownership is ambiguous, IEC 62443 compliance gaps usually show up at trust boundaries, maintenance channels, and supplier handoffs. The risk is not only a documentation issue, but a real exposure issue, because unclear accountability often leaves insecure remote access, unsupported configurations, or unowned vulnerabilities in place longer than intended.

Failure mechanism: A party assumes another party is responsible for a control, so no one validates it, tests it, or maintains it after deployment. That can leave maintenance access, security updates, or component hardening outside any accountable workflow.

Impact: The system can remain formally “owned” by everyone and operationally owned by no one, which increases the chance of missed defects, delayed remediation, and compliance findings that are hard to defend during audit or incident review.

Practitioner Guidance

What to verify: Write the responsibility model down at the level of specific deliverables, not just party names. Confirm who owns target security levels, who approves exceptions, who maintains remote access, and who supplies evidence for each control family.

Decision rule: If a control affects design, integration, and operations, assign one accountable owner and separate supporting contributors. If the same control is shared, define who tests it, who approves it, and who remediates it when it fails.

Common mistake: Treating the supplier as responsible only for product quality, the service provider only for uptime, and the asset owner only for policy. IEC 62443 works best when those roles are connected by explicit acceptance criteria and change control.

Practitioner takeaway: The strongest IEC 62443 programs do not try to blur responsibility, they make it testable, so every control has one accountable owner even when several parties contribute to it.

Related resources from NHI Mgmt Group

• Guide: IEC 62443 Guide
• When does a service account become a compliance problem?
• How should virtual asset service providers implement Travel Rule compliance across APAC jurisdictions with different licensing timelines?
• What is the difference between PCI DSS responsibility for third-party service providers and the customer’s own compliance obligations?
• How should crypto-asset service providers prepare for MiCA compliance in Lithuania before the transition period ends?