Who is accountable when a connected app grants unauthorised access to data?

Why This Matters for Security Teams

When a connected app grants unauthorised access, the failure is rarely only technical. The real issue is that the app is acting with delegated authority, so any weak approval path, overbroad token scope, or missing offboarding control can turn a routine integration into a data exposure event. NHIs are already a high-risk surface: the Ultimate Guide to NHIs reports that 92% of organisations expose NHIs to third parties, and 97% carry excessive privileges.

That matters because accountability must be assigned before the incident, not argued after it. Security teams often assume the vendor owns the failure, while business owners assume IAM has it covered, and the gap between those assumptions becomes the breach path. Current guidance from the OWASP Non-Human Identity Top 10 is clear that overprivileged machine access and weak lifecycle controls are recurring causes of unauthorised access. In practice, many security teams encounter this only after data has already moved through an approved connector that nobody thought to continuously review.

How It Works in Practice

Accountability for connected apps is shared, but the responsibilities are distinct. The business owner should approve the use case and confirm the data the app is allowed to reach. The IAM or security team should define the control model for scopes, consent, token lifetime, revocation, and logging. The vendor or integration owner should ensure the app does not request or retain more access than needed, and that offboarding actually breaks the trust path.

Practically, this means the control design has to follow the token path, not just the application name. Teams should be able to answer: who approved the connection, what data classes were exposed, what scopes were granted, where the secrets live, how quickly access can be revoked, and who receives alerting when the connector acts outside expected behaviour. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it connects poor lifecycle control with exposure, while OWASP Non-Human Identity Top 10 reinforces least privilege, rotation, and revocation as core controls.

• Document the approving owner and the data owner separately.
• Bind every connected app to a named integration record and scope review.
• Use short-lived credentials and fast revocation for abandoned apps.
• Log consent changes, token issuance, and access to sensitive datasets.
• Test offboarding so removing an app actually removes access.

For implementation, many organisations map these controls to Zero Trust and secrets governance so the token is treated as a high-value identity artifact, not a simple API convenience. These controls tend to break down when legacy SaaS connectors reuse long-lived refresh tokens because revocation is delayed, opaque, or dependent on manual vendor support.

Common Variations and Edge Cases

Tighter access controls often increase operational overhead, so organisations have to balance faster integration delivery against stronger review and revocation discipline. That tradeoff becomes more visible when third-party apps are embedded in finance, HR, or customer data workflows, where business units want rapid deployment but the security consequences are material.

There is no universal standard for this yet, but current guidance suggests treating different connection types differently. A low-risk productivity app may be governed through standard approval and periodic review, while an app handling regulated data should require explicit data-owner signoff, scoped consent, and event-based review. The 52 NHI Breaches Analysis is a practical reminder that incidents often involve forgotten integrations, stale credentials, or excessive permissions rather than exotic exploits.

One useful operational rule is that accountability should follow the party best positioned to prevent the failure: business for approval, security for control design, and vendor or integration owner for technical exposure. Where that breaks down is in shadow IT, unmanaged OAuth grants, and partner-managed apps, because no single team has full visibility and the authority chain becomes fragmented.

Related resources from NHI Mgmt Group

• Who is accountable when a remote work setup leads to overexposed access or data movement?
• Who is accountable when a user grants a risky third-party app access?
• How should organisations implement CJIS access controls for law enforcement data?
• Who is accountable when a third-party verification provider mishandles identity data?