Why do connected apps and integration users need separate governance from human users?

Why connected apps and integration users cannot be governed like people

Connected apps and integration users are not just another user population with a different label. They usually hold their own consent grants, scopes, API permissions, refresh tokens, or service credentials, which means the access path can outlive the person who created it. Governance has to track the application relationship and credential lifecycle, not only the human account behind it.

That distinction matters because people change roles, leave teams, or move organisations, but an app grant often remains valid until it is explicitly reviewed or revoked. If you only run human joiner-mover-leaver controls, you may conclude the access problem is solved when the person departs while the non-human access path still works.

What separate governance needs to cover

Separate governance starts with inventory. You need to know which connected apps exist, which integration users they depend on, what data they can reach, and whether the grant is user-consented, admin-consented, or service-account based. For SaaS-to-SaaS flows, a good reference point is SaaS-to-SaaS and OAuth App Governance Guide, because it treats consent, scopes, token risk, and revocation as the real control surface.

Next is privilege design. Connected apps should have only the API scopes and object access they actually need, and integration users should not be reused as convenient standing admin accounts. The same control logic applies across cloud, SaaS, and directory systems, which is why Service Account Security Guide is useful here: it frames least privilege, discovery, rotation, and governance for accounts that do not map cleanly to a person.

Lifecycle control is the third layer. When the business owner changes, the vendor relationship ends, or the integration purpose disappears, governance should trigger token revocation, app unassignment, and a review of any dependent service account. That is especially important where the access was created through consent rather than through a normal provisioning workflow, because consent can be easier to miss during recertification.

Why human controls do not fully reduce the risk

Human governance often focuses on employment status, manager approval, and role changes. Those controls are necessary, but they are not sufficient for connected apps because the access may be embedded in a token or app registration that remains active even when the user is removed from a team, disabled, or offboarded. In practice, the credential or grant becomes the durable security object, not the person.

That is why the cleanest mental model is ownership plus delegation. The human may sponsor or approve the connection, but the app or integration user is what actually authenticates and consumes rights. Human vs Non-Human Identity is a useful explainer for the boundary between people and machine access, especially where consent, shared credentials, or delegated access blur responsibility.

The same pattern shows up when app governance is weak in SaaS platforms. Salesforce Security Guide is relevant because it ties together connected apps, integration users, access review, and monitoring, which are the practical controls that stop app grants from drifting away from business intent.

Risk and Threat Considerations

Connected apps and integration users create a different risk profile from human accounts because they can preserve access after the original business context has changed. That makes them attractive for misuse, persistence, and stealthy data access, especially when OAuth consent, long-lived tokens, or reused service credentials are left in place.

Failure mechanism: The access decision is tied to a grant, token, or service account that is not bound to the human lifecycle, so offboarding the person does not automatically remove the privilege path.

Impact: An attacker or former insider can continue to call APIs, export data, or pivot into downstream systems even after the human owner has left, changed jobs, or lost legitimate need.

Practitioner Guidance

What to verify: Treat every connected app as an owned asset with a named business purpose, an approved scope set, and an explicit revocation path. If you cannot answer who approved it, what it can touch, and when it was last reviewed, it is already outside good governance.

Decision rule: If the access is carried by a token, app grant, or integration user, review and revoke on the basis of that object, not on the basis of the human’s employment status alone. If the app can reach production data, prioritise blast-radius reduction before you investigate whether abuse has already occurred.

Practitioner takeaway: Separate governance is required because the real security boundary is the non-human access path, and that boundary must be reviewed, rotated, and revoked on its own lifecycle.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Why do AI agents create a separate data governance problem from human users?
• How should security teams govern non-human identities at scale?