Platform security protects activity that occurs inside Salesforce, such as logging, encryption, and transaction controls. Ecosystem security extends beyond the platform to monitor how data, tokens, and integrations behave across connected SaaS tools. The distinction matters because many modern risks arise after a record is synced, exported, or processed externally.
Platform Controls Stop at the Salesforce Boundary
Salesforce platform security is about controlling what happens inside the tenant: who can sign in, what they can see, what they can export, and how the platform logs or constrains activity. Ecosystem security starts where that boundary ends. The question matters because modern compromise often does not stay in one app; a safe Salesforce object can still become a source of exposure once it is synced to a marketing tool, enrichment service, data warehouse, or automation workflow.
That boundary shift is why security teams need to distinguish between controls that protect the record in Salesforce and controls that follow the record, token, or API session after it leaves. When organisations only harden the platform, they can still miss abuse in connected SaaS apps, stale OAuth grants, and downstream data movement that is invisible from the core tenant. In practice, many teams discover the exposure only after an integration has already copied the data elsewhere, rather than during the original Salesforce transaction.
OWASP Non-Human Identity Top 10 helps frame why token and service-to-service trust becomes a separate security problem once integrations are involved.
How Security Responsibilities Split in Practice
Platform security is usually centered on native controls: authentication, role design, field visibility, audit trails, session management, encryption, and approval workflow enforcement. Those controls are necessary, but they are still mostly intra-platform. They answer questions such as whether a user or automation was allowed to read a case, whether a field was masked, or whether a transaction was logged.
Ecosystem security asks a different question: what happens after Salesforce data is handed to another system, or when another system can write back into Salesforce through an integration, connector, or token? That means assessing API permissions, OAuth app scope, sync frequency, downstream storage, partner access, and whether the integration can be abused if the external app is compromised. A token that is harmless inside a narrow Salesforce workflow can become a high-impact credential if it authorizes export, refresh, or bulk data access across multiple SaaS tools.
For practitioners, the split is operational as much as technical:
- Use platform controls to reduce internal misuse and constrain tenant-level exposure.
- Use ecosystem controls to inventory connected apps, review granted scopes, and monitor data leaving the tenant.
- Treat third-party automation as part of the trust boundary when it can move records, tokens, or attachments.
- Track where data is copied, not just where it originated.
The distinction becomes especially important for OAuth-based integrations, because the security question is no longer only about a user session in Salesforce, but about the lasting authority embedded in a connected app. These controls tend to break down when administrators assume the source system can fully govern copies, exports, and delegated access once external sync or API processing begins.
Salesloft OAuth token breach illustrates how token-based trust can expose Salesforce data through connected services rather than through the platform itself.
Where the Boundary Gets Fuzzy
Tighter control inside Salesforce often improves visibility, but it can also create a false sense of containment, so teams have to balance tenant hardening against integration sprawl. The real challenge is that many business processes now span multiple SaaS products, and the security model changes once data is duplicated, enriched, or transformed elsewhere.
Current guidance suggests treating ecosystem security as the broader governance layer whenever a Salesforce object feeds analytics, support tooling, AI assistants, partner portals, or workflow automation. The hardest edge cases are write-back integrations and vendor-managed apps, because they can blur ownership of logging, retention, and revocation. A platform team may know the user or field policy, while a separate application owner controls the integration secret or app registration.
One useful rule is this: if a control only protects the record while it remains inside Salesforce, it is platform security; if it must still matter after export, sync, or delegated API use, it belongs to ecosystem security. That distinction also explains why incident response must include downstream SaaS review, not just Salesforce audit logs. In organisations with many third-party apps, the practical failure point is often scope creep in the integration layer, where broad API grants quietly outlive the business need.
In a recent NHIMG research snapshot, 85% of organisations reported lacking full visibility into third-party vendors connected via OAuth apps, which is exactly the kind of gap that makes ecosystem risk harder to see than platform risk.
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 | Salesforce ecosystem risk often hinges on tokens and delegated app credentials. |
| NHI-03 — Authorization and Privilege Scope | The question is about how access differs inside Salesforce versus connected tools. | |
| NHI-05 — Third-Party Trust and Visibility | Ecosystem security depends on monitoring external SaaS relationships and OAuth apps. | |
| Recommendation — Inventory and rotate connected-app secrets before granting broad downstream access. Restrict integration scopes to the minimum data paths needed by each app. Review third-party app trust relationships and revoke unused delegated access. | ||
| CIS Controls v8 | 6 — Access Control Management | The distinction turns on controlling who and what can access Salesforce data externally. |
| 8 — Audit Log Management | Platform and ecosystem security both rely on logs, but ecosystem needs cross-tool visibility. | |
| Recommendation — Apply least privilege to user and application access across the SaaS estate. Correlate logs from Salesforce and connected apps to detect unauthorized data movement. | ||
| MITRE ATT&CK | T1528 — Steal Application Access Token | OAuth token abuse is a key mechanism when Salesforce data is accessed through integrations. |
| Recommendation — Hunt for token theft and anomalous API use across connected SaaS services. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | The platform-versus-ecosystem split is fundamentally a boundary and ownership question. |
| Recommendation — Define ownership for SaaS integrations and assign risk decisions to the right control owner. | ||
Practitioner Guidance
What to prioritise: Start by mapping every Salesforce integration to the data it can read, write, export, or refresh. The question is not whether the app is approved, but whether its permissions still match the business use case and whether its access persists longer than the workflow that justified it.
What to verify: Confirm who owns each connected app, where its secrets or refresh tokens are stored, and whether revocation actually breaks the workflow in a controlled way. If no one can explain the downstream data path, the organisation does not yet have ecosystem security, only platform security with blind spots.
Decision rule: If an external tool can outlive the user session, copy data outside Salesforce, or call back into Salesforce through a standing token, treat it as a governance boundary and review it like a privileged dependency.
Practitioner takeaway: The cleanest way to think about the difference is that platform security protects the system of record, while ecosystem security protects the trust relationships that keep that record safe after it leaves the system of record.
Related resources from NHI Mgmt Group
- What is the difference between an identity security platform and a full IGA platform?
- What is the difference between a standalone security key and a managed MFA platform?
- What is the difference between platform consolidation and best-of-breed security?
- What is the difference between CASB, DLP, and DSPM in Salesforce security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
