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

Why This Matters for Security Teams

Security-by-design across OEM and ICS supply chains fails when accountability is blurred between the buyer, the manufacturer, and the integrator. Asset owners can set requirements, but if OEMs do not engineer secure defaults, signed updates, strong credential handling, and verifiable logging into the product, the weakest link becomes an operational shortcut. This is especially true in industrial environments where a single inherited trust path can reach multiple plants or vendors.

NHIMG research on supply chain incidents shows how quickly insecure dependencies and exposed credentials turn into enterprise-wide exposure, as seen in the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign. The pattern is familiar: assurance breaks not because no one cared, but because no one was explicitly accountable for each control at design time. Current guidance also aligns with the OWASP Non-Human Identity Top 10, which treats machine and supplier identities as governance objects, not incidental implementation details.

In practice, many security teams discover ownership gaps only after a vendor remote-access path, update mechanism, or embedded credential has already been exploited.

How It Works in Practice

The practical model is shared accountability with named ownership. Asset owners define security outcomes, procurement language, and acceptance criteria. OEMs and ICS manufacturers are accountable for implementing those controls in firmware, software, service interfaces, and update workflows. Integrators and operators are accountable for safe deployment, monitoring, and compensating controls where the product cannot meet the requirement.

That division works only when the contract and the technical architecture match. For industrial products, this means requiring secure-by-default configuration, unique device identity, signed and verifiable updates, secretless or tightly scoped machine credentials, and audit evidence that survives support handoffs. The NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control vocabulary, but the accountability question is operational: who designs it, who validates it, and who proves it still works after deployment?

For NHI and machine access in these environments, the same logic applies to supplier-issued secrets, service accounts, API keys, and remote maintenance identities. NHIMG’s The State of Secrets in AppSec shows how fragmented secrets governance creates persistent risk, and that translates directly to industrial supply chains where long-lived credentials often outlive the equipment they protect. A mature program assigns design authority to the OEM, approval authority to the buyer, and continuous assurance to both sides through testing, attestations, and revocation readiness.

These controls tend to break down in legacy ICS fleets where vendor patching is infrequent, remote support is shared across customers, and the product cannot support unique identities or automated revocation.

Common Variations and Edge Cases

Tighter supplier accountability often increases procurement friction, certification cost, and deployment delay, so organisations have to balance assurance against operational continuity. That tradeoff is real in ICS, where uptime, safety, and patch windows can limit how far security-by-design can be enforced retroactively.

Best practice is evolving for situations where the OEM is no longer in business, the system is air-gapped, or the integrator is effectively acting as the manufacturer of record. In those cases, accountability should shift to the party with the most control over residual risk, usually the asset owner or prime integrator, but only for the controls they can actually implement. There is no universal standard for this yet, which is why contracts should spell out minimum design obligations, evidence requirements, and incident support timelines rather than relying on informal vendor trust.

For supplier identities, remote service channels, and machine-to-machine trust, the same issue appears in different form: if a third party can patch, monitor, or administer the environment, then that third party must also be accountable for how its credentials are protected and revoked. NHIMG’s 52 NHI Breaches Analysis reinforces that non-human access failures are rarely isolated events; they spread when ownership is unclear and controls are inherited without verification.

Current guidance suggests the safest pattern is to treat security-by-design as a shared contractual obligation with explicit technical checkpoints, not a one-time compliance statement.

Related resources from NHI Mgmt Group

• Who is accountable for partner enablement when identity security programs expand across regions and industries?
• Who should be accountable for workload identity security across platform, identity, and security teams?
• How should security teams extend change management across design, code, and cloud?
• How should security teams reduce the risk of phishing-led repository compromise in software supply chains?