How to run a Salesforce security review: beyond the Health Check score

Ask most admins whether their org is secure and they’ll quote a number: “We’re at 88% on Health Check.” It sounds authoritative. It’s a green dial on a Setup page, produced by Salesforce itself, and improving it feels like progress. The trouble is what that number doesn’t know. Health Check has no opinion about the seventeen people holding Modify All Data, the integration user running on a System Administrator profile with a password that hasn’t rotated since 2021, or the permission sets nobody has reviewed since the person who created them left.

We see this pattern in most orgs we assess: strong Health Check score, weak actual posture. The score measures configuration settings against a baseline. A security review measures who can do what, through which doors, and whether anyone would notice misuse. Those are different questions, and the second one is the one an auditor — or an attacker — actually asks.

This post walks through what a genuine Salesforce security review covers: what the Health Check score does and doesn’t measure, how to unwind permission sprawl now that profiles are on their way out, why integration users are usually the most over-privileged accounts in the org, where session and MFA settings really stand, when Shield is worth paying for, and the sequence we recommend running every quarter.

What your Health Check score measures — and what it never sees

Security Health Check lives in Setup and grades your org’s security settings from 0 to 100 against the Salesforce Baseline Standard. Password policies, session settings, network access, certificate expiry — each setting is compared to a recommended value and weighted by risk category: high-risk settings move the score most, low-risk settings least, and informational settings don’t count at all. If you operate under stricter requirements than the default baseline, you can import a custom baseline and grade against that instead.

Used properly, it’s genuinely useful. It’s free, it’s instant, and it catches the embarrassing stuff: minimum password length of five, sessions that never time out, clickjack protection switched off. Run it first in every review. Just be careful with the Fix Risks button — it changes settings in bulk to the recommended values, and Salesforce’s own training warns that doing so can break integrations or lock users out. Adjust settings one at a time and test in a sandbox first.

The blind spots

Here’s the uncomfortable part. Health Check evaluates org-wide settings. It does not evaluate access. The difference matters more than the score:

Health Check grades	Health Check ignores
Password policies	Who holds Modify All Data / View All Data
Session timeout and security settings	Profile and permission set assignments
Network access and login IP settings	Sharing model and org-wide defaults
Clickjack, CSP, and browser protections	Apex code vulnerabilities (SOQL injection, missing FLS checks)
Certificate and key expiry	Guest user and Experience Cloud site access
File upload and download security	Connected apps and OAuth scopes
—	Dormant users, stale integrations, unmonitored logins

An org can score 95% while every sales rep can export the entire customer database, because the sharing model isn’t a “setting” Health Check knows about. Guest user access — the source of several well-publicised Salesforce data exposures — never touches the score either. Neither does a single line of your Apex. Treat the score as the entry ticket to a security review, not the result of one.

Permission sprawl: auditing access in the twilight of profiles

The centre of gravity of any real review is permissions, and the ground has shifted here. Salesforce announced in 2023 that permissions on profiles would reach end of life with the Spring ‘26 release, then walked the deadline back — the date is no longer enforced, but the product team has been clear that all permissions investment is going into permission sets and permission set groups. As of early 2026 your profile permissions still work. Strategically, they’re legacy.

The recommended target model is simple to state: profiles shrink to the things only profiles can do — login hours, IP ranges, default apps, record types, page layout assignment — and every actual permission moves to permission sets, bundled into permission set groups per persona. In practice, the migration is where sprawl gets exposed. Years of “just clone the profile and tweak it” leaves orgs with dozens of near-identical profiles, hundreds of permission sets, and no one who can answer the auditor’s first question: who can modify all data, and why?

That question, at least, is answerable in one query. Every profile is backed by an underlying permission set, so PermissionSetAssignment covers both worlds at once:

SELECT Assignee.Name, PermissionSet.Label, PermissionSet.IsOwnedByProfile
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsModifyAllData = true
   OR PermissionSet.PermissionsViewAllData = true
ORDER BY Assignee.Name

Run the same query for PermissionsAuthorApex, PermissionsCustomizeApplication, and PermissionsManageUsers. The output is your review’s hit list. In most orgs the list is three to five times longer than anyone expected, and the remediation pattern is always the same:

• Shrink the admin circle. System Administrator and the “modify all” family should belong to a handful of named people. Everyone who got admin to close a ticket in 2023 comes off the list.
• Kill zombie permission sets. Anything unassigned for a year, or assigned only to deactivated users, gets archived. Fewer artefacts, smaller audit surface.
• Rebuild by job function, not by person. Small, single-purpose permission sets (“Manage Campaigns”, “Export Reports”) composed into permission set groups per role — with muting where a group over-grants.
• Check the automations too. Flows and Apex running in system context can quietly bypass everything your permission model says. Sharing settings and WITH USER_MODE in code are part of the permissions story, not a separate one.

Object and field access reviews follow the same logic one level down. Start with the objects that would hurt in a breach — anything with financial, health, or personal data — and confirm the org-wide defaults are private where they should be, with sharing rules opening access deliberately rather than defaults leaving it open by accident.

Integration users: the most over-privileged accounts in your org

If we could review only one thing in a mature org, it would be the integration users. The pattern is depressingly consistent: the middleware vendor’s install guide said “create a user with the System Administrator profile”, someone did, and five years later that credential — often a plain username and password shared across three systems — can read and write everything, from anywhere, invisibly.

Auditors flag this first for good reason. A human admin’s blast radius is limited by what a human can click. A compromised integration credential operates at API speed with no one watching. The hardening sequence:

1. One dedicated user per integration. Salesforce’s integration user guidance is explicit: a separate user for each integration limits blast radius and makes API activity traceable to a specific system. Shared credentials make incident forensics guesswork.
2. Use the Integration User license. Enterprise, Unlimited, and Performance editions include five Salesforce Integration user licenses at no extra cost. It comes with the Minimum Access – API Only Integrations profile: no UI login at all, API access only. Most orgs we see haven’t touched these free licenses.
3. Grant permissions per integration, additively. Start from minimum access and add a dedicated permission set granting exactly the objects and fields that integration touches. When a vendor asks for Modify All Data, ask them which objects they actually write to. The honest answer is usually four.
4. Authenticate like it’s 2026. Server-to-server integrations should use the OAuth 2.0 client credentials flow against a connected app — not a password and security token in a config file. For outbound callouts, named credentials and external credentials keep secrets out of Apex and put credential access behind permission sets.
5. Fence the network. API-only users with predictable source systems should have login IP ranges restricting where those credentials work from. A stolen integration password that only authenticates from your middleware’s IP block is a much smaller problem.

This is also where a review earns its keep fastest. Downgrading one admin-grade integration user does more for your real posture than ten points of Health Check score.

Session settings and MFA: the login layer auditors check next

MFA stopped being optional a while ago. It has been contractually required for all Salesforce users since February 1, 2022 — covering both direct logins and SSO — and after the auto-enablement waves through 2023 and 2024, enforcement began with Summer ‘24, making MFA a permanent part of the direct login process rather than something an admin can switch off.

The review question is therefore not “do we have MFA?” but “is our MFA any good?” Three things to verify:

• Method quality. Salesforce’s supported verification methods deliberately exclude one-time passcodes over email, SMS, or phone for internal users — they’re too easy to phish or SIM-swap. Authenticator apps qualify; for admins and anyone with high-risk permissions, push toward phishing-resistant methods — security keys and built-in authenticators like Windows Hello or Touch ID — which resist MFA-fatigue attacks that TOTP codes don’t.
• SSO coverage. If you log in through an identity provider, Salesforce doesn’t enforce MFA there — your IdP has to. Confirm the policy actually applies to every Salesforce-bound app assignment, including the “temporary” bypass group someone created for an executive.
• The exceptions list. Exempt users, legacy API integrations authenticating with passwords, and long-lived sessions are the residue every review finds. Each one needs an owner and an expiry date.

Session settings are the same story in miniature. Health Check will nudge you toward a sensible timeout; a review goes further and checks that sessions lock to the originating IP where the workforce allows it, that high-assurance sessions gate sensitive operations, and that idle timeouts aren’t set to twelve hours because a VP once complained about re-logging in.

Shield and Event Monitoring: when the paid tier is justified

Everything above uses features you already own. The next layer — knowing what users actually do — is mostly paid, and a review should be honest about when it’s worth it.

Baseline visibility comes free. The Setup Audit Trail tracks configuration changes for the past 180 days — who changed a profile, who created a user — and exporting it on a schedule costs nothing but discipline. Enterprise editions and above also get free access to a small set of event log files (login, logout, and total API usage) with one-day retention. That’s enough to spot-check, not enough to investigate an incident from three weeks ago.

The paid tier — Event Monitoring, sold standalone or as part of Salesforce Shield — extends retention, covers dozens of event types (report exports, list view reads, API queries, file downloads), and adds Real-Time Event Monitoring with transaction security policies that can block behaviour as it happens: “no one exports more than 10,000 lead records”, “flag logins from impossible geographies”.

Our rule of thumb: Shield is justified when at least one of these is true — you’re in a regulated industry where audit trails are mandated rather than nice-to-have; your org holds data whose bulk export would be a reportable breach; or you already ship logs to a SIEM and Salesforce is the blind spot. If none apply, spend the money on fixing permissions first. Monitoring an over-privileged org just gives you a detailed record of the breach.

The quarterly security review, in sequence

None of this needs to be a six-week project. Run as a quarterly cadence, each pass gets faster because the previous one shrank the mess:

1. Run Health Check and clear or consciously accept every high-risk finding. Log the exceptions with reasons.
2. Query high-risk permissions (Modify All Data, View All Data, Author Apex, Manage Users) across profiles and permission sets. Challenge every name on the list.
3. Review user hygiene: deactivate leavers, expire dormant accounts, check frozen users didn’t get quietly unfrozen.
4. Audit integration users: one per system, API-only profile, dedicated permission set, OAuth not passwords, IP-restricted.
5. Verify MFA and session posture, including SSO policy coverage and the exceptions list.
6. Check the exposure edges: guest user profiles, Experience Cloud sharing, connected app OAuth scopes, public reports and dashboards.
7. Scan the code. Apex running in system mode without CRUD/FLS enforcement undoes everything the permission model promises — our Apex security scanner catches the common patterns, and the checks mirror what Salesforce’s own reviewers look for in the AppExchange Security Review.
8. Export and archive evidence: Setup Audit Trail, login history, the permissions query output. Next quarter’s diff is your progress report.

The first pass through this list is the slow one. By the third quarter it’s a day’s work, and the org has a defensible answer to every question an auditor opens with.

A score is a snapshot; posture is a habit

The Health Check score endures because it’s legible — one number, owned by one admin, trending upward on a slide. Real security posture is less photogenic. It’s a short list of admins that stays short, integration users that can touch four objects instead of four hundred, an MFA exceptions list with expiry dates, and a quarterly rhythm that catches drift before an auditor or an attacker does.

The good news is that almost all of it is free. Permission sets, integration user licenses, OAuth flows, login IP ranges, audit trail exports — every control in this post except Shield ships with the platform you already pay for. What separates secure orgs from scored orgs isn’t budget. It’s that someone owns the review, runs the sequence, and treats “who can do what” as a question with a current, written answer. Get that habit in place and the Health Check number takes care of itself — as the least interesting line in a review you can actually stand behind.

Understanding the basics

What is a good Salesforce Health Check score?

Health Check grades your org’s security settings from 0 to 100 against the Salesforce Baseline Standard, with high-risk settings weighted most heavily. Higher is better, and clearing every high-risk finding matters more than the headline number. But the score only measures configuration settings — password policies, session settings, network access. It says nothing about permissions, sharing, code, or integration access, so a high score alone doesn’t mean the org is secure.

How often should you run a Salesforce security review?

Quarterly works for most organisations. Health Check itself is worth glancing at monthly since releases and admin changes can move settings, but the fuller review — high-risk permission queries, user hygiene, integration user audit, MFA exceptions, guest user exposure — fits a quarterly cadence. The first pass is the slowest; subsequent passes mostly diff against the previous quarter’s exported evidence.

Do integration users need their own Salesforce license?

They should get one. Enterprise, Unlimited, and Performance editions include five Salesforce Integration user licenses at no additional cost, each carrying the Minimum Access – API Only Integrations profile, which blocks UI login entirely. Give each integration its own user and a dedicated permission set granting only the objects it touches, authenticate with OAuth rather than stored passwords, and restrict login IP ranges to the calling system.

---

Staring at a Health Check score and not sure what it’s hiding? Talk to us — security reviews are part of what we do.