Who is accountable when a vendor or partner uses remote administrative access?

Why This Matters for Security Teams

Remote administrative access is not just a vendor convenience. It is a privileged pathway into production systems, cloud consoles, and identity infrastructure, which means accountability has to stay with the organisation that granted the access. Handing the session to a partner does not transfer ownership of approval, logging, scope, or revocation. Current guidance from the OWASP Non-Human Identity Top 10 treats these access paths as governance-heavy NHI use cases, not informal exceptions.

This is where teams often under-estimate risk: third-party access is usually created for speed, but it accumulates the same control failures seen with internal privileged accounts, including overbroad permissions, weak expiry discipline, and missing offboarding. NHIMG’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which helps explain why partner access so often becomes a supply-chain problem rather than a pure identity problem. In practice, many security teams discover the exposure only after a relationship has ended or a remote support account is still active long after the work was completed.

How It Works in Practice

Accountability should be assigned to the asset owner or system owner on the customer side, with the vendor or partner acting as an authorised operator under defined conditions. That means the granting organisation must decide who approves access, what systems can be touched, how long the access lasts, which sessions are recorded, and what triggers revocation. The control objective is not to trust the partner more; it is to make privileged access measurable, time-bound, and recoverable.

In practice, strong programs use a combination of PAM, JIT access, and workload-aware identity controls. A session may be approved for a specific ticket, launched through a broker, limited to a narrow set of commands, and automatically revoked when the task ends. That model aligns with the broader NHI governance guidance in NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks, especially where credential sprawl and weak lifecycle management create persistence after a partner engagement should have closed.

• Use named sponsorship and explicit business justification for every remote admin grant.
• Bind access to a ticket, service window, or incident scope, not to a standing relationship.
• Require searchable logs, command recording where feasible, and evidence retention for review.
• Separate approval authority from technical execution so no one can self-authorise access.
• Revoke the account, token, or bastion entitlement when the contract, incident, or support window ends.

NIST’s Cybersecurity Framework 2.0 supports this model through governance, access control, and monitoring outcomes, while the practical identity layer should still reflect that the organisation granting access remains responsible for the risk created by that access. These controls tend to break down when remote work is handled through shared admin accounts or direct VPN access because session attribution and rapid revocation become unreliable.

Common Variations and Edge Cases

Tighter control often increases operational friction, so organisations have to balance response speed against accountability. That tradeoff becomes visible in emergency support, break-glass scenarios, and managed service arrangements where an external party needs fast access but the business still needs proof of who did what. There is no universal standard for this yet, but current guidance suggests treating emergency access as short-lived, heavily monitored, and post-approved rather than permanently pre-authorised.

One common exception is incident response, where delaying access can worsen damage. Even then, the granting organisation should preserve ownership of the process by requiring a named internal approver, a fixed expiry, and post-event review. Another edge case is when a partner uses their own tools to administer cloud or SaaS systems. In that case, accountability still sits with the organisation exposed to the change, not with the tool vendor, so long as the access path enters the environment under that organisation’s trust boundary. NHIMG’s 52 NHI Breaches Analysis shows how frequently weak lifecycle discipline and missed offboarding turn temporary access into durable exposure.

For organisations formalising this area, the useful question is not whether the partner was “trusted,” but whether the access was time-bound, attributable, and fully revocable. That is the practical line between governance and unmanaged privilege.

Related resources from NHI Mgmt Group

• Who is accountable when sustained infrastructure attacks disrupt access and availability?
• Who should be accountable when a compromised mailbox leads to fraud or access loss?
• Who is accountable when cloud access expires on paper but persists in practice?
• Who is accountable when an autonomous system acts on access decisions?