Who is accountable when vendor credentials touch production data?

The organisation that owns the data remains accountable even when access is delegated to a vendor. OAuth grants, API tokens, and federated connections should be reviewed as part of the organisation’s identity perimeter, not left to initial onboarding decisions. If those credentials can reach production, they need the same governance as internal privileged accounts.

Why This Matters for Security Teams

Vendor access is not a side issue once credentials can touch production data. OAuth grants, API tokens, federated sessions, and service accounts all become part of the organisation’s identity perimeter, even if a third party operates them. That means accountability stays with the data owner, not the vendor, because the risk being managed is production exposure, not contract wording. Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-63 Digital Identity Guidelines both points toward stronger control of non-human credentials as first-class identities.

The practical failure is that vendor onboarding often treats access as a procurement problem, then leaves the credential path unmanaged after go-live. That is exactly how secrets sprawl starts, and why NHIMG’s Guide to the Secret Sprawl Challenge matters here: once a token or federated trust is accepted into production, it must be governed as if it were an internal privileged account. In practice, many security teams encounter breach conditions only after a vendor credential has already been reused, over-scoped, or forgotten.

How It Works in Practice

Accountability should be implemented as an identity lifecycle, not a one-time approval. The organisation that owns the data should define who can issue the vendor credential, what systems it can reach, how long it lives, and what evidence is required before and after access. That means inventorying external identities alongside internal NHI, classifying each secret or token by business purpose, and attaching an owner who can revoke it without waiting for vendor support. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because production-grade access should prefer short-lived credentials over long-lived static secrets wherever possible.

Operationally, the control set usually looks like this:

• Use least privilege and separate production from non-production vendor access.
• Issue JIT access for specific tasks, then revoke automatically on completion.
• Prefer workload identity and federated trust over shared API keys.
• Require approval workflows that map access to a named system owner, not just a procurement contact.
• Log token issuance, token use, and token revocation as auditable events.

That approach aligns with the spirit of OWASP Non-Human Identity Top 10, which treats machine credentials as security-relevant identities, not plumbing. It also reflects the reality that vendor access often becomes durable when teams optimise for onboarding speed instead of revocation speed. Where this breaks down is in legacy integrations that depend on static service accounts, because those environments resist JIT issuance and make ownership boundaries hard to enforce.

Common Variations and Edge Cases

Tighter vendor control often increases operational overhead, so organisations need to balance speed against revocation certainty. That tradeoff is real, especially when vendors support multiple environments, shared platforms, or 24×7 production services. Best practice is evolving, and there is no universal standard for every vendor pattern yet, particularly when a third party uses chained federated access rather than a single credential.

One common edge case is break-glass access. It may be justified, but it should still be time-bound, logged, and owned by the data controller rather than the supplier. Another is indirect access through a managed service provider or platform integrator, where the immediate credential holder is not the real operator. In those cases, accountability should follow the path to production data, not the contracting chain. NHIMG’s Cisco Active Directory credentials breach and Reviewdog GitHub Action supply chain attack show how quickly exposed machine credentials can widen impact when trust is inherited without enough review.

For organisations managing AI-enabled or automated vendor workflows, the question becomes even sharper because autonomous tools can request, reuse, or chain access in ways humans did not anticipate. In those cases, the safest approach is to treat every production-reaching secret as a governed asset with a named owner, a documented purpose, and an expiry that matches the actual task, not the contract term.

Related resources from NHI Mgmt Group

• Who is accountable when anonymous credentials are used in production?
• Who is accountable when contractor-held credentials expose cloud and internal systems?
• Who is accountable when a vendor compromise creates internal access risk?
• Why is it important to integrate identity and data governance?