← All posts
· 3 min read ·
SecuritySalesforceArchitectureZero Trust

Zero-Trust Architecture in Salesforce Org Design

Applying zero-trust principles to Salesforce - never trust, always verify - from network access to data visibility to API integration.

Digital identity and zero trust security concept

Zero-trust is often discussed in the context of network architecture - microsegmentation, VPNs replaced by identity-aware proxies, that kind of thing. But the principles apply directly to Salesforce org design, and most orgs violate them constantly.

Never trust, always verify. Least privilege. Assume breach. Here’s what that means in practice for Salesforce.

Never Trust the Network

The default Salesforce security model trusts the corporate network. Login IP ranges in profiles mean “if you’re on the VPN, you’re trusted.” That’s a perimeter security model, and perimeter security died when your users started working from home.

Replace network-based trust with identity-based trust:

  1. Enforce MFA for every user, every login - no exceptions for service accounts
  2. Use Salesforce Identity or an external IdP (Okta, Azure AD) with risk-based authentication
  3. Remove IP-based login restrictions from profiles - replace with device management and identity verification
  4. Monitor anomalous login patterns via Event Monitoring - new country, new device, off-hours access

Least Privilege on Every Dimension

Salesforce has five dimensions of access control. Zero-trust means applying least privilege on all of them:

Object-level - Does this user’s role actually require access to Opportunity? Account? Case? Audit this annually.

Field-level - FLS is ignored in a surprising amount of custom code. Apex running without sharing bypasses it entirely. Audit every without sharing class.

Record-level - Sharing rules are your record-level access control. Every sharing rule that uses “All Internal Users” as the target is a violation of least privilege.

Feature access - Remove permissions like “API Enabled”, “Modify All Data”, and “View All Data” from every profile where they aren’t required. These are the keys to the kingdom.

App access - Users should only see apps relevant to their role. Connected apps should be whitelisted, not open to all profiles.

Service Account Isolation

Service accounts - the credentials your integrations use - are the highest-risk identities in your org. They’re shared, long-lived, and often have elevated permissions because “it was easier.”

Apply zero-trust to service accounts:

  • One connected app per integration, not one shared app
  • Minimum permissions required - if the integration only reads Accounts, it doesn’t get write access
  • Certificate-based JWT authentication instead of username/password where possible
  • Separate Named Credentials per integration per environment - never share credentials across orgs

Assume Breach: Reduce the Blast Radius

Zero-trust’s “assume breach” principle means designing your org so that a compromised account can’t access everything.

For Salesforce, this means:

  • No single account should own all data - even System Administrator accounts should be role-scoped where possible
  • Field encryption (Shield or Classic Encryption) for PII, so a data export doesn’t expose your full customer dataset
  • Event Monitoring alerts on large data exports, mass record updates, and permission changes
  • Immutable audit trails - Event Monitoring logs should be forwarded to a SIEM that the org admin can’t modify

API Security: Zero-Trust at the Integration Layer

Every API connection to Salesforce is a potential breach vector. Apply zero-trust:

  1. Mutual TLS where the integration supports it - both sides verify identity
  2. Short-lived tokens - OAuth tokens should expire and rotate, not persist indefinitely
  3. Scoped OAuth - connected apps should request only the scopes they need, not full access
  4. API call logging - every external API call should be logged with the identity, endpoint, and payload size. Feed this to your SIEM.
  5. Rate limiting awareness - monitor for unusual API call volumes; a compromised integration will often show up as anomalous API patterns before it shows up as a data breach

Implementation Priority

If you’re starting from scratch, this is the order:

  1. Enforce MFA - immediate, high impact, low complexity
  2. Audit and remove elevated permissions - a few days of work, reduces blast radius immediately
  3. Implement Event Monitoring and SIEM forwarding - gives you visibility
  4. Service account isolation - medium complexity, high security value
  5. Field encryption for PII - highest complexity, highest compliance value

Zero-trust in Salesforce isn’t a product you buy - it’s a posture you build, incrementally, over time. Start with the high-impact, low-complexity items and build from there.

← All posts