Accountability should sit with the business owner of the access, the system owner, and the security team that approved the entitlement. If the relationship is governed well, the vendor can be identified, the session can be reconstructed, and the approval path can be reviewed against policy.
Why This Matters for Security Teams
When a vendor account is misused, the accountability question is not just contractual. It is operational, because the access path usually spans business ownership, technical ownership, and security approval. If entitlement reviews are weak, the organisation may not know whether the issue was overprovisioning, poor segregation of duties, or a vendor-side compromise. That is why current guidance from the NIST Cybersecurity Framework 2.0 emphasises governance, access control, and continuous monitoring rather than assuming the vendor alone is responsible.
NHIMG research shows why this matters: 92% of organisations expose NHIs to third parties, and only 5.7% have full visibility into their service account, according to the Ultimate Guide to NHIs – The NHI Market. In practice, that means an abused vendor account often becomes a shared failure across identity design, approval workflow, and monitoring. Security teams should expect accountability to follow control ownership, not blame alone. In practice, many security teams encounter the misuse only after the session is already over and the approval trail has to be reconstructed retrospectively.
How It Works in Practice
The cleanest accountability model is layered. The business owner is accountable for why the vendor needed access in the first place. The system owner is accountable for how that access was provisioned, scoped, and monitored. Security is accountable for the policy guardrails, such as privileged access management, NIST Cybersecurity Framework 2.0 alignment, and evidence retention. The vendor may be responsible for its own internal controls, but that does not replace the organisation’s duty to limit and review access.
Practitioners should treat vendor misuse as an identity lifecycle problem, not a one-time approval event. That means every vendor account should have:
- a named internal owner;
- a documented business justification;
- least-privilege scope tied to role and task;
- time-bound access with review dates;
- session logging and alerting for sensitive actions;
- offboarding and revocation steps when the work ends.
This approach is consistent with the governance principles in the Ultimate Guide to NHIs – The NHI Market, especially where third-party access and credential hygiene are concerned. It also fits the NIST model of identifying, protecting, detecting, responding, and recovering across the access lifecycle. In mature environments, the question becomes less “who is to blame?” and more “which control failed, and who owns that control?” These controls tend to break down when vendor access is granted through ad hoc shared accounts because attribution, revocation, and session reconstruction all become unreliable.
Common Variations and Edge Cases
Tighter vendor control often increases friction for operations teams and external partners, so organisations have to balance speed against traceability. That tradeoff is especially visible in incidents involving shared admin accounts, emergency access, or managed service providers, where multiple parties can legitimately touch the same environment. Best practice is evolving, but there is no universal standard for assigning blame in every hybrid case.
In regulated or high-risk environments, the preferred pattern is to avoid shared vendor identities altogether and use named accounts, just-in-time elevation, and recorded sessions. Where that is not possible, accountability should be written into the contract, mapped to internal control owners, and reviewed through periodic access attestations. The control objective is not to prove the vendor is solely at fault; it is to ensure the organisation can show who approved the access, who monitored it, and who must remediate it. The governance expectations described in the Ultimate Guide to NHIs – The NHI Market are strongest when paired with policy and accountability language in the vendor agreement, because ambiguous ownership is what turns misuse into prolonged exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Governance and oversight define who owns vendor access risk. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Vendor accounts are NHIs that need ownership, scope, and lifecycle control. |
| CSA MAESTRO | MAESTRO stresses accountability for autonomous and delegated access paths. |
Document decision ownership for delegated access and require evidence for every privileged vendor action.
