How to keep a Salesforce org secure as your team scales

Short answer: Salesforce orgs almost never become insecure because someone attacked them. They become insecure because permissions accumulate faster than anyone removes them, and because integration users are handed far more access than the integration needs. Both problems are silent, both scale with headcount, and both are fixed by design decisions rather than by security products.

What actually degrades Salesforce security as a team grows?

Two mechanisms, and neither of them looks like a breach on the day it happens.

• Permission sprawl. Access is granted as a series of exceptions. Someone needs a report on Friday, gets a permission set, and keeps it for three years. Multiply by every hire, every project, every leaver whose access was never reclaimed.
• Over-privileged integration users. The middleware needs to write to two objects, so it gets a System Administrator profile because that is the fastest way to make the sync work.

Both are additive by nature. Nothing in the platform removes access on its own. That asymmetry, easy to grant and nobody's job to revoke, is the entire story of how a well-designed org becomes an audit problem in two years.

Why does permission sprawl happen even in disciplined teams?

Because the fast path and the correct path point in different directions:

• Cloning is easier than modelling. Cloning a profile takes a minute and creating a proper permission set group takes an afternoon, so orgs end up with dozens of near-identical profiles nobody dares consolidate.
• Temporary access has no expiry. Salesforce will not take it back for you, and no ticket exists to remind anyone.
• Nobody owns removal. Grants have a requester. Revocations have nobody, which is why access reviews get scheduled and then quietly skipped.
• Sensitive permissions hide in aggregate. Two harmless permission sets can combine into an ability neither was meant to grant.

What permission model survives headcount growth?

The model that scales is boring and well documented. What matters is committing to it before you have 200 users, not after.

1. Minimal base profile. Give the profile only what every user in that licence type needs. No object access that belongs to a job function.
2. Permission sets for capabilities, not for people. A permission set should describe a task, so its name should survive the person who first needed it.
3. Permission set groups for roles, with muting where a group grants slightly too much. This is the mechanism that lets you assemble a role without cloning yet another profile.
4. Automate assignment with User Access Policies so joiners and movers get access from criteria rather than from memory.
5. Keep the dangerous permissions on a named list. Modify All Data, View All Data, API Enabled, export and Manage Users deserve an owner and a written justification per holder. If that list is longer than your leadership team, you have found your first project.

Salesforce Ben's walkthrough of least privilege is a good companion if you want the click-level detail. The design decision above is the part that has to come from you.

Why are integration users the biggest blind spot?

Because they are invisible in every conversation about security. They do not attend onboarding, they never leave the company, and nobody reviews them when a project ends. Meanwhile they typically hold broader data access than any human in the org and they authenticate without MFA prompts.

Four rules that hold up as the integration count grows:

• One integration user per integration. Shared integration users make it impossible to answer who wrote a record, and impossible to revoke one system without breaking another.
• Use the API-only integration licence where you can. Salesforce provides five free Salesforce Integration licences on Enterprise, Unlimited and Performance editions, with no UI access at all, which removes an entire class of misuse.
• Scope to objects and fields, not to profiles. Write down what the integration is allowed to touch and enforce it with a permission set built for that integration alone.
• Restrict by IP and monitor the volume. An integration user's behaviour is predictable, which means anomalies in it are unusually meaningful compared with human activity.

Which controls actually survive scale?

These are the ones that keep working when the team doubles, ordered by how much they repay the effort:

1. Deploy permissions through the pipeline, not by hand in production. If access changes are in version control, every grant has an author, a review and a date. This one control makes the next four possible.
2. Run a recurring access review with a named owner and a fixed agenda: the dangerous-permission list, integration users, and anyone whose role changed last quarter.
3. Set an expiry convention for exception access, even if you have to enforce it with a calendar reminder. Access with no end date is permanent access.
4. Track Health Check and Setup Audit Trail as a trend, not as a screenshot before an audit.
5. Include permissions in code review. A profile or permission set diff belongs under the same scrutiny as Apex, because it can do more damage faster.

How do you know it is working?

Pick metrics that go down. Count the holders of each dangerous permission. Count permissions granted outside a permission set group. Count integration users with UI access. Count profiles. If those four numbers are not falling quarter on quarter, your security posture is drifting even if nothing has gone wrong yet.

FAQ

Are profiles deprecated in Salesforce?

No, and you still need one per user. The practical guidance is to keep profiles minimal and to express everything role-specific through permission sets and permission set groups.

How often should access be reviewed?

Quarterly for dangerous permissions and integration users, and immediately on any role change or departure. An annual review is an audit exercise, not a control.

Do integration users need MFA?

API-only integration users authenticate system to system, so the meaningful controls are IP restrictions, scoped permissions and monitoring rather than an MFA prompt no human will ever see.

Is this a security tooling problem?

Tools help you see the sprawl. They do not decide who should have access. The decisions are architectural, which is why the fix belongs in your delivery process rather than in a product purchase.

We build on Salesforce as a certified SI, ISV and PDO, and we have taken packages through AppExchange security review in healthcare, logistics and manufacturing, so the permission model is something we design rather than inherit. If your org has grown faster than its access model, talk to us.