Who should be accountable for security-by-design across OEM and ICS supply chains?

Accountability Boundaries Across OEMs, Integrators, and Asset Owners

Security-by-design in OEM and ICS supply chains only works when accountability is assigned to the parties that can actually influence design, procurement, and operation. Asset owners should define the security outcomes they require, including hardening expectations, update support, and validation evidence. OEMs and ICS manufacturers should then build those requirements into the product architecture rather than leaving them to later integration.

That split matters because industrial environments often inherit risk from decisions made long before deployment. If accountability is vague, teams tend to treat security as a commissioning issue instead of a lifecycle obligation, which leaves gaps in firmware assurance, supportability, and change control. In practice, many security teams encounter the consequences only after an integration delay, a supplier dispute, or an unsupported control assumption has already become operational reality.

For supply chains that include connected components, engineering access, or machine-authored workflows, the accountability model should extend beyond the physical product to the identities and trust relationships around it. That is where control ownership often becomes blurred, and where NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful as a language for assigning responsibility across people, systems, and suppliers.

How Security-by-Design Becomes Operational in ICS Supply Chains

In practice, “accountable” does not mean every party owns the same task. It means each stage of the supply chain has a defined decision owner, a defined evidence requirement, and a defined escalation path when a control cannot be met. Asset owners usually own the security requirement set, acceptance criteria, and risk decisions for deployment. OEMs own product design choices, secure defaults, update mechanisms, and the evidence that those controls were tested before shipment. Integrators own the correct configuration, segmentation, and validation in the target environment.

This division is important because ICS environments are highly dependent on vendor behaviour after purchase. If the OEM does not design for safe updates, a secure deployment may still become fragile during patching. If the asset owner does not specify minimum support periods or authentication requirements up front, the supplier may deliver something that is technically functional but operationally insecure. If the integrator assumes the product will compensate for weak network architecture, the result is often a system that is difficult to monitor, patch, or recover.

A useful accountability model therefore has three practical characteristics:

• requirements are written before procurement, not after installation;
• testing covers both product behaviour and deployment behaviour;
• exceptions are time-bound and approved by the party that owns the risk.

This also means evidence matters. Security-by-design should produce artefacts such as secure configuration baselines, update and rollback expectations, validation results, and support commitments that can survive audit or procurement challenge. For industrial systems, the governance failure is often not the absence of a control, but the absence of a named owner for proving that the control still exists after integration. Where contracts, engineering realities, and operational safety all pull in different directions, accountability has to be explicit or it will drift.

Shared Responsibility Without Shared Ambiguity

Tighter accountability often increases procurement and engineering overhead, requiring organisations to balance design assurance against delivery speed. The main tradeoff is that clear ownership can slow purchasing if requirements are not standardised, but ambiguity is much more expensive once a vulnerable system is already embedded in a plant or production line.

The strongest model is usually not “one owner for everything,” but a documented allocation of duties across design, integration, operation, and assurance. There is still room for disagreement on how prescriptive buyers should be, especially where safety engineering and cyber security intersect, but there is no real consensus that accountability should remain implicit. In mature programmes, the buyer does not merely ask whether the product is secure; it asks who can prove it, who maintains it, and who carries the risk when that proof is absent.

One common edge case is where an OEM delivers a secure component, but a system integrator weakens it during deployment. Another is where the asset owner accepts a supplier exception without revisiting the operational impact once the system goes live. In both cases, the issue is not just technical weakness; it is the loss of a clear decision boundary. When that happens, responsibility fragments across procurement, engineering, and operations, and no team has enough authority to fix the control gap cleanly.

Practitioner Guidance

What to prioritise: Assign ownership first at the point where a control can be specified, then at the point where it can be validated, and finally at the point where it can be sustained. If those three owners are not named, the control is usually aspirational rather than enforceable.

What to verify: Check that the contract, acceptance criteria, and operational handover all name the same risk owner for exceptions, patch support, and evidence retention. A frequent failure is assuming the supplier owns security because the supplier built the product, when the buyer still owns deployment risk.

Practitioner takeaway: Accountability for security-by-design is strongest when each party owns the decisions it can actually make, not when everyone shares responsibility in theory and no one can be held to proof.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• Who is accountable for enforcing supply chain security across repositories and teams?
• How should security teams implement malware protection across modern software supply chains?
• How should security teams use graph-based context to prioritise application security findings across complex software supply chains?