A connected app is a third-party integration that is granted access to a SaaS platform through APIs and OAuth permissions. From a governance perspective, it is an identity-bearing access path that needs ownership, scoping, and periodic review like any other non-human identity.
Expanded Definition
A connected app is a SaaS integration that authenticates through OAuth scopes, API permissions, or delegated tokens to act on behalf of a user or service. In NHI governance, it is not just a convenience feature; it is an identity-bearing access path that needs an owner, a purpose, and a review cycle.
Definitions vary across vendors because some platforms treat connected apps as simple integrations while others expose them as first-class enterprise identities. For security teams, the practical distinction is whether the app can read data, write data, trigger workflows, or expand into tenant-wide privileges. That is why connected apps should be assessed alongside service accounts, API keys, and other NHI forms described in the Ultimate Guide to NHIs. The access model also maps closely to least privilege and continuous verification concepts in the NIST Cybersecurity Framework 2.0, especially when scopes are broad or long-lived.
Because connected apps often inherit trust from an employee who approved them once, they can outlive the business need that created them. The most common misapplication is treating a connected app as a static SaaS feature, which occurs when no one revalidates scopes after the original business workflow changes.
Examples and Use Cases
Implementing connected app governance rigorously often introduces user friction and administrative overhead, requiring organisations to weigh faster SaaS adoption against tighter control over delegated access.
- A sales team authorises a CRM integration to sync contacts and calendar events, but security later narrows scopes because the app also requested mailbox access that was never needed for the business workflow.
- An HR platform connects to a collaboration suite to provision users and update profiles, and the integration must be reviewed as an NHI because it can create, modify, and deactivate identities across systems.
- A developer installs an automation app in a ticketing platform, and the app is later found to have broad write permissions that should be governed with the same discipline described in the Ultimate Guide to NHIs.
- A finance team links a reporting tool to a cloud workspace, then limits the OAuth grant after mapping the permission set to the organisation’s control expectations in the NIST Cybersecurity Framework 2.0.
- A third-party AI assistant is approved to summarise documents, but its real risk comes from the scope that lets it read shared files and post results into production channels.
Why It Matters in NHI Security
Connected apps matter because they frequently become invisible privilege sprawl. Once granted, they can persist through employee turnover, team reorgs, and vendor changes, which means their access often survives longer than the original justification. That creates a familiar NHI failure mode: an integration keeps functioning even after nobody remembers who approved it or why.
That risk is not theoretical. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, and connected apps are a common place where that excess accumulates through broad OAuth consent and weak ownership. NIST’s guidance on governance and access control in the NIST Cybersecurity Framework 2.0 reinforces the need to identify, scope, and monitor these access paths continuously.
Practitioners also need to remember that connected apps are part of the external attack surface. If a malicious or compromised integration is trusted inside a SaaS tenant, the blast radius can include data exfiltration, workflow tampering, and lateral movement into connected systems. Organisations typically encounter the consequence only after a breach review or access audit, at which point the connected app 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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Connected apps are NHI access paths that must be scoped and reviewed. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions for integrations align with least-privilege governance. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires continuous verification of delegated app access. |
Treat every connected app as untrusted until its identity, scope, and context are verified.
