Who should own access accountability when vendor-managed OT software is involved?

The operating organisation must own the governance outcome even when the software is vendor-managed. That means every exception needs a named business owner, a documented purpose, and a lifecycle trigger for review or removal. Without that, vendor access becomes persistent by default and auditability collapses.

Why This Matters for Security Teams

When vendor-managed OT software is involved, access accountability does not shift to the supplier just because the tooling is externally operated. The operating organisation still owns the risk, the exception process, and the audit trail. That matters because vendor access often becomes the easiest path to production systems, especially when contracts focus on uptime while governance remains vague.

NHI Management Group’s Ultimate Guide to NHIs shows why this pattern is dangerous: 92% of organisations expose NHIs to third parties, and only 20% have formal processes for offboarding and revoking API keys. In OT environments, that combination creates persistent access by default unless ownership, review cadence, and removal triggers are explicitly assigned. The governance question is not who administers the software, but who can answer for access decisions when something goes wrong.

That is also consistent with the NIST Cybersecurity Framework 2.0, which treats accountability and oversight as core governance functions, not optional controls. In practice, many security teams encounter vendor access sprawl only after an incident review exposes that no business owner could explain why the access still existed.

How It Works in Practice

Ownership should be split between operational execution and governance authority. The vendor may administer patches, support sessions, and monitored maintenance windows, but the operating organisation must own the approval, scope, and expiry of every access exception. A named business owner should be accountable for the purpose of the access, the asset or site it applies to, and the trigger that forces review or removal.

For OT software, this usually means replacing standing vendor accounts with time-bound, task-bound access. The control should require:

• a named internal owner for each vendor account or access pathway
• a documented business justification tied to a specific system, site, or maintenance event
• approval from operations and security before activation
• expiry dates or event-based revocation tied to change windows, contract end, or incident response
• logging that preserves who requested, approved, used, and closed the access

This is aligned with the OWASP Non-Human Identity Top 10, which highlights the security failure modes that appear when machine identities are over-permissioned or left ungoverned. It also matches NHIMG’s Lifecycle Processes for Managing NHIs, where lifecycle ownership, rotation, and offboarding are treated as essential rather than administrative afterthoughts.

In operational terms, the strongest model is to treat vendor access like any other privileged NHI: assign a business owner, bind it to a lifecycle, and make removal automatic when the purpose ends. These controls tend to break down when OT vendors require shared support accounts across multiple plants because accountability becomes diffused and revocation becomes operationally risky.

Common Variations and Edge Cases

Tighter vendor access controls often increase coordination overhead, requiring organisations to balance maintenance availability against governance discipline. That tradeoff is real in OT, where safety, uptime, and legacy protocols can make just-in-time approval harder than in IT environments.

Best practice is evolving, but current guidance suggests the operating organisation should still own the exception even if the vendor owns the tooling. For high-availability plants, that may mean pre-approved maintenance windows, break-glass access with enhanced logging, or supervisory access that is reviewed after each use. For remote support, it may mean separate identities per technician, per vendor, and per site rather than a single shared credential.

NHIMG’s Regulatory and Audit Perspectives is useful here because audit teams typically care less about who clicked the button and more about whether the organisation can prove ownership, purpose, and removal. In mature programs, vendor access is reviewed alongside Top 10 NHI Issues so that excessive privilege, stale accounts, and missing offboarding are managed as one control problem rather than separate tickets.

The edge case is third-party emergency support during live incidents. Even then, the organisation should retain named accountability, because vendor urgency does not replace internal ownership, and post-incident review becomes impossible when no one can justify the access that was granted.

Related resources from NHI Mgmt Group

• Who should own database access accountability when contractors or service teams are involved?
• Why do SSO tools often fail to solve access governance on their own?
• Who should own access decisions when service management and IAM are connected?
• Who should own SaaS governance when access, licensing, and renewals overlap?