How Do I Ensure My Salesforce Org is Secure?

Your org has been live for three years, three admins have touched it, a handful of AppExchange packages got installed and half-forgotten, and nobody has looked at the Health Check score since the initial implementation. Nothing feels obviously broken, until a departed contractor’s login still works, or a Permission Set from 2023 quietly grants “Modify All Data” to half the sales team. If you’re asking how do I ensure my org is secure, the honest answer is that Salesforce security isn’t one setting you turn on. It’s a handful of areas that each degrade quietly over time unless someone checks them on a schedule. This guide walks through the six areas that matter most, in the order we check them during an org review.

Most Salesforce security incidents aren’t sophisticated attacks. They’re stale permissions nobody remembered to clean up.

1. Login and Identity Controls

This is the front door, and it’s the first thing worth locking down completely. Multi-Factor Authentication has been a Salesforce-enforced requirement for direct UI logins for several years now, but it’s worth verifying it’s actually applied consistently. This matters especially for any users who log in through SSO, where MFA enforcement can live on the identity provider side instead and get missed during setup.

Fix: Under Setup → Identity → Login History, review recent logins for unfamiliar IP ranges or unusual login times. Confirm MFA status under Setup → Session Settings. If you’re on SSO, verify enforcement lives with your identity provider, such as Okta or Entra ID, rather than assuming Salesforce is covering it. Consider Login IP Ranges or Trusted IP Ranges on Profiles for any users who should only ever be accessing from a known network.

2. Least-Privilege Access: Profiles, Permission Sets, and Roles

This is the area that degrades the fastest, because access almost always gets added during day-to-day support tickets and almost never gets removed afterward. A user who needed temporary “Modify All Data” access for a data cleanup project two years ago is often still carrying it today.

Fix: Pull a report of all Permission Set assignments and Profile-level “View All” or “Modify All” grants, and compare it against who currently needs that level of access. As a general rule, Profiles should carry the minimum baseline for a job function, and Permission Sets should layer on anything role-specific, not the reverse. Consequently, if you find yourself cloning Profiles repeatedly to handle small access variations, that’s usually a sign the access model needs a Permission Set Group cleanup rather than another Profile.

3. Field- and Record-Level Security

Object-level access is the first layer most admins check. Field-level and record-level security is where sensitive data actually leaks. Social Security Numbers, donor giving history, salary fields, or health information can be fully exposed on a page layout even when the object itself is properly restricted, if Field-Level Security was never set on that specific field.

Fix: For any field holding sensitive data, explicitly set Field-Level Security per Profile rather than relying on page layout visibility alone. Page layout hides a field from the UI, but Field-Level Security actually restricts access at the data level, including through reports and the API. Pair this with Sharing Rules and Organization-Wide Defaults set to the most restrictive reasonable baseline, opening up access with Sharing Rules rather than starting from a fully open default.

4. Connected Apps and API Access

Every integration, every AppExchange package, and every “connect this to Zapier real quick” moment creates a Connected App with its own OAuth scopes and API access. Unfortunately, these accumulate silently, and nobody audits them until something breaks, or until a security review asks what has API access to the org and nobody has a confident answer.

Fix: Under Setup → Apps → Connected Apps OAuth Usage, review every connected app currently authorized, when it was last used, and what scopes it holds. Anything unused in the last 90 days is a candidate for revocation. For anything still active, confirm the OAuth scopes granted are actually necessary. A marketing tool that only needs to read Contact records shouldn’t be holding a scope that lets it modify Opportunities.

5. Ongoing Monitoring

Security work almost always gets front-loaded at implementation and then never revisited, which means an org that was secure at go-live can drift for years without anyone noticing. Salesforce gives you the tools to monitor this on an ongoing basis. The gap is usually process, not tooling.

Fix: Check the Security Health Check score under Setup → Security → Health Check on a recurring schedule, quarterly at minimum, rather than only at go-live. For orgs with Shield or Event Monitoring, set up alerts for high-risk events like bulk data exports or mass permission changes. Even without Shield, Login History and Setup Audit Trail give a baseline view of who changed what and when. This is exactly the kind of drift a Cloud Nexus org review is built to catch before it becomes an incident.

6. Offboarding: The Step Everyone Underestimates

This is the single most common finding in a Salesforce security review, and it’s also the simplest to fix. An employee leaves, HR processes the termination, IT disables their email, and their Salesforce user sits active for weeks or months afterward with a fully functional login and, in some cases, active API tokens still valid.

Fix: Deactivation should happen the same day as departure, not during the next admin’s routine cleanup. If you’re managing this manually, build a simple offboarding checklist that includes freezing the user, deactivating the account, and revoking any personal API tokens or Connected App authorizations tied to that user. For organizations with regular turnover, connecting user lifecycle to your identity provider through SSO and SCIM removes this risk almost entirely by automating deactivation the moment someone leaves the directory.

A Quarterly Security Checklist

Frequently Asked Questions

Does enabling MFA alone make my org secure?

No. MFA closes off one of the most common attack paths, credential theft, but it doesn’t address over-permissioned users, exposed sensitive fields, unused Connected Apps, or stale accounts from former employees. Treat it as one item on the checklist, not the whole checklist.

Do I need Salesforce Shield to be secure?

No. Shield, which covers Event Monitoring, Field Audit Trail, and Platform Encryption, adds deeper visibility and is worth it for regulated industries or larger orgs handling sensitive data, but the six areas above are all achievable with standard Salesforce features. Shield makes monitoring easier and more granular. It doesn’t replace the underlying access and offboarding discipline.

How often should I actually run a security review?

Quarterly is a reasonable baseline for most orgs, with offboarding checks happening in real time as people leave rather than on a schedule. Organizations with frequent turnover, sensitive data such as donor records, health information, or financial data, or a history of ad hoc access grants should lean toward monthly reviews of at least the access and login areas.

What’s the fastest way to find out how exposed my org currently is?

Start with the built-in Security Health Check score under Setup. It flags the most common misconfigurations automatically and gives you a prioritized starting point in a few minutes, before you go section by section through the checklist above.