Who is accountable when a user grants a risky third-party app access?

Why This Matters for Security Teams

A risky third-party app can turn a routine consent action into a governance event with enterprise-wide impact. The user may click approve, but the organisation defines the boundary through policy, SaaS configuration, and delegated access review. That is why accountability is not treated as a purely individual decision. Current guidance from NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward governance, visibility, and enforcement rather than blame after the fact. NHIMG research also shows how widespread delegated-risk exposure is: in the Ultimate Guide to NHIs, 92% of organisations expose NHIs to third parties. In practice, many security teams encounter over-privileged access only after data sharing, mailbox access, or API misuse has already occurred, rather than through intentional consent design.

How It Works in Practice

Accountability works best when it is split across three layers: the user, the application owner, and the security function. The user initiates consent, but the enterprise owns the policy that determines which apps can request access, which scopes are acceptable, and when approval must be blocked or escalated. Security teams should treat third-party app access as an identity and secrets problem, not just a SaaS settings problem. That means enforcing RBAC where it helps, but pairing it with PAM, JIT approval, and scope-based restrictions so access is limited to the minimum necessary duration and permissions. It also means recording who approved what, when, and for what purpose, so incident response can trace delegated access back to a business owner.

For organisations managing high-risk integrations, the practical control set usually includes app allowlisting, admin consent workflows, periodic re-certification, and automated revocation for unused tokens. NHIMG’s 52 NHI Breaches Analysis and Top 10 NHI Issues show how quickly delegated trust becomes a persistence path when credentials and scopes are not reviewed. That is consistent with the intent of NIST Cybersecurity Framework 2.0: identify, protect, detect, respond, and recover are all needed when consent creates standing access.

• Define which app classes can receive consent without admin review.
• Require business owners for high-risk scopes, especially mail, file, and directory access.
• Review delegated access on a fixed schedule and revoke stale grants quickly.
• Log approval context so the enterprise can prove ownership during incident review.

These controls tend to break down when consent is spread across shadow IT, personal productivity tools, and unmanaged SaaS tenants because the organisation loses both visibility and revocation reach.

Common Variations and Edge Cases

Tighter consent controls often increase friction for end users, requiring organisations to balance productivity against exposure. That tradeoff is real, especially where employees rely on third-party apps for collaboration or automation. Current guidance suggests the answer is not to ban every integration, but to differentiate low-risk from high-risk access and apply stronger checks where the blast radius is larger. For example, read-only calendar access is not equivalent to mailbox send-as permissions or directory-wide data export. The same logic applies to non-human identities created by those apps: their secrets, tokens, and refresh grants must be governed as credentials, not convenience artefacts.

There is no universal standard for this yet, but mature programmes increasingly align delegated-access governance with OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs — Key Challenges and Risks. The edge case to watch is when a third-party app becomes an internal automation layer, then inherits broad API access without formal ownership. In that situation, accountability shifts from the individual user who clicked approve to the platform, security, and application owners who failed to set guardrails. Best practice is evolving, but the operational rule is stable: if the enterprise allows the grant, the enterprise must own the outcome.

Related resources from NHI Mgmt Group

• Who is accountable for third-party access after a campaign or project ends?
• Who should own third-party access risk in a banking GRC programme?
• Who is accountable when a third-party integration keeps an NHI active after the business need ends?
• Who is accountable when a third-party NHI causes PCI scope exposure?