Who is accountable when exposed credentials or weak supplier controls lead to an incident?

Accountability should sit with the system owner, the identity governance team, and the supplier manager together, because the failure is usually shared across lifecycle, access, and oversight. The right question is not who owns the blame, but who can revoke access, validate scope, and prove the controls worked.

Why This Matters for Security Teams

When exposed credentials or weak supplier controls trigger an incident, accountability usually crosses boundaries that many organisations still manage separately: the business system owner, identity governance, procurement or vendor management, and the supplier itself. That split matters because secrets are not just access artifacts; they are active trust relationships. Once a token, API key, or certificate is exposed, the incident can move faster than normal review cycles, especially when third-party integrations are already trusted by default.

Current guidance suggests treating this as an identity governance failure as much as a supplier risk failure. The OWASP Non-Human Identity Top 10 makes clear that long-lived secrets, excessive permissions, and weak lifecycle control are recurring causes of compromise, while NHIMG’s research on secret sprawl shows how exposed credentials keep creating downstream risk after initial detection. In practice, many security teams encounter accountability gaps only after an exposed secret has already been reused, not through intentional control testing. See OWASP Non-Human Identity Top 10 and Guide to the Secret Sprawl Challenge.

How It Works in Practice

Accountability should be assigned to the parties that can actually reduce blast radius: the system owner for the workload, the identity governance team for credential policy and revocation, and the supplier manager for contractual oversight and assurance. That does not mean shared blame in a vague sense. It means each role must own a concrete control point.

For exposed credentials, the operational sequence is usually straightforward:

• Identify the credential type, scope, and where it was used.
• Revoke or rotate the secret immediately, then invalidate related sessions and tokens.
• Review whether the credential was tied to a supplier account, CI/CD runner, agent, or service integration.
• Check whether the supplier had required controls such as secret scanning, short TTLs, and incident notification obligations.
• Document which control failed first: issuance, storage, detection, or revocation.

That operational split is why static supplier questionnaires are not enough. A supplier can be contractually “approved” while still issuing overprivileged API keys, using shared accounts, or storing secrets in places that are hard to monitor. NIST SP 800-63 helps anchor identity assurance expectations, but it does not by itself solve non-human credential lifecycle. NHIMG’s 52 NHI Breaches Analysis shows how credential exposure repeatedly becomes an incident when rotation, revocation, and scope control are not automated. Security teams should also use Ultimate Guide to NHIs — Static vs Dynamic Secrets to distinguish between recoverable exposures and design flaws. These controls tend to break down when suppliers rely on shared secrets embedded in automation, because the owning team cannot rapidly prove where the credential is used or whether every dependent system has been cut off.

Common Variations and Edge Cases

Tighter supplier control often increases onboarding time and operational overhead, so organisations have to balance speed against containment. Best practice is evolving, but there is no universal standard yet for how deeply a customer should inspect a supplier’s internal secret-handling process.

One common edge case is when the supplier is not the root cause but is the first place the exposure is discovered. In that situation, the supplier may be accountable for notification speed, while the customer remains accountable for deciding whether the secret can be trusted at all. Another is shared infrastructure, where a single exposed key touches multiple tenants, services, or environments. That often makes blame less useful than control mapping.

For regulated environments, the right answer also depends on whether the exposure came from code, chat, ticketing, or a build system. NHIMG’s Reviewdog GitHub Action supply chain attack and Shai Hulud npm malware campaign show why supplier controls and pipeline controls often fail together. Organisations should align these incidents to NIST SP 800-63 Digital Identity Guidelines while recognising that non-human identity accountability still needs local ownership. The practical rule is simple: if a team can revoke, rotate, or restrict it, that team is accountable for making it happen.

Related resources from NHI Mgmt Group

• Who is accountable when stale SSO sessions or weak token controls cause exposure?
• Who is accountable when an OAuth implementation allows weak code exchange controls?
• Who is accountable when certificate-based authentication is rolled out but lifecycle controls are weak?
• How do organisations reduce the dwell time of exposed credentials at scale?