For most of its life inside the enterprise, Salesforce was treated as “just” a critical application, a powerful CRM that needed strong profiles, roles, and sharing rules, and maybe some Shield features if you had the budget.

That world is gone.

Today, Salesforce is the hub of an ecosystem that includes managed packages from the AppExchange, custom integrations, marketing and outreach tools, data enrichment services, AI copilots, and homegrown automations built by every team with an API token and a deadline. The average large enterprise runs hundreds of SaaS applications, many of which are directly integrated with Salesforce.

This evolution is good for the business but uncomfortable for security. When Salesforce stops being “one app to secure” and becomes the beating heart of a SaaS supply chain, the threat model changes completely.

In this article, I want to walk through that evolution in four steps:

1. The comfort zone: misconfigurations
2. The expansion: OAuth and identity risks
3. The reality: SaaS supply‑chain attacks into Salesforce
4. The bridge: a 90-day plan to move from org-focused to ecosystem-focused security

Part 1: The Comfort Zone (Misconfigurations)

If you ask most teams, “How do you secure Salesforce?” the answers are familiar:

• Profiles, roles, and permission sets
• Sharing rules and org-wide defaults
• SSO and MFA requirements
• Field-level security and validation rules
• Shield Event Monitoring and Platform Encryption (for those on higher tiers)

This configuration-first mindset is where many organizations start, and it’s not wrong. Misconfigurations can absolutely cause serious exposure:

• A “temporary” permission set that grants API access to more objects than intended
• Overly broad sharing rules exposing opportunity or case data
• Debug logs or reports containing sensitive data and shared too widely

These are the kinds of issues admins and security teams are trained to look for. They show up in security reviews, in internal audits, and in most Salesforce hardening guides.

However, as your Salesforce footprint grows, something interesting happens. You can have a well-configured org and still be exposed, because the risk no longer lives only in the org. It lives in what’s connected to it.

That’s where OAuth, non‑human identities, and integrations come in.

Part 2: The Expansion (OAuth and Identity Risks)

As Salesforce usage matures, two things increase:

1. The number of integrations (managed packages, API clients, ETL tools, marketing platforms, custom apps)
2. The number of non‑human identities (NHIs): service accounts, API users, connected apps registered for automation or AI agents

Every one of those entities has tokens and scopes that determine what they can do with your Salesforce data.

In many attacks we’ve analyzed at Vorlon, the misstep wasn’t “we set the wrong sharing rule for users.” It was:

• “We don’t actually know how many integrations have high-privilege access.”
• “We don’t regularly review which NHIs still exist or what they can see.”
• “We can’t easily tell what ‘normal’ behavior looks like for a given integration.”

Recent campaigns like ShinyHunters exploited this exact weakness by abusing OAuth trust and identity rather than a simple profile misconfiguration.

From a Salesforce admin’s perspective, the pattern often looks like this:

A new integration is approved under time pressure (“we need this for the sales team this quarter”). It’s granted a broad scope, often read/write access to multiple objects, including custom objects with sensitive fields. The integration works, and everyone moves on. The underlying API user and tokens live on indefinitely.

Over time, you end up with dozens or hundreds of NHIs and connected apps weaving in and out of Salesforce. Each one is a potential path into your most sensitive customer data.

At this stage, the threat model is no longer, “What can Alice in Sales see?” It’s also, “What can this marketing automation tool, that ETL job, or this AI agent see and do?”

Now this sets the stage for the next phase: SaaS supply‑chain attacks.

Part 3: The Reality (SaaS Supply‑Chain Attacks)

When we talk about SaaS supply‑chain risk, it’s easy to think in abstract terms like, “third-party risk,” “vendor security posture,” and so on.

However in the Salesforce world, supply‑chain attacks are very concrete:

• A compromised marketing automation platform with high-privilege API access to Salesforce objects
• A hijacked OAuth token issued to a trusted AppExchange package
• An AI agent that was configured to read records for summarization, is now abused to exfiltrate data at machine speed

In our white paper, Secure Salesforce and Your SaaS Supply Chain in 2026, we walk through real 2025 incidents where:

• Attackers didn’t need a Salesforce zero-day
• They compromised a connected app or downstream vendor, then used existing OAuth trust to pivot into Salesforce
• Data was exfiltrated in minutes or hours, not weeks or months

From the Salesforce side, these events often look like:

• Legitimate API calls from a known integration
• Data access that’s technically within the allowed scope
• Unusual patterns that do not violate a single configuration rule, but absolutely violate what you would consider “normal” for that app

The uncomfortable truth is that you can pass a Salesforce security review and still be wide open to a SaaS supply‑chain attack.

Why?

Because the review is scoped to Salesforce the application, not Salesforce the ecosystem.

To close that gap, we need to think like ecosystem defenders, not just org admins. That’s where a structured 90-day plan comes in.

Part 4: The Bridge (A 90‑Day Plan from Org to Ecosystem)

The challenge is to extend your Salesforce security practice from “inside the org” to “across the ecosystem.”

Here’s a practical 90-day roadmap we’ve seen work with customers who started out configuration-focused, but aware that integrations were the blind spot.

Days 0 to 30: Discover and Baseline

Goal: Know what’s actually plugged into Salesforce and what it can reach.

Inventory connected apps and integrations
List all AppExchange packages, custom integrations, API clients, and AI tools connected to Salesforce. Include both “official” integrations and anything that shows up in login history, audit logs, or connected apps.

Map non‑human identities (NHIs)
Identify all API users, service accounts, and integration identities. For each, document:

• Which objects they can access
• Whether they can read, write, or delete
• Whether they can access custom objects and fields that contain sensitive data

Establish a data sensitivity map
Flag key data domains: PII, financial data, support case content, attachments, etc. Map which integrations and NHIs can touch those domains.

Takeaway: By the end of 30 days, you should be able to answer: “Which external systems and NHIs have meaningful access to my sensitive Salesforce data?”

If you can’t answer that today, you’re not ready to handle a SaaS supply‑chain incident.

Days 31 to 60: Prioritize and Tighten

Goal: Reduce the blast radius of a compromised integration.

Risk-rank integrations and tokens
Prioritize based on:

• Data sensitivity (what they can access)
• Permission scope (read vs. write vs. delete, admin APIs)
• Business criticality (could we restrict or replace this integration if needed?)

Apply least privilege to NHIs and scopes

• Tighten permission sets and profiles for API users
• Remove unused objects from integration scopes wherever possible
• Ensure production integrations aren’t using “god mode” admin users

Start lifecycle management practices

• Rotate high-risk tokens on a schedule
• Decommission stale integrations and NHIs that are no longer used
• Document ownership: who owns each integration from a business and technical standpoint?

Takeaway: This is where many organizations can dramatically reduce their exposed surface area without changing a single line of code, simply by aligning access with actual business use.

Days 61 to 90: Add Behavior and Ecosystem Context

Goal: Move beyond configs and permissions into how your Salesforce ecosystem behaves over time.

This is where Vorlon spends most of our time with customers, and it’s the core of the approach we describe in the white paper.

Define “normal” for your highest-risk integrations
For your top 10 to 20 integrations/NHIs, characterize:

• Typical data volumes
• Typical objects accessed
• Usual time windows and source IP ranges

This can start simple, using Shield Event Monitoring, SIEM, or a dedicated SaaS security tool.

Introduce behavioral monitoring
Set up alerts for:

• Unusual spikes in data access from a given integration
• Access to new, more sensitive objects not previously used
• Cross-application patterns (e.g., integration A suddenly reading the same records as integration B in a short window)

Connect data layer context to identity alerts
An anomalous login from an integration is interesting. An anomalous login plus large exports of PII or deal data is a break-glass event. Make sure your detection stack can “stack” identity anomalies with data sensitivity.

Run a tabletop on a SaaS supply‑chain scenario
Example: Your marketing automation vendor is compromised. Attackers use its OAuth token to read Salesforce records.

Walk through:

• How you’d detect this today
• How you’d investigate “legitimate” API calls from that vendor
• How you’d revoke access and communicate with stakeholders

Takeaway: The difference between a misconfiguration and a SaaS supply‑chain attack is often behavioral. You won’t see it if you’re only looking at static configs.

Closing: Salesforce Security Is Now SaaS Ecosystem Security

Salesforce has earned its place as a mission-critical system, but its function has changed. It now sits at the center of a dense network of SaaS and AI tools, each with its own identities, tokens, and behaviors.

If your security program stops at “We ran a configuration review,” “We turned on MFA,” or “We have Shield logs somewhere,” you’re still operating in a world where Salesforce was just one app.

The reality is that modern Salesforce security is SaaS ecosystem security. It spans:

• The org and its configurations
• The OAuth fabric of integrations and NHIs
• The behavior and data flows across connected apps, SaaS vendors, and AI agents over time

The good news is that this evolution is achievable. As we outline in Secure Salesforce and Your SaaS Supply Chain in 2026, the path from “strong org configs” to “ecosystem‑aware defense” can start in 90 days, with discovery, prioritization, and a first layer of behavioral monitoring.

Salesforce admins and security teams are already used to thinking in terms of relationships: objects, records, and sharing models. The next step is to extend that same mindset to applications, identities, and data flows.

Because in 2026, the question won’t be, “Is our Salesforce org configured securely?” It will be, “Can we see and control what’s happening across the entire SaaS and AI ecosystem that surrounds Salesforce?”

The organizations that can answer “yes” will be the ones that treat Salesforce security not as a checklist, but as a living, evolving ecosystem problem, before the attackers do.