Who is accountable when a third-party identity causes a manufacturing incident?

Why This Matters for Security Teams

When a third-party identity triggers a manufacturing incident, the failure is rarely just technical. The real issue is whether the business owner approved, monitored, and retired that access on time. NHI Mgmt Group’s Ultimate Guide to NHIs shows how often non-human access is over-privileged, poorly rotated, and left active long after it should have been removed.

This matters because vendor identities sit in the same control plane as production systems, OT-adjacent integrations, CI/CD runners, and API-driven workflows. A third-party account that outlives its task can become a persistent path into manufacturing schedules, recipe systems, or telemetry feeds. That is why accountability cannot stop at “security approved it” or “the vendor owns it.” Governance has to follow the access lifecycle.

OWASP’s Non-Human Identity Top 10 frames this as a control failure around lifecycle, privilege, and secrets handling, not a one-off misuse event. In practice, many security teams encounter the incident only after a vendor token has already been used outside its intended task window, rather than through intentional lifecycle review.

How It Works in Practice

Accountability should be assigned to the business owner of the access, with security, IT, procurement, and the vendor each holding defined operational duties. The owner defines the purpose of the third-party identity, approves scope, and confirms when the task ends. Security sets policy and verification requirements, while platform teams enforce them in code and controls. This model aligns with the lifecycle emphasis in 52 NHI Breaches Analysis, where compromised or unmanaged non-human identities repeatedly show up as an avoidable entry point.

In practice, the control stack should cover four steps:

• Pre-approval with clear business justification, risk rating, and named owner.
• Time-bound access with just-in-time issuance, short TTLs, and automatic revocation.
• Continuous logging of use, including what system was accessed and whether the access matched the approved purpose.
• Offboarding proof, such as ticket closure, revocation records, and post-task validation.

For manufacturing environments, that usually means vendor identities should be treated as workload identities, not as durable shared accounts. Current guidance suggests pairing access ownership with strong secrets hygiene and deterministic offboarding, as described in NHI Mgmt Group’s Ultimate Guide to NHIs. Where mature governance exists, it is easier to prove whether a contractor, integrator, or managed service provider actually had authority at the time of the incident. These controls tend to break down when multiple plants reuse the same vendor account because revocation then becomes ambiguous and cross-site impact is hard to contain.

Common Variations and Edge Cases

Tighter third-party control often increases operational overhead, requiring organisations to balance incident prevention against onboarding speed and vendor convenience. That tradeoff becomes sharper in manufacturing, where maintenance windows are short and supplier access is sometimes needed urgently. Best practice is evolving, but there is no universal standard for this yet: some organisations centralise accountability in procurement, while others place it with the operational system owner or plant manager.

There are also edge cases where accountability is shared. If the vendor was granted access with an approved expiration date but no one removed it, the business owner owns the governance failure and security owns the control gap. If the vendor supplied a managed service account, the organisation still remains accountable for whether the account was scoped, monitored, and revoked correctly. If approval evidence is missing, the problem shifts from misuse to control design and auditability.

For teams trying to strengthen this area, the practical test is simple: can they prove who approved the third-party identity, what it could do, when it was supposed to stop working, and who verified that it actually did stop? If any of those answers are unclear, accountability has already leaked across the organisation. The most common failure pattern is not malicious vendor behavior, but a missing owner for offboarding and exception closure.

Related resources from NHI Mgmt Group

• Who is accountable when a third-party identity causes data exposure?
• Who is accountable when a vendor’s access causes a third-party breach in manufacturing?
• Who is accountable when a compromised identity disrupts manufacturing operations?
• Who is accountable when a third-party NHI causes PCI scope exposure?