Who is accountable when a third-party credential is misused?

Accountability sits with the organisation that issued or retained the credential, even when a third party held it. That means supplier review, permission scoping, and offboarding discipline must be built into the contract and the IAM process. If the secret can still work, the governance failure is still yours.

Why This Matters for Security Teams

When a third-party credential is misused, the incident is rarely just a supplier problem. It usually exposes a gap in inventory, scoping, revocation, or monitoring inside the organisation that issued, stored, or allowed the credential to persist. That is why accountability follows control, not possession. If an external partner can still authenticate, the internal governance model has already failed.

This is especially visible in supply-chain incidents where secrets leak into build systems, repos, or package workflows. Cases like the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack show how quickly exposed secrets become someone else’s access path. Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-63 Digital Identity Guidelines points in the same direction: identity proofing, lifecycle control, and revocation discipline must be operational, not assumed.

In practice, many security teams only discover the accountability gap after an external dependency has already been abused and the credential trail has become forensic debris.

How It Works in Practice

Accountability should be assigned to the party that defined the trust boundary, because that party chose the credential type, allowed its scope, and decided how it would be revoked. For third parties, that means the contract and IAM process must define who can issue secrets, who can rotate them, what event triggers offboarding, and what telemetry proves the secret is no longer active. If a supplier receives an API key, certificate, token, or PAM-backed session, the organisation still owns the governance outcome.

A practical model is to treat third-party access as a managed non-human identity rather than as an informal vendor convenience. That means:

• Issue only the minimum scope needed for a defined business purpose.
• Prefer short-lived credentials over long-lived static secrets.
• Require JIT access where feasible so credentials expire after the task ends.
• Track every credential to an owner, a supplier, a workload, and a revocation path.
• Verify offboarding with automated checks, not only contract language.

The strongest programmes align this to the lifecycle lessons in the Ultimate Guide to NHIs — Static vs Dynamic Secrets and the breach patterns described in the 52 NHI breaches Report. Those patterns show that once a secret exists outside visible governance, revocation becomes slower than misuse. The control objective is simple: reduce standing exposure, confirm who can act, and remove trust as soon as the business need ends. These controls tend to break down when suppliers share credentials informally across teams because ownership, rotation, and revocation become ambiguous.

Common Variations and Edge Cases

Tighter third-party credential control often increases onboarding effort and vendor friction, so organisations have to balance speed against the cost of unmanaged exposure. That tradeoff becomes sharper when a supplier runs critical integrations or supports many customer environments, because aggressive revocation can interrupt service if the identity model is weak.

There is no universal standard for this yet, but current guidance suggests different handling based on credential type. A shared secret in a script is a poor control choice because it is hard to attribute and even harder to revoke cleanly. A federated workload identity, a short-lived token, or a brokered session gives much better accountability because it ties use to a specific system and time window. Where suppliers cannot support that model, the risk should be explicit and compensating controls should include tighter logging, narrower scope, and faster rotation.

Two NHIMG research threads are useful here: the Guide to the Secret Sprawl Challenge shows how credentials multiply across toolchains, while the 52 NHI Breaches Analysis shows how weak lifecycle controls repeatedly turn into incident response problems. In a mature programme, the question is not whether the third party held the secret, but whether the organisation could still prove who owned it, who could use it, and when it stopped working. That distinction matters most in hybrid environments where revocation delays and shared admin paths blur accountability.

Related resources from NHI Mgmt Group

• How can organizations manage the risk of credential leaks in MCP frameworks?
• Should organisations prioritise external exposure or internal credential governance first?
• Who is accountable when ServiceNow leaks credentials or internal data?
• How do third-party SaaS integrations create NHI risk and how should they be managed?