Who should be accountable for third-party non-human identity risk when business tools request elevated access?

Why This Matters for Security Teams

When a business tool requests elevated access, the risk is not just technical. It becomes a governance problem across the team that owns the workflow, the security function that sets boundaries, and the identity function that enforces control. If accountability sits only with a platform administrator, approvals tend to follow convenience instead of business risk, which is exactly how third-party NHIs end up overprivileged and underreviewed. NHIMG notes that 92% of organisations expose NHIs to third parties, which makes shared accountability a practical necessity, not a nice-to-have, as discussed in the Ultimate Guide to NHIs.

Standards-based guidance points in the same direction. The OWASP Non-Human Identity Top 10 treats weak ownership, excessive privilege, and poor lifecycle control as recurring failure modes, while NIST Cybersecurity Framework 2.0 expects clear governance for access decisions, monitoring, and response. In practice, many security teams encounter third-party NHI abuse only after a vendor integration has already been approved, connected, and given more reach than anyone intended.

How It Works in Practice

Accountability should be split by function, but not diluted. Business owners should justify why elevated access is needed, define the workflow outcome, and accept the operational risk of the tool. Security should define the guardrails, including approval thresholds, segmentation, detection, and revocation triggers. Identity governance should ensure the NHI is inventoried, scoped, reviewed, and removed when the business need ends. That model aligns with the control expectations in NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially around least privilege, access enforcement, and monitoring.

For third-party tools, the practical question is who can answer four things at approval time: what data or system the tool needs, why elevated access is necessary, how long that access should last, and who will review usage after issuance. NHIMG’s Top 10 NHI Issues highlights that excessive privilege and poor lifecycle discipline are common, which is why approval should be tied to business ownership rather than delegated entirely to operations. A sound process usually includes:

• named business owner for the integration request
• security approval for privilege scope and logging requirements
• identity governance review for expiration, rotation, and offboarding
• periodic recertification tied to actual business use
• revocation path when the vendor, tool, or workflow changes

Where possible, treat the third-party tool as a distinct NHI with a documented purpose, a bounded permission set, and a clear review cadence. These controls tend to break down when ownership is spread across procurement, IT, and business units without a single party responsible for revocation.

Common Variations and Edge Cases

Tighter approval controls often increase friction and slow down delivery, so organisations have to balance speed against the risk of granting broad, durable access. There is no universal standard for this yet, especially where low-code tools, SaaS connectors, or managed service providers request access on behalf of many users or business functions.

One common edge case is a shared platform integration used by multiple departments. In that case, accountability should still be explicit, but the business owner may need to be a service owner or product owner rather than a single team lead. Another is emergency or break-glass access, where current guidance suggests time-bounded approval with enhanced logging and post-event review rather than standing exceptions. The more autonomous the workflow, the more important it becomes to document who can authorize the tool, who can monitor it, and who must revoke it after the job is done. NHIMG’s 52 NHI Breaches Analysis reinforces that unmanaged access paths often become the first place attackers look. The right accountability model is the one that makes misuse hard, not the one that makes approval easiest.

Related resources from NHI Mgmt Group

• Who is accountable when a leaked non-human identity is used to access production systems?
• Who should be accountable for risky non-human identity access when automation spans multiple platforms?
• Who is accountable for identity risk across employees, third parties, and non-human identities during a cyber incident?
• Who is accountable when a financial institution fails to meet cybersecurity requirements for access control and third-party oversight?