Security teams should scope named credentials to the smallest possible endpoint and permission set, rather than exposing broad APIs or tenant wide access. Keep the credential tied to one intended action, validate the URI path, and avoid designs that let requests append arbitrary data. That reduces pivot opportunities if tokens are stolen and limits abuse to the narrow workflow the integration actually needs.
Why Named Credential Scope Matters After Token Theft
Named credentials are only safe when they behave like tightly bounded integrations, not general-purpose trust bridges. If an access token is stolen, the attacker inherits every path that token can legitimately reach, so scope determines how far the compromise can travel. That is why the endpoint, HTTP method, and permission set should all be narrowly aligned to the single workflow the integration supports, rather than to broad tenant-wide or reusable API access.
Over-scoped named credentials create a lateral movement problem because the attacker does not need to break the original control again. They can simply reuse the trusted channel, probe adjacent objects, and look for requests that accept attacker-controlled parameters or arbitrary path construction. NHI security teams should treat the credential as part of the attack surface, not just an authentication detail. The Salesloft OAuth token breach is a useful reminder that stolen tokens often become a movement path, not just a data-access event.
In practice, many teams discover the blast radius only after an integration token is reused outside its intended workflow and the request structure itself becomes the pivot point.
How to Contain Abuse in Practice
The practical goal is to make the named credential incapable of doing anything the workflow does not explicitly require. That starts with a dedicated integration user or service principal that has only the object and record permissions needed for one business action. The named credential should point to one fixed base endpoint, and the consuming code should avoid composing URLs from untrusted input or appending arbitrary paths that let a stolen token reach additional resources.
Security teams should also separate authentication scope from functional scope. A token may authenticate successfully, but the surrounding Salesforce permissions, connected app policy, and downstream API route should still block anything outside the approved action. Where possible, prefer short-lived tokens or rotated secrets over long-lived bearer credentials, because theft becomes less useful when the token window is small. For a broader view of how exposed machine credentials are abused once discovered, the Ultimate Guide to NHIs — Static vs Dynamic Secrets is directly relevant.
- Bind the credential to one endpoint and one integration user, not to a shared admin-style account.
- Restrict the Salesforce permission set so the token can only act on the records and objects the workflow truly needs.
- Reject designs that allow caller-supplied path fragments, object names, or query construction.
- Log the exact destination, object, and action so unusual reuse is detectable.
- Rotate or revoke the credential quickly if the integration is changed, copied, or repurposed.
These controls tend to break down when teams centralise many workflows behind one credential, because the token then becomes a reusable bridge across otherwise separate application functions.
Where Scope Breaks Down and What Teams Overlook
Tighter scope often increases integration overhead, because each workflow may need its own user, policy, and operational owner. That tradeoff is worth making when the credential can reach sensitive CRM data or trigger business actions, but it does mean teams must resist the convenience of shared service accounts. A narrow credential can still be dangerous if the backend integration can be tricked into accepting attacker-supplied identifiers, so scope has to be enforced in both Salesforce permissions and the consuming application logic.
Best practice is evolving toward per-use or per-purpose credentials for high-value workflows, especially where a stolen token could be replayed through an API integration. The main failure mode is assuming that a trusted connector is safe because it is authenticated; in reality, bearer tokens make stolen access hard to distinguish from legitimate use unless the workflow itself is constrained. The OWASP Non-Human Identity Top 10 helps frame why overbroad machine access and weak lifecycle controls become exploit paths.
Practitioner Guidance: Treat every named credential as a privilege boundary, not a convenience layer. If one token can enumerate, modify, or export more data than the business workflow needs, the design is already too broad and should be split before incident pressure forces a redesign.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Named credentials are machine credentials that must be tightly scoped and rotated. |
| NHI-02 — Lifecycle and Ownership | Token theft impact depends on ownership, rotation, and offboarding discipline. | |
| Recommendation — Scope each credential to the smallest viable endpoint and revoke broad, reusable access. Assign a clear owner and enforce rapid rotation when the integration changes. | ||
| CIS Controls v8 | 5.1 — Establish and Maintain an Inventory of Accounts | Integration users and service accounts need inventory and accountability to limit reuse. |
| 6.3 — Disable Dormant Accounts | Stolen tokens stay useful when unused integration identities remain active. | |
| Recommendation — Inventory every integration identity and remove shared or orphaned accounts. Disable stale integration accounts before they become reusable attack paths. | ||
| MITRE ATT&CK | T1528 — Steal Application Access Token | The question centers on attacker reuse of stolen access tokens. |
| Recommendation — Monitor for token theft and invalid destination reuse in connected app activity. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | Scoped access and least privilege are the core control objective here. |
| Recommendation — Apply least-privilege access so the token cannot reach unrelated Salesforce resources. | ||
Related resources from NHI Mgmt Group
- How should security teams prevent lateral movement across shared AI and SaaS clusters when service credentials are exposed?
- How should security teams reduce S3 exfiltration risk when access is granted through shared credentials or tokens?
- How should security teams design OAuth access tokens for least privilege across APIs and services?
- How should security teams decide whether JIT access is safe for non-human identities?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
