Who is accountable when a supplier account is used in an attack?

Why This Matters for Security Teams

Supplier accounts sit at the junction of business trust, identity governance, and third-party risk, which is why accountability becomes blurred during an incident. Attackers rarely care whether a login belongs to a vendor, a contractor, or an internal service; they care whether the account still works. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks shows how often organisations keep secrets and access paths alive long after they should be retired, and that pattern is what turns supplier access into a durable attack path.

This is not only an offboarding problem. It is also a governance problem because the business owner approved the access, the identity team managed the entitlements, and the vendor process was supposed to remove them when the relationship changed. Guidance from CISA cyber threat advisories consistently reinforces that exposed or stale credentials are operationally exploitable long before they are formally discovered. In practice, many security teams encounter supplier-account abuse only after anomalous activity is already underway, rather than through intentional access review.

How It Works in Practice

Accountability should be mapped across the full lifecycle of the supplier identity, not just the moment of compromise. The approving business function owns the access decision, the identity team owns provisioning and control enforcement, and vendor management owns the review cadence, contract boundaries, and offboarding trigger. If any one of those steps fails, the attacker inherits a path that should have been removed.

A practical response starts with knowing whether the supplier account is human-operated, service-based, or used by an AI agent. For AI-driven or autonomous workflows, static role assignments are often too blunt. Current guidance suggests combining least privilege with time-bound access, workload identity, and request-level policy evaluation. That means short-lived credentials, explicit approval for high-risk actions, and revocation tied to task completion rather than calendar-based cleanup.

• Assign a named business owner for every supplier account and record the approved purpose.
• Use Ultimate Guide to NHIs — Why NHI Security Matters Now to benchmark lifecycle controls against real-world NHI exposure patterns.
• Enforce just-in-time access and revoke credentials automatically when the engagement ends.
• Require periodic attestation from procurement, security, and the consuming system owner.
• Log the source of truth for every entitlement change so accountability is auditable after the fact.

For incident analysis, evidence from 52 NHI Breaches Analysis is useful because supplier-linked access often behaves like other non-human identity failures: hidden sprawl, weak rotation, and delayed revocation. These controls tend to break down when supplier access is shared across teams and no single system records who approved, renewed, and retired it.

Common Variations and Edge Cases

Tighter supplier controls often increase operational overhead, so organisations must balance faster onboarding against stricter revocation and review discipline. That tradeoff becomes sharper when the supplier provides managed services, development support, or machine-to-machine integrations, because the account may be essential to operations even while remaining high risk.

There is no universal standard for this yet, but current guidance suggests treating supplier access as a governed identity class rather than as a one-time procurement artifact. That matters when the account is embedded in CI/CD pipelines, shared by multiple vendor staff, or used by an outsourced AI agent. In those cases, accountability should still be traceable to the internal owner who accepted the risk, even if the external party executed the activity. The real question is not whether the vendor used the account, but whether internal controls left it active, overprivileged, or unreviewed.

Security teams should also expect disputes when contracts are vague, because legal ownership and technical accountability are not the same thing. A vendor may be contractually liable, but the internal organisation is still accountable for access governance if it failed to monitor, rotate, or revoke the account. The fastest way to reduce that ambiguity is to tie supplier identity reviews to Anthropic’s report on AI-orchestrated cyber espionage and the MITRE ATLAS adversarial AI threat matrix when automated or agentic tools are in scope.

Related resources from NHI Mgmt Group

• Who is accountable when compromised credentials are used to access personal or infrastructure accounts?
• Who is accountable when an LLM denial-of-service event is triggered by a legitimate user or service account?
• Who is accountable when a stolen session is used to pivot into SaaS platforms?
• Who is accountable when cloud data is exposed through a shared account or snapshot?