Salesforce Integration User Risk: What Admins Miss at Renewal

What Is an Integration User?

An integration user is a Salesforce user account created specifically for system-to-system communication. They're typically:

• Assigned an API-only profile (no UI access)
• Used by connected apps, middleware, ETL tools, and custom integrations
• Not associated with a real person
• Often given broad permissions to support multiple integration use cases

Well-managed integration users are invisible during normal operations — they run background API calls and never generate interactive sessions. The problem arises when this discipline breaks down.

How Integration Users Accumulate Risk

There are several common paths to integration user risk:

1. Manual admin logins

An admin needs to test an integration or debug a permissions issue. The fastest path is logging in as the integration user directly. This is tempting and common — and it creates an interactive UI session on an account that was never designed for one.

2. Broad permissions assigned “temporarily”

During integration development, an integration user gets elevated permissions to troubleshoot an issue. The “temporary” permissions become permanent. The account now has access well beyond what it needs for production.

3. Credential sharing

The integration user credentials are shared among developers or admins who need API access. This makes the account a multi-person login target and eliminates the audit trail for individual actions.

4. Stale OAuth tokens

Connected apps accumulate OAuth tokens over time. An integration is decommissioned, but its token isn't revoked. The token remains valid, represents unauthorized access to the org, and doesn't appear in routine user access reviews.

Why This Matters for Security Reviews

Integration users with interactive sessions are a significant finding in security audits and Salesforce AppExchange Security Reviews. Specifically:

• Shared credentials violate SOC 2 CC6.1 — user authentication should be individual and auditable
• Broad permissions violate least-privilege principles — integration users should have exactly the permissions required for their integrations, no more
• Stale OAuth tokens represent unauthorized access paths — a token for a decommissioned integration is an open door
• Interactive sessions on API users are an anomaly indicator — any SIEM or security tool watching for unusual login patterns will flag this

How to Detect Integration User Risk

The detection requires two SOQL queries against the AuthSession and OAuthToken objects.

Interactive sessions on API-type users:

SELECT
  s.UsersId,
  u.Name,
  u.Username,
  u.UserType,
  s.LoginType,
  s.SessionType,
  s.CreatedDate,
  s.LastModifiedDate
FROM AuthSession s
JOIN User u ON s.UsersId = u.Id
WHERE u.UserType IN ('Standard', 'PowerPartner', 'CsnOnly')
  AND s.LoginType = 'Application'
  AND s.SessionType = 'UI'
ORDER BY s.CreatedDate DESC

Stale OAuth tokens (unused for 90+ days):

SELECT
  t.Id,
  t.AppName,
  t.UserId,
  u.Name,
  u.Username,
  t.CreatedDate,
  t.LastUsedDate
FROM OAuthToken t
JOIN User u ON t.UserId = u.Id
WHERE t.LastUsedDate < LAST_N_DAYS:90
  OR t.LastUsedDate = null
ORDER BY t.LastUsedDate ASC NULLS FIRST

The results need to be cross-referenced against your list of known integration users. Anything that looks like an API user with a UI session, or a token for an app that was decommissioned, is a finding that needs to be remediated.

Remediation Steps

For each finding, the remediation path depends on the root cause:

Monitoring Continuously, Not Just at Audit Time

The challenge with integration user risk is that it accumulates gradually. A new integration gets deployed, temporary elevated permissions get forgotten, a developer logs in as the service account to debug something — and two years later, you have a half-dozen integration users that security auditors flag as findings.

The effective countermeasure is continuous monitoring. SpendReady runs weekly checks against your org's AuthSession and OAuthToken objects and flags integration user risk automatically as part of the same report that surfaces inactive users and PSL waste. You get a single weekly PDF that gives security, IT, and RevOps everything they need.

For orgs preparing for a SOC 2 audit, security questionnaire, or AppExchange Security Review, this continuous audit trail is evidence of a functioning access control program — not a one-time cleanup.