Accountability should sit with the application owner and the identity governance team together. The application owner controls implementation and monitoring, while governance owns lifecycle policy, approval, and review. If either side assumes the other is responsible, delegated access can persist without clear ownership.
Why This Matters for Security Teams
A revoked or misused connected Salesforce org is not just a cleanup issue. It is a governance failure that can expose customer records, integration tokens, and downstream SaaS trust relationships. In NHI terms, the org connection is a non-human identity with delegated authority, so accountability must cover the full lifecycle: approval, monitoring, revocation, and post-incident review. That is why current guidance aligns with OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, which both treat ownership as a control, not a formality.
If accountability is vague, revocation often becomes delayed, partial, or unverified. The result is persistent access that survives policy changes, mergers, vendor changes, or staff turnover. In practice, many security teams encounter this only after an integration has already been abused, rather than through intentional access review.
How It Works in Practice
Accountability should be split into operational ownership and governance oversight, but not duplicated in a way that creates gaps. The application owner is typically responsible for knowing why the Salesforce org exists, what data it can reach, what permissions it needs, and how it behaves after changes. The identity governance team owns policy, approval workflow, evidence, and periodic review. That division is consistent with the lifecycle approach in the NHI Lifecycle Management Guide and the risk patterns described in the Top 10 NHI Issues.
Practically, a defensible process should include:
- Named business and technical owners for every connected org.
- Documented approval for creation, scope, and revocation.
- Periodic review of tokens, scopes, refresh behaviour, and last use.
- Immediate revocation playbooks when the org is unused, misconfigured, or suspected compromised.
- Evidence that revocation actually removed access across Salesforce and any linked APIs.
For teams that need a standards lens, the OWASP Non-Human Identity Top 10 supports tighter ownership and secret governance, while the Salesloft OAuth token breach shows how a single delegated connection can become a broad data-access path when controls are weak. The control objective is simple: one team owns business justification, another owns policy enforcement, and both must sign off on revocation completion. These controls tend to break down when Salesforce connections are created through ad hoc admin access and never enter a formal NHI inventory because no one can prove who approved the trust relationship.
Common Variations and Edge Cases
Tighter revocation controls often increase operational overhead, requiring organisations to balance speed of business integration against auditability and containment. That tradeoff matters most in large Salesforce environments where multiple business units, managed packages, and middleware platforms share the same trust boundary.
There is no universal standard for whether ownership should sit with IT, the CRM platform team, or the business process owner. Current guidance suggests the application owner should be the person best able to explain intended use, while governance remains independent enough to challenge access. In merger, outsourcing, or reseller scenarios, this can become messy because the original owner may no longer exist, which is exactly when hidden access tends to persist.
This is also where secret sprawl becomes a material risk. If the Salesforce connection uses tokens or certificates stored in code, config files, or CI/CD systems, the revocation decision must cover those secondary locations too. The Guide to the Secret Sprawl Challenge and Ultimate Guide to NHIs — Static vs Dynamic Secrets are useful here because they show why disabling one connector does not always eliminate every live credential. In higher-maturity programs, teams also cross-check revocation against Guide to NHI Rotation Challenges to confirm that stale access cannot be reactivated later. The answer becomes harder in federated ecosystems, but the ownership model should not change: if no one is accountable for the trust relationship end to end, revocation will remain incomplete.
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-01 | Ownership and lifecycle control are core to revoking misused non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege and access management apply directly to delegated Salesforce org access. |
| NIST AI RMF | GOVERN | Clear accountability is a governance requirement for autonomous delegated access decisions. |
Set decision ownership, escalation, and evidence rules before granting or revoking access.
