Connected applications are external apps, games, or websites that are linked to an online account through an authorization prompt. Once connected, they may inherit access to selected account data or functions. Their risk depends on the permissions granted, the data exposed, and whether the service remains trusted and maintained.
What Connected Applications Are
Connected applications are third-party services that a user links to an account by approving an authorization prompt. The connection can grant limited access to profile data, content, or actions, so the relationship is defined as much by permissions as by the app itself.
How Connected Applications Work
A connected app usually uses a delegated authorization flow, such as OAuth-based consent, so the user grants the app specific scopes instead of sharing the account password. That distinction matters because the app can act within the approved boundaries even when it never sees the primary credentials.
The practical result is a standing trust relationship between the account and the external service. If the app is well-designed, that relationship can support useful integrations, automation, and convenience; if it is poorly designed, the same connection can expand the blast radius of a compromise.
Permissions, Scope, and Data Exposure
The core security question is not simply whether the app is connected, but what it is allowed to do. A narrow read-only connection presents a very different risk profile from an app that can publish content, manage settings, or access sensitive account data.
Scope design should follow least privilege. Users often approve broad prompts without understanding the long-term effects, and many services do not make revocation or scope review obvious enough. For a technical model of least-privilege access and control enforcement, see NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0.
Trust, Lifecycle, and Control Boundaries
Connected applications are only as trustworthy as their lifecycle. A service that is abandoned, compromised, or repurposed may still hold valid access until the user reviews the connection, so the security posture depends on ongoing maintenance, vendor trust, and timely removal of stale integrations.
This is why connected-app governance is partly an access-management problem and partly a third-party risk problem. The account owner must be able to see what is connected, understand what each app can reach, and remove relationships that no longer have a legitimate business purpose. Where account access and delegated permissions are involved, NIST SP 800-63 Digital Identity Guidelines is a useful reference for authentication assurance, while OWASP API Security Top 10 helps explain how authorization failures can expose data and functions.
Risk and Threat Considerations
Connected applications create a durable trust edge, which makes them attractive to attackers and easy to overlook during routine account use. The main risk is that an app can retain access after user intent changes, the vendor changes hands, or the service is compromised.
Failure mechanism: Excessive scopes, weak review of consent screens, stale tokens, and poor revocation handling can let an app keep operating with more access than the user intended. If the connected service is malicious or later compromised, that access can be abused without re-entering the account password.
Impact: The result can be data exposure, unwanted actions performed on the user’s behalf, session or token abuse, and lateral misuse of trusted integrations. In higher-value accounts, a single overbroad connection can become a stepping stone to broader compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Connected apps rely on delegated access scopes that should be limited to minimum necessary privileges. |
| IA-5 — Authenticator Management | Connected apps depend on tokens, secrets, and other credential material that must be managed across their lifecycle. | |
| AC-3 — Access Enforcement | Connected apps are governed by authorization decisions that define what an external service may do. | |
| Recommendation — Apply least privilege to delegated app scopes and remove unnecessary access paths. Manage tokens and secrets through issue, rotation, revocation, and expiry controls. Enforce approved scopes so connected apps can only perform authorized actions. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Connected apps may call functions on the user’s behalf, making authorization boundaries central to the risk. |
| API2 — Broken Authentication | Connected apps often rely on tokens and authorization flows that must be robustly validated. | |
| Recommendation — Verify function-level authorization for every delegated action exposed to connected apps. Validate token issuance, binding, and revocation paths for delegated app access. | ||
| NIST SP 800-63 | 3.1 — Digital Identity Model and Authentication Protocols | Connected apps are commonly enabled through protocol-based delegated authentication and authorization flows. |
| Recommendation — Use approved authentication protocols that preserve user control over delegated access. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Permissions | Connected applications are controlled through assigned permissions and access boundaries. |
| Recommendation — Review and constrain permissions granted to connected applications. | ||
Practitioner Guidance
Why practitioners should care: Connected applications are not just convenience features, they are delegated access relationships that should be governed like any other privilege. Security teams should treat consented integrations as part of the account’s attack surface, especially where business data, publishing rights, or administrative functions are exposed.
Common misunderstanding: Many users assume an app is safe once it passes the initial authorization prompt. In practice, trust must be revalidated over time, because permissions can outlive the user’s memory of granting them and the service’s original security posture can change.
Practitioner takeaway: The safest connected-app posture is specific scopes, visible review, and easy revocation, because delegated access is only acceptable while the business need and the trust relationship both remain current.
Related resources from NHI Mgmt Group
- Why do page-level permissions matter for Notion-connected applications?
- What breaks when identity automation stops at connected applications?
- How should teams govern access across Active Directory and connected applications?
- Who is accountable when identity data drifts across SAP and connected applications?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
