Who is accountable when a vendor causes a cyber incident?

Why This Matters for Security Teams

A vendor-caused incident is rarely just a vendor problem. Once a third party receives credentials, tokens, API keys, or privileged access, the buying organisation has already made a governance decision that must be owned, monitored, and reversed when risk changes. That is why third-party exposure often shows up in NHI and agentic workflows, not just classic SaaS integrations. NHIMG research shows that 92% of organisations expose NHIs to third parties, and only 20% have formal offboarding and revocation processes, which helps explain why vendor risk becomes an internal control gap so quickly. See Ultimate Guide to NHIs — Key Challenges and Risks and CISA cyber threat advisories for the broader operating model around shared risk.

The practical issue is accountability drift: procurement approves the supplier, IAM provisions access, security expects monitoring, and the business owner assumes the vendor is responsible for what happens next. When no one owns the whole lifecycle, incidents are detected late, containment is slow, and revocation is inconsistent. In practice, many security teams encounter this only after a vendor credential has already been abused, rather than through intentional lifecycle governance.

How It Works in Practice

Accountability should be split by duty, not blurred by blame. The vendor is accountable for the behaviour of its personnel, tooling, and controls. The buying organisation is accountable for the access it granted, the data it exposed, and the conditions it allowed. That means a named business owner, IAM, security, and procurement each need explicit responsibilities across onboarding, approval, monitoring, review, suspension, and offboarding. Current guidance suggests treating vendor access like any other high-risk identity path: least privilege, time limits, logging, and regular attestation.

For NHIs, the access path must be managed as a workload identity problem, not only a human vendor problem. Secrets should be short-lived where possible, rotated aggressively, and tied to task scope. JIT provisioning is preferable to standing access when the use case allows it. For autonomous or agentic vendor systems, static RBAC often fails because behaviour changes at runtime. That is where intent-based authorisation and policy-as-code become more useful than fixed role maps. See 52 NHI Breaches Analysis, Ultimate Guide to NHIs — Why NHI Security Matters Now, and the Anthropic — first AI-orchestrated cyber espionage campaign report for evidence that autonomous behaviour changes the risk model.

• Assign one accountable owner for every vendor identity, secret, and integration.
• Require expiry, rotation, and revocation triggers for all secrets and API keys.
• Log vendor actions at the tool, workload, and data layer, not just the login layer.
• Review access on schedule and after any incident, scope change, or contract change.

These controls tend to break down when vendors operate nested subcontractors, shared service accounts, or autonomous agents that can chain tools faster than human review can keep up.

Common Variations and Edge Cases

Tighter vendor control often increases operational overhead, requiring organisations to balance faster delivery against stronger containment. In mature environments, the hardest cases are not obvious shared accounts but delegated automation, managed services, and agentic workflows where the vendor’s system acts on the buyer’s behalf. In those cases, there is no universal standard for this yet, but current guidance suggests treating each execution path as a separate trust decision rather than assuming one vendor contract covers all access.

One common edge case is a breach that starts at the vendor but is amplified by weak customer-side controls. If the buyer never scoped access, never reviewed tokens, or never enforced expiry, liability may be shared contractually, yet operational accountability still sits with the organisation that allowed persistent access. NHIMG’s research shows that 71% of NHIs are not rotated on time, and that 97% carry excessive privileges, which is why third-party incidents so often become internal privilege problems. For a deeper view of the breach pattern, see The 52 NHI breaches Report and Top 10 NHI Issues.

For agentic or semi-autonomous vendor services, the accountability model should also include runtime policy enforcement and emergency kill-switches. That aligns with emerging practices in MITRE ATLAS adversarial AI threat matrix and the governance emphasis in OWASP NHI Top 10, but these controls are still evolving rather than universally standardised.

Related resources from NHI Mgmt Group

• Who is accountable when a privileged non-human identity causes a security incident?
• Who is accountable when a vendor breach exposes downstream client data?
• Who is accountable when a vendor identity failure exposes institutional data?
• Who is accountable when an AI agent causes a clinical access problem?