Treat delegated Salesforce writes as governed non-human identity activity. Assign ownership, scope the integration to the minimum required Salesforce permissions, and make revocation visible to security and application teams. The important control is not the UI widget itself but the lifecycle around connection, token use, disconnect, and auditability.
Why This Matters for Security Teams
Delegated Salesforce writes are not just an app integration detail. They are governed NHI activity with production impact, because the app can create, update, or delete business records with the same authority a user grants through OAuth or connected app consent. If ownership is unclear, the integration becomes a shadow administrator that survives app changes, staff turnover, and incident response.
This is where least privilege and lifecycle control matter more than the front-end connection flow. Security teams should define who owns the integration, which Salesforce objects and fields it may touch, how tokens are issued, and how quickly access is revoked after risk changes. The control set should map to broader identity governance and audit expectations in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives and align with NIST Cybersecurity Framework 2.0 functions for governance, protection, detection, and response.
NHI Mgmt Group research shows why this matters: 97% of NHIs carry excessive privileges, which broadens the attack surface and increases unauthorised access risk. In practice, many security teams encounter over-permissioned Salesforce writes only after a token is abused or a business owner asks why an app can still write data long after it should have been disconnected.
How It Works in Practice
Govern delegated Salesforce writes by treating the integration as a managed identity, not a static application setting. Start with ownership: one business owner and one technical owner should be accountable for the connector, its scope, and its review cadence. Then constrain the app to the minimum set of Salesforce permissions needed for the workflow. That usually means object-level and field-level limits, not blanket API access.
Next, separate connection approval from runtime authorisation. A strong pattern is to issue short-lived, purpose-scoped credentials and review every write path against business intent. That is consistent with current guidance in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and with NIST Cybersecurity Framework 2.0 expectations for access control and continuous monitoring.
- Register the integration in an identity inventory with owner, purpose, data scope, and expiry.
- Prefer least-privilege connected apps, scoped tokens, and restricted API grants.
- Log every create, update, delete, and admin-level write separately from normal app telemetry.
- Review token age, last use, and failed write attempts as revocation signals.
- Disable and rotate credentials when the app owner changes, the use case changes, or the vendor relationship ends.
Salesforce writes also need evidence. Security and app teams should be able to show who approved access, what was granted, when it was last used, and how revocation was executed. The Salesloft OAuth token breach is a reminder that OAuth-based access can become a data-access path if monitoring and revocation are weak. These controls tend to break down when multiple business units reuse the same connected app because ownership, scope, and audit trails become fragmented.
Common Variations and Edge Cases
Tighter control over delegated writes often increases operational overhead, so organisations have to balance developer speed against the need for revocation and auditability. That tradeoff is real, especially when Salesforce is used by many teams with different data needs.
There is no universal standard for every connected-app pattern yet, but current guidance suggests a few consistent rules. High-risk integrations should use separate app registrations per business purpose, not one shared integration for everything. Vendor-managed connectors need extra review because the security team may not control the release cadence or token lifecycle. If the integration performs bulk updates or synchronises records across systems, it should also be monitored as a privileged automation path, not a low-risk SaaS feature.
For environments with strong compliance needs, add evidence retention and periodic recertification to the control set. The Lifecycle Processes for Managing NHIs guidance fits well here, while NIST Cybersecurity Framework 2.0 helps translate those reviews into repeatable governance. Where the model breaks down is in multi-tenant estates with ad hoc admin consent, because access sprawl makes ownership and revocation difficult to prove quickly.
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 | Delegated writes need credential rotation and revocation discipline. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to governing Salesforce write scope. |
| NIST Zero Trust (SP 800-207) | SC.L2 | Zero Trust supports continuous verification for privileged app writes. |
Treat each write as a verified transaction and continuously validate the integration's trust state.
