Who is accountable when third-party credentials are used to reach enterprise systems?

Why This Matters for Security Teams

Third-party credentials are not just an access convenience; they are a delegated trust decision that can reach the core of enterprise systems. Once support engineers, contractors, or outsourced operators use shared, borrowed, or long-lived credentials, accountability becomes split across identity governance, vendor management, and operational oversight. That split is where incidents turn into governance failures, especially when access is granted faster than it is reviewed.

NHI Management Group’s research on the 2024 Non-Human Identity Security Report shows how immature non-human access practices remain across organisations, with many still relying on static secrets and inconsistent lifecycle control. That matters here because third-party access behaves like a non-human identity problem even when a person is driving it. The security team must know who owns the account, who approved the scope, who monitors usage, and who can revoke it without waiting on a ticket queue. Guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-63 Digital Identity Guidelines both reinforce the point that identity assurance and lifecycle control are inseparable from access governance.

In practice, many security teams discover the ownership gap only after a vendor account has outlived the contract or been reused outside its intended scope.

How It Works in Practice

Accountability starts by treating every third-party credential as a governed identity with a named business owner, technical owner, and expiration path. The enterprise that grants access remains responsible for the system and the authorization boundary, while the third party remains responsible for how its personnel use the access. That shared model is the practical answer, but it only works if the workflow is explicit.

Current best practice is to bind the credential to a specific task, environment, and time window. That usually means just-in-time provisioning, short-lived tokens, strong session logging, and immediate revocation when the task ends. For systems with higher sensitivity, policy should be evaluated at request time rather than relying only on static role assignments. In many environments, that is where NIST SP 800-53 Rev. 5 Security and Privacy Controls and the OWASP NHI guidance translate into operational steps: approve the minimum entitlement, record the approver, monitor every action, and force revalidation when the context changes.

• Assign one accountable internal owner for every third-party account.
• Use unique credentials, not shared vendor logins, whenever possible.
• Set short TTLs and require re-approval for renewal.
• Log the human operator, the vendor, the target system, and the session purpose.
• Revoke access automatically when the contract, ticket, or maintenance window closes.

NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is a useful reminder that long-lived secrets create durable blast radius, while dynamic secrets make attribution and rollback far more reliable. These controls tend to break down when vendors insist on shared administrative access across multiple clients because attribution and revocation become ambiguous.

Common Variations and Edge Cases

Tighter third-party control often increases onboarding friction and support overhead, so organisations have to balance faster delivery against clearer accountability. That tradeoff is especially visible in managed services, incident response retainers, and legacy platforms that were never designed for per-user delegation.

There is no universal standard for this yet, but current guidance suggests that organisations should avoid treating every third-party account the same. A break-glass account for emergency recovery needs different controls from a routine contractor login, and a machine-to-machine integration should follow workload identity patterns rather than person-based access. In agentic or automated support scenarios, the account may be operated by a human one day and a workflow the next, which makes the provenance of the action more important than the nominal account owner.

NHIMG’s 52 NHI Breaches Analysis and Guide to the Secret Sprawl Challenge both reflect the same operational lesson: the most common failure is not initial access, but uncontrolled persistence after the business need changes. In high-churn environments, accountability breaks down when access reviews are scheduled but not tied to actual usage, because stale approvals create a false sense of control.

Related resources from NHI Mgmt Group

• Who is accountable when a third-party service desk is used to reach client systems?
• Who is accountable when a third-party identity is used in an insider incident?
• Who is accountable when a third-party enterprise application is exploited through a zero-day?
• What breaks when a third-party support platform can reach internal systems?