A third-party account that a user has linked to an application so the app can call an external provider on their behalf. In practice, the connection becomes a governed entitlement because it can persist, expand in scope, or remain active long after the original user action occurred.
Expanded Definition
A connected account is more than a convenience link between a user and a third-party service. In NHI governance, it is a delegated access relationship that can authorize an application to act on the user’s behalf through tokens, consent grants, or partner APIs. That makes the connection a governed entitlement, not just a UX feature.
Definitions vary across vendors, especially where connected accounts overlap with delegated authorization, OAuth consent, or social login. The important distinction is operational: a connected account can persist after the original user session ends, can expand in scope when permissions change, and can continue to expose downstream systems if it is not inventoried and reviewed. This is why it belongs in NHI oversight alongside service account, tokens, and API keys.
For a broader NHI governance lens, see NHI Mgmt Group’s Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0, which both reinforce the need to manage access lifecycle, visibility, and least privilege. The most common misapplication is treating a connected account as a one-time login convenience, which occurs when teams fail to track the delegated scope after the initial approval.
Examples and Use Cases
Implementing connected accounts rigorously often introduces lifecycle overhead, requiring organisations to weigh user convenience against continuous access governance.
- A productivity app connects to a mail provider so it can read calendar data and send invitations on the user’s behalf, creating a standing delegated entitlement that must be reviewed when scopes expand.
- A customer support platform links to a file-sharing provider to retrieve attachments for case handling, which means offboarding must revoke the connection when the employee leaves or the ticketing role changes.
- A workflow tool uses a connected account to post to a collaboration channel after approved events, but the token remains valid long after the initial approval, so expiry and rotation matter.
- An enterprise enables a third-party analytics service to access cloud resources through user consent, and the resulting access must be inventoried as part of NHI management rather than treated as a simple SaaS feature.
- Identity federation guidance from NIST Cybersecurity Framework 2.0 becomes relevant when the connection is used to reach regulated systems, while NHI Mgmt Group’s Ultimate Guide to NHIs helps frame the lifecycle controls needed around delegated access.
Why It Matters in NHI Security
Connected accounts are security-relevant because they can quietly outlive the business event that created them. Once a user approves access, the resulting entitlement can remain active across sessions, devices, and organizational changes unless it is monitored, scoped, and revoked with the same discipline applied to other NHIs. That is where misuse becomes likely: stale connections, excessive scopes, and hidden third-party dependencies create pathways for data exposure and lateral movement.
NHI Mgmt Group reports that 92% of organisations expose NHIs to third parties, raising supply chain security concerns, and the same pattern applies when connected accounts are left unreviewed. The risk is not just unauthorized use, but also delayed detection when a connected app is compromised or when the user no longer needs access. This is why connected accounts should be governed as part of access review, secret hygiene, and third-party risk management, not only as app settings.
Organisations typically encounter the consequences only after an application misuse, a tenant compromise, or an employee departure, at which point connected-account governance 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-03 | Connected accounts create delegated access that must be inventoried and governed as NHI entitlements. |
| NIST CSF 2.0 | PR.AC-1 | Connected accounts are access pathways that must be authorized, reviewed, and revoked over time. |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero Trust requires continuous verification of delegated access, including third-party connected accounts. |
Track every connected account, scope, and revocation path so delegated access does not become standing privilege.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
