The 10 Salesforce Security Gaps Most Orgs Miss

The Salesforce org has been live for 18 months. No breaches. The admin team is confident security is fine. Then a third-party penetration test, SOC2 audit, or insurance carrier questionnaire surfaces ten findings — and most of them are not exotic vulnerabilities. They are configuration drift: defaults that were never tightened, exceptions that became permanent, permissions that were granted once and never revisited. This is the gap most Salesforce orgs miss, and it is almost always the gap an outside auditor finds first.

Gap 1: MFA That Isn’t Actually Universal

Salesforce requires MFA for all direct logins, and most orgs enabled it years ago. The drift comes from the exception list. A handful of integration users were exempted at launch because the connected app did not yet support OAuth. A “temporary” exemption was granted to an executive who was traveling. A consultant was added to the bypass list during a migration. None of these were ever removed.

Audit the MFA Assignment report and the Login History in setup. Filter for users without MFA-verified logins in the last 90 days. Every one of them is either a legitimate integration user that should be on a Connected App with OAuth, or a person whose exemption should be revoked.

Gap 2: Permission Set Stacking

Permission sets are additive. Every time a user needs a new capability, an admin grants a permission set. Over three years, individual users accumulate eight, ten, fifteen permission sets. The original intent of each grant is lost. Shadow admins — users with effective admin rights through stacked permissions that no single set provides — are the most common finding in this gap.

Pull the Permission Set Assignments report by user. Anyone with more than five permission sets needs a review. Anyone with permission sets containing “Modify All” or “View All” on standard objects is functionally an admin. Document who actually needs those capabilities and trim the rest. A clean org optimization pass can usually consolidate stacks by 40 to 60 percent without changing what any user can do day to day.

Gap 3: Field-Level Security Bypassed by Reports

Field-level security restricts which fields a user can see on a record. Reports follow FLS — but only at the point of report execution. The trap is report folder permissions. A report saved by an admin can contain filter logic, summarized values, and even export columns that aggregate sensitive data. If the folder is shared with a broader audience than the underlying fields, the data leaks through the report even though FLS would have blocked it on the record page.

Audit report folders by sensitivity, not by department. Reports referencing salary, account revenue, customer health scores, or PII fields belong in restricted folders with sharing rules that mirror the underlying field permissions. The same logic applies to dashboards.

Gap 4: Audit Trail Not Enabled or Not Reviewed

Setup Audit Trail logs administrative changes in the org. Field Audit Trail logs field-level data changes on standard and custom objects. They are two different tools with two different retention windows. Most orgs run with the default 180-day Setup Audit Trail and no Field Audit Trail at all. For SOC2, HIPAA, or financial audits, neither is enough.

Enable Field Audit Trail on objects with regulated data. Extend retention via the data archive feature if your compliance framework requires more than 180 days. Build a monthly review cadence — even a five-minute scan of Setup Audit Trail changes catches anomalies that would otherwise compound for months.

Gap 5: IP Restrictions Empty or Too Permissive

Profile-level Login IP Ranges restrict where users can log in from. Network Access settings define trusted IPs that bypass identity verification. Both default to empty or wide open in new orgs. The most common configuration we see during audits is a single Login IP Range entry covering 0.0.0.0 through 255.255.255.255 — which is the entire public internet.

Tighten by user type. Internal employees should log in from your office network and corporate VPN. Sales reps in the field should be on a trusted IP from your MDM-managed devices only. Integration users should be restricted to the IPs of the systems they connect from. The work is one-time. The benefit compounds across every future user.

Gap 6: API Integrations Using Direct Logins

Older integrations were often built with a dedicated “integration user” using a username, password, and security token. That pattern is brittle, hard to rotate, and visible in audit logs as if it were a real person. The modern pattern is Connected Apps with OAuth flow, named credentials, and JWT or client-credentials authentication.

Inventory every integration touching your org. For each one, document the auth method. Anything still using password-based auth is on the list to migrate. Tokens should rotate on a defined schedule. The replacement work is rarely more than a sprint per integration and removes an entire class of credential-leak risk.

Gap 7: Platform Encryption Misunderstood

Salesforce encrypts data at rest by default. Platform Encryption (Shield) is different — it encrypts specific field values with customer-managed keys, blocking even Salesforce employees from accessing raw values. Most orgs assume the default encryption satisfies compliance frameworks that actually require customer-managed keys. They learn otherwise during an audit.

If your compliance framework (HIPAA, certain SOC2 controls, financial regulations) requires customer-managed keys, you need Shield. Identify which fields need encryption — typically PII, PHI, and financial identifiers — and apply Platform Encryption selectively. Encrypting everything is wasteful and breaks search and reporting in unexpected ways.

Gap 8: Session Settings Left at Default

Session timeout, IP lock during session, force re-authentication on sensitive operations, session level required for administrative changes — these settings live in Setup under Session Settings and the default values are designed for usability, not security posture. A two-hour session timeout is comfortable. An eight-hour timeout (also a default option in some editions) is a liability.

Tighten to a 30-60 minute timeout for standard users. Require High Assurance session for administrative profile changes. Lock sessions to the IP they were authenticated from. None of these break legitimate workflows. All of them shorten the window during which a hijacked session can do damage.

Gap 9: Profile and Role Hierarchy Sprawl

Profiles get cloned. Roles get added. Neither gets retired. After three years, a 150-user org can have 40 profiles and 60 roles, most of which were created for a specific user who has since left or changed roles. The security implication is harder to see than the operational mess: sharing rules and OWD calculations depend on the role hierarchy. A messy hierarchy creates unintended sharing patterns that auditors flag.

Pull the profile and role lists. Mark every entry with the user count assigned. Profiles or roles with zero or one assignment are candidates for consolidation. Map the hierarchy on a whiteboard and compare it to your current organizational chart. Where the two diverge, the hierarchy needs to catch up.

Gap 10: Health Check Score Not Monitored

Salesforce ships with a built-in Security Health Check tool in Setup. It scores your org against a baseline of recommended security settings — password policies, session settings, certificate management, and more. The score is visible. The score also tends to drift downward over time as edge cases are granted and never revoked. Most orgs run Health Check once at launch and never again.

Add Health Check to a monthly admin checklist. A 15-minute review catches drift early. A quarterly comparison against the previous quarter surfaces patterns that one-time audits miss. Salesforce’s official Data Security Trailhead module walks through the scoring model.

What Security Auditors Look For (and Why It’s Not the Same as Compliance)

Compliance frameworks — SOC2, HIPAA, ISO 27001, PCI-DSS — test that your org meets a defined baseline. Auditors look for something subtly different: whether the org is configured securely beyond the framework’s minimum. An org can pass a SOC2 audit on paper while still having configuration drift that a penetration test would surface in 30 minutes. The two are not the same exercise, even though most teams treat them as one.

The most common pattern: compliance audits check policy documentation, sample 5-10 users for access reviews, and confirm the audit trail is enabled. Security audits go further. They look at the effective permissions of every user (not just sample), the actual contents of the audit trail (not just whether it’s enabled), the integration auth methods, the IP restriction configurations, and the gaps between documented policy and live configuration. An auditor with Salesforce-specific experience will find drift the compliance checklist misses.

If your next audit is compliance-driven, run a Salesforce-specific security review 60-90 days beforehand. The two exercises feed each other: the security review finds the configuration gaps, you fix them before the formal audit, and the formal audit finds clean documentation. Skipping the security review and going straight to compliance means cleanup happens under audit pressure with the auditor watching every change.

How to Document Your Salesforce Security Baseline for SOC2/HIPAA

Documentation is the part of security audits that catches the most teams off guard. Auditors do not just want to see that controls exist — they want documented evidence that controls are reviewed on a defined cadence, that changes are logged with justification, and that exceptions are explicitly approved. A Salesforce security baseline document is what makes this evidence repeatable instead of reinvented for every audit.

A working baseline document captures the configured values for each of the 10 gaps from earlier in this post — MFA enforcement scope, permission set inventory and review date, FLS and report folder mapping, audit trail retention, IP restriction ranges, integration auth methods, encryption scope, session settings, profile and role inventory, and Health Check score history. For each, the document records the current state, the review cadence (monthly, quarterly, annually), the approval authority for changes, and the last review date. The same document is the security narrative auditors ask for — and the working tool the admin team uses to track drift.

The orgs that survive audits with the least pain run the baseline document as a living artifact, not a pre-audit scramble. A 30-minute quarterly review beats a two-week pre-audit cleanup every time. If your team does not have a Salesforce security baseline document yet, a free 90-minute Salesforce audit is a starting point — the output is the first draft of the baseline document, not a generic findings list.

Configuration Drift Is the Real Threat

The Salesforce platform is secure by design. The configurations on top of it are secure on day one and drift from there. Every “temporary” exception that becomes permanent, every permission set added without removing the old one, every integration shipped on password auth because OAuth would have delayed the launch — they all stack up. The orgs that survive audits cleanly are not running fundamentally different Salesforce. They are running cleaner configurations of the same Salesforce.

If even three of these gaps sound familiar in your org, that is the starting list for a productive 90-minute conversation. You can book a free 90-minute Salesforce audit and walk out with a written findings list — not a sales pitch.