Third-party app consent is the permission a user grants for an external application to access cloud data or actions on their behalf. In identity security, it is a trust boundary that should be governed like privileged access. Excessive scopes, weak review, or poor revocation can leave durable exposure.
Expanded Definition
Third-party app consent is the permission boundary that allows an external application to read, write, or act on cloud resources using a user’s delegated access. In NHI governance, it should be treated as a privileged pathway, not a convenience feature. The key issue is not that consent exists, but whether scopes, duration, and revocation are controlled tightly enough to prevent durable access.
Definitions vary across vendors, especially around whether a consent grant is “app trust,” “delegated authorization,” or “OAuth app access.” The operational meaning is the same: the application receives actionable authority that can outlive the original user interaction. Guidance from the OWASP Non-Human Identity Top 10 aligns with this view by treating overbroad delegated access as an identity risk, not merely an app preference.
The most common misapplication is allowing broad consent to be granted once and then forgetting to review it when the user changes role, leaves the company, or the app’s publisher changes behavior.
Examples and Use Cases
Implementing third-party app consent rigorously often introduces friction for users and administrators, requiring organisations to weigh faster onboarding against tighter authorization review.
- A sales team authorizes a calendar integration to read mailboxes and create events. The consent is legitimate, but the scope should be narrowed to the minimum needed for scheduling.
- A productivity app requests tenant-wide file access. Security teams should verify whether the app truly needs broad read access or whether a scoped, per-folder model is possible.
- An employee approves a cloud add-on during a self-service workflow, then leaves the company. Revocation should occur as part of offboarding, not only through password reset.
- A SOC reviews risky OAuth grants after an incident and finds a dormant app still holding access to sensitive data. That pattern is well represented in the 52 NHI Breaches Analysis and in the Klue OAuth Supply Chain Breach.
- A privacy team maps app consent to personal-data processing and retention obligations under the EU General Data Protection Regulation (GDPR) when external apps can access identifiable customer records.
Why It Matters in NHI Security
Third-party app consent becomes dangerous when it is treated as a one-time user choice instead of a standing access relationship. A single consent grant can expose mail, files, tickets, source code, or automation actions for as long as the token or refresh path remains valid. NHI Management Group data shows that 92% of organisations expose NHIs to third parties, underscoring how common this trust boundary is and why consent governance must include app vetting, scope minimization, monitoring, and periodic reauthorization.
This is especially important in supply chain and collaboration tooling, where a malicious or compromised app can silently inherit high-value access through normal user workflows. The same concern appears in incidents covered by the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack, where trusted integrations became an attack path. Organised consent review also supports least privilege and operational trust boundaries described in the OWASP Non-Human Identity Top 10.
Organisations typically encounter the consequences only after a malicious app, leaked token, or ex-employee’s lingering grant is used to access data, at which point third-party app consent becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers excessive delegated access and risky app-to-data trust paths. |
| NIST CSF 2.0 | PR.AA-1 | Identity proofing and access authorization govern who can grant app access. |
| NIST Zero Trust (SP 800-207) | Zero trust limits implicit trust in third-party applications and tokens. | |
| NIST SP 800-63 | Delegated access depends on the strength and assurance of the authenticated user session. | |
| NIST AI RMF | Managing app consent is a governance and risk evaluation problem. |
Ensure the user session and authenticator strength are appropriate before high-risk consent is accepted.
Related resources from NHI Mgmt Group
- What breaks when organisations cannot see third-party app consent clearly?
- How should security teams govern third-party SaaS app consent so access does not outlive the approving user?
- When should organisations revoke an OAuth grant or third-party app permission?
- How should security teams respond when a third-party OAuth app is compromised?
