Ownership should sit with identity governance, app owners, and the business function that depends on the integration, not with a single admin team alone. That split is important because connected apps combine technical access with business use. Reviews should confirm that the app still exists, still needs the same scope, and still uses a dedicated identity.
Why This Matters for Security Teams
Salesforce connected app are not just technical integrations. They are production access paths that can read records, push data, trigger workflows, and chain into downstream systems. That means ownership must extend beyond a platform admin team and into identity governance and the business function that relies on the integration. The risk is not theoretical: the Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In a connected app review, the question is whether the access is still justified, still scoped correctly, and still tied to a dedicated identity with a real owner.
This is where teams often get it wrong. A single admin group may be able to click through the Salesforce UI, but it usually cannot judge whether a marketing automation app, revenue operations tool, or support workflow still needs the same OAuth scopes. The OWASP Non-Human Identity Top 10 treats overprivileged and poorly governed machine access as a recurring weakness, not a one-time setup issue. In practice, many security teams discover stale connected app access only after an integration has already been repurposed or left behind by a departed owner.
How It Works in Practice
Ownership works best as a shared control with clear decision rights. Identity governance should run the review process, app owners should validate the technical configuration, and the business sponsor should confirm the integration still supports an active process. That split matters because connected app access is part identity, part application lifecycle, and part business dependency. Current guidance suggests treating each review as a recertification of both access and purpose, not as a checkbox against a static inventory.
At minimum, reviewers should verify four things: the connected app still exists; the app still has a current business use; the scopes and permissions still match that use; and the app authenticates through a dedicated identity rather than a shared human admin account. That last point is important because connected apps often outlive the staff who created them. The NHI Lifecycle Management Guide reinforces that non-human identities need explicit ownership, periodic review, and offboarding, not passive reliance on platform defaults.
- Identity governance schedules and documents the review.
- The app owner confirms the integration design and OAuth scopes.
- The business function confirms the use case is still required.
- Security or IAM checks whether secrets, refresh tokens, and consent grants remain appropriate.
For implementation detail, the OWASP Non-Human Identity Top 10 is a useful reference for spotting stale entitlements, weak ownership, and excessive token exposure. These controls tend to break down in large Salesforce environments with many delegated admins, because the approval trail gets split across teams and no single group sees the full integration lifecycle.
Common Variations and Edge Cases
Tighter review ownership often increases coordination overhead, requiring organisations to balance control quality against review speed. That tradeoff shows up most clearly when Salesforce connected apps are managed by a central platform team but used by multiple business units. In those environments, a purely technical reviewer can approve something that is operationally obsolete, while a purely business reviewer may miss scope creep or orphaned credentials.
There is no universal standard for this yet, but current guidance suggests handling sensitive or high-impact connected apps differently from low-risk internal tools. For example, integrations that touch customer data, finance workflows, or external partner systems should get stronger business sign-off and more frequent recertification. Lower-risk apps can often use a lighter review path, provided a dedicated owner remains accountable and the access is still tied to a defined purpose. The 52 NHI Breaches Analysis is a reminder that weak machine-identity governance tends to show up as an accumulation of small failures, not one dramatic misconfiguration.
A practical edge case is admin-created apps used for temporary project work. Those should have an expiration date, a named business owner, and a planned review at decommissioning. If that is missing, the connected app becomes a standing access path with no clear accountability, which is exactly what review programs are meant to prevent.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Connected apps need ownership, scope review, and lifecycle control. |
| NIST CSF 2.0 | PR.AC-4 | Reviews should validate least privilege for Salesforce integrations. |
| NIST AI RMF | Governance should define accountability for autonomous or dynamic access decisions. |
Establish clear human accountability for non-human access decisions and recurring review outcomes.
